Size problem

Mon Jan 13 03:34:00 GMT 2003

The only compelling argument I've ever heard for shared libraries
(with modern computer prices, of course -- things were different in
the 70's when this stuff was invented) is upgradability. When the
libz buffer overflow was discovered, all those apps that statically
linked libz were a real pain in the butt to secure.
 - a
"Erik Poupaert" <erik.poupaert@chello.be> writes:
> At the beginning of a dll's existence, it may even be true. But wait until
> it exists in 12 different versions, with different applications linked
> against these different versions. Two versions of a dll are treated by the
> system as two different dlls in every respect. A dll is usually a moving
> target. The faster it moves (gets released more often), in relation to your
> application, the less chance that other applications will use the same
> version, and the less chance that you will realise any savings.
>> >>>>> But if you application consists of 20 executables which have 80% of
> their code in common, then
> >>>>> you really want shared libraries.
>> 20 executables is something like a toolkit you deploy to other developers,
> or administrators for scripting purposes or so. These people can re-compile
> and re-build by themselves to whatever config they need. I really wouldn't
> bother. The average windows user, however, would use a GUI with 20 or more
> forms. He wouldn't be able or even want to handle 20 executables. Especially
> task oriented workers, like for example POS workers (Point of Sale). They
> don't even have access to the OS. They boot right into their one and single
> application. And the ones that do have access to the OS, are usually a
> support nightmare.
>>
--