Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE30141E446@probe-2.acclaim-euro.net> From: Shawn Hargreaves 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) Content-Type: text/plain; charset="iso-8859-1" Reply-To: djgpp AT delorie DOT com Eli Zaretskii 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.