Author Archives: neozeed

AXP64 2210 Installation Media Reconstruction

Posted on by
19
Yes, Neko is ALPHA64 Powered!

Introduction

Unfortunately, during this amazing period, the Dec Alpha I had acquired specifically for this research had died. However, I was able to find an amazing group of people to not only go through with this research but take it upon themselves to provide an amazing working ISO image release! Needless to say, this is beyond my knowledge, and this is obviously a guest post

Background

In ~1997, Microsoft started work on a project dedicated to porting Windows NT to use 64-bit addressing on 64-bit machines. Before this, Windows NT used the 32-bit mode or ABI of 64-bit machines. This effort was internally referred to as “Sundown”, otherwise referred to as “Win64”. The ports consisted of not only to the Itanium/IA-64 architecture (which later shipped as Windows XP 64-Bit Edition) but also to the 64-bit DEC Alpha architecture.

Compaq dropped support for Windows on Alpha in mid-1999, and Microsoft stopped the development of 32-bit Windows NT for Alpha soon afterwards, with Windows 2000 build 2128 (RC2) being the last build. Due to a lack of physical IA-64 hardware and the slowness of the simulator, Microsoft continued to work on the AXP64 port of Windows till mid-2000, to help fix general issues related to 64-bit addressing. You can read more about this project here.

In May 2023, a disk image containing an installation of an AXP64 build of Windows XP (Whistler) build 2210 was discovered by a guest reader of this site, and a team (amarioguy, neozeed, pivotman319, starfrost and Tenox) was later assembled to help make this release possible.

Why Repack To ISO

When I saw the news about this build, I asked my friends why didn’t neozeed or Tenox share the full disk image, they told me that the disk image contained PII (Personally Identifiable Data) and neeozeed would like to have them removed first. I have some experience with cleaning up Windows builds, so I joined their Discord server and offered to help, then I got sent a full sector dump of that disk. I scanned the build 2210 partition with a file recovery tool that I stole from a data recovery shop when I worked there, and to my amazement, quite a few files in the deleted \$WIN_NT.~LS directory (a place for holding temporary setup files) survived (more importantly, setupdd.sys, txtsetup.sif, setupldr and the hiv*.inf files). Since all the files required for a clean install from ISO/CD are there, this build can be repacked into an ISO which is guaranteed to contain no personal information!

Recovery

The first thing I did was I recovered all of the files in the deleted \$WIN_NT.~LS directory, but since the integrity of files recovered from NTFS and FAT partitions cannot be guaranteed, I checked every single one of them. Most of those files were Microsoft Cabinet (CAB) archives, so I wrote a tool called CabChk to verify that 1) they are valid CAB archives, 2) there is only one file per archive, 3) the name of the compressed file is the same as the name of the archive and 4) the compressed file extracts fine. This helped me to verify most of those 4600 files, but I had to verify the remaining 300 or so files by hand because they’re not CAB archives and that task alone took days to complete. After verifying all the recovered files, it turned out that 85% of them survived while the remaining 15% didn’t.

Repacking

A lot of those overwritten files are actually in the Windows directory (NT64) of that 2210 install, so I copied them out and recompressed the appropriate ones. I set my computer to the time zone Microsoft used and compressed them with the Cabinet Tool (CABARC) parameters Microsoft used. Microsoft used UTC-8 and the following CABARC parameters:

CABARC -m LZX:21 N [output_cab] [input_file]

After repacking and copying over the files, the number of missing files went from about 650 all the way down to roughly 30 :).

Missing User Mode Setup Stub

Unfortunately, usetup.exe was one of those 30 or so files. It doesn’t do much as it’s a stub, but nonetheless without it, text mode setup won’t start. My original idea was to decompile I386 build 2211’s usetup.exe (as it has only about 20 functions) and recompile it for AXP64 with the toolchain discovered earlier on, but I had to wait for someone to cross compile it on an Alpha for me. While I was waiting, I searched that partition for substrings in the I386 usetup.exe and I got a match!

It’s compressed, but since LZNT1 is a simple and weak-ish compression algorithm, you can sort of recognise the original data. I cobbled together an LZNT1 decompressor and decompressed that 32 KiB chunk, and indeed it’s the AXP64 usetup.exe!

E:\Projects\LZNTTool>LZNTTool -d "E:\Whistler 2210 AXP64 Recovery\usetup_compressed_0.bin" "E:\Whistler 2210 AXP64 Recovery\usetup_0.bin"
Decompression successful.

E:\Projects\LZNTTool>wsl hexdump -C -v -s 0x600 -n 0x200 "../../Whistler 2210 AXP64 Recovery/usetup_0.bin"

I then searched for strings expected to be in the second 32 KiB chunk and then the third chunk and so on, until I got all of them recovered. After decompressing all of the 5 chunks, I concatenated them together into one single executable and yay, we now have the original AXP64 usetup.exe!

E:\Projects\PEChkSum>PEChkSum "E:\Whistler 2210 AXP64 Recovery\usetup.exe"
Expected checksum is: 0x00035E4E
Actual checksum is: 0x00035E4E

"E:\Whistler 2210 AXP64 Recovery\usetup.exe" is valid.

Broken Driver Cabinet

pivotman319 pointed out to me that some files in driver.cab were dead, and indeed, Setup did not work with that broken cabinet:

Crash to the NT firmware Monitor

There were 2 copies of driver.cab on that disk, sadly the deleted one in $WIN_NT.~LS got overwritten and the one in \NT64\Driver Cache\axp64… well, 68 errors 😢:

Looking at the broken files, I noticed a pattern – all of them came from 3 blocks – 5, 36 and 37. What on Earth are “blocks”? Well, let’s talk about how CAB archives work first.

Files in CAB archives are stored in blocks, where each block stores 1 or more files. When files are added to a CAB archive, they are all concatenated together into one big file. The concatenated big file is then split into multiple sub-blocks (with default size of 0x8000 bytes) and each of them gets compressed and then concatenated together to form the compressed block. So, for small corruptions (bit-rots and etc.), theoretically only 0x8000 bytes are lost and the rest should still be recoverable, but tools like 7-Zip will refuse to extract anything beyond the point of corruption.

Now looking at the corruption in driver.cab, 2 of the 3 blocks can be fully recovered because we have all of those files in uncompressed form. Block 5 contains mostly printer-related files that are arch- and build-independent, so they can all be borrowed from build 2211 i386. Block 37 has only 1 broken file (win32k.sys) which exists on the hard drive (in system32). To fix these blocks, I simply took the uncompressed files, compressed them and replaced the broken blocks with the newly created ones.

And after fixing block 37:

I then ran my CabScan tool on the fixed CAB and as expected, there is only one bad sub-block left:

E:\Projects\CabScan>CabScan "E:\Whistler 2210 AXP64 Recovery\driver (fix).cab"
Offset 0x0253FD75:
    Expected checksum is 0x568C0AC3
    Checksum is 0x1CEBB9DE
    Original size is 0x00008000
    Compressed size is 0x00003862

Detected 1 bad sub-block(s) in 1 bad block(s).

So, what can we say about the corruption?

  1. Size: 4 bytes
  2. Location: Last 4 bytes of a 0x2000 section
  3. Pattern: Starts with 00 F0 (possibly the result of a buggy NTFS driver)

Knowing these, I immediately located the 4 corrupted bytes in block 36:

So how did I recover those 4 bytes, did I brute force them? Nope, I used the checksum to calculate them! Here is the checksum algorithm Microsoft used for CAB archives:

CAB checksum algorithm

And as you can see, it’s very simple, so it took me almost no time to work out the 4 missing bytes (4A ED 16 71) from the checksum 0x568C0AC3! With block 36 fixed, as expected, all files are now good!

Buggy Setup Loader

I thought I got everything necessary recovered and fixed, so I packaged up the files and sent them to G-Nug85 to test… and it didn’t work:

It failed to find A321064.PAL in the [SourceDisksFiles] section of txtsetup.sif. Well, this is an AXP64 build and A321064.PAL is a 32-bit PALcode image… why would it be there? Needless to say, copying that file to the disc image didn’t help. I have literally spent days on this stupid issue and who would have expected this:

E:\Whistler 2210 AXP64 Recovery>wsl strings -t x SETUPLDR | wsl grep -i '.pal'
  91f68 A321064.PAL

The culprit of the problem was they hard coded the name “A321064.PAL”… in the setup loader executable… how stupid!

We can tell from this that Microsoft has never made ISOs or discs for AXP64 builds, otherwise they would’ve found and fixed this bug. Well, maybe they did eventually try installing AXP64 builds from disc, because it’s fixed by the time of Windows XP SP1, but that’s long after this build:

#if defined(_AXP64_)
        SlGetDisk("a121165.p64");
#else
        SlGetDisk("A321064.PAL");
#endif

Oh well, I replaced the hard coded “A321064.PAL” with “a121165.p64” and what do you know, it’s working!

Finishing Touches

That install went smoothly, but one error did pop up during second stage setup:

A missing driver – big deal, hey? We actually have the build 2209 AXP64 version of this driver, so I injected it to the ISO and Setup happily accepted it.

I’ve also copied the Arc Installation Program (ARCINST) from Windows 2000 build 2128 AXP32 to the AXP64 directory of the ISO, because it is required for disk partitioning if you don’t have AlphaBIOS (and yes, it works because it’s not a Windows executable).

Supported Machines

Microsoft compiled several HALs for this build, but not all of them are listed in txtsetup.sif, the following machines are supported by default:

  • Digital Personal Workstation A-Series
  • Digital AlphaServer 4×00 5/xxx Family
  • Digital AlphaServer/AlphaStation 1200 5/xxx Family
  • Digital Alpha 21264/Tsunami Uniprocessor
  • Digital Alpha 21264/Tsunami Multiprocessor

The following machines may be supported if you replace textsetup.sif with a modified version:

  • Digital Alpha EB164
  • Digital Alpha PC164SX
  • Digital Alpha XL 300/366 Family
  • Digital AlphaPC 164LX
  • Digital AlphaServer 1000 5/xxx Family
  • Digital AlphaServer 1000a 5/xxx Family
  • AlphaServer 800 5/xxx (Corelle)
  • AlphaStation 600A 5/500 (Alcor Primo)

We have only tested this build on the Digital Personal Workstation A-Series, AlphaServer DS10 and the AlphaServer 800, so there is no guarantee that the other HALs work (though they should).

Also, since this is a checked build, it does run slower than a retail build, and by default it will expect you to have a kernel debugger attached. Be sure to add the /NODEBUG flag to the bootloader to improve performance. I had noticed the SDL spite test demo going from 60fps to 70fps on my Alpha Personal Workstation 500a before it had died.

For Preservation

As I have said earlier on, Microsoft has never made ISOs/discs for AXP64 builds, so please don’t preserve the ISO file (eg: don’t upload it to BetaArchive). I know BA prefer ISOs over folder dumps, so let me tell you this mrpijey, the ISO is a franken-build with a patched Setup Loader and files from 2128, 2209 and 2211. We have a folder dump of the original files from the \NTDev network share with original high-precision timestamps just for preservation, so please for the sake of preservation, use this. Also don’t even think about creating an ISO out of the folder dump, you’ll end up with a non-existent thing that doesn’t work.

Download

ISO for Installation: https://mega.nz/file/q5AhhDJR#MsLYxxvmAdYDQ101fUHoGyzJ5Pk0EFsc2xdYH1p9qxQ
Whistler 2210 axp64 installable

Folder Dump for Preservation: https://mega.nz/file/r5gE3RxQ#4VfviMdQo44wJZT0df0cw8o4kE30lvSQKBZklma0mtg

Modified TXTSETUP.SIF For Other Machines: https://mega.nz/file/zsBVAJDD#5oQVM6U2AwseTJ54lOmN1E7BHTDFuwOuWdZOykmXP8E

Special Thanks

  • to the person who sent us the disk image
  • to Microsoft for not wiping that disk before throwing it away
  • to pivotman319 for verifying recovered files and finding missing files
  • to Tenox for testing
  • to G-Nug85 for testing and providing photos used in this post
  • to Furball for testing
  • to lbdm for testing
  • to myself… I guess?

Special Offer – Windows 2000 RC2 AXP32 Full ISO

The ISO on BetaArchive is the same as the ISO on WinWorld, which was originally named usa_2128_axpfre_win2000.pro_beta3_cairo.iso… hmm, that doesn’t sound very ‘Microsoft’!

Yep, definitely not original. Even worse, SETUP.EXE is broken/truncated:

The fact that the AXP32 2128 ISO we’ve had for over a decade is both unoriginal and incomplete is truly shocking! Well, I have something to offer – an at least complete Windows 2000 build 2128 AXP32 ISO from my private collection:

The SETUP.EXE in this ISO is good and complete! The CDIMAGE parameters used to build this image matches what was used to build ISOs of AXP32 builds from the same era and the disc label (W2PAS_EN) is much more sensible than “Cairo_2128”. The only thing that doesn’t make sense is the timestamp – 1999-09-23 12:00:00. Microsoft used 1999-09-10 as the timestamp for all other copies of build 2128, so I’m not sure why this one is different. It’s worth noting that all files from the incomplete ISO also have the strange 1999-09-23 timestamp, so I guess it’s not a coincidence ¯\_(ツ)_/¯.

Download: https://mega.nz/file/qoYyUbLB#oKArX_Qqh_kjnESnT6dQD8NGTg05_CMhKMxW4FKuhjEWindows 2000 build 2128 DEC Alpha

CDE on WSLv1

Posted on by
4

AKA CDE on Windows 10!

This is about as weird as it sounds. While many disregard WSLv1 as being borderline useless, it can still quickly bridge the gap when you need something in user-space, and quickly. And for those of us on Windows 10 (I could upgrade this machine, but I haven’t bothered as I don’t have a real GPU for it), there is no real UI. But how to solve this?

Well, the first thing is xrdp. Xrdp is an RDP server that will allow any halfway good Unix machine become a terminal server, very ‘Citrix like’. Combine that with the Xorg virtual frame buffer, and now you have a display surface that is basically exported over RDP. I did modify it to listen on a different port so I could retain RDP to Windows 10 by modifying xrdp.ini:

port=4389
port=ask4389

Now the real fun comes from CDE.

I built 2.5.1 from source, following the guide, with 2 important notes: Make sure you install and activate the UTF!!!. The other thing that was trashing my build was that WSLv1 picks up the Windows path, and it has spaces in it, which confuse the build process. Be sure to export something like:

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

before beginning the process.

With all the bits in place, the next issue is the RPC. I couldn’t figure out how to start the ‘safe mode’ version, so it will absolutely need RPC. But it turns out that you just have to start the rpcbind manually, since WSLv1 doesn’t have a real ‘startup’. I also saw a lot of errors trying to talk to dbus, so may as well start that up as well.

mkdir -p /run/sendsigs.omit.d/
/usr/sbin/xrdp
/usr/sbin/xrdp-sesman
/usr/sbin/rpcbind
/usr/bin/dbus-daemon --system

And finally link the Xsession to the default user .xsession so CDE will be the default environment.

ln -s /usr/dt/bin/Xsession $HOME/.xsession

Now you should have everything in place, to login and get the Xrdp login

xrdp login

And with any luck, you’ll be greeted with CDE!

CDE on WSLv1!

And there we go! Neat!

Citrix 2 on Qemu!

Posted on by
Reply

Something weird happened when I was stress testing a build platform, I scripted out a build of all the old Qemu I could with GCC 3.4.5, and I had pointed them to a random disk. Turns out it was a Citrix Multiuser 2 disk. And something weird happened, a few of them actually booted!

I setup a simple script to have it listen on both serial ports, one for the ICA Citrix client, the other accepting a more generic serial terminal.

qemu -L pc-bios -m 64 -M isapc ^
-fda dummy.vfd ^
-hda citrix2-1b.vmdk ^
-serial telnet:127.0.0.1:5523,server,nowait ^
-serial telnet:127.0.0.1:5524,server,nowait ^
-net nic,model=ne2k_isa ^
-net user

Just very simple stuff.

I can then just boot a simple PC qemu and attach it to the other side of the serial port

qemu.exe -L pc-bios -m 8 ^
-serial telnet:127.0.0.1:5523 ^
-fda "i:\Citrix Multiuser Link 1.0 (3.5-720k)\Images\disk01.img" ^
-hda msdos5.vmdk

Sadly it’s only text mode, and at 9600 baud, which you can really feel. Sadly OS/2 PC Serial port drivers sucked.

this kind of setup for me was a bit easier to mess around with linkers as I have multiple screens to view stuff, along with a terrible modem option to transfer files. Only the console can run graphical programs, so this isn’t the one to build a Windows 3.0 farm on

If anyone was crazy enough to try this, I’d suggest the 1.0 manuals. Sorry I didn’t get a chance to scan the 2.0 stuff.

The serial ports lock & jam a lot so I made some scripts to try to deal with it, just rserial1/2 to reset the port, and logouts1/2 to logout the serial connection. Yes it’s that fragile. Being a pre-release version of OS/2 I had zero luck getting any lan client going. If I had it’d make dealing with this thing, even with NetBEUI a lot more tollerable.

I did load up Windows 3.0 by the directions so it does work, albeit standard mode only. Looking back at OS/2 6.123, while it has the OS/2 1.2 interface, it’s MS-DOS was restricted to real mode only. So this was also a nice step up.

One thing to point out is that it’ll hang at the logo screen for literally a minute. I’m not anywhere near as smart enough to debug the loop and ‘fix’ it. Sometimes it just won’t make it, so close it down, and try again. It may seem hopeless sometimes but it does work. Although this unpredictability is why there is no public Citrix 2.0 on demand. I haven’t bothered tryng to build Qemu 0.8.2 on Linux, but if it were more reliable booting and networking, combining it with xinetd having a LAN backing store of homes & apps would make for a neat Citrix on Deman farm thing.

I can’t imagine anyone wanting to play but I did upload it to archive.org.

Windows NT demo on the DECstation 5000

Posted on by
2

Well this was unexpected find! Thanks to hyenasky over on discord.

While the platform had a few mentions here and there but it’s great to have found a talk about the product with video of it running.

Interestingly enough Compaq was apparently in charge of the ARC specifications? Also kind of funny how the do touch on that maybe one day it could be available for the Dec Alpha, but as we know DEC pivoted away from the MIPS entirely to focus on the Alpha.

The other part being how the Pentium/Pentium Pro was entirely unexpected from the wider RISC market that thought they had the migration point out of 386/486 based machines.

Unfortunately, like the platform, Alexandre Bronstein exited DEC to go onto other ventures, oddly enough at Veritas being pulled back into dealing with Microsoft with the disk manager.

Re-visiting VM/386

Posted on by
8

So years ago I had won an eBay auction for 3 disks:

VM/386

But pretty much everything I threw at it emulation wise came up with NOTHING but green bars when trying to enter a virtual machine. I’d always thought it was a video ROM thing but VGA type ROM I put in Qemu it’s always the same thing, green jail bars.

VM/386 in action

However, I tried it again on 86box, and YES it runs!

VM/386 VM status

You can see VMs running, where they are in memory and all that other fun stuff.

And even better you can run graphical PC programs on your advanced 80386, and seamlessly multitask them all, using the hotkey ALT+PRINTSCREEN to toggle between them all. Surprisingly creating and terminating VMs didn’t really mess with overall system stability. I have to imagine that had this program had a 32bit API, it would have killed OS/2 before it ever got a chance. Considering that version 1.2 is from 1988 there very well could have been a larger possibility.

It does have the ability for individual profiles to specify RAM or even where or how to boot, it has disk drivers for sharing of files (think file locking). It also has the ability to boot from floppy, or even ROM!

MS-DOS 3.30A booted under VM/386

Indeed there is a rather good review from PC Magazine: January 1988, that goes into many features, and compares it to other contemporary multitaskers of the era.

The one big drawback is there is no data exchange facilities. The one thing that Windows/386 had bridging the gap between MS-DOS & Windows applications.

So many products like VM/386 ended up finding their niche’s in attaching dumb terminals, and turning 386 classed machines into ‘micro mini’s’ witthout the power of Unix. It’s even out of this environment Citrix was born.

But there was so much potential here to be something so much larger, but sadly that was not to come. Perhaps 1988 was just a little too early in the sense of GNU GCC/GAS/LD and some Xenix COFF help. The world would have been a lot more stranger had Microsoft lost that second vital platform war.

Anyone crazy enough to want to try it in 86box, I uploaded my images on archive.org.

Microsoft’s Netware emulators

Posted on by
6

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?

Building a 100% virtual SNA network on your desk!

Posted on by
4

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.

Microsoft SNA Server

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
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.

ABEND

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.

I hope this has helped someone.

SDLC attempt #1

Posted on by
Reply

TL;DR it didn’t work, got the exact same result.

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.

Fun with Windows ePDK NT 3.1 build 196 & Some Xenix fun!

Posted on by
4

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 and an OpenNT 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.

Which gave me the following assembly:

        .file   "SIMPLE.c"
gcc_compiled.:
.text
LC0:
        .ascii "Win32, it's happenin'!
        .file   "SIMPLE.c"
gcc_compiled.:
.text
LC0:
.ascii "Win32, it's happenin'!\0"
.align 2
.globl _main
_main:
pushl %ebp
movl %esp,%ebp
pushl $LC0
call _printf
leave
ret

"
        .align 2
.globl _main
_main:
        pushl %ebp
        movl %esp,%ebp
        pushl $LC0
        call _printf
        leave
        ret

Now to assemble with the GAS Xenix assembler

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:

phoon.obj : error LNK2001: unresolved external symbol "___fixdfsi"
astro.obj : error LNK2001: unresolved external symbol "___fixdfsi"
phoon.exe : error LNK1120: 1 unresolved externals

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:

CC=gcc
CC1=cc1
AS=ax386
CPP=cpp


CFLAGS= -O
CPPFLAGS= -lang-c-c++-comments -nostdinc -I/xenixnt/h

OBJ =   astro.obj \
date_p.obj \
phoon.obj

LIBS = libgcc1.lib LIBC.LIB KERNEL32.LIB

phoon.exe: $(OBJ)
        link -out:phoon.exe $(OBJ) -entry:mainCRTStartup $(LIBS)

%.obj: %.c
        $(CPP) $(CPPFLAGS) $< $*.i
        $(CC1) $*.i -quiet $(CFLAGS) -version -o $*.S
        $(AS) $*.S -o $*.obj


clean:
        del $(OBJ) *.i *.S phoon.exe

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!

I then built the ’87 InfoTaskForce, Infocom interpreter, and it was just a simple link, and it’s running!

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!

For those interested in such things, I’ve uploaded all of this to archive.org here: windows-nt-196-linking-and-running-gcc