On Aug 02, 1996 at 01:53, Paul Edwards of 3:711/934.9 wrote:

 db>> That's just *one* executable.  Multiply that mode of thinking across
 db>> every application using that same code, and what happens when you want
 db>> to upgrade it because of a bug?  Relink the bloody lot!  No bloody
 db>> way .. be prepared for Linux, with *shared* libraries everywhere (the
 db>> default).  :-)
 PE>
 PE> There have been plenty of bugs fixed in Msged, most of them not in
 PE> MSGAPI38.  THAT is the main reason you get new Msged executables.

So why tag the same code onto each executable if it isn't changing (the
MSGAPI38 component)?  That should remain static (unchanging, as opposed to
static linking!), and only update the "Msged" component of the
application - that's what dynamic libraries are all about!

 PE> What you REALLY want is bug-free software.

Actually, I do - as does everyone else - but having fault-free software
doesn't alter the matter one iota, as the enhancement factor still weighs
in favour of dynamic linking.

 PE> The static-link of MSGAPI38 does absolutely no harm in the real world.

"Harm" isn't the issue, Paul - it's waste and duplication at issue.

 PE> What you are talking about you have never actually done, just dreamed
 PE> about. BFN.  Paul.

Bullshit!  Recent examples - upgrading variants of EMX under OS/2, if
you've compiled executables using EMX with the dynamic library option, then
place the new DLLs in your LIBPATH and *all* those executables will benefit
from the bug fixes in the new libraries - any static-linked executables
must be re-linked in order to take advantage of the changes/fixes.

Also, under Linux - just took a machine from a 1.2.13 kernel and 5.0.8 libc
to a 2.0.10 kernel and 5.2.18 libc;  every single executable on the system
that's dynamically linked (just about everything) automatically takes
advantage of the 5.2.18 libc and its performance improvements.

No dreams, Paul - Reality(tm).

    - dave
    d.begley{at}ieee.org

---