This was a silly side project that got out of hand, building an XP physical machine to run some old software. Over in the UK, there is this fantastical store, CeX that sells all kinds of retro crap, often for cheap. Normally I wouldn’t care but with pc titles going from £0.50 to £3 it seemed like some fun 1990’s computing value right there!
I had been slowly amassing a collection of bargain bin, garbage tier games ‘from back in the day’ and while I had been running a few on VMware on Windows 10, with that sub £5 copy of Windows XP home, it sadly didn’t help with so many games being copy protected.
I would need a physical machine, and that is where this hunk of junk the S20 fell into place.
S20 is way overkill!
When it comes to Windows XP, the S20 is no slouch. With 12GB of RAM, a Nehalem 3Ghz Xeon W3550 @3Ghz, 2x 120GB SSD drives, and a functional optical disk, this makes for a great system. Rounding out the absurdity is a Nvidia Quadro 4000 with 2GB of VRAM. I’m pretty sure when XP was new I was still using a PII 233Mhz with 256Mb of RAM. So yeah, this is way overkill.
Since all the disks are SATA, the default install CD won’t work. As a matter of fact, not much works on the retail CD-ROM. I tried to use rufus but…
Setup cannot find the End User Licensing Agreement (EULA).
I got this strange error from the USB stick. It appears after some searching it’s seeing the CD-ROM and trying to load the rest of the installer from there. Further searches said don’t use Rufus, instead use “WinSetupFromUSB-1-10“. I figured if I was going to use something like this, that I’d want some crazy pirated/hacked up to date version of XP to compliment the whole hacked up experience, so I went with the seemingly reputable “Windows XP SP3 Integral Edition 2022-6-16“.
WinSetupFromUSB 1.10
Options seemed to be somewhat straightforward, make sure it targets your USB drive! not any external backups. It does recommend you reformat with NTFS & set the alignment for a much needed speed improvement. Other than checking a few boxes to make sure it’s got the BTS driver pack & it’s a 2000/XP/2003 from USB install it pretty much worked.
After rebooting to the USB, be sure to select the
By selecting this option it’ll inject the needed ‘modern’ disk drivers. Otherwise it just wont work (EULA error or inaccessible boot device).
If everything goes well it’ll have injected a tonne of drivers, allowing the install to work.
Once the text part of setup is completed, be sure to boot off the USB again, again choosing option 1 to Auto-detect and use SATA/RAID/SCSI, but then choose option 4 for the Second part of the Windows XP setup.
Windows PE?
From here the setup feels very Windows PE. I suspect it is, but it’ll continue basically unattended and on it’s own. From here you can just boot directly from the hard disk, once it’s finished installing. It will prompt for the USB stick again to add all the additional options
Optional options!
I didn’t know what to exclude or pick, So I just chose them all.
It did take about 20 minutes, but at least by the end I did have a very usable XP install.
Trying the first Quadro Driver I could find, and I got knocked down to 640×480 in 4bit colour. It sucked. I don’t know what the deal was.
320.92 is the version that worked for me!
Working Video
With video working, the next step is all the reaming device drivers. Ohver on Phils Computer Lab, he had mentioned snappy driver installer, but the first link I hit on google was some virus loaded thing. Luckily since this is a fresh install it wasn’t at all painful to shove the USB back in and format the machine. I think I was also spared a lot of damage as it was constantly failing with a “bcrypt.dll missing” error. Saved by being obsolete!
Instead, I found the one on sourceforge.net, and it was working as expected.
Adding the audio drivers took a few attempts at installing stuff, rebooting, trying the windows auto-detect, rebooting, re-running snappy driver, and a few more reboots, and I got the NVIDIA audio and the built in audio working.
Overkill XP
One thing is that some games fail entirely on XP. While GTA: Vice City had been running on Windows 10, it fails to do anything on XP. Older games with Win16 setup programs do run but Games like Links LS 1999 fail completely to run. I think the system has both too many cores, too much RAM, and it’s just plain too fast.
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!
I am not much of a chess player. That said one thing that has annoyed me to no end is GNU Chess 1.2. Over on bitsavers is this fun directory:
And despite being a treasure trove of ancient GNU software, I have never been able to get GNU Chess to do much of anything. At best it’ll give the Chess prompt, and then it’ll either crash (good!) or worst case it just exits silently with no reason given.
I have put only minimal effort into debugging it, and really got nowhere. I don’t know why this is such a tough beast to deal with, or why I even care. As I mentioned above, I’m not much of a chess player.
But for some reason this time around I thought I’d try the earliest release quality Visual C++ to build it. I wasn’t expecting much, however for some reason this ancient version seems to run.
I had to enable a few things such as the RANDOM & HASH to make it look like it wants to play. I ended up having to make some changes after a draw or victory as the ‘self playing mode’would keep going. Not sure what’s going on there, and I added a line at the end of the logic loop to always print the board, so at least you can see what is going on if you have it playing itself.
With that said this is the most ridiculous thing I’ve seen:
Given I don’t have any good rusage emulation going on (I know its in MinGW at some point, and I probably can find it, and get it running on MSVC but I don’t see that as important) an 8 move victory seems pretty… unlikely?
Maybe it’s a good test of other C compilers to see if they produce anything. Or maybe it’s all a red herring? I haven’t tested with much but GCC 1.40 can’t even run it on x86. Watcom 10 can build, but it crashes during a self game.
It’s one of those mysteries, that I’m sure there is some fundamental lesson, but I’m not sure what it is.
Other than it’s a long way down, standing on the shoulders of giants.
In my “C:\Program Files (x86)\Windows Kits\10\Emulation\Mobile\10.0.14393.0” directory I have a modest 2GB file called flash.vhd which contains the phone image. I copy it to where I run my VM’s and run it with the XDE emulator:
And I’m running in no time, I login, load some apps, then I notice the storage:
What is this, a phone for ants?
What?! the disk image is a paultry 10GB. I guess the idea is that you wouldn’t actually try to load up the emulator like it’s your daily driver, rather you load YOUR app and only YOUR app, and just pretend that this isn’t some weird offshoot nostalgia machine.
Well needless to say something needs to be done about this storage situation.
I look and find this package, vhdutils. I had to go to some sketchy site, but it did include source. I should put this somewhere more legit to take away from all those weird squatters.
So with stuff installed onto my phone I’m almost at 7GB physical 7.6 virtual space. I could go all crazy with 128 or 256GB but it’d largely be stuff I bought… which of course thanks to the magical world of DRM won’t play.
Yeah I guess you are welcome that I bought all those movies, and stuff but sure I wasn’t going to watch them on this phone… emulator. Thanks. thanks again.
So the resize vhd is quick. brutal. and efficient. I go with 64GB, because, why not? I could probably just grow it again if I needed to.
Now for the fun part. We need to attach the vhd, and resize the volume. I hope you like diskpart.
In the MMC I attach the disk image.. it’ll pop a few folders as it’s got a bunch of drive letters. I’ve never explored a phone, I don’t know if the ARM images are just as weird.
Even more strange, it’s MBR!
So if you were thinking, lots of partitions, and a clear win for GPT, sadly this isn’t it.
Sadly there is no free partitions (although one hiding could be deleted…?) And the UI doesn’t support expanding a logical drive (the green container). But diskpart does.
As indicated above the emulator’s vhd is disk3. You can see it’s the 64GB disk. Select it.
Next list the volumes. The Data disk (J:) is what we want so select Volume 10.
Literally just ‘select volume 10’ and ‘extend’. Don’t tell me this is difficult.
Listing the volumes again will show a 59GB Data partition. Congratulations we did it!
Back in the MMC, you’ll see it as well how the Data partition, along with the green extended partition is now taking up the entire disk. So we can now Detach the VHD, and run the emulator again!
Nice!
And just like that we now have plenty of free space on the emulator.
I downloaded some games, and some music. It’s nice to be back home.
It’s not an extensive list as I didn’t game much on my phone but here is what I know works:
Final Fantasy 1
Heroes of Larkwood
Skulls of the Shogun
Sonic CD
FL Studio
Candy Crush Saga
Pixel Dungeon +
Halo Spartan Asslt just closes, and Asphalt 8: Airborne doesn’t get the screen size right so it’s impossible to click enough buttons.
Sonic CD on Windows Phone 10
It’s nice that sonic runs, (haha) although using a mouse makes it impossible to control.
Now one fun thing is that the emulator is x86, nor ARM based so I converted the VHD to a VMDK, ran it under VMware, and YES it RUNS… sort of.
Perhaps a format that never was to be, the Phone/Tablet but it boots quickly and is so responsive. Windows without most of the .. Windows bits. I guess the real experiment will have to be will it run on a Surface?
It’s all 32bit anyways, and such an evolutionary dead end. Pitty.
A long long time ago, in a distant continent I once interviewed at this small company called Citrix. It was some QA position, they didn’t need programmers. I’d passed the interviews easily as I’d been programming serial TSR’s so I was hip to the 8250/16450. Citrix was an interesting but troubled company. They had incredible contacts and more importantly a deal from Microsoft that gave them access to OS/2. Sadly OS/2 1.0 had been a dud, and by the time OS/2 2.00 saw even a limited release, Microsoft had pulled out of OS/2. Citrix was a company that had lost twice in what should be a big market. -Multi user commodity systems.
Citrix Multiuser 1.0 was based on OS/2 1.21, and was limited to 16bit protected mode apps. Citrix Multiuser 2.0 was based on the Limited Availability version which means that it cannot run “GA” or General Availability programs. So no 32bit programs here. Instead it can run the same 16bit protected mode applications, however it can also run MS-DOS based programs. DOS4/GW programs run so oddly enough the only real commercial stuff that can be run is MS-DOS.
So here we were 1994. Citrix had struck out twice, but this time it was going to be different, but the deal had to be re-struck again. I have no idea how they managed to secure this lucrative deal again, but Citrix was able to get access to the source access Windows NT, after the 3.1 release to 3rd parties (when they got DEC involved). By now the world had gone Windows, Office 4.2 was a thing, and on the high end side, NT had SQL & SNA, and there was most defiantly a market for multiuser systems as there had been from the old days of Unix, with the old mix of ASCII and network graphical terminals.
The CD looks like a normal-ish NT 3.5 Server CD although there is no MIPS or Alpha builds, as expected everyone at Citrix would be working and targeting the larger established i386 market.
As you can see this is Beta build 101.
In the text mode setup it looks like a normal setup program. No doubt they had better things to do than skins, wallpapers and themes. HOWEVER there is a silent IDE bug that many people will no doubt run into:
Although it works okay in short bursts, the IDE driver will send a command 28 zero byte and then shut down the controller. From this point it hangs. So that means we either need to generate all the floppy disk images (not going to happen!) or do the MS-DOS cross install. Yeah I’m doing that instead.
When setting up under Qemu, use the AMD PCNET card. It’s much easier. I set it to Twisted Pair, and PCI bus. I’m not sure if those matter all that much, but it works for me!
If you are going to use Hyper-V, you’ll need the GF100 NIC driver, but use the Windows NT 3.1 driver, as this is technically a beta of NT 3.5 and the production 3.5 driver will blue screen.
I set the driver to autosense.
I also had both Qemu and Hyper-V bluescreen when doing DHCP. I don’t know what the issue is, and I’m too old to care as I don’t have source code to South Beach, and even if I did I’d probably regret posting fixes. So static IP address it is!
Ready to login
Honestly again the air in the office when I was there is that everyone was running around like crazy to QA the product, and get ready to expand client support. While I was too much of an OS/2 fan boy, they certainly knew that from now on everything was going to be about Windows NT.
Logging into the Citrix the first fun thing to do is to define some remote terminals, using the WinStation app.
The first interesting thing is that async terminals are supported. Along with using either NetBIOS or Winsock protocols for connecting clients. Isn’t that great! TCP/IP built in!
Now for the crazy part. The only client that works is MS-DOS based. Yes there is no Win16, no Win32, no Java, no protected mode DOS, no Linux, SunOS, Solaris, DG/UX, AIX, HPUX, Xenix, UnixWare or SYSV i386ABI. ONLY Real Mode MS-DOS. Despite the connections being able to be ICA version 2 or 3, they are incompatible with newer Windows based clients from Win Frame.
This it the following list of supported protocols. Although I had Novell Lan WorkPlace and used it before for Desqview X, I can’t find it at the moment. good luck finding FTP TCP/IP, in retrospect it’s a terrible name, and for all intents and purposes it’s disappeared from the earth. So that leaves Microsoft TCP/IP. Now all the LANMAN clients have it, although this isn’t what it wants. It wants the MSCLIENT found in the “\CLIENTS\MSCLIENT\NETSETUP” path from a retail version of NT Server 3.5
The DOS client is.. very touchy. Deleting profiles can lead to a corrupted profile. Altering existing profiles well yeah can lead to a corrupted profile. I thought it was EMM386 causing issues but it locks up on it’s own.
Revenge of text mode UI
One interesting thing I found is that the text mode UI didn’t die. It’s still very much alive. As mentioned above you can connect async terminals, or even connect over the network!
Text mode does bring up a Program Manage analogue, but all my programs are graphical so it’s kind of moot. But rest assured text mode stuff works great.
PowerStation Oregon Trail
So 32bit Fortran stuff works great, what about MS-DOS?
Here is MS-DOS / Qbasic editor. Running on Citrix South Beach! Great, what about OS/2?
OS/2 F2C Dungeon
And here we go running the f2c translator through Dungeon to get an OS/2 text mode app. As you can see forcedos reveals that this isn’t a bound executable, instead it only runs on the OS/2 subsystem.
As you can see the os2.exe/os2srv components of the OS/2 subsystem
And of course it looks better on the graphical client to mix and match them all.
Obviously somewhere post South Beach the text mode stuff dropped off. I’ll have have to dig for more, but it’s kind of neat the idea of a real text mode NT. Sadly South Beach doesn’t seem to like VMware. I haven’t dug too far, as I like WSLv2 so I’m stuck with Hyper-V. It may work fine on ESX I haven’t tested. Obviously you need the appropriate drivers, ill try to update links later, if anyone cares.
No doubt that finally Citrix was no positioned to realize the dream of multiuser commodity based hardware along with commodity applications. Of course it wouldn’t be all sunshine and rainbows, and no doubt there was a toll needing to be paid between Windows NT 4.0 and on the way to Windows 2000. But back in 1994, things were looking good!
This is something that honestly deserves so much more. Back in the original scope of NT OS/2 it was going to be a C parallel of OS/2 2.00 Cruiser that had the promise of running on one of those new fangled microkernels, and those trendy RISC workstations. The 486 / Pentium were considered like the 68040/68060 to be the peak of CISC processors and from there on it was going to be a RISC world, the only question was to be which one?
Many of the Motorola customers who couldn’t afford to make their own (SUN with the SPARC), or license a school project (SGi with MIPS) were expected to use the 88000 processors that were expected to eclipse the 68040. There was an Apple initiative, and even a NeXT RISC Workstation built among many others. Only with the launch of the 88010 it was discovered performance was nowhere near expected and it’d take significant work to fix.
Back on the i386 side, Microsoft had been working with Intel on their upcoming RISC, the NTen aka i860. And just like the 88000 it too had performance issues, which resulted in Microsoft retargeting the MIPS.
Things changed along the way, and not only was the primary CPU platform dumped, but Windows 3.0 became such an incredible seller that OS/2 Cruiser was dumped from NT OS/2, and it became Windows NT. NT had been promised with the ability to run OS/2, MS-DOS, and POSIX applications, with an emphasis on Win16 and the new extended Win32 applications. However MS-DOS was super limited, POSIX was just enough to run vi & tar, Win16 was incredibly slow as it ran through WOW (Windows on Windows), and OS/2 had been kneecapped to the 16bit 1.x support as it was primarily a vehicle for running Microsoft SQL Server 1.0/4.0 . Another consequence of this is that OS/2 was command line only. In the back of deployment guides, and resource kits there was always an inference to a Presentation Manager subsystem for NT, although I’d never seen one in the wild.
Until I got a hold of a bunch of Microsoft Select CD-ROM’s that mostly were multilingual service packs of Office and Windows 98 / NT 3.51 & NT 4.0 But burred in there was a copy of Presentation Manager for NT 3.51!
First off it’s a text based install. It feels like October 1991 all over again. It installs a parallel OS/2 directory with presentation manager support.
Once it is installed it’ll setup program icons from the Windows NT side. Presentation manager runs in a separate window from the GDI. This is akin to how OS/2 would run Windows in a ‘full screen’ session. So oddly enough both support each other’s 16bit applications full screen, while reserving the desktop for 32bit applications. IBM would later introduce dual mode video drivers capable of rending Windows and OS/2 applications at the same time. Clearly Microsoft would never do this.
Launching the control panel reveals that it’s OS/2 version 1.3. No big surprise there. You can return to the Windows NT desktop either via the Windows NT icon in the bottom right, or via a Control+Alt+Delete.
The DeScribe 3 beta installs pretty smoothly into the subsystem. However running Describe is a different story:
It hangs trying to open or do anything. Even the ‘help about’ is too much. Such a pitty.
The readme warns against trying to copy the file manager from OS/2 although it does tell you what files to copy in manually. Naturally there is no ‘console’ for Presentation Manager, rather that is handled on the Windows desktop.
No doubt there had to be some big customer that demanded a way out for their investment in Presentation Manager on Windows NT. Otherwise this would have been built in. And it’s only 5 diskettes so it’s not a space issue. I suspect since it was on a Select CD, it really was not meant for wide scale distribution.
Last time I tried, Excel 3, and Word 1 had issues running on Windows NT, as the loader tried to intercept them as Win16. Things didn’t go so well. Or maybe it’s my memory. I went ahead and installed Excel 2.2 for OS/2
Despite it being text mode, it has Presentation Manager hooks, and needs PM Shell to be running. It’s a simple setup program, but yes, it’s text mode.
One nice thing about Describe & Excel is that they can see the program groups on the NT side, and create icons over there. However NT has no ability to read OS/2 resources so the icons are all incorrect.
And yes, Excel for OS/2 runs on Windows NT! Back then Excel was super expensive, this is before the big Office OEM bundles that took over the industry. So I could totally see preserving this massive investment in Excel.
Despite having 80286 emulation in the earlier versions of NT, and 80486 emulation in Windows NT 4.0 (Yes DooM runs on the MIPS!) the OS/2 subsystem was never available on the RISC platforms. I suspect had Windows 3.0 not been a big seller it may have. Then again without the big ‘rabbit out of a hat’ like DOS Extenders, Windows would have died on the vine. Who knows, maybe NT OS/2 is a thing in a parallel universe.
(This is a guest post from Antoni Sawicki aka Tenox)
I have been living under a rock for several years now when it comes to Windows development. Recently wanting to do some maintenance on couple of my projects I needed to download Visual Studio and Windows SDK. Poking around the download page I have discovered that Microsoft now provides a fully pre-installed VMs with Visual Studio, SDK etc. for VMware, Hyper-V, VirtualBox and Parallels. That’s actually super cool and handy. Thank you Microsoft!
Looks like this has been available for 3 or 4 years now. Oh well.
32bit computing arrived to the masses. Although it’s incredibly frail by modern standards, Windows 95 did deliver on the promises of OS/2. Depending on your apps, and drivers of course. Although OS/2 did have int13.sys to pass disk calls to a special v86 machine which then used the disk BIOS to make disk access possible, Microsoft and IBM stopped short there, not going all the way letting OS/2 use MS-DOS device drivers. Windows 95, however could.
This was always the winning strategy of Windows, is that it relied on the incredible OEM driver support for MS-DOS. Of course this would also be a catastrophic weakness. From my personal experience being able to leverage ancient MS-DOS drivers also helped squeeze as much as possible out of existing hardware. Case in point, the NDIS2 drivers for the AT&T Starlan 1mbit cards worked fine under Windows 95, additionally you could lost just the lower level drivers, and 95 could then load it’s protocols on top of that stack allowing you to have a TCP/IP network over that 1mbit Starlan stack letting you telnet into your 3b2 (or setup SAMBA, and doing file/print sharing).
If anything the biggest flaw of Windows 95 was not installing TCP/IP by default. However unlike many OS’s of the time, Windows 95 did include LAN and dialup stacks. There was plenty great about OS/2, but it’s refusal to integrate networking into the operating system hamstrung things like named pipes, peer, and larger apps, as you would have to buy and license a stack of stuff to bring OS/2 up to where it should be, while NT and 95 were complete out of the box.
Windows 95 was an excellent bridge OS for the era, until OEMs finally got around to writing drivers for Windows NT. Once the mainstream could finally take that leap, and leave MS-DOS far behind. But that didn’t really happen until Windows XP.
That being said, the favorite thing is to run Windows 95 in a browser. I found https://copy.sh/v86/ the fastest and best, as it loads a short 6MB compressed core image, and you are instantly teleported to the 95 desktop.
I have this old toolchain that relies on MSYS 1.0 from 20+ years ago. It’s great. I know others always love the newer, but I’m happy with this one.
Well this morning I wanted to rebuild some Qemu 0.90 thing and I got this fun error trying to run configure:
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x440000, State 0x10000
d:\mingw\msys\bin\bash.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0
What the heck?! MSYS uses cygwin? I guess I should have known. So the solution is to ‘rebase’ the DLL, as it tries to take a static ‘grab’ at some memory block, because…. I guess subsystems or loaded DLL’s suck?
I rebooted and got the same error.
So obviously it’s a lot more involved.
So looking the rebase I have is part of the Platform SDK. Maybe there are others.
D:\MinGW\msys\bin>"D:\MinGW\include\directx\Microsoft Visual Studio 8\VC\PlatformSDK\Bin\rebase" -b 0x50000000 msys-1.0.dll
REBASE: Total Size of mapping 0x0000000000110000
REBASE: Range 0x0000000050000000 -0x0000000050110000
And now I can run stuff again. YAY.
I’m sure this has been covered time and time again, but you know it’s mostly to remind me in another 20 years.
