I also put up the source for my ‘null doom‘, for anyone who ever needs some massaged source to DooM that will compile with a C compiler, instead of needing something that can understand C++ style comments, although I know in cccp.c there is the ability to turn on cplusplus style processing. However since I did want something that would compile without altering the compiler (too much) I thought it was best to just change all the comments.
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:
Although I’m using DPMI to drive realtime 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.
Using GCC 4.1.2 because that is what I wanted.
It’sGCC 4.1.2 for MinGW on OS X. Naturally I had some fun along the way.
cp/cp-lang.o stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o c-dump.o winnt-cxx.o c-pretty-print.o c-opts.o c-pch.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-gimplify.o tree-inline.o dummy-checksum.o main.o libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv ../libiberty/libiberty.a
Undefined symbols for architecture x86_64:
“_libc_name_p”, referenced from:
_nothrow_libfn_p in except.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [cc1plus-dummy] Error 1
make: *** [all-gcc] Error 2
make: *** [all] Error 2
From stack overflow:
When gperf wasn’t installed, the compilation script ran the command anyway but generated a blank
./gcc/cp/cfns.h. Since this file was newer than the source (
./gcc/cp/cfns.gperf) the makefile left it alone and never regenerated the ‘real’ file when you actually had gperf. To continue, run
rm ./gcc/cp/cfns.h and try again.
to dealing with duplicate inlines exact_log2 from an include gone wrong. Not to mention more and more headers not generating. But in the end it actually works. As always it feels so much faster to run on OS X than Windows. I’m sure there is stuff out there for newer versions of GCC, but I wanted to use the older toolchain and libs for some other reason.
As always it’s on my site here: OSX_16.3.0-MinGW_GCC_220.127.116.11z but I don’t think the world at large would even care.
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 D:\proj\gcc-3.0.4\gcc>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.
In my quest for old software, I’ve seen this file in multiple searches, gcc-0.9.tar.bz2, which is the first version of GCC!
article from virtuallyfun.superglobalmegacorp.com
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
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
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
- 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?
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 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
- Make a symbolic link from `tm.h’ to the machine-description
macro file for your machine (its name should be
- Make a symbolic link from `md’ to the
machine description pattern file (its name should be
- 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
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
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
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:
And of course source tapes are here.
While cruising archive.org, I found this CD-ROM image, “OS/2 Archive CD-ROM Walnut Creek May 1992“, which included the following zoo files:
05/05/1992 09:46 AM 144,272 EMXDEV.ZOO
05/05/1992 09:44 AM 167,809 EMXINFO.ZOO
05/05/1992 09:46 AM 101,132 EMXLIB.ZOO
05/05/1992 09:46 AM 19,266 EMXTEST.ZOO
05/05/1992 09:46 AM 586,285 GNUDEV.ZOO
05/05/1992 09:40 AM 78,575 GNUPAT.ZOO
05/05/1992 09:41 AM 138,891 GNUSRC1.ZOO
05/05/1992 09:41 AM 184,671 GNUSRC2.ZOO
05/05/1992 09:45 AM 1,044,875 GNUSRC3.ZIP
05/05/1992 09:43 AM 1,015,692 GNUSRC3.ZOO
05/05/1992 09:42 AM 505,127 GNUSRC4.ZOO
05/05/1992 09:45 AM 3,178 README.DOC
And from the readme, the release is from Feburary of 1992. Keeping in mind the GA release of OS/2 2.0 was released in April of 1992.
EMX 0.8b INTRODUCTION 22-Feb-1992
Welcome to emx, a common environment for creating 32-bit programs for OS/2 2.0
and MS-DOS. You can use the GNU C compiler to compile programs for EMX.
Included in the emx package are:
- emx.dll dynamic link library for OS/2 2.0
- emx.exe DOS extender for running 32-bit programs under MS-DOS
- emxbind.exe for creating .exe files which work both under OS/2 2.0 and
- C header files and a nearly complete C library, including source
Additionally, the following GNU programs are available compiled and with
sources (note that these files are not part of EMX):
- gcc, the GNU C compiler
- gas, the GNU assembler
- gdb, the GNU debugger
- ld, the GNU linker
- ar, nm, size, strip, objdump: some GNU utilities for dealing with binary
- Patched source for gcc, gas, gdb, ld, ar, nm, size, strip, objdump. You can
compile all these programs with the files that come with emx (but you also
need a make utility, such as NMAKE)
So this pretty much sums it up. I went ahead and extracted the ZOOs and placed a copy on my site: emx08b_extracted.7z Although I don’t think anyone really cares about ancient versions of GCC on OS/2.
EMX on Win32
I know it’s utterly pointless… But yeah GCC 2.8.1 + EMX 0.9d, hosted (running) on Win32. The main reason is that I wanted to be able use use my substantially faster Win64 machines to build stuff for OS/2. And since I have a 4 core (+4 hyper thread), I want to be able to use make with the -j 16 flag, and say compile QuakeWorld/2 in under two seconds.
I was able to get the binutils 2.6 derived stuff to compile, along with the ‘ancient’ binutils which is notably the linker that EMX depends on. I would imagine this ought to be able to compile PDOS, although my own simple attempt at InfoTaskForce met with spectacular failure. While it does compile fine using an older EMX 0.8h based release.
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 18.104.22.168 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
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 22.214.171.124 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!
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-126.96.36.199_binutils-188.8.131.52z
I’m using Slackware 4.0 as a starting point, so it’s Binutils 2.9.1 and GCC 184.108.40.206 .. I verified that I can build a static hello world executable, and it runs! …
However Linux 2.0.40 has the same issue, it starts to decompress, and triggers a reboot in both Qemu and PCem. Going in circles I guess. I suppose the next step is to use the exact version they have in Slackware to see if Qemu can actually run that pre-built kernel, and if I can create one via cross compiling.
I should add that on Debian 7.1 I got GCC 220.127.116.11 running, and it too produces the exact same thing.
After getting Linux 0.98 to compile, I thought I’d take a stab at Linux 1.0. I vaugely recall when it was released, and I just remember a much larger push to 1.1. So I guess it really comes as no surprise that in the Linux kernel archives, there is simply the 1.0 tar, and 9 patch files.
I went ahead, and patched up the release, and then tried to build with GCC 2.3.3. This however proved not to be up to the task, as 2.3.3 has issues with some of the assembly macros, so delving into the readme shows that you need to use GCC 2.4.5 or higher. Since I wanted to keep at least the tools on par, I went ahead and build 2.4.5, and once more again used the gcc driver from 2.6.3. I further ended up relying on headers, and checking tool versions from Debian 0.91, which also revealed that they were still using GAS 1.38 back then.
One interesting note while building piggback, which takes the compressed system object, and wraps it in an object file, is that it directly uses the magic “0x00640107”, which is for a later “Linux/i386 impure executable (OMAGIC)” filetype. But because my binutils is so ancient, I needed to change it to “0x00000107” so that the linker would recognize it as a “386 executable not stripped” file. As always when having no idea what I was doing, it was easier to have it make an empty object file, set the type for 12345678 and look for where it occurs in the data stream, and just match it with a known object file. As you can see, it worked.
And of course, you’ll want the latest download, which includes the pre-built tools, qemu, and build environment to get you started.