delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/06/09/09:48:03

Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE30141E446@probe-2.acclaim-euro.net>
From: Shawn Hargreaves <ShawnH AT Probe DOT co DOT uk>
To: djgpp AT delorie DOT com
Subject: Re: Hello World and File size
Date: Wed, 9 Jun 1999 14:45:42 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> writes:
> DLLs are really a mixed blessing, because they introduce an 
> additional dimension into configuration management and subtle 
> system differences.

All too true. But I'd just like to add that there is also an 
efficiency argument in favour of static linking, odd though that 
may seem. Disclaimer: these figures are not even remotely scientific, 
as I am comparing unrelated data, but it should at least give some 
indication. Checking the sizes of some files from my hard drive, 
using the last version of Allegro that I happened to put on this 
machine (3.9.14), you get some interesting statistics:

all3914.dll is 483,328 bytes in size. This is an optimised DLL,
compiled using MSVC 6.0.

liballeg.a is 1,141,232 bytes in size. This is the regular djgpp
version of the library. Wow, twice the size! But that is because of 
the symbol table, which doesn't affect the final executable. If you 
strip liballeg.a, it goes down to 542,740 bytes, which is still 
larger than the DLL version, but that is because the DOS library 
contains a lot more features than the current Windows routines 
(eg. that Windows code doesn't contain any sound drivers). In other 
words, you can expect to see the same overall file size from a 
static library or a DLL, which is exactly as you would expect.

The difference comes at runtime. When you link a program with
liballeg.a, unused code can be left out, so if you don't call the
FLIC animation player or 3D texture mapping functions, your 
program will be smaller by however much space that code takes up.
With a DLL, your program will always require the complete file,
even if most parts are unused.

My copy of the djgpp libc.a is 622,440 bytes large, and strips
down to 317,696 bytes. But most programs don't use all of the
functions it contains, and thus many djgpp executables are far 
smaller than 300k. My copy of mfc42.dll is 995,383 bytes. Ok,
so this is a totally different thing to libc, and it is unfair 
to make a direct comparison, but the key point is that you can't
make this any smaller. Even if you only use a single routine from
this DLL, you have to distribute the entire meg of code along
with your program.

So for any given program, a statically linked version will be
smaller than a dynamically linked executable plus the required
DLL files. If you have many programs that share a single DLL,
you can still save a lot of space by using dynamic linking.
This is a huge benefit for a programmer who is writing lots 
of programs using the same compiler, and for system-level 
files like the MFC libraries, or the Linux libc. But for an
end user of a normal application, this has little or no benefit.
If djgpp used a dynamic version of libc, you would then have
to distribute that DLL along with every program that you write,
in order for people who don't use djgpp to be able to run it,
and the end result would be a _much_ larger download.

In other words, dynamic linking is only useful for system software, 
when you can count on the library always being installed so that
you don't need to include it with your program. Otherwise, it
is just an optimisation for the programmer, and actually makes
life harder for the end user. That is the wrong way around.

The other question is of runtime efficiency. Similar issues apply
here to with the executable size: if you only have one program
in use at a time, the DLL approach wastes memory. Since DOS is
a single-tasking system, dynamic linking won't provide much
benefit here. The big win is in cases like a recursive make,
if you could have make, gcc, cc1, cpp, etc, all sharing a single
runtime, but that needs serious support from the OS. Windows
can share a single copy of the DLL code between multiple programs,
and Linux goes even further by doing copy-on-write, which allows
you to share readonly data as well, but this sort of thing would
be an absolute nightmare to implement from inside a DOS program
(I'm not even sure whether DPMI is flexible enough for it to
even be possible).


	Shawn Hargreaves.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019