DJGPP 1.03 saved thanks to shovelware +

I can’t stress enough just how awesome is for finding ancient stuff!

I’m not sure why I started on this quest but I was looking for some old finicky DOS extender, and started hunting for Go32, the first DOS extender used by DJGPP.  And for the heck of it, I wanted to find the first version, which I pretty much had assumed was lost to the mists of time.

However the CD-ROM shareware collection called MegaROM-1 actually had a ‘full’ copy of one of the first versions of DJGPP, 1.03.

Installation is pretty straightforward, however you have to use pkunzip for all the various old ‘methods’ of storing data in zip files, I found infozip leaves things out..

Also DJGPP 1.03 uses a LOT of environment space.. which is more so a problem for people running real MS-DOS on real machines.. (there are some!)…

Hello World!

It runs in DOSBox, but there is no doubt some stack corruption as trying to run things like dos edit result in:

Packed file is corrupt

But at least we can run more than one copy, or use a native editor.

GO-32 from this era is *NOT* DPMI compliant, nor is it VCPI compliant.  And its based on GCC 1.39, which was a popular level with things like 386 BSD, although it seems early Linux used GCC 1.40 ..  The tool chain by default outputs the GNU a.out format, but relies on modifying the linker that was separately included in G++.  Later versions of GO32 included VCPI support, and near it’s end of life version 1.10 added support for DPMI which greatly simplified things like hooking IRQ’s and doing DMA.

For those who want to play, without the pkzip fun, I’ve slapped it into a single 7zip file.  It’s not even a megabyte.  But it was 1991, when 4MB of ram seemed like an incredible amount of memory!

Quake & QuakeWorld for MS-DOS update

So after a year+ of inactivity I’ve spent some time with Quake (netquake) and QuakeWorld for MS-DOS.  I had modified it to support the WatTCP stack for MS-DOS, allowing you to play over the internet with any MS-DOS PC with a packet driver.

After a good bit of prodding and playing with DJGPP I’ve updated everything to include some new tweaks for a malloc ‘bug’ (Quake assumes the memory is clean, which under DJGPP it isn’t) some limit increases (zone to 1MB, and increases in max edicts, models & sounds), and forcing the sound to 22050Hz.  The source code is now here.  As much as it pained me, I built it with this DJGPP under MS-DOS (On Qemu) and I’m keeping it here, as gcc 3 & 4 are incapable of building a working WatTCP or Quake.

Another big fix for QuakeWorld is that it now can run in 640×480, 800×600, and even 1024×768 if your video card is VESA 2.0 compatible!!!

Basically you can just replace the default exe’s in a Quake1 install and go from there.  If you do not have quake at all, you can always look for the shareware version.  QuakeWorld will require the commercial version for what it is worth. I’ve found it runs best with 32MB of ram.  I don’t know if that is even an issue in this day & age.  Quake1 will run in 16, but I have a feeling QuakeWorld runs in VM (thanks to CWSDPMI) and it does say it is using 32MB … Because I clear the ‘zone’ before Quake runs there may be a 30 second to 1 minute pause.  This is to be expected, just hold tight.

QuakeWorld at 640x480

QuakeWorld at 800x600

QuakeWorld at 1024x768

You can download either Quake.exe or Qw.exe.

Thanks to [hci]maraakate, for the hints on what to update where, and of course the testing on a ‘real pc’!`

QuakeWorld client for MS-DOS

So as leileilol pointed on on VOGONS, QuakeWorld’s networking was a rapid departure from Quake 1, and formed the basis of a lot of modern multiplayer games… Like teamfortress and half-life.

So with a little bit of work, I was able to compile a QuakeWorld client for MS-DOS. Or here for the standalone exe, and don’t forget CWSDPMI. Oh and be sure to get a packet driver, for your NIC. Many vendors have these on their site for newer stuff.

Now I managed to get a new computer between posts, and it’s not working on virtual pc… I may be 500 updates behind though so maybe it’s something else. So in the meantime I’m testing with Qemu.

The other oddity is that compiling QuakeWorld with GCC 2.95.3 with either -O1 or -O2 builds a client that will time out after 2 minutes… -O0 ran for over an hour with me playing and dying a lot on …

Oh and what good would this be without pictures?

Yes, I’m really that bad.

You can find quakeworld servers on the site And I can verify that you can indeed download levels!


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).



So years ago there was this great free TCP/IP package out of the University of Waterloo (CANADA!) called WATTCP. And then later it was ported to DJGPP and named Watt-32 TCP/IP.

The sad thing is that as the years have gone by, this kind of stuff has slipped away, and is nearly all lost.

But thanks to the internet archive yet again, I’ve been able to pull out some key stuff, and google a bunch more of it out…


And of course the older wattcp:

So thats one of the manual sets, a binary set, and a source set. I guess the thing that really matters is that the source set seems to be the last version..

Wattcp relied on a packet driver, in which to communicate with the outside world. I know there is SLIP/PPP and all kinds if NIC drivers out there..

So I went ahead and snagged the driver for Virtual PC’s NIC, then running the DOS-Telnet client, I went ahead and connected to a SIMH Vax running BSD…

And it works pretty well.

I’ll have to walk through some of the code and produce something more… interesting.

At any rate, I hope this will help anyone trying to do some embedded work around MS-DOS & DJGPP.

— edit
While browsing the list at I found the new Watt-32 home page…. So it’s good news, but strange that google seems to have not picked up on it, or other people…

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…..

Cross compiling for MS-DOS (DJGPP) from OS X

So building on DOOM, I thought I’d try to build a djgpp cross compiler from my main OS X box, as compiling under DOSBox is… just too slow. Luckily Delorie has a page on building a cross compiler.

I started out with binutils-2.9.1, just as he does, with a few things thrown in…

First I had to run configure like this, as OS X didn’t exist back then, let alone x64 cpu’s..
./configure --target=i586-pc-msdosdjgpp --host=i386-netbsd --prefix=/usr/local/djgpp
Next the following error is thrown…

strerror.c:463: error: conflicting type qualifiers for ‘sys_nerr’

So I just edited libiberty/strerror.c, and commented out the following line.

Next up was a strange error in gas/targ-cpu.h

targ-cpu.h:374: error: array type has incomplete element type
targ-cpu.h:378: error: previous declaration of ‘flag_16bit_code’ was here

I simply commented out the lines.

Then later while compiling gas/write.c it bombs out because of an undefined type.. One of which was commented out in targ-cpu.h . The easiest fix is to go to the start of the relax_align procedure and just add in the definition:

extern const struct relax_type md_relax_table[];

Next up was gcc. I couldn’t get 2.8.1 to build, instead I built gcc-2.95.3.

I had to configure gcc like this:
./configure --target=i586-pc-msdosdjgpp --host=i386-netbsd --prefix=/usr/local/djgpp
And it threw the same error as binutils… with the same fix (commenting out the line in libiberty/strerror.c).

strerror.c:465: error: conflicting type qualifiers for ‘sys_nerr’

I also had an error pop up like this:

./config/i386/i386.c:142:22: error: macro “strcat” requires 2 arguments

And again I just commented it out.

Under OSX the makeinfo parts crashed, so I simply removed them from the makefile. With a little more tweaking the cross compiler was ready!


The cool thing is that now I can run make with the -j4 flags allowing gcc to run on each of the cpu cores letting me build doom in under 3 seconds!

i586-pc-msdosdjgpp-gcc -O2 -DNORMALUNIX dos/doomdef.o dos/doomstat.o dos/dstrings.o dos/i_system.o dos/i_sound.o dos/i_video.o dos/i_net.o dos/tables.o dos/f_finale.o dos/f_wipe.o dos/d_main.o dos/d_net.o dos/d_items.o dos/g_game.o dos/m_menu.o dos/m_misc.o dos/m_argv.o dos/m_bbox.o dos/m_fixed.o dos/m_swap.o dos/m_cheat.o dos/m_random.o dos/am_map.o dos/p_ceilng.o dos/p_doors.o dos/p_enemy.o dos/p_floor.o dos/p_inter.o dos/p_lights.o dos/p_map.o dos/p_maputl.o dos/p_plats.o dos/p_pspr.o dos/p_setup.o dos/p_sight.o dos/p_spec.o dos/p_switch.o dos/p_mobj.o dos/p_telept.o dos/p_tick.o dos/p_saveg.o dos/p_user.o dos/r_bsp.o dos/r_data.o dos/r_draw.o dos/r_main.o dos/r_plane.o dos/r_segs.o dos/r_sky.o dos/r_things.o dos/w_wad.o dos/wi_stuff.o dos/v_video.o dos/st_lib.o dos/st_stuff.o dos/hu_stuff.o dos/hu_lib.o dos/s_sound.o dos/z_zone.o dos/info.o dos/sounds.o dos/i_main.o \
-o dos/dosdoom

real 0m1.174s
user 0m2.626s
sys 0m0.679s

How’s that for fast?

For any curious OS X 64bit users out there you can download my binary toolchain here.

I would imagine that if you stuck with versions of binutils & gcc that build on your platform you too should be able to build a MS-DOS DJGPP cross compiler. And there is nothing like native 64bit tools for building for DOSBox… Oh and DOOM runs just fine, although I guess screen shots of the cross compiled exe is… redundant.

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!