This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Size problem
- From: Adam Megacz <gcj at lists dot megacz dot com>
- To: "Erik Poupaert" <erik dot poupaert at chello dot be>
- Cc: "Jeff Sturm" <jsturm at one-point dot com>, <java at gcc dot gnu dot org>
- Date: 12 Jan 2003 19:33:48 -0800
- Subject: Re: Size problem
- Organization: Myself
- References: <POEIJGMGPFPGFHAGKFHAKEKGCDAA.erik.poupaert@chello.be>
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.
>
>
--