GCC 1.40 on Windows

I know with all the talk of GCC 6.1.0 for MS-DOS, and other platforms, you must be thinking that all this talk of progress, and high versions numbers just isn’t right! I’ve just started to migrate code to GCC 5.1, and now you are telling me there is a GCC 6!

Where can I turn away from all this so called progress! I don’t like my C compilers to be C++ programs that require massive HOURS to compile. Can’t we just go back to the good old days?

And the answer is YES, you can!

While looking for some libraries on another project, I came across this old defunct project called RSXNT. And it’s a port of EMX to Win32 platforms! Well isn’t that fantastic!

So, considering I was able to build GCC 1.40 and cross compile to Linux 0.11 from Windows, can we do something with this?

Well ancient versions of EMX are very difficult to track down. Somehow I did mange to find this hybrid of 0.8B & 0.8C. The EMX runtime & binaries are from 0.8C, but the source code is from 0.8B. And the best thing is that the 0.8B is based around GCC 1.40! So with a little bit of tweaking the files, and messing around I got the assembler, linker, and C compiler to build with MinGW! Sadly the source code to EMXBIND, wasn’t included in the zips that I have, but the aformentioned RSXNT packages included a version of EMXBIND that will run on Windows! So I managed to mash them together, and for the fun of it, I’m using the old InfoTaskForce interpreter from 1987 to complete the vintage feel.

Compiling & Binding

Now with my executable, I can run it on MS-DOS & OS/2!

MS-DOS via DOSBox

and OS/2 2.0!

OS/2 (on Qemu)

Well isn’t that fantastic!

However when running RSXNT’s bind, NTBIND I got this error:

D:\emx_w32\infocom>..\bin\ntbind info2
No relocations in file:
you have not linked the NT library

Great. Some more digging around, and if you want to make Windows programs, you need to use the RSXNT includes & libraries. So I shifted the libraries around, and patched gcc to call the linker the same way RSXNT’s gcc driver calls it, and first go this error:

io.o: Undefined symbol __streams referenced from text segment

And looking at the stdio.h there is this:

extern struct _stdio _streams[];

No doubt, the headers & libraries are tied together. So now making both of the RSXNT versions, I can link the executable. (YES I did try declaring the structure anyways, and I get stdout, but stdin doesn’t work).

Running on Windows 10

Just like EMX before it, RSXNT, requires you to have the RSXNT.DLL file in your path, or in the same directory. I suppose it’s a fair trade off. Not that I expect there to be a surge of people cross compiling from Windows to OS/2, or even MS-DOS these days. GCC 1.40 is ancient, 1991 vintage, but even Linus Torvalds loved it!

For an attempt at porting some code, I choose Nethack 1.3d, and used the MS-DOS based makefiles. It didn’t work so well, but I was able to patch in enough of the unix based termios logic, and thanks to EMX/RSXNT’s built in termios capabilities I was able to get a working version!

Nethack 1.3d on Windows 10 x64

I don’t know if there really was any advantage to compiling with GCC 1.40, but it was great to see that this 1991 compiler could handily compile the 1987 based code.

How about some speed comparisons? I dug out the ancient dhrystone.c, and gave it a shot. I had to define 500,000,000 passes, as my computer is fast. GCC 1.40 only offers -O for optimization, while GCC 5.1 offers many more levels, but for this quick experiment they really aren’t needed.

As you can see, GCC 1.40 produces the slowest code. While it’s optimized code did beat out GCC 5.10 with no optimizations, turning on optimizations did blow it away. And again GCC 5.1 beat out the older 1.40 for executable sizes.

And this time by over a 2x lead! It is fair to say that the new versions of GCC, despite being significantly larger do indeed produce smaller and faster code.

For anyone who’s read this far, I guess you want to take it out for a test drive? Remember it is still EMX based, which means is wants to live on the ROOT of your hard disk. I’m using the ‘D’ drive for myself, so if you are using C or whatever you’ll need to alter the environment vars.

2 thoughts on “GCC 1.40 on Windows”

Anyways, AFAIK, EMX is still found (but with old GCC 2.8.1). 0.9d is the last (2001?), supporting up to 1 GB RAM (due to EMS limits??). In DOS, I can use that GCC if I first do “set EMX=c:\utils\rsx.exe” and load CWSDPMI (otherwise it crashes/hangs, too much RAM!).

Of course, it’s all moot (because most people stopped caring about binary compatibility). EMX tried to straddle the line between DOS (EMS/VCPI) and OS/2. RSX tried to help it support DPMI (a Win 3.0 invention, as you know, that even OS/2 2.1 supported). Yes, I once or twice used RSXNT to make a dual-mode .EXE for DOS and Win32, but overall it wasn’t well-supported, so it was hit or miss.

Honestly, things like DJGPP v2 (DPMI 0.9 only) “should”, in theory, run on DOS, OS/2, or Win32 (or Linux with DOSEMU, or even DOSBox within limits). But most developers don’t even care enough about that!

So, instead, nowadays you’re expected to recompile for every single target. While not perfect, OpenWatcom does help a lot in that regard.

I want to use GCC 1.x on Windows. You are looking too close at the trees to see the forest. I don’t want GCC 2 or higher, as I want to run the oldest version of GCC I can find to run on Windows 10. EMX 0.9anything is again far too new.

Try to find EMX 0.8a, EMX 0.8b, EMX 0.8c and you’ll see they are impossible to track down.

I’m more interested in seeing if I can get the ancient versions working on modern Windows.