Size problem

[Andrew Haley]

Erik Poupaert writes:
 > >>>> the disk space savings and memory savings
 > 
 > 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.

Undeniably true, at least until interfaces stabilize.

 > >>>>> 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.

No, not at all.  It's a perfectly reasonable way to construct an
application.

 > 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.

How would he know that there were 20 executables?  It's just a way of
building an application.

 > 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.

One _application_, yes.

Andrew.