Mail Archives: djgpp/1999/06/09/08:59:23
Sorry for a lengthy message; I hope it will be useful nonetheless.
On Tue, 8 Jun 1999, Igor I. Tovstopyat-Nelip wrote:
> Are you sure that this big difference really goes away for large real-life
> programs?
Some (if not all) of the difference is because VC++ doesn't link in
library functions. These are loaded at run time from several DLLs.
In contrast, DJGPP programs are statically linked and include all the
library functions they call.
If you have an immediate question "Why won't DJGPP use DLLs as well",
then read on.
DLLs are really a mixed blessing, because they introduce an additional
dimension into configuration management and subtle system differences.
Consider a DJGPP developer who is maintaining a package. Let's say
that developer finds a bug in one of the library functions. The
obvious solution is to fix the library bug and then relink the
application. In the current setup, the binary distribution of that
application is all users need to run the program reliably, since it
was built with a fixed library.
Now suppose that we ditch the static linking and distribute the
library as a DLL to be installed in every machine. Now the developer
needs to put a fixed DLL into the binary distribution, otherwise the
program will have a bug when it uses an unfixed library on users'
machines. Installing the package would then have to overwrite the
DLLs on users' machines with the fixed version.
But now suppose that the fix in that single library function made it
subtly incompatible with other library functions, which the program of
our developer didn't use (so those problems went unnoticed). What you
have now is a broken system, where programs that worked perfectly
before would now mysteriously crash.
Moreover, since there are quite a few DJGPP packages, all maintained
separately by different individuals, and since users are installing
the new-and-improved versions all the time, after some time there's no
way of knowing what versions of system DLLs are installed on any given
machine. The result is that no developer can be sure that their
program would work on any given system, because the mix of the system
DLLs on users' machines cannot be predicted. What you have is a
system where major programs constantly crash.
Sounds familiar? Of course: this is *precisely* the reason that most
Windows systems are so unstable: people are constantly installing
hottest new versions of Office or IE, and are constantly overwriting
their system DLLs with new and subtly incompatible versions. If you
can afford that, try installing Windows 9X and run it for a year
without installing any add-on package which comes with a replacement
for a system DLL--you will see a rock-solid system that can be run for
weeks without crashing. (Yes, I actually tried that.)
I think wasting some disk space is much cheaper than having to deal
with the user frustration and outcry that would result from using the
DLL approach. Perhaps Microsoft could afford it, but around here a
good name of the product still counts.
- Raw text -