So while looking for some Win32s nonsense, I stumbled onto RGB Classic Games, and they have this interesting thing to run dos games online. A quick glimmer of the DOSBox logo flashes by.. So I fire up doom and quickly exit and…

Yes it’s DOSBox.

But in my browser.. A little tearing it apart, and it’s actually a port of DOSBox to JAVA!

Seeing it can run 80386 code, namely DOS4G/W, I figured it’d be interesting to see how it’d handle Microsoft PowerStation Fortran & PharLap TNT.

You can try it if you feel inclined here.

Quake1 with WATTCP built with DJGPP on DOSBox


As far as I know this was never done, as the world at large moved away from MS-DOS, and of course when Quake 1 on MS-DOS was popular they weren’t exactly giving out the source… Such a shame the DLM thing was lost in the shuffle as DLL’s on DJGPP/MS-DOS could have made quake more modular..

So what I’ve done, is I’ve used an ancient version of cygwin that I was playing around with line, and built a cross compiler for DJGPP. Then using that I’ve built the latest version of Watt-32 tcp/ip with it, then I took my build of Quake 1 on DJGPP, and built quake to use the net_bsd, net_udp, net_dgrm services, and added in the needed hooks for Watt-32 TCP/IP. And to their credit, I just added a single function call to both protocols init functions, and a single function to the general network poll function. All and all I think it’s 3 lines I changed.

Then to test, I used an older copy of DOSBox that included a virtual NE2000 that binds onto a physical interface via libpcap, loaded up the packet ne2000 driver, and ran the client!

For a server, I used the much older, quake dedicated server I had built to run on Windows NT 3.1. Although I never did automatically turn on the ‘-dedicated’ flag for some reason…

On the Windows XP virtual machine, I installed a loopback adapter, then set it up with internet connection sharing so that XP would act as a DHCP server to the Watt-32 TCP/IP stack.

Anyways, as you can see in the picture I connected a simple sniffer, WinDump to watch the packets, and it worked.

I’m still blown away that it worked on the first shot.

It’s really a testament to all the people that make all the moving parts here, when I can just string stuff along and get it to work.

For anyone daring enough, this zip contains all the source, and binaries of all the parts, except for the cygwin install. (I did have to poach a ‘modern’ cygwin1.dll from a modern install).


Quake1 & MS-DOS

And because I had a request for it, here is a 7zip containing a makefile, and source suitable for building quake under MS-DOS.

I sourced it from the Doom makefile, and cross built it under OS X… It builds in under 5 seconds using all 4 cpu’s on my OS X box with my OS X to MSDOS DJGPP cross compiler…. I had forgotten that the gpl’d source included MS-DOS support.. I had taken the video part from Chi Hoang’s DOS port of DOOM and gotten it to run until I remembered.. Oh well a few hours wasted.

So there it is, Quake1 built on a mac, and running on DOSBox on a PC.....

And speaking of Quake, it’s on sale too!

But just for today, on steam…..

Doom for MS-DOS

Today while checking out eets on steam ( yeah I know… ) I came across this sale… It’s Doom, Doom II, and Doom III all together, with all the expansion sets for $8.74 USD!

Well needless to say I couldn’t resist the offer, so I bought it. While playing around with Doom, I was wondering what was the first port of the Linux X11 doom back to MS-DOS. A bit of googling brought me to the doom wiki, and from there it seems that “DOSDoom” version is the first source port returning DOOM back to MS-DOS.

As mentioned in Chi Hoang’s notes, it took him 4-5 hours to do the initial port. So I figured it’d be worth re-creating the 0.1 version of his work, under DOSBOX with DJGPP.

I did find out the hard way that there is a single assembly clause that breaks under newer versions of DJGPP, and there is a small issue with the HOME environment variable that if it’s not set it’ll crash DOOM. So I ‘fixed’ that to use the current directory.

To install this legacy version of DJGPP, I found the needed files..


Simply unzip all of this into a directory that your DOSBox mounts, and alter your dosbox.conf something like this:

# Lines in this section will be run at startup.

mount c c:\dos

Then you should be able to extract the doom source that I’ve patched up, and run make to re-build the exe. I’ve included a shareware wad file that won’t explode on missing demos…

So the end result is the following:

DOSDoom 0.1
DOSDoom 0.1

Which… has no networking support, no audio, but it does work! This port is overall minimally invasive to the code, and I’d suspect it’d make it a very easy starting point for yet even more ports of doom… I think there is over 40 out there.

That’s the one great thing about making the source available, is that the product lives on and on!

pcap and IPX/SPX

I found this link where someone had implemented a virtual NE2000 for DosBOX, allowing you to run among other things DOOM!

This reminded me of my own work to add pcap into Qemu back in the 0.9.0 days… SO I figured I’d try to build the thing out and see how they interact!

So the first thing to do was build DosBOX, and add the patch. I found that 0.73 worked pretty well for this!

So after some hammering around, I got it to build, and launched it on two separate machines (one over terminal server) on my lan, and launched the oldest network doom version I could find to get things going.

Doom multiplayer IPX-SPX
Doom multiplayer IPX-SPX

And there we go. Now in the dosbox.conf you have to make sure that they have unique MAC addresses, and of course, that they are bound to the correct physical nic. in the config file, there is a list option that will print out the possible choices then you can just put the number, or the full name into the right spot on the ini file. I’ve build a prebuilt win32 version of this with all the DLL’s and the gravis ultrasound enabled… You can download it here.

The next thing I did was search high & lo for my patches to Qemu, and thankfully I’d emailed them to myself as it seems all the other places are dead… So with a little playing with Qemu 0.90 to enable the adlib, and remove some logging messages, I’d built a client machine again with Doom. Naturally I had the DosBOX & Qemu face each-other off.. Sadly this is a little SLOW.

DOSBox and qemu IPXSPX Doom
DOSBox and qemu IPXSPX Doom

For those that wish to download, you can find the Qemu client & server files.

Now for Qemu, you’ll need to get that full NIC name… Dosbox provides a great way to see what it is, just paste it into the batch files, and you’ll be good to go.

And remember you’ll need WinPcap installed!!!!!!

OS/2 1.x emulation via HXRT

I finally got this working, although I’ve got to sit down and work out the old makefile format to bind in the hxrt stub instead of running it all on the CLI…

So as a poor example, I used the ancient Fortran 5.1 to build up an OS/2 1.x VIO executable of dungeon, which would run happily on NT 3.1, but of course will not run on XP as they have removed the OS/2 subsystem.

Anyways it’s impossible to run the exe on dos, but fishing around I came across my old Visual C++ 1.5 CD, and on there was the Phar lap 286 dos extender. And one of the neat things it could do, was run simple OS/2 applications under MS-DOS!

So I bound the exe and now it’d run under MS-DOS.

phar lap 286 dungeon 2.5..6
phar lap 286 dungeon 2.5..6

However, since it’s a trial version, it’s limited to 2MB of ram, and you can’t redistribute the resulting exe. Now this is where HX DOS Extender (archive.org mirror/sourceforge mirror) comes in. Over the years, the HX dos extender has provided the functionality of the old Phar lap TNT dos extender by allowing you to run Win32 exe’s under MS-DOS, and it provides a pretty impressive subset of the Win32 api on MS-DOS.

So taking this lead, HX now has a 16 bit 286 centric version that provides a basic OS/2 emulation layer.

So by simply passing the OS/2 exe as a parameter to the DPMI loader (I haven’t quite worked out the stub syntax…) you can run the OS/2 build of dungeon under MS-DOS!

HX16 dungeon 2.5.6
HX16 dungeon 2.5.6

For anyone stuck with either legacy 16bit tools, or a need to support ancient systems, it’s certainly nicer with OS/2 as you have access to a LOT more memory! According to the documentation the HX extender should work nicely with the OpenWatcom Fortran & C, although I currently haven’t tested it.

What’s kind of interesting is that HX doesn’t work under DOSBox, while the Phar Lap 286 DOS Extender will….

Both of these dos extenders build on the old idea of the “Family API” where common API’s between OS/2 and MS-DOS could be mapped between the two OS’s, and a common “bound” executable could then run in either environment. However on the MS-DOS side, it’d be subject to the memory constraints of a realmode MS-DOS executable. The DOS extenders build on this idea, but provide access to additional memory, and a more feature rich OS/2 api.


Well I was originally looking around at the new & exciting 16bit support for HX, but so far I’m having little luck… It seems all the ‘cool’ OS/2 stuff it should do just crashes out on me…

I’m hoping to get something going eventually.

In the meantime, I had to check to see if an old MS-DOS favorite, DJGPP was still around.. And not only is it still there, but they now support GCC 4.42!

DJGPP, is simply put a port of GCC to MS-DOS. The best part, is that the compiler, libraries, and even the dos extender are all FREE. The sad thing is that DJGPP hit popularity around the mid 90’s with the rise of Windows 95, and the internet… Kind of killing 32bit MS-DOS applications… However Quake 1 shipped as a djgpp/cwsdpmi application… I’m sure there are others.

So at any rate, I was intrigued that it was still around, so I fired up DOSBox, then downloaded the zips according to the zip picker, read the readme, setup the environment, and I was off and away compiling my trivial hello world.

Sadly for me, I couldn’t sleep, so I then just grabbed the f2c/dungeon stuff and did a compile… I only had to tweak a few things, mostly a garbled long file name thing, but in no time… It was running.


I did manage to crash dosbox building the libf2c, but luckily changing gcc to use the -O0 (no optimizations) it was able to build the library… It’s kind of sad generating a 150kb ‘hello world’ type application, but thats the price for essentially statically linking everything….

MS-DOS isn’t the most modern thing out there…. I always wonder if those kids writing a 32bit ms-dos like os ever got anywhere…

DOS-Minix 2.04

I was looking around for some old compilers as a side project of mine has stalled looking for some TS-11 Fortran compiler with overlays…

Anyways I found mention of this DOS-Minix.  It does NOT comply with things like DPMI, VCPI as it will not run in nice things like emm386 & other v86 switchers.  However it will run in DOSBox.

Digging through the kernel & the boot program, you’ll find the basics of a DOS Extender.  The boot program will allocate as much memory as it can from the XMS driver, and then switch to protected mode & transfer control to the kernel.  Likewise the kernel then uses MS-DOS & BIOS calls for video, disk access etc as you can find it’s int86 calls that switch from protect to real mode, (doshead.s) or even in the disk driver dosfile.c

Installation is SUPER simply, just download the file DOSMINIX.ZIP unzip it somewhere then either use the great DOSBox, or any other pc emulation etc that you could want to use…  The NTVDM from Windows NT is not good enough as you’ll get an error message about not being able to load the 386 kernel on an 8086.  This again probably stems from dosminix not using DPMI calls, but the old fashioned raw XMS calls.. I guess it *could* be updated…

Start it up is simple you just run the boot program and point it to a diskfile:

boot minix.mnx

Then you’ll get greeted by the boot loader..  For me hitting any key doesn’t do anything, so I just press escape, then type in boot.

And in NO time you’ll be up and running MINIX!

The ‘best’ way to shut it down I’ve found is to type in ‘reboot’ then press escape like wild, and you’ll interrupt the boot loader.  Then you can type in ‘exit’ and you’ll get dumped back into MS-DOS.

I think it’s an interesting example of how to use the ancient MS-DOS to bootstrap yourself into protected mode… And the source seem somewhat straight forward…

dosminix on DOSBox.
dosminix on DOSBox.

Microsoft Fortran Powerstation 1.0

PowerStation Fortran for Windows 3.1

While going through my stuff, I did manage to find some diskettes for Microsoft FORTRAN PowerStation 1.0 …  I recall using this under Windows 3.1 but there was some reason we never really used it under Windows 95 & NT (Found it 9 years later!) …

So I loaded it up on a VM with Windows 3.1 and quickly found out why:  While it produces win32 exe’s they are built with pre-release tools, and will *NOT* work under any released version of Windows NT, (Yes, including Windows NT 3.1!!).

I’m sure others may find themselves down the path with failed exe’s that crash with:

RtlExAllocateHeap not found in ntdll.dll

Microsoft had a fix, named beta2fix.  It renamed the references to ntdll.dll into beta2.dll.  Which sounds fun, except the resulting exe’s DONT WORK. Nothing like a ‘solution’ that took missing references into exe’s that just crash.

Naturally the ‘fix’ is to upgrade to 4.0 which.. is impossible to find, or track down Compaq fortran, or even Intel fortran.  Or just run it in a MS-DOS/Windows 3.1 VM and be happy for emulation.

But I figured what the hell, perhaps it’s possible to replace some of the key parts with old versions of Visual C++ and use HX DOS as an extender instead of an ancient Phar Lap TNT.

Googling around, the issue lies with the linker, link32.exe.

Now on my Visual C++ 1.0 cd there is a link32.exe that just calls link.exe.  On the Visual C++ 2.0 & 4.0 CD’s there is no link32.exe.  Seeing that Visual C++ 1.0 just calls through I just made a ‘stub’ program to call link.

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void main(int argc,char* argv[])
char command[255];
int rc;
int j;

sprintf(command,”link “);
sprintf(command,”%s %s”,command,argv[j]);
printf(“running [%s]\n”,command);
printf(“return code was %d\n”,rc);
{printf(“I think it’s too many nested DPMI things between TNT & whatnot\n”);}

Ok, it’s not work of art, but it’ll get the job done.  You’ll need some kind of MS-DOS 16 bit real mode compiler to build this thing.  I would imagine Watcom’s C++ compiler can still build 16bit dos realmode exe’s, or Borland has something in their museum thing.  I’m using QuickC for Windows in a Windows 3.0 VM…

Ok so now with our ‘link32.exe’ replacement, copy it into the f32\bin directory overwriting the existing one.

Next we will need the link.exe from Visual C++ 2.0 (or higher I figure), and copy that into the f32\bin directory, along with it’s needed files dbi.dll & msvcrt20.dll.

Next, download and unzip the HX runtime And you can either place it’s bin directory onto the fl32\bin, or unzip it to it’s own directory, and add a statement in your autoexec.bat adding it’s bin directory to the path.

Reboot to pickup the hxrt’s bin directory, unless you copied it’s bin into fl32\bin

Now we need to alter Visual C++ 2.0’s linker to run under MS-DOS. Simply run

pestub \f32\bin\link.exe

And now you should be able to run link.exe under MS-DOS.

Finally replace the libc.lib & kernel32.lib with ones from your Visual C++. Naturally these are in the \f32\lib directory. Visual C++ 2.0 will link without complaining, 4.0 gives some weird messages, but it still works.  I never did test Visual C++ 6.0 & beyond.

So building a simple ‘hello.for’ (mention in the prior blog post)

c:\F32>fl32 hello.for
Microsoft (R) FORTRAN PowerStation Optimizing Compiler Version 1.0
Copyright (c) Microsoft Corp 1984-1993. All rights reserved.

Microsoft (R) 32-Bit Incremental Linker Version 2.50
Copyright (C) Microsoft Corp 1992-94. All rights reserved.

running [link  -link @C:\TEMP\003635lk]
return code was 0

The only caveat here, is that because of HXDOS it *thinks* it’s running on Windows NT, (beta 2!) and will not run the bindmsf.exe program… Not that it mattered as it was broken. I suppose if I were more brave I could read the link file, and scan for a ‘-out’ and run pestub on the output.. But I don’t so you will have to.  Otherwise when you run hello.exe you’ll get:

This program cannot be run in DOS mode.

But running pestub.exe:

c:\F32>pestub hello.exe
pestub: hello.exe modified successfully


Ok, so with all this work, we’ve managed to restore the basic functionality of Microsoft Fortran here.  Now the bigger question, will hello.exe run on say Windows Vista x64?


Microsoft Windows [Version 6.0.6002]


Not to bad, eh?

Oh and onto zork:

c:\F32\DUNGEON>fl32 *.for
Microsoft (R) FORTRAN PowerStation Optimizing Compiler Version 1.0
Copyright (c) Microsoft Corp 1984-1993. All rights reserved.

DEMONS.FOR(520) : warning F4999: RLIGHT : variable declared but not used
DEMONS.FOR(520) : warning F4999: RSER : variable declared but not used
DGAME.FOR(781) : warning F4999: PROTCT : variable declared but not used
NP.FOR(397) : warning F4999: DFLAG : variable declared but not used
NP.FOR(397) : warning F4999: QHERE : variable declared but not used
NP.FOR(507) : warning F4999: DFLAG : variable declared but not used
NP.FOR(780) : warning F4999: DFLAG : variable declared but not used
NP.FOR(1154) : warning F4999: DFLAG : variable declared but not used
NP.FOR(1277) : warning F4999: DFLAG : variable declared but not used
ROOMS.FOR(1195) : warning F4999: F : variable declared but not used
Microsoft (R) 32-Bit Incremental Linker Version 2.50
Copyright (C) Microsoft Corp 1992-94. All rights reserved.

running [link  -link @C:\TEMP\000731lk]
return code was 0

The exe works fine on Vista, and pestub will allow it to run on MS-DOS.

*NOTE that the fortran compiler will *NOT* run on Vista/XP/NT.  The compiler was also linked with bad libraries & linker and it just won’t work.  I doubt forcedos would help for 32bit NT systems as the phar lap stuff is all out of date.  However DOSBox will happy run the compiler.

I haven’t even tried to debug anything, as I figure the best environment would have been a virgin copy of PowerStation 1.0 running under Windows 1.0… I did say keep a copy right!!!

Frontier, Elite II

I was playing with DOSBox on an XP machine, and I came across this exciting link: http://www.eliteclub.co.uk/download/ You can now download Frontier II as shareware! Most cool, so I’ve downloaded it & just run it under DOSBox. No tweaks, answer for the SoundBlaster sound card, and away you go! Here is me attempting to do a flyby of the Saturn system..

This game was super cool back in the day for it’s realistic physics as you could do slingshots, flybys, orbits & even land on various moons & planets. There is nothing more exhilarating then flying through the solar system or the universe at hundreds of thousands of Km/s. Not to mention the hyper drive!

You can give it a shot too, if your browser is Java enabled!  Just click right here, and enjoy!