Porting Catacomb3D to MS-DOS (DJGPP v1/GO32).

Catacomb 3-D for GO32

No really, it’s Catacomb 3-D: The Descent.  First ported to 32-bit SDL by NotStiller.  Me being the person I am, I fixed a slight bug regarding binary files on Windows, and MS-DOS, then cleaned up some of the C++ syntax (yuck!) making it far more C89 friendly.  And of course, hot off the heels of DooM for GO32 DPMI, I was able to get it to build and run using GCC 1.39 and GO32.

I know most people really won’t care, but I found it kind of interesting.  I should try to see if it’ll run on actual hardware, just as a comparison of tightly optimized Borland C++ / Assembly vs 100% pure C on DJGPP.  The best tech of 1991 for sure!

At current I just put the source up, you can git it here.

26th anniversary of Linux!

As the joke goes:

Happy 25th birthday, Linux! Here’s your f-ing cake, go ahead and compile it yourself.

So it’s always a fun time for me to push my old project Ancient Linux on Windows.  And what makes this so special?  Well it’s a cross compiler for the ancient Linux kernels, along with source to the kernels so you can easily edit, compile and run early Linux from Windows!

As always the kernels I have built and done super basic testing on are:

  • linux-0.10
  • linux-0.11
  • linux-0.12
  • linux-0.95c+
  • linux-0.96c
  • linux-0.97.6
  • linux-0.98.6

All of these are a.out kernels, like things were back in the old days.  You can edit stuff in notepad if you so wish, or any other editor.  A MSYS environment is included, so you can just type in ‘make’ and a kernel can be built, and it also can be tested in the included Qemu.  I’ve updated a few things, first with better environment variables, and only tested on Windows 10.  Although building a standalone linux EXE still requires a bit of work, it isn’t my goal here as this whole thing is instead geared around building kernels from source.  I included bison in this build, so more of GCC is generated on the host.  Not that I think it matters too much, although it ended up being an issue doing DooM on GCC 1.39.

So for people who want to relive the good old bad days of Linux, and want to do so from the comfort of Windows, this is your chance!

Download Ancient Linux on Windows
Download Ancient Linux on Windows

WSAPoll & MinGW

For some reason if you try to use WSAPoll, you’ll get this fine error on linking:

poll.c:(.text+0x26): undefined reference to `WSAPoll’


Turns out that it’s basically missing from the includes.  Thanks to this hint, just simply add this into your source/header after pulling in winsock2.h and it’ll link.

typedef struct pollfd {
SHORT events;
SHORT revents;

And now you can happily compile and link.

Just for you, lucky Spanish user, GCC 3.0.4 for Windows NT (MinGW)

From Spain!

I cannot understand why you want this, or why I’m even going to do it.  At this point in GCC history the winnt-3.5 target had been dumped in favour of going all in with Cygwin.  So yeah, this does not either clearly configure, or compile.  But a little bit of mashing files, and I have it at least compiling some assembly that can be translated into an object file that a later version of MinGW can actually compile.

All I’ve built is the gcc driver, the cpp pre-processor, and the cc1 aka C backend.

D:\proj\gcc-3.0.4\gcc>xgcc -c -v hi.c
Using builtin specs.
Configured with:
Thread model: single
gcc version 3.0.4
 cc1 -lang-c -v -iprefix ../lib/gcc-lib/i386-winnt35/3.0.4/ -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=4 -Dunix -DWIN32 -D_WIN32 -DWINNT -D_M_IX86=300 -D_X86_=1 -D__STDC__=0 -DALMOST_STDC -D_MSC_VER=800 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D_cdecl=__attribute__((__cdecl__)) -D__unix__ -D__WIN32__ -D_WIN32 -D__WINNT__ -D_M_IX86=300 -D_X86_=1 -D__STDC__=0 -D__ALMOST_STDC__ -D_MSC_VER=800 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__cdecl__=__attribute__((__cdecl__)) -D__unix -D__WIN32 -D__WINNT -D__ALMOST_STDC -D__cdecl=__attribute__((__cdecl__)) -Asystem=unix -Asystem=winnt -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__ hi.c -quiet -dumpbase hi.c -version -o C:\Users\jason\AppData\Local\Temp\ccpflisr.s
GNU CPP version 3.0.4 (cpplib) (80386, BSD syntax)
GNU C version 3.0.4 (i386-winnt35)
        compiled by GNU C version 5.1.0.
ignoring nonexistent directory "../lib/gcc-lib/i386-winnt35/3.0.4/include"
ignoring nonexistent directory "../lib/gcc-lib/i386-winnt35/3.0.4/../../../../i386-winnt35/include"
ignoring nonexistent directory "D:/pcem/building/MinGW/msys/1.0/local/include"
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "D:/pcem/building/MinGW/msys/1.0/local/lib/gcc-lib/i386-winnt35/3.0.4/include"
ignoring nonexistent directory "D:/pcem/building/MinGW/msys/1.0/local/lib/gcc-lib/i386-winnt35/3.0.4/../../../../i386-winnt35/include"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
End of search list.
<command line>: warning: "__STDC__" redefined
<builtin>: warning: this is the location of the previous definition
<command line>: warning: "__STDC__" redefined
<command line>: warning: this is the location of the previous definition
hi.c: In function `main':
hi.c:3: warning: return type of `main' is not `int'
 as --traditional-format -o hi.o C:\Users\jason\AppData\Local\Temp\ccpflisr.s

D:\proj\gcc-3.0.4\gcc>gcc hi.o -o hi

Hello from GCC 3.0.4

So there you go, mysterious internet user!  Download my source dump with binaries in the tree because I’m lazy.


N64 cross GCC / Binutils for Win32

Building GCC & Binutils for the Nintendo 64

I had a request to help get a GCC+Binutils running as native win32 exe’s something comperable to the ancient ‘ultra’ N64 toolchain done by Kyoto Microcomputer (resume pdf).  One interesting thing about their toolchain is that they used a common object format for MS-DOS, DOS/V and MS-DOS on the PC-98 format, along with Win32.  However the Win32 runtime doesn’t like Win64 environments.  On Win64 the exew32 driver just complains:

Can’t allocate memory (Error Code=487)

However the stubs in all the exe’s reference exegcc98 exegccv DOS extender’s along with a exegcc.  However googling around yields nothing.

Running on a x86 version of Windows, however the tools run and report gcc 2.7.2 release 1.2 and the binutils version is simply 2.6 with BFD version 2.6.  So going with this, and the request to keep it 1997 vintage I went ahead with Gcc and Binutils 2.8.1 as they are the end of the line in both trains of code.

To configure is really a snap, as both support the Windows NT platform directly

sh configure --host=i386-winnt3.5 --target=mips-elf

I guess I should add that I build with TDM GCC 5.1, and I use the incredibly ancient MSYS-1.0.11-rc-1.  But it’s enough to bootstrap and build with!  Since my GCC is much newer, I did have to finagle some things.  Here is a quick list of my notes on what I had changed, and some justification.

Binutils 2.8.1 notes:


make sure this uses MS-DOS rb wb type constraints!


There is no sbrk on my MinGW32 … so comment out all the sbrk stuff.


My sed LOVES UNIX style text files, so this one shouldn’t be in MS-DOS CRLF format.


mkdir only accepts the path on Win32.  Also there is now chown.

Gcc notes:


‘__inline’ for is_reserved_word needs to be commented out.


Set like the following for both ASM_FINAL_SPEC to prevent the t-mips from trying to be run.

#define ASM_FINAL_SPEC “\



Just because we are on Windows NT, doesn’t mean we want an .obj object suffix.


__spawnv : __spawnvp work better as _spawnv : _spawnvp


*((void **)__o->next_free)++ = ((void *)datum);

confuses newer compilers, with this error message:

obstack.h:341:32: error: lvalue required as increment operand

replace it with with:

*(__o->next_free)++ = ((void *)datum);

So at the end I have a cross compiler, and I can generate object files, and link files that the final tool MILD can then use and produce N64 ROM images.  It’s not a 100% solution, as I don’t see any mention of MILD being GNU, however the compiler and binutils is running on Windows 10 x64!

GCC cross compiling to the N64 target

GCC cross compiling to the N64 target

I built a few demos and tested with the 1964 emulator.

And there you have it.  For anyone who cares, you can download the toolchain + source here: winnt3.5_i386-mips_elf-gcc-

Stupid GCC error

So while mixing and matching GCC on Windows, I ran into this issue with stdio.h of all things:

In file included from hi.c:1:0:
\mingw\include/stdio.h:191:65: error: unknown type name ‘size_t’
_CRTIMP int __cdecl __MINGW_NOTHROW setvbuf (FILE*, char*, int, size_t);

Good grief how could stdio be all screwed up?

Well, it turns out it was my fault.  I had not rebuilt things like SDL, or copied over pcap so I figured I could incorrectly just point a -I to my old includes, and the new gcc would post-pend all use -I stuff.  NOPE it pre-pends them, meaning the old headers now take priority.  And wouldn’t you know it, things have drifted between versions.  So I just manually copied the files and libraries and all was well.

Googling around I did see other people with broken stdio.h but nobody posted the solution.  I guess it’s to embarrassing, but here we are.

GCC 6.1.0 for MinGW

Since MS-DOS has it’s 6.1.0 I was dying to re-build stuff for 6.1.0.  As I don’t want to build it myself I did mange to find a version on equation.com

I rebuilt Cockatrice III, and that seems to be running fine.

Continuing from my GCC 1.40 on Windows, here is version 6.1.0’s scores:

Dhrystone(1.1) time for 500000000 passes = 53
This machine benchmarks at 9433962 dhrystones/second

Dhrystone(1.1) time for 500000000 passes = 18
This machine benchmarks at 27777777 dhrystones/second

Dhrystone(1.1) time for 500000000 passes = 16
This machine benchmarks at 31250000 dhrystones/second

Dhrystone(1.1) time for 500000000 passes = 13
This machine benchmarks at 38461538 dhrystones/second

As you can see the scores are actually slower than GCC 5.1.0.  Well that was kind of surprising.  Since I almost never read the manual, I did find out about -Ofast vs -O3/-O2, and yes, it is much faster!  So I guess I should recompile everything with GCC 5.1.0 … But I do prefer the diagnostic messages in GCC 6, it’s very CLANG like.

Ported UAE 0.7.6 to MinGW!



I can’t find any source of the 0.5 versions, and I had issues with 0.6.x  but with enough mashing of stuff around I did manage to get 0.7.6 to compile, then leaning more on the xwin.c source file I was able to get the SDL output working for 32bit depth (does anyone even have 8bit displays anymore?).  I suppose with this version working I can go back and take a stab at resurrecting 0.6.x

What is cool is that 0.7.6 (perhaps earlier versions of 0.7?) switched from a non commercial license to the GPL 2.0 license.

I managed to ‘fix’ the keyboard in this version so that not only does it not type too fast, but it’ll remember “sticky” keys like shift, control & meta.  So now you can actually use the CLI, and change disks.  Double clicking is an impossibility as it simply runs far too fast.  I compiled in audio support but didn’t bother with the SDL end, as it would sound like noise with it running so fast.

I also updated UAE 0.4, with the fixed keyboard code, and it’s usable now as well, with the same caveat that it simply is just too fast.  UAE is from an era where a 100Mhz computer was a luxury item.  Now some $5 computer, you could pack in breakfast cereal has a 1Ghz processor.

For the 2/3 people who care, I put the binary & source tree on sourceforge here. UAE 0.4 & UAE 0.1 are also available for download, plus all the source code I’ve been able to find.

Stack corruption in MSYS with Windows 10

I’m sure it’s happened in other versions of Windows too.  Everything will be fine, then out of the blue you start getting errors like this:

0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x3B0000, State 0x10000
d:\mingw\bin\sh.exe: *** Couldn’t reserve space for cygwin’s heap, Win32 error 0
make: *** [all] Error 1

Well MSYS like Cygwin uses persistent shared memory locations, and if they become corrupt, it’s game over.

So yeah, reboot.

Updated build of Linux 0.11 on Windows 10

Building & Running Linux

Building & Running Linux

I’ve updated my project for compiling Linux 0.11 on Windows 10.  In this version it builds a lot better with TDM MinGW 5.1.0 + MSYS.

The big improvements is that you can compile Linux without the full MinGW/MSYS install by running the ‘blind’ script which will compile the kernel without make and friends.

The build process for the kernel works as well so now with the included Qemu 0.12.5, no need to link under Linux anymore.  I fixed up some of the build processes as I thought I’d re-build and some stuff bombed so it’s all fixed up.

For those interested, I just updated the original download here: