Mail Archives: djgpp/1999/06/09/12:50:28
Thank you very much for your comprehensive answer. I think I understand it
better now.
Though, I still think that dynamic libraries might be not that bad. For
instance, all kinds of Unixes use them intensively and nevertheless may be
regarded as solid and reliable systems. You just have to maintain those
libraries in an organized and systematic way.
Concerning relative file sizes (DJGPP and VC++), they are getting close
when the program is compiled in DJGPP with '-s' switch (stripping
symbols). As a beginner I just didn't know that DJGPP produces a debugging
version of executable by default (which is not usually a case in Unix).
Igor.
On Wed, 9 Jun 1999, Eli Zaretskii wrote:
> 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 -