DOS ain't dead

There is a page on the djgpp site that describes how to make the executables smaller:

http://www.delorie.com/djgpp/v2faq/faq8_14.html

Georg

>
> How many of these you did in your djgpp203.7z?

Unfortunately, not many, due to time, complexities, or whatever. I mostly just recompiled everything with 2.03p2 with -march=i386 -O1 (or -Os) and let 7-Zip (solid LZMA compression) do the rest. I tried to keep it as sane, "modern", and stock (unmodified) but useful as possible. Despite nobody appreciating it but me, I still consider it a successful package, esp. for fitting (compressed) on one floppy (and unpacking on very low RAM machines).

> > * check linker map (mkdir() function pulling in ctime.o without reason?)

I noticed this with 7zdecode, when 9.x added subdir extraction via 'x', it bloated 10 kb. mkdir() accidentally was pulling in filetimestamp(). But nobody else really cared, so I never submitted a "perfect" patch for 2.03p2 or 2.04 or CVS trunk.

> > * recompile (parts of) libs with -Os or -O1 ("ar rvs libblah.a
> smaller.o")

Last I heard, some of it was using -O2, some -Os, etc. I never bothered looking too closely. I'm sure it could be more fine-grained, in smaller pieces, esp. since the linker isn't "smart", but I didn't see any obvious place to slim it down, at least nothing worth immediately doing. Again, check the linker map, it should show you the biggest pieces. But most of it doesn't really use exorbitant amounts or anything. Sure, it's not nearly as small as raw assembly, but you can't have everything.

EDIT: --gc-sections doesn't work on COFF.

> > * recompile (parts of) libs with stripped functionality or hand-written
> > assembly

If you don't need floating point support in printf(), you can shave off about 2 kb from _doscan().

> > * avoid printf (and related) in lieu of _dos_write (etc.)

Better to avoid printf() altogether if you don't majorly need it. Though I think OpenWatcom is slightly worse about this than DJGPP.

> > * use empty cmdline glob function

See djgpp203.7z's tiny.c, but it's rarely useful (and only saves about 6 kb). This is really only meant to mimic *nix shell default globbing.

> > * 2.03p2 (no true symlink support in libc)

I almost always prefer 2.04 for various (mostly unnecessary) reasons, even though it's bigger. But it does have better symlink support, which does bloat things up a bit more. If you don't need it, don't use it. At least recompiling UNZIP with 2.04 was worth it (to me) for that, though.

> > * strip ("gcc -s" or "ld -s" or "strip blah.exe")

gcc.exe is just a compiler driver, it doesn't actually do much anyways. cc1.exe is the real compiler proper. So "gcc -s" really is just "ld -s", which does strip. Hence I don't include separate strip.exe in djgpp203.7z because you don't need it!

The best way to save space is to not include what you don't need.

> > * compare various (-O1 or -Os or -O2) with UPX --ultra-brute --small

--small is undocumented (IIRC) and doesn't save barely 1 kb (I think??). But yeah, sometimes -O1 is smaller after UPX, but sometimes -Os is instead. (BTW, GCC 2.7.2.x didn't have -Os, only -O2.)

> > * -fomit-frame-pointer

Normally this doesn't help and makes it slightly larger, but sometimes it's still good to compare with and without.

> > * -fno-align-functions, -fno-align-labels, -fno-align-loops,
> > -fno-align-jumps

These don't save much, so usually I don't bother. But perhaps that last little crumb of space can be saved here.

> > * -march=i386, -march=i486, -march=i586

I'm not 100% sure if these would save anything. 386 should be best, but maybe not. I know 486 was just extra alignment, so avoid that, but who knows how small it is "after" UPX.

> > * don't bind DPMI host, use default 2 kb stub, leave CWSDPMI separate

You don't (usually) need ten bazillion DPMI hosts bound to every single .EXE, so you can obviously save space by having it separate (and letting the default stub call it). While D3X is fairly good, CWSDPMI is slightly better in some ways (including the licensing, which I hate arguing about, but ...).

> sorry for bumping, but since there is some years after this reply and I
> wonder if anything is changed in DJGPP 2.05.
> and newer bash-4.1 seems working better.

I don't know if you need DJGPP in particular, but
note that if you use HX, which supports DLLs, and
you use the MSVCRT.DLL provided by PDPCLIB for the
C library, and you use gccwin.exe or equivalent as
your C compiler, you can have a "hello world" of
about 3K.

BFN. Paul.

> sorry for bumping, but since there is some years after this reply and I
> wonder if anything is changed in DJGPP 2.05.
> and newer bash-4.1 seems working better.

printf() is much bigger, so it should be avoided, if possible (!). (7ZDEC avoids it.) Symlink support in 2.05 (like in 2.04) adds some bloat.

I'm still not quite sure if --gc-sections is even accidentally supposed to work for DJGPP COFF, but it does halfway work (still), e.g. 7ZDEC (see my MAKEFILE.GNU "SMARTLINK=1"). I tried again this morning with GCC 10.3 and whatever latest BinUtils is, and it seems to save some noticeable space (although UPX'd makes it less pressing).

But DJGPP was never optimized well for size. They just never found the time or motivation. But I'm grateful for what we have.