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!

A little while back I had worked on getting GCC to build and run on the FPU enabled versions of Windows NT from 1991. I had mentioned that it turns out thanks to the Xenix assembler, that GCC had been basically available the entire time Windows NT had been available, but lamented that since the OS/2 compiler is 16/32bit, the 5.2 compiler couldn’t handle compiling GCC without blowing it’s heap. 16bit issues in a 64bit world.

However after doing some research on all the early cl386 compilers I could get my hands on, including the Windows NT Pre-release ones, I’d noticed that if I built CC1.EXE (the actual compiler) first for Win32, then rebuilt those object files with the December NT Pre-release compiler, that some versions of LINK386 from the OS/2 2.1 DDK would actually link with them. And sure enough it worked!

I have to admit I was pretty amazed, I had managed to ‘cross compile’ GCC using quite the tool chain.

First the compiler from the December NT Pre-release CD-ROM is shipped as a 16bit OS/2 compiler, but I’m using Windows 11. First I use the MS-DOS player with a quick fix from crazyc to allow Phar Lap 286|Dos Extender to run, which provides a basic enough OS/2 emulation to allow the compiler to run under ‘dos’. The linker on the DDK suffers the same fate as far as it also being 16bit. However the combination of MS-DOS player & Phar Lap gets stuff working! The only weird catch is that the 386 emulator causes strange floating point related crashes, while the 286 or 486 emulators work fine.

Now targeting OS/2 or running on OS/2 isn’t all that new, but building it from a Microsoft C compiler is. And now of course you’ll ask yourself, who cares? why is it interesting?

Well, the vast majority of the GCC ports to OS/2 don’t support the OMF object file binary standard, instead they used the much outdated a.out format, and rely on tools to convert the objects if needed. Additionally, they have DLL dependencies, and other startup issues with things needing to be setup. And of course they rely on a binary standard that is ‘GA’. *HOWEVER* by using a Microsoft compiler, I have OMF object files that the OS/2 built in system linker LINK386 can understand. So in plain English I can just relink the compiler and it’ll run on a new ‘version’ of unsupported OS/2.

I made a diskette image with my objects & a linker script and in a few moments I had it running!

The substantial thing here is that the binary format for OS/2 changed twice, and each release introduced changes that broke binary compatibility, in an effort to force people onto the new tools. So there is no way that the old ‘LE’ format would ever work. And you can see it’s running! In addition I could take the same object files, and copy them to my Citrix server, and likewise it was just a matter of linking, and it too now has GCC!

One annoying thing is that the LINK386 that ships with OS/2 2.00 GA doesn’t like the output of the Xenix assembler, so I built the a.out traditional assembler, and the emxomf tool to convert the a.out to OMF, and that worked well.

I still have much to mess with, including the pre-processor & main ‘gcc’ program. I have not built anything beyond a trivial program, so there is indeed much more work to be done before I can even try anything challenging. Some programs like emxomf have portions in the debug support that require the ‘long long’ type, which obviously Microsoft compilers from 1989-1991 don’t have, so I’ll have to re-build them with GCC.

Ive been putting my ports onto github (cl386-research) as it handles the rapid changes well enough. It’s a bit of a complex setup and it involves using a build system that I’ve put over on archive.org here: cl386-research-v2.

Not that I can imagine anyone wanting to try but I’ve uploaded some disks with the objects. Copy them to a hard drive, and run the ‘build.cmd’ command and it’ll link to a native freestanding executable.

• cc1
• as386
• emxomf

I’ll explain it more with a post later, along with going over all the versions of cl386 I’ve acquired, over the years in more of a part 2: Targeting OS/2 with Visual Studio 2003!

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

gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../.. -I../.. -I../../include -g -O2 -Wall -c cs_grammar.c
cs_grammar.y: In function ‘cs_parse’:
cs_grammar.y:1074:58: error: ‘YYLEX’ undeclared (first use in this function)
1074 | yychar = YYLEX;
| ^~~~~
cs_grammar.y:1074:58: note: each undeclared identifier is reported only once for each function it appears in
make[3]: *** [Makefile:334: cs_grammar.o] Error 1

Notice it’s all UPPERCASE, but you can find plenty on the lowercase issue where its not being linked correctly. And yeah turns out YYFLEX should define out toe yyflex

# ifndef YYLEX
#  define YYLEX		yylex()
# endif

Add that in the top of whatever source is complaining and you’re golden.

Really.

DooM!

Good news, it actually works!  I was using the version 1.1 WAD, so honestly weird crashes really aren’t unexpected.  I haven’t looked much at what to do with audio, but I was really impressed compared to the Qauake II wars, it was really surprising to not only see DooM run on the first shot in real metal, but the keyboard works as well.  Well enough for me to pick a level, and get killed.

Naturally it doesn’t work under Windows, however it runs fine with MS-DOS mode.

phew.

DooM via DJGPP v1 GO32

Around the time of the x68000 port of DooM, I was cutting down the DooM source for a null/portable version.  I never could get it to actually run either using EMX or DJGPP 1.03, as I couldn’t get it to link to save my life with a constant never-ending battle of unresolved symbols. After a while I just used what I had towards the x68000 version and concentrated on getting it up and running and just shelved the null/portable effort.

Later on I wanted to get it running again as part of messing with another cross compiler, as DooM isn’t a trivial application to port and verify correct operation. And in the process of trying to get the null version to build and run on Windows using TDM GCC, I wanted to make sure it at least kept compiling with GCC v1.x.

Once more again I was able to compile individual files but unable to link.  But this time, I just looked at the diffs for binutils, I thought it should be somewhat easy to get hosted on Windows.  Although versions may point to binutils 1.0, I had to use binutils-1.9.tar.gz even though the diffs are against Mar 24 1991, and the source for 1.9 is dated April 17 1991.

My first effort gave me a linker that would happily link, but go32 would either refuse to run the executable, or just crash.  I was going to give up again, but I found mention in another file that DJGPP actually uses the linker from G++, the C++ compiler which was a separate thing in the late ’80s and early’90’s.  This time it worked, and I could link a trivial hello world style application!

Now that I finally had a cross linker actually working, I didn’t want to compile under emulation, so looking at the other diffs, they didn’t look too extensive. I went ahead ,and took DJGPP v1.06 and patched up the compiler & assembler to get a full cross toolchain.  And in no time, I had a null version of DooM running on MS-DOS well at least tested on DOSBox.

This was fun, and all but I didn’t see any easy way to do fun things like hook interrupts so I could get the keyboard & clock like any good MS-DOS program.  DPMI greatly eased this kind of stuff, so looking at the DJGPP history, DJGPP v1 version 1.10 actually adds preliminary DPMI support!  And in the next version, DPMI was much more better supported, however the binary format had changed from a.out to COFF as part of the move to v1.11. I was able to take the memory, and DPMI portions from the final v1.12 libc, and manually build and run them against the v1.06 library / dev tools.

And much to my surprise, it actually worked!  At least having the wrong format didn’t have any effect on how GO32 worked for me.

So, feeling lazy, I snagged some of the support code from Maraakate’s revamp of DooM, just to make sure of the timer code, and the keyboard code, and again verified that I can build with the keyboard & timer ISR and I’m able to play the v1.9 shareware & commercial levels fine.  I haven’t done a thing to clean up or update the DooM source itself against all the dozens of bugs and issues with Ultimate DooM, or other games like Chex Quest etc.

I’m sure 99% of people wouldn’t care but you can download it here:

Win32_DJGPPv1_DooM.7z

Although I’m using DPMI to drive real-time events, if I looked further at the GO32 v1.06 environments I could either figure out how it operates it’s timer or modify the extender directly to drive the PIC timer and keyboard as I need.  But overlooking that, the vintage 1991 software is more than capable of running DooM.

I was looking for stuff where I only had a patch, but not the original files.  So it was great for me to not only dig out an ancient sed from the era, but also bison, and gas.  The ancient binutils are great for people who need to manipulate the a.out format, although the later binutils version 2 supports far more formats by virtue of it’s “BFD” or binary file database or as it was known as back then a ‘big fucking deal’

If you have ancient and or obsolete stuff, GNU stuff can fill the void of the often missing vendor development tools.  It’s crazy how many people sold the tools that kept their systems relevant, although needless to say that attitude pretty much solidified the end of their existence..

The good stuff from 1989 to 1993.

http://www.decuslib.com/decus/lt89a/gnusoftware/
http://www.decuslib.com/decus/lt89b2/gnusoftware/
http://www.decuslib.com/decus/lt90a/gnusoftware/
http://www.decuslib.com/decus/lt90b1/gnusoftware/
http://www.decuslib.com/decus/lt91a/gnusoftware/
http://www.decuslib.com/decus/lt91b/gnusoftware/
http://www.decuslib.com/decus/lt93a/gnusoftware/
It’s not complete, but it’s still fantastic!

• bison-1.03.source.tap.bz2
• emacs-18.55.source.tap.bz2
• flex-1.0.source.tap.bz2
• g++-1.35.0.source.tap.bz2
• gas-1.34.source.tap.bz2
• gawk-2.10.source.tap.bz2
• gdb-3.2.source.tap.bz2
• ghostscript-1.4.source.tap.bz2
• grep-1.3.source.tap.bz2
• m4-1988.source.tap.bz2
• sed-1.02.source.tap.bz2
• tar-1.07.source.tap.bz2

Quite a list!

I haven’t tried to build any of it, but I figured for the time being, it may be easier to make some tap files for SIMH, and maybe someone else will do the hard work for me.  Or it’ll be a lazy day type thing.

CVS brows of the following:

• GAS
• GDB
• Binutils

I didn’t know that GNUmake 2.9 and prior was actually part of binutils.  I guess at some point I’ll build the older ones on 4.2 BSD to round out the experience.

And I don’t know where to find Emacs 18.41 and going further back.  Although I did find emacs1855.taz a DECUS (Digital Equipment Computer Users’ Society) image from late 1989.

article from virtuallyfun.superglobalmegacorp.com

GCC 0.9 on SIMH VAX / 4.2BSD

From the original announcement:

 Date: Sun, 22 Mar 87 10:56:56 EST
From: rms (Richard M. Stallman)

   The GNU C compiler is now available for ftp from the file
/u2/emacs/gcc.tar on prep.ai.mit.edu.  This includes machine
descriptions for vax and sun, 60 pages of documentation on writing
machine descriptions (internals.texinfo, internals.dvi and Info
file internals).

   This also contains the ANSI standard (Nov 86) C preprocessor and 30
pages of reference manual for it.

   This compiler compiles itself correctly on the 68020 and did so
recently on the vax.  It recently compiled Emacs correctly on the
68020, and has also compiled tex-in-C and Kyoto Common Lisp.
However, it probably still has numerous bugs that I hope you will
find for me.

   I will be away for a month, so bugs reported now will not be
handled until then.

   If you can’t ftp, you can order a compiler beta-test tape from the
Free Software Foundation for $150 (plus 5% sales tax in
Massachusetts, or plus $15 overseas if you want air mail).

Free Software Foundation
1000 Mass Ave
Cambridge, MA  02138

[tapes are generally in Unix tar format.  If you have other needs,
write to the above address, and ask if they can be met. -len]

And indeed, the files are dated 22/03/1987 making this the first public release of GCC.

GNU CC is a fairly portable optimizing C compiler intended for
machines with 32-bit words that have several registers and address
memory in terms of 8-bit bytes.  It supports full ANSI standard C, not
including libraries (which we do not consider to be part of a
compiler).
Currently we have working machine descriptions for the Vax and for
the 68000/68020 (including 68881 support).
Optimizations performed by GNU CC include:

• Invariant code motion out of loops.
• Common subexpression elimination.
• Automatic register packing (register declarations are unnecessary
  and ignored).
• Constant propagation and elimination of consequent dead code.
• Copy propagation.
• Elimination of dead stores.
• Jump optimization including cross-jumping.
• Delaying of stack adjustments after function calls.
• Arithmetic performed in subword types when appropriate.
• Many local optimizations.

GNU CC runs about as fast as PCC.
Most of the optimizations are machine-independent or controlled by a
machine description.  GNU CC takes advantage of all the 68020
addressing modes that we can see how to make the Sun assembler
assemble.  Debugging output for DBX is available whether you request
optimization or not.

Seeing as 4.3BSD didn’t ship until 1988, I went ahead and set out to build this on 4.2BSD. The first stumbling block I hit is that GCC needs bison.  The oldest version of bison I have is 1.25 which honestly is just too new!  However in the same location as GCC is this file gnu1988.tar.bz2 which contains all of the current GNU software of 1988!  And what is on that tape?

• bison-1.00
• gcc-1.21
• gdb-2.5.1
• gplusplus-1.21
• libgplusplus

So this is probably as old as it is going to get, so I downloaded and went to compile bison, however getopt is a missing call!  A creative search found getopt.c (local mirror) and even better PCC liked it enough to get a running bison so I could then configure GCC.

Configuring GCC is a manual process, but not too involved:

• Make a symbolic link from file `config.h’ to the top-level
  config file for the machine you are using. Its name should be
  `config-MACHINE.h’. This file is responsible for
  defining information about the host machine. It includes
  `tm.h’.
• Make a symbolic link from `tm.h’ to the machine-description
  macro file for your machine (its name should be
  `tm-MACHINE.h’).
• Make a symbolic link from `md’ to the
  machine description pattern file (its name should be
  `MACHINE.md’)
• Make a symbolic link from
  `aux-output.c’ to the output-subroutine file for your machine
  (its name should be `MACHINE-output.c’).Make sure the Bison parser generator is installed.Build the compiler. Just type `make’ in the compiler directory.

And in a minute I had GCC compiled.  I ran it with -v and got this output:

# gcc -v
ld /lib/crt0.o -lc
Undefined:
_main

It really is nowhere near as featured as 1.21 that is for sure!  So time to do a simple hello world program:

# cat hello.c
#include <stdio.h>
void main(){
printf(“GCC 0.9 in action!\n”);
}
# gcc -v hello.c -o hello
cpp -Dvax hello.c /tmp/cc002050.cpp
cc1 /tmp/cc002050.cpp -quiet -dumpbase hello.c -noreg -o /tmp/cc002050.s
as -o hello.o /tmp/cc002050.s
ld -o hello /lib/crt0.o hello.o -lc
# ./hello
GCC 0.9 in action!

And there we go!

I don’t know why, but I haven’t seen anything about anyone actually running GCC 0.9.  Or even where or how they found this ‘lost’ file. Â Let alone anyone even building or running it in 2016.

For anyone who wants to try, SIMH tape files of the binaries are here:

• bison-1.00.binary.BSD-4.2.tap.bz2
• gcc-0.9.binary.BSD-4.2.tap.bz2

And of course source tapes are here.