Well what is it? Basically it’s just enough of the UNIX/POSIX standard to check a box that gave Windows NT an in for US Government contracts that required a POSIX checkbox. And nothing else more. It’s basically agreed that it’s just enough to run ‘vi’ and that’s basically it.

But surely we can probably do more with this?

The first fun part is that setting up the environment is basically UNDOCUMENTED. It was a nightmare back. then, as you need to setup a termcap environment that again is not mentioned. The only hint is is an old KB article Q108581, which sets out the vauge guide. I do know that back in the day I did have vi running, but I can’t remember how I did it exactly but wow.

The first thing you need to do, naturally is install Windows NT 3.1. I did have access to this fun CD back in the day, it’s a combination Windows NT 3.1 Workstation +SDK CD-ROM. This way you not only get the operating system, but you also now have the C compiler, libraries and headers. Once setup, there is even a POSIX sample program. Great? Well, no. Because this doesn’t include the OS environment, there is no previous ‘vi’ either. Very sad. Naturally you need another CD to install, which of course back in the day if you were going to use or support Windows NT, you’d naturally run out or order the Windows NT Resource Kit. These were absolutely required back in the day as the ‘task manager’ only at best would show you named windows, it doesn’t show you the actual processes, making managing NT a nightmare without pviewer. (process viewer), among others.

On the Resource Kit is not only a tiny ‘userland’ but also it includes Elvis a vi clone, along with a much needed ‘cc’ wrapper that will let you invoke the SDK C compiler as if it’s the Unix cc C compiler command.

Elvis was written by Steve Kirkendall, back in the day, and even on Linux back in the day, I was using Elvis as well. Remember ‘real’ vi was tied to needing a 32v / BSD source license so it wasn’t free.

/* Author:
 *      Steve Kirkendall
 *      14407 SW Teal Blvd. #C
 *      Beaverton, OR 97005
 *      kirkenda@cs.pdx.edu
 */

It’s just how things were back then.

To make things weird, I installed Windows NT onto a HPFS partition, because I wanted long file names, but I didn’t want to have a case preserving filesystem, as these old things have so much UPPERCASE/lowercase naming conflicts, because YES as a feature of NTFS & POSIX it really does support Mixed case naming. And I don’t feel like dealing with it, and it’s 1993, and HPFS is still a popular filesystem for us OS/2 users.

Okay, so you’ve installed both the SDK & the resource kit, surely you can just run vi?

No. No you cannot. Remember you need that TERM variable and termcap library!

Now to save you the hassle you’ll go back and check Q108581 and you’ll see this example:

li|ansi|psx_ansi|:\ 

            :co#80:li#25:\ 
            :am:pt:ms:bw:\ 
            :cl=\E[2J:cm=\E[%i%d;%dH:ce=\E[K:cd=\E[J:\ 
            :sf=\E[S:sr=\E[T:\ 
             :ho=\E[H:sc=\E[s:rc=\E[u:up=\E[A:d=^J:nd=\E[C:le=^H:\ 
             :ku=\E[A:kd=\E[V:kr=\E[C:kl=\E[D:kb=^H:\ 
             :so=\E[7m:se=\E[m:mr=\E[7m:me=\E[0m:\ 

copy paste and and, yeah IT DOESNT WORK. Like something being passed endlessly through a photocopier, it got mangled in usenet (maybe where I found it?) , and yeah you need to ‘fix’ it up as it should look more like this.

Or for anyone hoping to copy/paste:

li|ansi|psx_ansi|:\
	:co#80:li#25:\
	:am:pt:ms:bw:\
	:cl=\E[2J:cm=\E[%i%d;%dH:ce=\E[K:cd=\E[J:\
	:sf=\E[S:sr=\E[T:\
	:ho=\E[H:sc=\E[s:rc=\E[u:up=\E[A:d=^J:nd=\E[C:le=^H:\
	:ku=\E[A:kd=\E[V:kr=\E[C:kl=\E[D:kb=^H:bc=^H:\
	:so=\E[7m:se=\E[m:mr=\E[7m:me=\E[0m:\

Note that the leading ‘tab’ actually matters and there should be NO empty spaces at the tail backslash! If that tab or ending \ is padded or wrong it just plain will not work. I wasted so much time before realizing the craziness of this setup.

Okay.

Thinking that’s enough you have to keep reading, as the POSIX environment has no idea what c: is, or how to set variables, so you need to specify the full NT path, not the Win32 path

To save the adventure some time this is what I end up just putting into a CMD file so I can just click and go!

@stitle posix
@set PATH=c:\bin;%PATH%
@set Lib=c:\mstools\posix\lib;%lib%
@set Include=c:\mstools\posix\h;%include%
@set TERM=ansi
@set TERMCAP=//C/etc/termcap
@set _POSIX_TERM=on
@set TEMP=
@set tmp=
@set INCLUDE=
@set include=
@set lib=/usr/lib
@set tmp=//C/tmp
@set temp=//C/temp
@set MAKEPATH=//C/posix/src/MK-RULES
@cls
@sh

Now with a corrected environment for POSIX and a termcap file, now we can actually run VI/Elvis!

This is what success looks like!

Now I know what you’re thinking okay, were setup now, we can just build something simple like say a hello world style program right? I made a simple Makefile, and let’s go ahead and try to invoke the ‘cc’ compiler wrapper:

And it just hangs, doing nothing. As it turns out that the ‘cc’ wrapper uses a file for IPC to talk between POSIX & WIN32. Remember they are separate personalities on the NTOKS kernel, and they cannot directly communicate with eachother.

I don’t know why they didn’t use a named pipe, maybe POSIX cannot write to them? Maybe when they were writing the POSIX subsystem, named pipes weren’t working yet? It’s hard to say, and the early NT 3.1 pre-releases don’t included the POSIX, or OS/2 subsystem. Actually they don’t even have the NTVDM/MS-DOS/WoW either.

So you need to run something called ‘devsrv’ which is a Win32 program that looks for c:\tmp\ for devsem.ini file telling it what Win32 program to run and how. For example, in this case it looks like this:

Now if you think you can just blindly run devrv, you’ll 99% of the time be in for a bad time as you need to initialize a working Win32->POSIX cross environment. Me being, me I just put this into another CMD file:

title devsrv
@set PATH=c:\bin;c:\mstools\bin;%PATH%
@set Lib=c:\mstools\posix\lib;c:\usr\lib
@set Include=c:\mstools\posix\h;c:\usr\include
@set TEMP=c:\temp
@set tmp=c:\tmp
@c:\bin\devsrv

I’ve already started to place headers & libraries into a more ‘UNIX’ like path structure with /usr/include & /usr/lib although by default the MSFT scripts expect things to live in the SDK world. But I do have goals of running GCC and dealing with weird paths isn’t my goal as the less I have to fight, the better.

Now with devsrv running it cannot call the C compiler, and the linker. It will fail at first as it’s expecting to link against NTDLL.LIB as in the Pre-release/Beta days there was a ‘ntdll’ you had to link against. It isn’t there in the RTM Windows NT, so it’s kind of clear that although POSIX shipped it was basically abandonded during the development cycle, and nobody expected anyone to actually do anthying with it. Or at best find the KB article and maybe run vi.

Or you could just fix & rebuild the linker proxy, ld.c and remove the offending line:

char *def_lib[] = /* Default library */
{
   "libcpsx.lib",
   "psxdll.lib",
   "ntdll.lib",
   "psxrtl.lib",
   SNULL
};

And re-compile. Which of course is time to show yet another CMD file that sets up a Win32 environment enough to cross compile to POSIX:

title posix cross
@set CPU=i386
@set PATH=c:\posix\bin;c:\mstools\bin;%PATH%
@set Lib=c:\mstools\posix\lib;c:\usr\lib;%lib%
@set Include=c:\mstools\posix\h;c:\usr\include;%include%
@set TERM=ansi
@set TERMCAP=//C/etc/termcap
@set _POSIX_TERM=on
@set TEMP=c:\temp
@set tmp=c:\tmp
@set MAKEPATH=C:\posix\src\MK-RULES

So now I can build things from the Win32 side of life, like the LD proxy, or even ‘cross compile’ a simple enough hello world from Win32:

See wasn’t that fun?!

Since I already have a version of GCC-1.40 building with the Microsoft C compiler this seemed like a great leg up on building a POSIX version. And naturally to make it more complete building bison-1.16 is also required. Since I have Bison building on normal Win32, this wasn’t much of a problem. The weird hurdle came in the C Preprocessor where I found out that POSIX is missing some seemingly vital stuff like fstat!

int                 
file_size_and_mode (fd, mode_pointer, size_pointer)
     int fd;
     int *mode_pointer;
     long int *size_pointer;
{ 
#if 0
//this is missing from posix
  struct stat sbuf;
  
  if (fstat (fd, &sbuf) < 0) return (-1);
  if (mode_pointer) *mode_pointer = sbuf.st_mode;
  if (size_pointer) *size_pointer = sbuf.st_size;
#endif
  return 0;
}

Also, for some reason I can’t link any real programs that call unlink, I have to proxy that to a stub file that has no includes, define unlink as Xunlink, then link against that stube and it all links fine. I know WTF?! I don’t get it ether. But I wanted to build stuff so these are… tradeoffs that I made to just short-cut the whole thing. Maybe I’ll go back and look and try to figure it out. As I see in the POSIX util source mutiple things call fstat, so maybe it’s happier when linked from Win32?

To complete the round trip, since we already know the Link386 from the SDK and early Visual C++ will happily accept Xenix OMF files, I can use the GNU Assembler that targets Xenix, and then get a round tripped GCC on POSIX NT!

And there we have it!

Installing it for the BRAVE

I’ve gone ahead and uploaded my working directories to archive.org here: POSIX-4.

I guess I could have found my old zip/unzip for NT 3.1 but I didn’t I stuck to PAX which surprisingly is in NT 3.1. It’s not quite as friendly as TAR but you can copy posix4.tar to the C: drive and just extract it with ‘pax -r -f posix4.tar’

I should note for some reason trying to extract it from my tranfer disk, causes a BLUESCREEN in the HPFS device driver on NT 3.1… Bummer.

Once all the files are unpacked the first thing I do is make a Program Item on Program Manager for the Posix shell. All the hard work is done, you just have to path it to c:\posix\shell.cmd

This is how I setup mine, so YMMV

And the last part is the DEVSRV. This is how I setup mine, with the emphasis on running minimized. It does and can crash from time to time so I wouldn’t try to wrap it as a service or anything that creative.

And then I move mine to the startup items, so that way, every time I login, I now have the devsrv all ready for my POSIX experiments!

Now you can just logoff/log back in, and you are ready for some POSIX GCC adventures.

It’s a shame that back then I just was totally unaware of that Xenix OMF GAS version. I pretty much had given up on Xenix 386 back then, as I never could find the developer’s kit, as they had gatekept people off the platform. Linux is where all the excitement was, as not only did it have GCC, but you also had full source. Even if I’d had access to GCC on Xenix, with no libc no headers it wasn’t going to go very far.

Credit to Microsoft though, they did learn with that $3,000 OS/2 SDK, that if you paywall the low end developers away, nobody writes for your platform. Although Microsoft did lose their way on this when they stopped QuickC, forcing new users to pay for the full thing. They didn’t realize how much territory they ceded by charging for the C compiler to GCC until it was too late, as all ‘starving university’ kids are GNU kids now (Yes I know CLANG is where it’s at today, thats’s Apple’s lesson I guess in there). By the time they did free as in beer limited “Visual C++ Toolkit 2003” it was already far too late.

The POSIX subsystem was never going to be all that useful, as it was pretty clear if NT became a competent UNIX, nobody would write Win32 server software. But considering one of the best features to be added to Windows 10/Server 2016 was the WSL subsystem, we already crossed that bridge.

Addendum

I thought it’d be ‘fun’ to do this from Citrix as it easily allows me to map drives making life MUCH easier, but nothing worked. I went thorugh installing NT 3.5 it’s SDK and Visual C++ 2 and noticed that nothing ran on that either. Maybe it’s Qemu?

So I just jumped forward to NT 4.0, because why not??

Turns out it doesn’t work either.

Well sure vi does work, but the whole ‘cc’ cross thing is just plain deprecated after 3.1… It’s like whatever attempt at POSIX being useable was fully given up on. The only other interesting thing on the NT 3.5 resource kit, is that it does mention GCC being part of the kit, but obviously that never happened. Politics I suppose.

So now I really remember why I never really bothered with the environment, as it basically became unusable by Windows NT 3.5

Running at home!

I’ve gone ahead, and uploaded the source to github, and included a binary release. So you can try this on your own Windows NT 3.1 machine, or try the fight with NT 3.5 or higher and go through the fight yourself.

https://github.com/neozeed/windowsnt31_posix

And yes, I did get hack-1.03 running!

Building on previous work, where I had built GCC 1.40 using the OS/2 hosted Microsoft C compiler that shipped with this Pre-Release, and using MinGW to build Linux 0.11, it was time to combine the two, like chocolate & peanut butter!

Getting NT ready

The first thing I wanted was to install the Pre-Release onto a HPFS disk. I’ve uploaded this over on archive.org (Windows NT December 1991 prepped for Qemu). I took the CD-ROM image, removed all the MIPS stuff, built a boot floppy, and setup the paths so that the floppy can boot onto the secondary hard disk to a ‘full’ version of NT. This lets me format the C: drive as HPFS, and then do a selective install of Windows NT to ensure that that the software tools (compiler) are installed.

I use a specially patched vintage QEMU build, qemu-0.14.0.7z which kind of makes it ‘easier’, along with the needed disk images in dec-1991-prepped.7z

qemu.exe -L pc-bios -m 64 -net none -hda nt1991.vmdk -hdb nt1991-cd.vmdk -fda boot.vfd -boot a

This will bring up the boot selection menu. The default option is fine, you can just hit enter.

NT will load up and you now have to login as the SYSTEM user. We need the advanced permissions to format the hard disk.

From the desktop we first format the C: drive as HPFS. I made icons for all this stuff to try to make it as easy as possible.

You’ll get asked to confirm you want to do this, and give the disk a creative name.

And with the disk formatted it’s time to start the setup process.

Who are you?

And what slick account do you want? It doesn’t matter tbh.

I’m going to do a custom install as the NIC’s aren’t supported, and even if they were it’s just NetBEUI anyways.

And select your hardware platform. NT basically only supports this config, so it doesn’t matter.

The default target drive is our C drive, which we had just formatted to HPFS.

Next, I unchecked everything only leaving the MS Tools

It’ll offer the samples & help files. I always install them as I eventually need examples of stuff to steal, and to learn that including <windows.h> won’t work right unless you manually define a -Di386 on the command line. I’m saving you this pain right now up front.

Files will copy, and on a modern machine this takes seconds.

And there we go!

And Windows NT is installed.

Yay.

I put in a ‘CAD’ feature in this Qemu hitting control+alt+d will send the familiar pattern, and after a few times NT will reboot. We are pretty much done with NT for the moment, but congrats you’ve installed the December 1991 Pre-release onto a HPFS disk for those sweet long long file names!

Going over the strategy:

I’ve already built GCC 1.40 for NT, so what is the rest of the stuff needed to build Linux? It’s a quick checklist but here goes, in no specific order:

• GCC 1.40
• bin86
• binutils
• gas 1.38
• bison
• unzip
• zip

Luckily as part of building on Windows 10 using MinGW, I had fixed the weird file issues as MS-DOS/Windows NT/OS2 handle text/binary files, as we went through with how Github mangled MS-DOS 4.00.

The primary reason I wanted a working zip/unzip was to deal with long file names, and to auto convert text files. And this ended up being an incredible waste of time trying to get the ‘old’s code on the Info-Zip page.

I’m sure like everything else, the old versions are removed as they probably suffer from some catastrophic security issue with overflows. The issue I ran into is that the version 5 stuff uses so many features of shipping NT, to even 2000 that it was going to be a LOT of work to get this far. The quicker & easier path as always turned out to be a time machine.

Thankfully, since I had made a copy of the UTZOO archives, I was able to fish out, both version 3.1 from the archives. Also known as “Portable UnZIP 3.1”, parts 1/2/3. I also found version 4.1 as well. And people wonder why you want to save these ‘huge’ data sets. If the lawyers could have their way, they would obliterate all history.

I spent a lot of time messing with Makefiles, as linking & object conversion on old NT is a big deal, and not the kind of thing you want to do more than once. Another big pain is that large files become delete only. I don’t know what the deal with notepad is, but I could remove text, but not change or add. I solved that by wrapping a number of things by including it in another file with some #define work to go around it. Needless to say, that sucked.

One thing that constantly threw issues is that this version of Windows doesn’t handle Unix style signals. I removed all the signal catch/throw stuff, and the binaries ran fine. Why on earth does ‘strip’ need signals is beyond me, but it runs fine without them!

Bringing it together.

From my “Build artifacts from Building Linux 0.11 on Windows NT build 239, December 1991” page, grab the two files, bin.zip & source0.zip.

On Windows I just unzip the bin.zip file and leave source.0.zip intact into a directly say something like temp. Then I can use a cool feature of Qemu where it can mount a directory as a read-only FAT disk. This saves a lot of time!

Running Qemu like this:

qemu.exe -L pc-bios -m 64 -net none -hda nt1991.vmdk -hdb fat:temp -fda boot.vfd

Will drop to the bootloader. Hit enter to login, and you’ll be at the desktop. Hit enter again, and open a command prompt.

By default, the Numlock is messing with the arrow keys (I think it’s mapping to the old 83 key keyboard no matter what?) Hit num-lock and your arrow keys should kind of work. It’s a great time saver.

I copied the binaries & the ygcc.cmd file into the \bin directory, created a \proj directory and get ready to unzip all the source code. For some reason this version of unzip doesn’t understand the zip compression, so it’s just storing instead, much like TAR. It’s not that involved but unzip with the -d flag so it creates directories as needed.

This will let us keep long file names. HPFS is case insensitive, but it also preserves the case, so don’t worry about the names being all weird. It doesn’t matter.

One thing worth mentioning is that even though the C pre-processor does compile it just hangs when trying to run it. I’m not sure what is wrong exactly, but it’s just not worth fighting. Instead, I had the better idea, of using the Microsoft C compiler to pre-process the source. Apparently, this is how they originally built Windows NT, pre-processing on OS/2, then uploading the pre-processed files to a SUN workstation with the i860 compiler and downloading the objects to be converted & linked. Wow that must have been tedious!

I created a CMD file ‘ygcc.cmd’ to run the cl386 pre-processor, call CC1 & GAS and clean up afterwards.

cl386 -nologo /u /EP -I\include -D__GNUC__ -Dunix -Di386 -D__unix__ -D__i386__ -D__OPTIMIZE__ %2 > \tmp\xxx.cpp
\bin\cc1 -version -quiet -O -fstrength-reduce -fomit-frame-pointer -fcombine-regs -o /tmp/xxx.s /tmp/xxx.cpp
\bin\ax386 -v -o %1 /tmp/xxx.s
@del \tmp\xxx.s
@del \tmp\xxx.cpp

It’s not pretty but it works!

Building

Before you can build Linux, you need to create both a \tmp & \temp directory. Also the include files need to be copied to the \include directory to make the pre-processor happier.

I’ve tried to make this as simple as possible there is a ‘blind.cmd’ file which I built that’ll manually compile Linux. There is no error checking.

And saving everyone the excitement here is an animation of the build process

And there we go! All compiled!

From there it’s a matter of copying the Image file out of the VM, I used the boot floppy and 7zip’s ability to extract FAT images, and then boot up Qemu using the Image file as a ‘floppy’ as back in the day we used to rawrite these to floppy disks.

qemu.exe -L pc-bios -m 64 -net none -hda nt1991.vmdk -hdb fat:temp -fda boot\IMAGE -boot a

I don’t have a root filesystem, so the panic is expected, but yes, we just cross compiled Linux from Windows NT, circa 1991!

This is a guest post by CaptainWillStarblazer

Hello, everyone. This is a continuation of my previous blogpost on EmuWoW (formerly win32emu) found here, but to summarize, I’m the 18-year-old developer behind a project that allows running applications compiled for the MIPS/Alpha version of Windows NT on standard x86 PCs through emulation, but without requiring a full system emulator. Since that last post, the project has made some substantial strides.

Since then, I’ve adapted the MIPS emulator from MAME, which is both more accurate and faster than my own (writing my own was a fun exercise but to the end of running applications, borrowing an emulator was a better decision). This alone enabled WinMine to function, which can be seen below.

Around the same time, another VirtuallyFun member named x86matthew entered the scene. His prior credits include a similar project, for Win16. He was inspired by the initial win32emu blog post, created his own similar project called WoWMIPS, which quickly started running a few simple apps, such as WinMine, Solitaire, and Notepad. Be sure to check out WoWMIPS – MIPS Emulator for Windows, Part 1: Introduction, and parts 2,3,4,5,6!

This had actually been what I was hoping for from the beginning; I always saw win32emu as a proof of concept for a smarter person (either myself in the future or someone else altogether) to come back later and do it better, and this is a massive undertaking for a single individual. What makes x86matthew’s WoWMIPS so incredible is its clean design. For one, there’s no thunk DLLs required. When an application tries to import a DLL, the host x86 DLL is first loaded, and then any attempts to get the address of an exported procedure from it are then redirected to an auto-generated stub of MIPS code which invokes the emulator to call the function. In other words, the thunk DLLs are generated at load time. Additionally, there’s no window procedure thunks required either. Instead, MIPS code pages are marked as non-executable, causing an access violation when Windows attempts to call them. Using an exception handler implemented via Windows XP’s Vectored Exception Handling feature, one can detect this and then invoke the emulator to execute the callback. Storing the CPU state in thread-local-storage allowed proper support for multithreading. I duplicated these design choices into EmuWoW, and the results largely speak for themselves. Unlike WoWMIPS (at time of writing), EmuWoW is still capable of loading MIPS DLLs (and will prefer to do so if possible), however.

To aid the process of fixing faults in the emulator, I hacked up a quick, minimal debugger into EmuWoW. First of all, there’s a “crash screen” which will indicate the type of error and dump registers and the current instruction if there’s a fault, and a running disassembly can be printed as you go, but most crucially, there’s a limited degree of interactive debugging functionality.

The main capabilities contained herein are dumping registers and memory to the screen, disassembling regions of memory, listing loaded modules, getting import entry points, setting breakpoints, and single-stepping, along with printing functions. It’s no gdb (especially for the lack of PDB symbol support), but it’s something.

MIPS is all well and good, however, but we can already emulate Windows NT for MIPS. MIPS is a fairly clean, simple architecture, often used for teaching, and short of weirdness like delay slots, is dead simple to emulate. And it fits the bill for what I’m trying to do here – a RISC architecture Microsoft abandoned, fixed-length 32-bit instructions, the works. However, adding support for the DEC Alpha AXP will finally get this project to where it was intended to be from the beginning, and I hope for it to eventually be able to run the Visual C++ compiler toolchain under EmuWoW. Being able to compile (and even test!) Alpha apps on readily available modern PCs will be a game-changer, and I intentionally wrote EmuWoW to be CPU-agnostic, so adding rudimentary support for the Alpha wasn’t difficult. Like with MIPS, I lifted the emulator from MAME. This admittedly did pose some challenges, due to MAME’s use of C++ features such as

• Classes (which I had to substitute for passing pointers to structs)
• Templates (which I had to substitute for macros)
• Function-style casts (which I had to change into C-style casts)

There was a lot of weirdness in how Alpha function calls, but it was my misunderstanding of the calling convention, and when to consider values to be 32-bit vs 64-bit posed a modest issue, but I got it to the point where some very simple DEC Alpha programs started to run, though many of them have various issues.

This is the first time this has ever been possible; emulation of AXP NT programs on standard PCs has just become possible now. I’m hoping to see EmuWoW continue to evolve, and I welcome contributions, whether that be improving support for the CPUs I already have, adding support for another (such as PowerPC) or anything else. To take a look at the code, go to github.com/bhty/emuwow and to download EmuWoW and try it out for yourself, click here.

I’m sure many people have explained this far better than I ever could but in C you write source files (obviously), the pre-processor reads those and ‘header’ files that describe interfaces to libraries, other objects, various macros and definitions (magical numbers) and the pre-processor will read those files, and do simple macro expansion and test insert/replacements to generate a single .i file at the end of it’s run.

The C compiler (cc1) now reads that single .i file and translates it into native assembly. This allows for ‘mid/high level’ aspects of C to be machine independent (portable) but now will be written into a very system dependant assembly file, the single .S file. One thing of note is that so far everything is text files. You can edit the assembly file as you would any document, or even further ‘process’ it if needed/wanted.

The assembler ax386 (GAS) will then read the single assembly file and write a a binary object file hi.OBJ. There typically isn’t all that much to be said about assemblers although fancier ones allow for really strong Macro capabilities like Microsoft MASM.

From here on, it’s all binary objects!

The linker then takes your object files, and links them together with other system objects and system libraries into an executable, in this case. Linkers can build all kinds of other things, but for now we’re just pretending its static C compilation like it’s the 1970’s.

At it’s heart GCC processes text files.

The first part in this insane experiment, is to build GCC 1.40 with Microsoft Visual C++ 1.0. Surprisingly it didn’t take an insane amount of messing with stuff, and I got an executable! But everything it compiled failed to assemble. Looking at this fragment, even if you don’t know i386 assembly you might spot the error:

main:
        pushl %ebp
        a b,c
        pushl %esi
        pushl %ebx

Yeah, it’s the “a b,c” part. Those are NOT valid i386 opcodes!

Just because it compiled didn’t mean it actually worked.

I used MinGW to build the same source, same Makefile, and I got a working executable. Annoyed I started compiling random files with Microsoft C, and finally found the file that broke it all, it turned out to be insn-output.c needing to be compiled with the “/D__STDC__” flags. A quick modification of the Makefile and now I have a working CC1!

Okay, great, it’s well known back in the early dangerous ages of the 1980’s/1990’s that everyone wasn’t running Linux, nor were binary distributions of GCC that far spread, rather I think to re-enforce the source was available it was expected that you’d use your system compiler. Systems like DJGPP/EMX take the path of binding a.out object files into something that MS-DOS can run via a dos extender, or the bind utility to allow you to run the a.out on OS/2. What I wan’t to do is verify that in fact Windows NT was a viable host for GCC back in the public pre-releases of 1991.

I’m sticking with the December build 239 version as it has working floating point. Something that GCC has intrinsic support of, and I don’t feel like trying to work out emulation.

The next step is to try to build it with the family mode-OS/2 version of the C compiler, which of course lead to the real issue of this 16bit hosted cross compiler:

        cl386 /u /Od /Ic:\MSVC32S\C386\INCLUDE /I. /Iconfig /c combine.c
Microsoft (R) Microsoft 386 C Compiler. Version 1.00.075
Copyright (c) Microsoft Corp 1984-1989. All rights reserved.

combine.c
combine.c(1734) : fatal error C1002: compiler is out of heap space in Pass 2
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x2'
Stop.

Very frustrating. I tried mixing and matching from Visual C++ 1.0 & this old compiler, and while it did compile, it doesn’t run. does it mean anything?!

I should point out that this should be an expected working configuration as GCC does build on Xenix using the 32bit Microsoft C 5.1/386 compiler. Furthered again that Xenix and these 1991 versions of NT use the same 32bit OMF object format. And expanding on the Xenixnt experiment using the Xenix’ified GAS assembler with old Visual C++ includes & libraries to produce a possible retro-early port of GCC to NT, the next move is to bulid GAS on NT.

GAS gave me some weird issues with ctype.h where it runs fine with the one from Visual C++ 1.0 but the OS/2 & NT pre-release both fail. However the old Pre-release compiler cannot deal with the much newer ctype include file. So after much hammering I amputated whatever was bothering it, and it’s just enough to build & run. Great!

Going back to the phases, I used a simple hello world program:

void main() {
 printf("Hello World!\n");
}

While not being a good program, it doesn’t include stdio.h, nor does it return anything. It’s terrible. But in this case it allows me to be lazy and sidestep the pre-processor cpp.exe. This way I can just directly run it through cc1 and get my assembler file hi.S

Next I pass it to ax386 (GAS) and get the resulting object file hi.OBJ

And finally link it with link.exe in this case.

And with all the drama I’ve now compiled a simple hello world program on Windows NT.

If it were 1991, I would hollow out gcc.c so it doesn’t use signals or forks to invoke the needed phases, and of course build the pre-processor. In addition, libgcc needs to be compiled to allow for floating point operations to work correctly. None of which is impossible, although I’m not sure it’s all that needed as it isn’t 1991.

With a little bit more work, I got the floating point support to compile, which relies on both a working ‘native’ compiler, and a working GCC to compile the 2nd half. I usually use phoon, or Phases of the Moon, to test floating point, and as you can see, it’s working!

I’m not sure if there was a 32bit version of Microsoft C/386 available for Microsoft OS/2 2.00 betas. Also, I don’t know if the Microsoft link386 for OS/2 can also link Xenix 386 object files? Would it have been possible to bootstrap GCC/GAS on Microsoft OS/2 2.00? I really don’t know, and as of this writing no versions of the old Microsoft OS/2 2.00 betas have surfaced.

** update from the future, turns out that I found a way to convince the cl386 compilers from the NT Pre-Releases in 1991 to re-build an existing GCC that was built for NT. The catch is the linker, LINK386 of course, as the format was constantly changing. However the object files are fine, and I was able to just copy them over on diskette and re-link the compiler. It even ran. It’s not tested at all, so it turns out the 1989 compiler wasn’t good enough, but the 1991 was.

It’s interesting to me to see that even before GCC 2.6, that vintage versions from 1991 would compile and run directly on Windows NT.

I uploaded the source on github, along with some binaries.

As I was preparing the Windows NT RISC exhibit for VCF west, I realized that I’m missing a rather important piece of the history. While I was showing the potentially last DEC Alpha Windows build ever – AXP64 2210, I don’t have anything earlier than NT 3.51. It would be nice to showcase the very first RTM version – NT 3.1 on a RISC platform.

From time perspective, NT didn’t get popular until 3.5 and later. Windows NT 3.1 would be considered rare even on a 386, let alone on a RISC machine! So what hardware does Windows NT 3.1 run on?

Quite a limited list! The HCL published on gunkies has a few more systems, but nothing that I would have. The early MIPS based systems are all but unobtanium as of today. This is probably a good time to mention a little known port of Windows NT 3.1 to the DECstation 5000. However these builds have not surfaced anywhere, so no help.

The Alphas were looking a little more reachable. The DEC 2000 Model 300 and DECpc AXP 150 are one and the same machine, packaged in a server and workstation cases. Code-named Jensen, DEC designed and marketed these specifically around Windows NT. Unlike prior Alphas, this model used a lot of “PC” components for increased compatibility and lower cost. Eventually paved way for the more well known DEC Multia. The Jensen has been seen floating here and there and many people have these.

I was able to get a loaner from Chris Satterfield aka Compgeke and I was set for the VCF. However, having a working specimen at hand, I started looking at part numbers of various components. In an amazing streak of luck, in practically zero time I was able to find, buy and assemble a complete DECpc AXP 150 from spare parts on eBay! Without a case, but nevertheless. Also big thanks to Christopher Rivett for help with some fine details!

BOM

• Motherboard + CPU – DEC 70-29685-01
• GPU – DEC/Compaq Qvision 1024/E (1024×768) – 126654-001
• GPU – (Optional) Number 9 High Res (1280×1024) – 30-41800-01
• HBA – Adaptec AHA-1742A EISA – 467806-00
• NIC – DEC DE422-S EISA – 5021102-01
• RAM – 4x 16MB, FPM, 60ns, 72-Pin, 12-Chip, True Parity SIMM
• PSU – DEC/HP 30-37197-02, however a standard AT PSU may be OK

If you going to build one yourself, beware of overheating. Jensen runs rather hot and needs good cooling. Not only for the CPU. There is a section of the motherboard just under the EISA cards that runs incredibly hot. See the picture, where I have installed a large Noctua fan.

OS Install

There are many Windows NT 3.1 CDROMs floating around. I purchased a DEC branded, shrink-wrapped CD on eBay to use as a prop along with the machine. You can download the iso image here.

Installation of Windows NT 3.1 on DECpc AXP 150 is pretty straightforward and not that much different from the later versions. However as a prerequisite you will need the ECU floppy disk to configure the EISA slot assignments, card and jumper settings. After that you will have to go through various setup screens in ARC BIOS to configure system settings. Then you run arcinst to create a system partition and setupldr to install the OS. The rest of it is pretty uneventful. This is somewhat expected, as this was pretty much the only one and supported hardware combination, so must have been well tested. The only curious part is that the NT OS Kernel does not display any messages in text mode. Later versions of NT will display the build number and MP or UP kernel variant and dots indicating subsystem load progress. This is rather odd because I expected more char mode stuff from earlier NT version, but who knows.

Service Pack Saga

If you are even vaguely familiar with installing Windows NT at all, you will know that the very first thing you have to perform after installation, is to apply a service pack. NT 3.1 did have service packs, up to SP3. The problem was that, as you may expect, RISC editions were nowhere to be found in 2023. The only thing I could come up with was http://www.win31.de/ent31.htm, which at the time had a German AXP and MIPS SP3, but no English! [It since has been updated…]. I had to do some real detective work to track down an US-English AXP SP3 version. I spent a few days going through various random CDs and ftp site mirrors of that era, with little luck. Eventually I stumbled on this README file, stating:

Due to space constraints on the Windows NT Service Packs for
International Versions CD, the USA Service Pack version 3 is located on
the Additional Windows NT Service Packs, Windows 3.11 versions, SDKs,
and DDKs CD in the NTSRVPC3\USA directory.

Bingo! After a few hits and missed I spotted this particular CDROM here: https://archive.org/details/microsoft-developer-network-january-1995-disc-4-of-15 – Now the OS is finally “servicepacked”

Applications!

OS by itself without apps is not much. While overall Alpha NT application outlook is pretty scanty I was able to find a several very interesting gems!

Most importantly, thanks to Chris, a DEC Windows NT Developers CD-ROM!

The disk has an incredible amount of demo, freeware, public domain and shareware applications as well as DEC marketing material.

You can get a lot of DEC proprietary software like C++, Fortran, PATHWORKS, DECtalk, as well as X servers, etc.

However I was particularly interested in some 3rd party commercial apps.

For example there is an early version of DMC Calamus Desktop Publishing.

Also a demo version of a vintage, text-mode SlickEdit, way before it was replaced by the Visual SlickEdit known today.

There also is WinDev editior, which is quite superior to Notepad and has some code editing goodies and shortcuts to SDK tools, making it something of a simple IDE.

Another big source is Windows NT Application Sampler CDROM, (also from Smithsonian).

One of the coolest thing found there is a GUI text editor called WinEdit. It has a ton of features including syntax highlighting! It has since became my default to go editor / IDE on this system!

There of course is a Windows NT SDK with the M (MEP) editor.

There also are quite few public domain apps and games, ports of GNU software, Micro Emacs, Kermit, etc.

Update: CICA NT Shareware Collection has some interesting apps under the /alpha directory.

High Resolution GPU

One of things that was troubling me for some time was rather low resolution of the default QVision graphics card. The maximum being only 1024×768 is just not acceptable. Talking to several Jensen’s owners, no one even heard about anything better. However looking at the Windows setup options, I curiously noticed that the system does support one 1280×1024 video card – Number 9 GXE.

I assumed that such card would simply be unobtanium in 2023. However, digging through some old catalogs and spare part listings, I managed to find a DEC part number, which is 30-41800-01. Armed with this, I was able to find it via DEC spare part reseller that I often use. They had it in stock listed as “HIGH RES EISA 1280 x 1024 GRAPHICS”. The price wasn’t too bad either. A few days later I received this:

After installation of the S3 driver (must be the Service Pack 3 version!) I was finally able to get 1280×1024 from the poor thing!

With this I should have a more cozy environment to compile and port even more apps

In future I want to try the Advanced Server edition as well as some early Betas with Alpha support. To be continued…

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.

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'!\0"
        .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

So back in the day I wrote something vague about the October 1991 preview version of Windows NT, and after messing with the tools and building f2c & dungeon (among some other stuff) one that that stuck out to me is that the object files had to be converted for NT.

The interesting thing is of course that it doesn’t support the cl386 direct compile and link (hence CL). Instead you have to compile, convert and then link. A fun thing about the October 1991 version is that there is a cl386 cross compiler for OS/2. So while looking around for OMF linkers (and assemblers that either understand GAS but output OMF, or some translator) I ran across this, and well yeah, it turns out that the OS/2 tool chain is the toolchain. I guess it makes sense in that the NT team was using OS/2 to build NT, but objects and exe’s were not solidified.

I think 6.00.080 was the last version of Microsoft C 386 for OS/2. I need to start collecting more of the SDK/DDK’s of the mixed era, I think the LX/OMF stuff was a bit more widespread hiding in plain sight.

Anyways, interesting?! sure. useful? Maybe 30 years ago. Although I’d probably say just use Watcom C/C++ instead of Microsoft C 6.00

Apps for Windows NT RISC… Alpha AXP, MIPS and PowerPC. Happy downloading.

STUDS from Microsoft .
(Video in MPEG-1/Audio MPEG-2 care of JSMpeg).

I had this ages ago, although I couldn't remember if the NT 3.5 SDK/DDK had shown up at this point, but it's only the Japanese version in this set.  Since I'm having such a PITA in tracking down a 3.5 set, and I'm not sitting on this, I may as well archive it.

So you too can find the early Video for Windows, and all kinds of other things from the mid '90's on archive.org.

Or Wallpapers like this 'puppy' from the Japanese version of Windows 3.1

https://archive.org/details/MSDNOctober1994