I can’t stress enough just how awesome cd.textfiles.com 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!
Wasn’t exepack’s “Packed file is corrupt” triggered by certain memory situations, too? (and wasn’t there even a patch distributed with later DOS versions that fixed this error?)
I’m not sure, I just know it was a good sign that your machine state was questionable, and you ought to reboot….
Not necessarily, “Packed file is corrupt” also happens if you have *too much* RAM available! As described in https://jeffpar.github.io/kbarchive/kb/072/Q72360/, LOADFIX addresses this by forcing the application to not load in the first 64K of RAM. Other workarounds suggested there are just running another copy of COMMAND.COM. DOSBox is prone to triggering this since it has a lot of RAM available by default, but at least in recent versions it does have LOADFIX.
Oops, I just realized that some of the posts below were links to this or other related information!
Look what I found:
ftp://ftp.microsoft.com/misc1/PEROPSYS/MSDOS/KB/Q72/3/60.TXT
wow what a blast from the past!
mirror: https://ftpmirror.your.org/pub/misc/ftp.microsoft.com/MISC1/PEROPSYS/MSDOS/KB/Q72/3/60.TXT
See this:
http://www.os2museum.com/wp/?p=753
And this:
http://www.os2museum.com/wp/?p=734
I’ve managed to track part of the first djgcc release here:
http://193.166.3.2/pub/archive/comp.binaries.ibm.pc/volume10/dj1bin/
http://193.166.3.2/pub/archive/comp.binaries.ibm.pc/volume10/dj1lib/
After unpacking, joining and uudeconding those files I ended with dj1bin.zoo and dj1lib.zoo files, original binaries and libs.
Unfortunatly, header files are incomplete, so no header (nor source code):
http://193.166.3.2/pub/archive/comp.binaries.ibm.pc/volume10/dj1inc/
Wow it’s something to dig around for. And not surprising it’s also zoo format.
I’d always associated zoo with the ST and CP/M… Or early PC. I guess zip wasn’t quite hip yet.
I’ll have to try it.
Also the bootstrap stuff like gcc.exe were almost always turbo c++ as the ability to chain protected mode stuff wasn’t exactly stable back then.
And just last week I found that pharlap workalike too!
Give it a go, hope you enjoy the discovery
Kind of funny DJGPP is old enough to be at the tail end of UTZOO
https://utzoo.superglobalmegacorp.com/usenet/b202/comp/binaries/ibm/pc/3506.txt
So it turns out this release is in UTZOO, and I’ve been sitting on it for years. Ironically I built that altavista personal search proxy thing to look for stuff, but never searched for djgpp. The includes zoo is intact!
The binary announcement is here:
https://utzoo.superglobalmegacorp.com/usenet/b202/comp/binaries/ibm/pc/3506.txt
Docs announcement:
https://utzoo.superglobalmegacorp.com/usenet/b203/comp/binaries/ibm/pc/3562.txt
Lib announcement:
https://utzoo.superglobalmegacorp.com/usenet/b204/comp/binaries/ibm/pc/3569.txt
And includes:
https://utzoo.superglobalmegacorp.com/usenet/b203/comp/binaries/ibm/pc/3564.txt
Although it appears the zoo has always been corrupted.
All I had to do was use the gateway:
https://altavista.superglobalmegacorp.com/altavista?pg=q&what=0&q=dj1bin.zoo&search.x=0&search.y=0
And here is the announcement, mentioning no source:
Originally-from: grape.ecs.clarkson.eduSubmitted-by: [email protected]
Archive-name: dj1bin/part01
This is the first of many parts of gcc and g++ for DOS running on 386
and 486 machines. It doesn't run on any of the smaller machines, nor
will it, since the hardware is just not there for 32 bit arithmetic. It
will run integer programs without a 387, but will not even compile a
program which uses float (including constants). I've been trying it and
while it's useful, it is not totally bug free yet, so there will
probably be an update in a month or so based on user's reports.
There will be postings of binaries, the include files, and the
libraries. I am confident enough in an update soon that I'm holding off
on the sources for now, they'll come last if there's no update.
This software is usefully robust, but certainly not without some minor
flaws in either documentation or the implementation.
Please post comments or mail them to the submitter, not to me. I'm just
a user like you.
dj1inc unpacked fine. got part5 from my previous link, uudecoded dj1inc.zoo, unpacked (unzooed?), got a “INC.TAR” file, untarred… and all header files came out without a single warning.
Now, what about the sources?
In the binary post it mentions that there is no source for this release. Maybe for the following release.
volume 16 of that site you found has something called GPP5 which should be the next release of DJGPP.
There is *SOME* source in there.
http://193.166.3.2/pub/archive/comp.binaries.ibm.pc/volume16/
Yeah, I’ve said that on the post bellow. Gpp5 (1.05) and Gpp3(1.03) were available. I was hoping to rebuild djgpp using turbo c …
Anyway, those are the oldest files we can get. Too bad there is no mirror from that era, no http://ftp.archive.org.
I am now looking for older fmsx source code for unix, versions 0.1 to 1.0. they are out there somewhere.
Funny, I’ve wrote a post but it did not show up. I’ve found qhat appears to be the first djgcc release:
http://193.166.3.2/pub/archive/comp.binaries.ibm.pc/volume10/
Some uudecodig I’ve got “dj1bin.zoo” and “dj1lib.zoo” (binaries and libs). Unfortunatly, header related posts were incomplete.
Most files are dated from january 1991, and executable files were built with Turbo C.
No source code found…
Don’t worry the spam thing is a bit strong, but I do manually review it as often aa I can.
Oh, on later posts on comp.binaries.ibm.pc I’ve found djgpp 1.03 and 1.05, complete and with full sources (and again, zoo compressed), but those versions were already available.
On a side note, there is an even older port of gcc to msdos. never heard of it before.
http://cd.textfiles.com/bbox4/progc/gccmsdos.arj
files are dated as of april, 1990
I think this is the Japanese one that is ported from the FM-Towns… Actually yeah the towns.h has credit to Keisuke Yoshida.
It very well may be an older version of TOWNS-gpp.
Japan had quite the movement of GCC on home machines, also the x68000 although their native tools were written in assembler.