First thing to take care of, is if you have the old pcap on Windows running around. If you have it, you’ll know as you’ll get spammed with “FATAL Bad Memory Block.”, although things will continue to operate just fine.
Win10Pcap!
C:\dynamips\netware\qemu-0.90-pcap-client>qemu -m 16 -L pc-bios -M isapc -hda client.disk -soundhw sb16,adlib -net nic,macaddr=52:24:00:22:00:01 -net pcap,devicename={BFA868ED-E508-4436-B085-EC815C4C544C}
Eth: opened {BFA868ED-E508-4436-B085-EC815C4C544C}
Could not open '\\.\kqemu' - QEMU acceleration layer not activated
FATAL Bad Memory Block.
FATAL Bad Memory Block.
FATAL Bad Memory Block.
FATAL Bad Memory Block.
So be sure to dump that for the one over on npcap!
The old times, actually running Netware 3.12
There was a time when Windows NT didn’t dominate the 1990’s data centre. Instead as a carryover from the 1980’s the majority of corporate LANS were instead based on Netware. And the only way Windows NT was going to make space in this environment was to dress up in sheep’s clothes and mingle among them unnoticed. That brings us to this GEM:
Services for NetWare
This fun CD will let our NT 4.0 server emulate a NetWare server! The first thing in one of these stealth migrations was to just join the existing network.
The existing network is 0C0FFCAB
In order to do this, the two bits of information we need is the frame type, since NetWare supports so many, and the network address. In this case its 0C0FFCAB.
default IPX is no good
By default the NT server will just listen to the network, and participate on what it sees. This is fine if you are just playing along as a dynamic node, but being a NetWare node requires you to step it up, and have these values set, as it is very possible that you could be the first one (or only one) live on the network, and you don’t want clients trying to think on their own.
I also gave mine an internal network number of 1381, because you know, it’s NT 4.0.
To add the FPNW, you need to add it as a new service. Just tell it you have a disk
You’ll then have to point it to the path of the install. This is honestly the hardest part.
Selecting the first option will install the NetWare Server emulation on the NT server.
I went ahead and named my NetWare emulation as SHEEP, as I NT to blend into the existing NetWare network, with nobody being the wiser.
indeed, on our client that was already connected to the Qemu server before I built WOLF, I ran an slist command to show all the servers on the network, and there is my Wolf in Sheep’s clothes.
Creating NetWare compatible volumes is done in the Server Manager, under the FPNW option. It’s pretty self explanatory, nothing too exciting there.
The truth is during the period where this was important the NT 3.51-40 timeframe, NetWare was still a dominant force. But once Windows 95 had launched, and the explosion of people wanting MORE, the natural interest of people going to NT was just amazing to see in corporate space. While there was an early beta of the newshell for NT 3.51, when NT 4.0 shipped it was just amazing as all the reservations for running NT had just evaporated. We’d gone from hiding among the sheep to full on eating them all. It was staggering how fast we were backing up NetWare volumes to only re-format the servers to NT, and get people converted to using them. Before NT 4, the consensus was that rolling out the client config was going to be a nightmare, and that being able to emulate NetWare was the way to go, as it would just work (see the MS-DOS VM talking to NT with an unmodified NetWare client). Instead we saw a massive drive to Windows 95, which ended up changing the client landscape and upending NetWare completly.
About the most difficult thing was user mappings, there was tools to do this kind of thing, and I believe we had something to even proxy passwords, but it was easier to make people just login to the NT side.
Of course this is ONE of the emulators, you might be asking, okay, what is the other?
Why, it’s WINDOWS 95.
YES.
I’m joining the NT domain for the full experence, but the NetWare emulation relies on NetWare servers for authentication. You could use an actual NetWare server, or of course a FPNW server.
Adding file and printer sharing for NetWare workgroups under Windows 95 is done by adding a Service to the network stack. It’s even on the floppy version.
To maximize the functionality and the pain, be sure to turn on SAP Advertising. This way it’ll appear in server lists.
SAP on!
So with all of this in place, yes you can map drives from the MS-DOS client to the Windows 95 workstation acting as a server.
Mapping a drive on 95, authenticated by the WOLF hiding as a SHEEP
And there we go, I can now see the Windows 95 workstation on the SLIST, and connect and map drives. My user account of course exists on the NT side.
While professionally I didn’t rely too much on this feature, but it was nice in that era where you still had MS-DOS/MacOS/OS2 desktops with NetWare clients to quickly share stuff. But in a large organisation this would lead to major issues.
The fundamental flaw in NetWare is that there is no directory service. Instead, all the servers have to broadcast that they exist, along with what services they provide.
On my tiny demo network this isn’t that much traffic. But on a larger network that spans continents this becomes a problem. With thousands of servers there can be an incredible amount of this SAP announcement traffic. Since there is no directory service, the other problem is that when a new client is booted up, it’ll do what is known as a GNS or Get Nearest Server request in order to find the closest server to attach to, in order to facilitate a login. And EVERY server will reply.
And as you can see some servers even will reply more than once. And this can have other effects where people reboot servers during the day, something that is very natural for a Windows 95 user, which could create issues for other users, even forcing them to reboot! And yes, anecdotally I ran into this so many times where people with laptops with this feature turned on, and they would screw up the local office building (impacting hundreds of people). Even when they weren’t winning the GNS elections.they are still generating extra traffic, and occasionally they will win. This was another problem we had with all these wolves hiding in sheep’s clothing.
In the end, NetWare was utterly removed from the data center’s by the end of 1997. Windows NT just scaled too well for SMP and large disks (I had one server with 1TB! It was using 4GB disks it was massive!), along with being able to easily install stuff like SQL Server & SNA Server, unlike NetWare where any NLM conflict will bring the entire thing down. Not having a name lookup server was a giant pain, but the final nail was also in 1997 with the rise of the internet, and normal people now getting involved the entire LAN/WAN was going TCP/IP, where it had only been a fringe protocol used for managing cisco routers, and tftp/ftp some files around, Windows NT’s ability to encapsulate named pipes, and NETBIOS over TCP/IP let them embrace this new world where the TCP/IP stack on NetWare 3.12/4.11 was only good for sending SNMP alerts.
But don’t cry for NetWare, they made so much money they were able to coast for decades before being bought out in 2010 by a Mainframe Terminal Emulation company of all things, The Attachmate Group, who was later in turn bought out by Micro Focus, a COBOL language company. I guess in the end, the Mainframes won?
So I have been fighting the Mainframe thing for a while (see part1/part2) and getting nowhere. I couldn’t shake the feeling that it was working, but something on the mainframe side was broken. I just don’t know enough about MVS/VTAM on the host side. Although I have setup and deployed quite a few cisco routers in production doing remote ring groups, translational bridges, and the like, a DLSw connection to SDLC was something I’d never done as I’d always had direct token-ring access to the FrontEndProcessor.
On suspicion that I’ve been talking to the mainframe the whole time is that in the packet trace from Microsoft SNA server I’d see the string UNSUPPORTED FUNCTION in the capture.
The LU goes online, but there just isn’t anything to be displayed. Traffic is constantly flowing but it’s always the same, a blank dead screen.
On a fluke I had spotted a copy of Attachmate Extra! 4.20 on eBay for $10. I was able to get someone to get it for me, and fence me a copy of the disks. Configuring Extra isn’t too involved, just set the terminal to type 4, and using the same block/destination address as all the others:
LU #3, and Model 4!
With the usual restricted I-Frame (MTU), and I turned everything on feature wise (it didn’t matter)
I had fired up both OS/2 & NT and with the same empty screen showing nothing. Next I loaded up Extra on Windows 95, and got this:
Unsupported Function
Well that was unexpected!
The 3705’s on Hercules can be connected to direclty, so I try c3270 and get this:
Wait, so my suspicion was right?!
I reset the mainframe, and then was greeted with the cat!
Finally!
So what was wrong?!? I’m still not so sure, but turning off the debug on DLSw, let me see that both OS/2 AND Windows NT crash out SNASOL with an abend code of U0020.
I’m sure it means something to someone, but not to me. So this is one of those ‘dont do that if it hurts’ type things.
Since I had used Windows 95, as I figured it had more robust networking support than Windows 3.1
Setting up Windows 95 was a minor challenge as Extra! 4 is a Win16 application, and it’s DLC/802.2 support requires you to knock down the 32bit networking support to instead use the 16bit networking drivers. This is what let Extra! attach to it. Of course the following updates/files are needed for Windows 95 on Qemu:
the AMD PCnet driver is built in, so it works the best. Again, I have Dynamips & Qemu using the Microsoft Loopback as their common network, so I can do packet captures, and they both can communicate on the network.
So, of course the other question is, does it work with physical hardware?!
And YES it does!
If anything, using a terminal emulator that doesn’t crash out the host makes it seem all too easy. While I’ve seen SDLC PCI cards on ebay they are rather expensive, and does the ISA card really add anything that you could get over the LAN? Honestly no. Back in the day it really was just what you could get a hold of, and of course logically (virtually) setting stuff up made the 802.2 stuff all the easier to do, instead of leased lines, physical v35 cables, and all that other fun stuff.
With everything said & done, if you want to experience some pseudo fake SNA, go virtual. It’s far more portable, less cables involved, plus it’s self-contained making it more of a conversation piece.
All the hard work is being done by IOS, and it’s functionality like this is why cisco had established itself as king of the multiprotocol networking world. But everything is TCP/IP these days, and Cisco doesn’t commend the same enterprise place as it had once before, making this whole thing a middle point relic of the past. It’s far too new for real FEP/DLC networking, but everything now is TN32720 (telnet 3270).
I guess as a tip for people who buy physical routers is that those super expensive PCMCIA flash cards aren’t needed as long as you have enough RAM. One cool feature of the cisco routers is that the power on bootrom loads up a ‘boot’ version of IOS that is either also burned on ROM, or it’s also in FLASH. You have to remember it was super expensive back then so it may be only a few megabytes of space. The boot IOS can’t route or do anything too useful but it can load the proper IOS from various network sources into memory. My 7200 has one that supports FTP, so I could just drop IOS onto an anonymous ftp server at home.
I guess my ‘old man yells at the clouds’ is that I’ve had to deal with some bug in a remote site where the router didn’t have enough flash to store the image, and the Ethernet cards were too new for the boot IOS to drive, but we had an async card that did work, so I rebooted it to load production IOS over a T1. This one didn’t support FTP, rather it was TFTP, and it took about an hour to load. During that much time I didn’t have console access so I was getting ready to drive the 5 hours to the site, when I barely got onto the highway when I got the call that my ‘fix’ had worked and that the site was online. YAY.
Well today was a special day, I got 2 deliveries, one PC SDLC card, and the other being the 4 port high speed serial card for my cisco 7200.
In case you were wondering what was the serial cable, its a CAB-232FC FEM DCE RS-232 cable looks like here is the DB-60 connector side:
And here is the DB-25 side.
VERY RS-232 isn’t it?
Connect the cable to the to the router! Easy!
The router doesn’t have any PCMCIA storage so I configured the thing to get it’s IOS from a FTP server.I have to say that netbooting works great.
Slot the card into the board I found in the trash that has an ISA slot, and we’re off to the races! I wanted try to replicate my NT setup, so Server 3.5 was installing when of course:
Of course this 400Mhz Celeron is going to break the lookup list as anything beyond Pentium is too much. 🙁 I just installed on Qemu instead, and used MS-DOS backup/restore. Yes it worked!
On the SNA server install, I used the IBM SDLC option hoping it was this card I’d bought. I got lucky it was!
Just like 9track.net I kept it ‘leased’ and no constant RTS.
One thing to note about this SDLC card is that it takes IRQ 4 & DMA 1. So there goes any hope of a Sound Blaster or COM1. It’s not the end of the world.
And of course, I got the exact same result as last time.
I don’t know what I’m doing wrong.
I can see the serial interface up and passing traffic, and the DLSW circuit builds and is established.
I’ll either edit this with more details, or just follow up. I’m tired, and my eyes are blurry. But I thought I’d post this much to the world.
I’m not sure if I covered the Windows NT 3.1 build 196 before. First the most obvious is that as of this moment it’s the earliest version of Windows NT available.
So let’s do some obligatory scratch of the surface. Like all the other 1991 pre-releases there really is just a text mode setup install script. Choosing the lesser amount of pain, I went with a MS-DOS hosted install. However, using MS-DOS 6.22 resulted in a broken dual boot system. But we live in the era of virtual machines, so it really doesn’t matter. I’m using Qemu 0.14-rc2, something that is ‘era correct’ for when the first avalanche broke on early Windows NT pre-releases. I’ve had issues with more modern versions of Qemu, and I felt that if we’re using vintage software may as well go in all the way.
The boot loader identifies itself as being 1990 vintage. Pretty sure it doesn’t mean anything, but we haven’t been blessed with the “blue screen” of ARC yet.
The login screen and desktop have a very strong Windows 3.1 beta feel to them. And that would land this where it was, Windows was such a big seller that Maritz had been trying to convince Gates & Balmer to ‘switch to the Windows horse’ in the spring/summer of 1990, culminating in Gate’s July decision to walk away from NT/OS2 and rebrand the new OS as Windows NT. Oddly enough it was Balmer who was in favour of OS/2 & IBM. (Showstopper 89-90)
At first glance the opening window isn’t all that interesting. It’s just very. Windows.
Rest assured Reversi, of course made the this Win32 cut. And it’s full of weird easter eggs, oddly enough in the OS/2 surviving bits.
type OS2LDR.DOS
OS2LDR 01.00.01
by KeithMo 01/08/91
On the Discord there had been a big discussion about early NT executable formats, and the whole COFF vs ECOFF vs PE/PEI. I had tried to hunt down the specific version of GCC I used ages to to build a so called Dec Alpha GCC cross compiler, but the short version is that it didn’t work as we don’t have any assembler/linker for anything GNU targets. There had been a cygwin port andanOpenNT on Alpha, but all that is lost to the winds, minus what few scraps I had saved. I did try building some cross tools to elf hoping to just objcopy out the data and get linkable objects, but that didn’t work either.
So I though this was a perfect opportunity to take a look at this early pre-release version of NT, and although I do know that you have to convert your objects into something the ‘COFF’ linker will accept:
And I never really paid that much attention to the object files. I do know that you can link them with Link386 for OS/2, but the NT object files themselves report:
wsl file SIMPLE.OBJ
SIMPLE.OBJ: Intel 80386 COFF object file, not stripped, 4 sections, symbol offset=0x102, 20 symbols, created Thu Jun 1 14:13:50 2023, 1st section name ".text"
Well, now that is interesting. And of course the COFF thing reminded me of Xenix! And sure enough ages ago I had found the source to a modified version of GNU GAS that outputs COFF. Once more again this is an indication that all 386 roads in Microsoft really did originate with Xenix. It’s too bad there never was a Windows/386 on Xenix/386. What an incredible OS that would have been! There must be some incredible stories from the tool teams that worked on Microsoft C/386 along with other projects. Oddly enough they never get anywhere near as much exposure as Office or OS.
Now this is fun, but nothing takes in these ancient COFF objects, do they? I tried to run LINK 1.0 from Win32s SDK and surprisingly it didn’t complain about the object, rather, it auto converted it in memory:
Microsoft (R) 32-Bit Executable Linker Version 1.00
Copyright (C) Microsoft Corp 1992-93. All rights reserved.
SIMPLE.OBJ : warning LNK4016: unresolved external symbol "__chkstk"
LINK : warning LNK4016: unresolved external symbol "_mainCRTStartup"
SIMPLE.OBJ : warning LNK4016: unresolved external symbol "_printf"
SIMPLE.exe : error LNK1120: 3 unresolved externals
Does this mean that if I give it some libraries it will actually link?
LINK.EXE SIMPLE.OBJ /SUBSYSTEM:CONSOLE /MACHINE:i386 -entry:mainCRTStartup -out:simple.exe libc.lib kernel32.lib
Microsoft (R) 32-Bit Executable Linker Version 1.00
Copyright (C) Microsoft Corp 1992-93. All rights reserved.
C:\temp\nt196\x\dec\x>simple
Win32, it's happenin'!
This was. VERY unexpected.
So I had this crazy idea, what if the Xenix assembler could in fact build objects that are also compaible in this manner? I used the a.out GCC / Linux porting tools I had built so I could compile Linux on Windows NT using the vintage tools as a starting point. I guess I should also add that when people always say ‘use newer version of THING’ this is how you miss out on old stuff like this. If I had been obsessed with using modern tools and modern operating systems, I’d have missed out on this Xenix filled window.
I took the gcc driver & the cc1 compiler from 1.40 and the c pre-processor from 2.5.8 as it can understand C++ comments. First I manually compiled the ‘simple’ example to assembly:
gcc -v -nostdinc -I/xenixnt/h -S SIMPLE.c -O simple.S
gcc version 1.40
cpp -nostdinc -v -I/xenixnt/h -undef -D__GNUC__ -Dunix -Di386 -D__unix__ -D__i386__ -D__OPTIMIZE__ SIMPLE.c C:/Users/jsteve/AppData/Local/Temp/cca2_048.cpp
GNU CPP version 2.5.8 (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
/xenixnt/h
End of search list.
cc1 C:/Users/jsteve/AppData/Local/Temp/cca2_048.cpp -quiet -dumpbase SIMPLE.c -O -version -o SIMPLE.s
GNU C version 1.40 (80386, BSD syntax) compiled by GNU C version 5.1.0.
default target switches: -m80387
cpp -nostdinc -v -I/xenixnt/h -undef -D__GNUC__ -$ -Dunix -Di386 -D__unix__ -D__i386__ -D__OPTIMIZE__ simple.S C:/Users/jsteve/AppData/Local/Temp/cca2_048.s
GNU CPP version 2.5.8 (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
/xenixnt/h
End of search list.
C:\temp\nt196\files\MSTOOLS\SAMPLES\SIMPLE>ax386 SIMPLE.s -o SIMPLE.obj
C:\temp\nt196\files\MSTOOLS\SAMPLES\SIMPLE>wsl file SIMPLE.obj
SIMPLE.obj: 8086 relocatable (Microsoft), "SIMPLE.c", 1st record data length 10, 2nd record type 0x88, 2nd record data length 11
Not quite the same. But it does closer resemble the output from the OS/2 bound versions of the Pre-Rease compilers:
file EMPTY.OBJ
EMPTY.OBJ: 8086 relocatable (Microsoft), "empty.c", 1st record data length 9, 2nd record type 0x88, 2nd record data length 7
So will it link?!
C:\temp\nt196\files\MSTOOLS\SAMPLES\SIMPLE>LINK.EXE SIMPLE.OBJ /SUBSYSTEM:CONSOLE /MACHINE:i386 -entry:mainCRTStartup -out:simple.exe libc.lib kernel32.lib
Microsoft (R) 32-Bit Incremental Linker Version 2.50
Copyright (C) Microsoft Corp 1992-94. All rights reserved.
SIMPLE.OBJ : warning LNK4033: converting object format from OMF to COFF
C:\temp\nt196\files\MSTOOLS\SAMPLES\SIMPLE>simple
Win32, it's happenin'!
Well now this is interesting! LONG before MinGW, or the GCC port to Windows NT, it turns out that in fact GCC could target Windows NT the entire time!
So the next thing to do is something not as trivial, like phoon.
I setup some quick script to pre-process, compile, assemble and then try to link, but as this one uses floating point, disaster struck:
Now ages ago while messgin with old GCC & DooM I also had weird math calls not working. In the end I ended up extracting them from libgcc builds, so I thought I’d try the libgcc built during the GCC 2.6.3 on NT adventure.
link /NODEFAULTLIB:libc.lib /NODEFAULTLIB:OLDNAMES.LIB -out:phoon.exe astro.obj date_p.obj phoon.obj -entry:mainCRTStartup libgcc1.lib LIBC.LIB KERNEL32.LIB
Microsoft (R) 32-Bit Incremental Linker Version 2.50
Copyright (C) Microsoft Corp 1992-94. All rights reserved.
And of course:
To try to make the steps make a little more sense, and to allow for some higher level of automation I made a Makefile:
I’m sure there is better ways to do this, but it breaks the compile up to it’s individual parts:
Run the pre-processor to allow // in the comments, C++ hadn’t been the default thing back when GCC 1.40 was a thing. Also path it to the headers, in this case I’m using the ones from NT 196. Trying to link with the 196 libraries gave me this:
C:\xenixnt\demos\phoon>link /NODEFAULTLIB:LIBC.LIB /NODEFAULTLIB:OLDNAMES.LIB -out:phoon.exe astro.obj date_p.obj phoon.obj -entry:mainCRTStartup base.lib wincrt.lib ntdll.lib \xenixnt\lib\libgcc1.lib
Microsoft (R) 32-Bit Incremental Linker Version 2.50
Copyright (C) Microsoft Corp 1992-94. All rights reserved.
wincrt.lib(maincrt0.obj) : warning LNK4078: multiple ".data" sections found with different attributes (40000040)
astro.obj : error LNK2001: unresolved external symbol "_asin"
astro.obj : error LNK2001: unresolved external symbol "_atan"
astro.obj : error LNK2001: unresolved external symbol "_atan2"
phoon.obj : error LNK2001: unresolved external symbol "_cos"
astro.obj : error LNK2001: unresolved external symbol "_cos"
astro.obj : error LNK2001: unresolved external symbol "_floor"
astro.obj : error LNK2001: unresolved external symbol "_sin"
phoon.obj : error LNK2001: unresolved external symbol "_sqrt"
astro.obj : error LNK2001: unresolved external symbol "_sqrt"
astro.obj : error LNK2001: unresolved external symbol "_tan"
phoon.exe : error LNK1120: 8 unresolved externals
Which is not surprising as there is no FPU/Floating point math support in 196. I tried the December 1991 Pre-Release, but it failed for other reasons:
I did copy over BASE.DLL BASERTL.DLL CSR.DLL DBGDLL.DLL as it wanted, but despite the symbol being in the DLL it didn’t load.
So that’s why I’m using the libraries from the Win32s SDK.
Okay, so far now we have GCC 1.40 compiling to an old Xenix GAS assembler, and linking with Microsoft link from Visual C++ 1.0/2.0 era. The next step is to see if we can just link the objects under 196, and get a running EXE!
I have this tiny fibonacci example program, so with it compiled & assembled by GCC & GAS, I did the final link under 196, and YES it runs!
Possible things to do? GCC should be able to build itself, so it should be possible to build GCC and link that on 196 or December 1991, and get a native version of GCC on NT. The other possibility is to get newer versions of GCC (cc1 drop in replacements) to build for Xenix and / or OS/2. Obviously this Xenix linker is the gateway to older 386 Microsoft based products!
Unironically, I had purchased this for a whopping £4.68
No, really here’s the receipt. What a bargain!
Of course this is a legit copy with a legit key. But the online activation servers are all gone, and it looks like I’d have to call someone asking about my 22 year old copy of Windows, that I’ll load up and quickly forget.
Since I’m going to use QEMU, 0.90 with pcap support I thought I’d share the startup options:
I had high hopes for this thing. Clearly misplaced ambitions.
First up, it’s an upgrade version. So that means instead of installing XP I had to waste my time installing NT Workstation 3.51, then installing XP. Yuck. And of course it just want small FAT disks of the 2/4 gigabyte boundary type as it’s 1994. Not the bright future of 2002’s Windows XP.
I don’t know why Qemu 0.90 has issues with XP detecting the CD-ROM drive, but yeah that sucked. I wanted to load up some more insane SNA experiments, but there is no DLC / 802.2 driver for XP Home. wow.
At least once it’s satisfied, we can format the disk as one big happy partition, and we can get on with our lives.
Installation is rather uneventful, however we are instantly reminded that we have only 30 days to go. Since we have that nasty CD-ROM issue that means shutting down, and booting back up, but with this fun program on an ISO image, xp_activate.
I did try to make a call, to activate my Windows, but the connection was terrible and I’m not even sure if these numbers were right. No I mean I know they didn’t work.
So I did what all legit users end up doing, using the crack for my 21 year old copy of Windows.
And just a few clicks later, it was done.
Windows XP Home is activated.
I don’t know if it’s even really going to last, I didn’t try anything else, actually I already deleted it. And the XP folio is back on the bookshelf.
Not only is there no DLC, did you know you can’t uninstall TCP/IP? At least you can unbind it from your NIC. While it does have IPX/SPX there is no built in Netware client. When they said HOME they meant it!
There is a LOT going on in this image, and I’ll try to explain it, but yeah “it’s complicated”.
SNA networking & Hercules has always been a goal for a lot of people, including me as we always wanted to setup some SNA server of some kind. Especially on RISC platforms, as there is only so much fun on SQL server.
Okay I know the practical among you will say, doesn’t it support telnet 3270? Isn’t that good enough? Yes for day to day mundane stuff, absolutely. But I’m not all that interested in that, I wan’t to have the whole ancient network, and I wan’t it self contained and on my desk! Or on a laptop, as I see fit.
What started this whole adventure was a simple image from 9track.net, showing that being able to connect physical devices to Hercules was indeed possible!
This is a physical IBM 3178 & 3179 terminals talking to TK4- , a MVS3.8j pre-configured system!
The magic that makes this all possible, is a cisco router, running enterprise IOS, with dlsw support.
My setup is going to be inspired by this setup, but not exactly 100% But this is what I’m going to use on Windows 10
Dynamips for the cisco router, running JS-M 12.2(25)S8
Qemu 0.90 with PCAP running Windows NT 3.51 Server along with SNA Server 2.1
I had originally wanted to run the NT server on VMware but for some reason it just hangs trying to initialise the NT kernel. I didn’t bother trying to troubleshoot it, I just jumped to Qemu. Even service pack 5 didn’t help. VMware left me with the virtual network that will NAT if needed, and of course let me telnet to the Dynamips program. The SNA traffic is isolated to the MS Loopback adapter, which will let pcap programs talk to each other.
The first thing I did was run ‘hdwwiz’ on Windows 10, and added in the KM-TEST loopback adapter
We know what we want, so go to the manuall selection
Network adapters
And select the KM-TEST Loopback Adapter
Next I changed the protocols available on the loopback, as I don’t want my Windows 10 host interfering with the SNA network at all.
So the next thing to do is to get your network GUID’s. ethlist.exe from the Dynamips download will get you that:
C:\dynamips>ethlist.exe
Network devices:
Number NAME (Description)
0 \Device\NPF_{3DF0EC5D-7FBE-46DF-ACF8-EF5D8679A473} (loopback)
1 \Device\NPF_{D9FBD118-B9DF-4C3C-BD9E-07A0E34D8F75} (Local Area Connection* 8)
2 \Device\NPF_{F5057901-6A30-413A-80E4-4765DA794B7C} (Local Area Connection* 7)
3 \Device\NPF_{E3D3EC8D-29C3-4B70-B01C-600D3F9ED1D6} (Local Area Connection* 6)
4 \Device\NPF_{82EEDBC1-899D-416F-BD51-3DBE2287257F} (VMware Network Adapter VMnet8)
5 \Device\NPF_{3BC364F4-5A15-405D-926C-C594383F0323} (VMware Network Adapter VMnet1)
6 \Device\NPF_{DDF1FA94-7488-414F-A41A-EC88C1FB0DE4} (Ethernet)
7 \Device\NPF_{E7CA8F40-4639-410D-B5CA-F402FE69AF5D} (Ethernet 2)
I want the cisco router to have two interfaces, one with TCP/IP for me to be able to telnet into it (maybe other management as well?!) and the other one for the SNA traffic.
Setting up Dynamips
As mentioned above I’m going to use the VMnet1 for TCP/IP to the router, and the loopback adapter for SNA traffic. To try to make things a little easier to read I setup a small batch file that let’s me plug in variables to Dynamips:
set loopback=\Device\NPF_{3DF0EC5D-7FBE-46DF-ACF8-EF5D8679A473}
set vmnet1=\Device\NPF_{3BC364F4-5A15-405D-926C-C594383F0323}
set IOS=c7200-js-mz.122-25.S8.bin
set NPE=npe-200
..\dynamips.exe -P 7200 %IOS% ^
-t %NPE% ^
-p 0:C7200-IO-FE ^
-s0:0:gen_eth:%vmnet1% ^
-p 1:PA-4E ^
-s1:0:gen_eth:%loopback% ^
-p2:PA-4T+
The caret symbol will break up lines on NT, much like the ampersand will on Unix. And this let’s me use clear variables for the networks, IOS & NPE type so it’s nowhere near as complicated to edit.
This will create a cisco 7200 with an NPE-200, with the following cards:
So all my TCP/IP in this example will be using 192.168.199.0/24
As mentioned on the 9track page, all the magic happens on the cisco router. I’ve made a few changes as I may want to try the SDLC in the future to perhaps some other experiment if I can find an emulator that’ll drive it over serial, but for now let’s just get to the config:
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname dlsw
!
boot-start-marker
boot-end-marker
!
enable password cisco
!
ip subnet-zero
!
!
no ip domain-lookup
!
ip cef
no mpls traffic-eng auto-bw timers frequency 0
call rsvp-sync
!
!
!
!
!
!
!
source-bridge ring-group 1
dlsw local-peer peer-id 192.168.199.10
dlsw remote-peer 0 tcp 192.168.199.1
dlsw mac-addr 4000.1020.0100 remote-peer ip-address 192.168.199.1
dlsw udp-disable
dlsw transparent switch-support
!
interface FastEthernet0/0
ip address 192.168.199.10 255.255.255.0
duplex half
no clns route-cache
!
interface Ethernet1/0
no ip address
duplex half
no clns route-cache
dlsw transparent redundancy-enable 5555.5555.5000
dlsw transparent map local-mac 4000.1020.0100 remote-mac 4000.0999.0100
!
interface Ethernet1/1
no ip address
shutdown
duplex half
no clns route-cache
!
interface Ethernet1/2
no ip address
shutdown
duplex half
no clns route-cache
!
interface Ethernet1/3
no ip address
shutdown
duplex half
no clns route-cache
!
interface Serial2/0
no ip address
encapsulation sdlc
no keepalive
serial restart-delay 0
clockrate 64000
no clns route-cache
sdlc role primary
sdlc vmac 4000.0999.0100
sdlc address C1
sdlc xid C1 01700019
sdlc partner 4000.1020.1000 C1
sdlc dlsw C1
!
interface Serial2/1
no ip address
shutdown
serial restart-delay 0
no clns route-cache
!
interface Serial2/2
no ip address
shutdown
serial restart-delay 0
no clns route-cache
!
interface Serial2/3
no ip address
shutdown
serial restart-delay 0
no clns route-cache
!
ip classless
!
no ip http server
!
!
!
!
!
!
control-plane
!
!
dial-peer cor custom
!
!
!
!
gatekeeper
shutdown
!
!
line con 0
session-timeout 35791
stopbits 1
line aux 0
stopbits 1
line vty 0 4
password cisco
login
!
!
end
This sets up the router so I can telnet to it from my desktop at 192.168.199.10, and allows it to talk to the base Windows machine on 192.168.199.1
All the magical MAC addresses come from 9track.net, as he wrote the dlsw hooks, so I just copied that. There is probably a great deal that could be cleaned up, but once I saw the two talking I kind of froze what I was doing.
With that much in place I then jumped to WSL,and built the emulator from github. I cloned it, and renamed that to herc-dlsw. At least for me this was pretty straightforward. The Hercules fork will build with Visual Studio as well, but I knew I was going to need some kind of tn3270 emulator, and I wanted to use x3270, and I had just recently bought this discounted copy of XVision, so of course I wanted to use that.
Despite this catastrophic defect that wasn’t disclosed in the auction.
I downloaded and extracted the TK4- latest distro on WSL. I just created a ‘herc’ directory in my home to house the tk4- release. The next thing to do is overlay your dlsw enabled exe’s and libraries.
cd ~/herc-dlsw/.libs
mkdir x
cp * x
cd x
rm *.o *.lai
cp *.so $HOME/herc/hercules/linux/64/lib/hercules
cp *.la $HOME/herc/hercules/linux/64/lib/hercules
rm *.so *.la
cp * $HOME/herc/hercules/linux/64
Now with the binaries in place, I do need to setup the Xvision VM so I can receive the X11. Of course there is so many other ways to do this, but this is mine:
The important thing is that tcp port 6000 is redirected inwards, and that I’m using the NE2000 card, which on my weird fork will print out the hardware config, so I know how to find the nic.
added SLIRP
adding a [GenuineIntelC♣] family 5 model 4 stepping 3 CPU
added 64 megabytes of RAM
trying to load video rom pc-bios/vgabios-cirrus.bin
added parallel port 0x378 7
added NE2000(isa) 0x320 10
pci_piix3_ide_init PIIX3 IDE
ide_init2 [0] s->cylinders 203 s->heads 16 s->sectors 63
ide_init2 [1] s->cylinders 0 s->heads 0 s->sectors 0
ide_init2 [0] s->cylinders 2 s->heads 16 s->sectors 63
ide_init2 [1] s->cylinders 0 s->heads 0 s->sectors 0
added PS/2 keyboard
ps2.c added PS/2 mouse handler
added Floppy Controller 0x3f0 irq 6 dma 2
installing PS/2 mouse in CMOS
Bus 0, device 0, function 0:
Host bridge: PCI device 8086:1237
Bus 0, device 1, function 0:
ISA bridge: PCI device 8086:7000
Bus 0, device 1, function 1:
IDE controller: PCI device 8086:7010
BAR4: I/O at 0xffffffff [0x000e].
Bus 0, device 1, function 3:
Class 0680: PCI device 8086:7113
IRQ 0.
Bus 0, device 2, function 0:
VGA controller: PCI device 1013:00b8
BAR0: 32 bit memory at 0xffffffff [0x01fffffe].
BAR1: 32 bit memory at 0xffffffff [0x00000ffe].
And in this case it’s 0x320 IRQ 10. XVision being it’s own level of disappointment, I’ll have to cover it further, and later but suffice to say it at least catches the x3270 so I can get onto the console.
Setting up Hercules
Editing conf/tk4-_default.cnf is pretty easy as it’s on Linux and you can use VI.
First get MVS up and running. You have to run the ‘console_mode’ script to see what is going on.
cd herc/unattended
./set_console_mode
cd ..
./mvs
It’s not all that difficult XVision is using SLiRP, so it’s listening on all my IP addresses so I just do a simple
export DISPLAY=192.168.1.72:0
nohup x3270 &
And the emulator will pop up in Qemu. Just connect to localhost:3270 and you’ll be greeted by the login pannel:
Credentials are HERC01 / CUL8TR
I would HIGHLY recommend following the tutorial to get used to submitting a simple COBOL program. It walks through the key concepts of locating a file, and viewing it on MVS. Something that up until yesterday was out of my league.
We need to edit the file S3705 on SYS1.VTAMLST
Basically it’s 1,3,4 from the main pannel:
or RFE, Utilities, DSLIST
Type in the Volume name, then tab over to the left of the volume and put in V to view
Now we will get a list of all the files. We want to edit S3705, so you can tab/arrow down, but sure to put an `E’ next to it, then hit enter so we can edit the file
F7/F8 will page down/page up as needed. As mentioned we are interested in Subarea 13, PU type 2.
The line we are changing is the MAXDATA or MTU size for this unit. Since we are doing dlsw, or an emulated serial link, we need to knock it down to 256. Notice all the plus signs on the right hand? THOSE ARE IMPORTANT! Not only do they need to exist, but they also have to be on the far right.
For those wondering the MTU sizes on the client side by media type are as follows: And notice that the host size is different, as this takes in account of packet headers.
Making sure to overtype the 3780, to a 256, and ensuring the + sign hasn’t moved you can hit enter, cursor to the top and type in SAVE.
We can then edit the N13 file, changing line 35 to have MAXLU=3
Hopefully this clears up editing VTAM files.
As mentioned the easiest way to regen the system is to delete the old object files. So hit f3 a few times and get back to the dataset list
This time we want the VTAMOBJ set. Go and ‘V’iew it like last time and we will get the list of files:
Now we are going to put a ‘d’ next to N13 and S3705. This will flag them for deletion. Hit enter!
The files are now gone! On the next boot they will be rebuilt.
I just hit F3 a bunch of times and it’ll drop to some TSO shell
From here you can shutdown the system. It’ll take a few minutes, but you can start it up again just the same way you brought it up. Remember to attach your console.
Setting up SNA Server
Just like Dynamips, I setup a batch file, as the default one is just far too long to read:
@echo you need to figure out your nic name..
@echo something like
@echo \Device\NPF_{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
set loopback=\Device\NPF_{3DF0EC5D-7FBE-46DF-ACF8-EF5D8679A473}
set vmnet1=\Device\NPF_{3BC364F4-5A15-405D-926C-C594383F0323}
qemu -m 64 -L pc-bios ^
-hda SBS15.vmdk ^
-soundhw sb16,adlib ^
-net nic,model=pcnet,macaddr=52:24:00:22:00:01 ^
-net pcap,devicename=%loopback% ^
%1 %2 %3 %4 %5 %6
This will setup a small machine with 64MB of ram, a single AMD PCNet adapter on the loopback interface. I installed Windows NT 3.51 from the Small Business Server 1.5 setup. I don’t know why VMware + NT 3.51 didn’t get along, maybe it’s my Erying, Or maybe it just plain doesn’t work, I’m not sure, and far too impatient to troubleshoot it.
It’s very important that you do add the DLC Protocol during setup. It’s in the ‘Add Software’ part. I kept my NT very simple with only NetBEUI and DLC protocols. At the moment I’m not that interested in actually networking the NT, and if I was, I would add a second NIC, just like what I did for Dynamips.
Setting up NT isn’t that interesting, but SNA server is. I did use the 2.11 on the Back Office CD, but for completeness sake of testing I tried the oldest one I could find, and 2.1 beta from June, Build 2.1.0.216.
I left the network name & control point name blank as I just want terminal, I’m not even going to think that LU6.2 applications on such an ancient version of MVS was even possible.
This is pretty much default, the Link service basically sets itself up as we only have the one NIC.
Take note of the remote network address. 400010200100 which came from above the address we directly point to the dlsw. Also it’s form the 9track blog.
Insert a 3270 LU for us to try to talk to Hercules.
I’m pretty sure it was hard coded to be a model 2.
I turned off the ability for the model to be overwitten.
Create a pool, I called it swimming, because of ‘reasons’. I made it a type 2 pool and added the terminal to it.
Next I added the EVERYONE user, and gave them access to the SWIMMING pool
Finally we are ready to save the config, and do the hand holding and start up. If the stars aligned you will see them go ACTIVE/ACTIVE and the terminal will go Available.
Sadly the terminal won’t go live, it’s stuck in SSCP.
And this is as far as I can go. I have to think that with either something far older protocol wise for the PC, such as IBM Personal Communications/3270 for Windows V2.0 (v4 didnt work either), or a far newer Mainframe software version would support whatever it is SNA server wants to give us the crazy dream of running SNA self contained.
Running Wireshark on the loopback network I see this message:
UNSUPPORTED FUNCTION
Sadly this is as far as I can take you. I do want to give a special thanks to Vinatron & blackbit for trying to troubleshoot this with me. Best we can figure is that TK4- is just too old.
Troubleshooting
From the cisco router try dlsw commands like this:
dlsw>sho dlsw circuits
Index local addr(lsap) remote addr(dsap) state uptime
2281701660 4a24.0044.0080(04) 0200.9099.8000(04) CONNECTED 00:02:23
Total number of circuits connected: 1
This does show the connection. Notice that ‘show bridge’ will show nothing in this config.
Be sure to check peers as well:
dlsw>show dlsw peers
Peers: state pkts_rx pkts_tx type drops ckts TCP uptime
TCP 192.168.199.1 CONNECT 10 13 conf 0 1 0 00:05:07
Total number of connected peers: 1
Total number of connections: 1
Make sure your interfaces are ‘up/up’ and passing traffic
FastEthernet0/0 is up, line protocol is up
Hardware is DEC21140, address is ca00.48f4.0000 (bia ca00.48f4.0000)
Internet address is 192.168.199.10/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1000 bits/sec, 2 packets/sec
5 minute output rate 2000 bits/sec, 2 packets/sec
12768 packets input, 1439279 bytes
Received 3609 broadcasts (0 IP multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
9999 packets output, 1037736 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
dlsw>show int eth1/0
Ethernet1/0 is up, line protocol is up
Hardware is AmdP2, address is ca00.48f4.001c (bia ca00.48f4.001c)
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:02, output 00:00:02, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
52426 packets input, 5148287 bytes, 0 no buffer
Received 12336 broadcasts (0 IP multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
36383 packets output, 2465490 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
dlsw>
And of course check WireShark to see if there is any handshake:
And of course check the Hercules logs to make sure your VTAM rebuilt, look for ERROR or anything related to S3705 or N13.
Years ago when I’d bought Office 4.2 for Windows NT, it only included i386 & Alpha builds of Word and Excel in the box, and a coupon for MIPS and PowerPC.
About the only thing interesting is that it actually ran under Win32s.
But today looking at term24‘s uploads on archive.org, I saw two CD-ROM images:
I quickly fired up Qemu MIPS NT, and confirmed that both do in fact contain a MIPS version! Excel does have the PowerPC version as well.
As far as I know the only RISC platform to get apps from Office 97 was the Dec Alpha, but at least MIPS users can rejoice now, knowing that they too have been blessed with 32bit Office 4.2 apps!
One of the amazing things about NT & portable apps is that visually, they look identical. So other than me telling you that these are the MIPS native versions, there really is no way to tell.
Well, other than there is no ntvdm running. There is no WOW needed here!
100% native.
I guess the only other question is that since the Word is 1994, and Excel is from 1995, did they have earlier versions for Windows NT? It seems like everything was finally coming together for RISC NT, except the users. Would a release of 64bit Windows 2000 on Dec Alpha save the platform by bringing a strong 64bit platform with integrated JIT i386 WoW built in? (AXP64 Windows 2000 didn’t use !FX32). I guess we’ll never know.
(this is a guest post by Antoni Sawicki aka tenox)
Hinted by friends on Discord, Neozeed recently “discovered” a Win64 compiler for AXP64 / ALPHA64. It came as part of Windows Platform SDK from 1999. Microsoft wanted developers to test-compile their code to see if it’s “64bit ready”, well ahead of the 64bit hardware even being available. However, this was just a cross-compiler and there was no way of running any of the binaries. That is until Itanium eventually came out, after infamously long delays. The Win64 project for AXP64 and IA64 was code name “Sundown”.
Trying the compiler, just for fun, I built Alpha64 version of Aclock – with zero hopes of ever being able to run it. There are some known surviving machines with AXP64 stored at Microsoft Archives. In fact I saw one with my own eyes, last time I visited there some 10 years ago:
DEC Alpha with AXP64 Windows codename “Sundown”, at Microsoft Archives, 2014
The machine in picture above was featured in a blog post by Raymond Chen, which is a must read. It will give you background info on the whole Alpha 64bit situation. Sadly, 64-bit Alpha AXP Windows was never released outside of Redmond.
And that would be the end of the story… if not for one generous reader, who contacted Neozeed after his previous post, and shared a disk image… containing non other but a 64bit build of Windows 2000 for Alpha AXP! The reader got it from a lot of random hard disks, bought from an e-waste, years ago and completely forgot about it until they saw the blog post!
The image was previously installed on Digital Personal Workstation. Having a PWS500 with ZuluSCSI handy, I was able to slap the image on an SD card and boot it up:
Windows 2000 Alpha64 Splash Screen
The system BSOD shortly after. Turns out, this is a checked (debug) build and requires a permanently attached kernel debugger to even boot up. Initially WinDbg and kd.exe refused to work, as the target CPU did not match the host (the exact error code is: KD Version has unknown processor architecture). After some deliberation and help from friends, I learned that alphakd.exe can be run on x86 machine to cross debug an Alpha target. Most importantly it works with AXP64!
Another problem was that the system came up with “Found New Hardware” wizard and there was no functioning keyboard and mouse to click through it. Yes, I tried safe mode, VGA mode, etc., but nothing worked. The system was completely stuck on this dialog:
Fortunately, the network card worked. Neozeed and I built and hacked in to the registry an rlogin daemon. Finally solved the PNP fuckup by remotely executing a VBScript that clicked through 20+ “found new hardware” and “install unsigned driver” dialogs. Eventually, a PCI to ISA bridge was found and keyboard and mouse came up!
Aclock running on 64bit Windows on Alpha AXP
Unfortunately there are no identifying marks that would definitely prove that this is a 64bit Alpha AXP build. The only way to tell is because there is no WOW, even for AXP32. You can’t run 32bit Alpha binaries. It will only run executables produced with the ALPHA64 compiler. This also means in practice there is no self hosted, native compiler. You have to cross compile on 32bit NT4 or 2KRC.
For sake of search engines the build number is 2210, the full string: 2210.main.000302-1934.
Update I have copied and ran a x86 `winmsd.exe` from Windows NT 4.0 and this came out:
How is it possible to run x86 binary? Because of Fx!32.
Update: So what else is in the image?
First of all, everyone is asking about Pinball… Yes, it’s there, but it won’t start:
In addition, I can’t open the event details. Maybe one day we can debug it with NTSD.
Other than that, it has some basic stuff, the every other Windows would have. Internet Explorer 5.5, agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0). Sadly msinfo32 doesn’t work, unable to connect to a service.
The image, similar to other private builds, comes with Internal Developer Workstation (IDW). It’s a set of developer tools, that most of (but not all) were released in Platform SDK and/or Windows Resource Kit.
There are a bunch of unix like utilities, cp, mv, ls, kill, etc.:
Lastly, lets explore 64bit Alpha AXP gaming scene! While Pinball doesn’t work, IDW comes with an impressive amount of games. Microsoft engineers must have been busy playing these while waiting for builds to complete…
64-bit gaming on Alpha AXP
We have 4 different card games, FreeCell, Solitaire, Gold and Cruel. Also Taipei game, TicTactics, Reversi, Minesweeper and Snake.
AXP64 NT also has fully working OpenGL Screensavers:
If you want to see this live in action. We going to be exhibiting on VCF West 2023 in August, alongside other NT RISC machines. Come and see us!
