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!

23 thoughts on “DJGPP 1.03 saved thanks to shovelware +

  1. 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, 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.

  2. I’ve managed to track part of the first djgcc release here:

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

  3. Funny, I’ve wrote a post but it did not show up. I’ve found qhat appears to be the first djgcc release:
    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…

      • Oh, on later posts on I’ve found djgpp 1.03 and 1.05, complete and with full sources (and again, zoo compressed), but those versions were already available.

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

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.