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.

db> So why tag the same code onto each executable if it isn't changing (the 
db> MSGAPI38 component)?  

Between bugfixes, maybe 1% of the code changes, but I still ship 100% of
the executable.  That's the nature of creating an executable, or would you
have me separate every single source file, or maybe even every single
function, into a separate DLL?  No thanks.  MSGAPI38 is just one set of
routines, just like the *.MSG reading routines are just another set.  I
didn't notice you getting so worked up about the *.MSG routines being
statically linked.

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

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

How many K are we talking about here?  There are date manipulation routines
in MSGED too, which are probably also found elsewhere. Yes, you could get
everyone organized and find out if we could save 1k of your disk space, but
it's an entirely useless exercise.

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

db> Bullshit!  Recent examples - upgrading variants of EMX under OS/2, if 
db> you've compiled executables using EMX with the dynamic library option, then 
db> place the new DLLs in your LIBPATH and *all* those executables will benefit 
db> from the bug fixes in the new libraries - 

WHAT BUGS THAT YOU WERE EXPERIENCING?  The theoretical ones, yes, know all
about those ones.

db> any static-linked executables 
db> must be re-linked in order to take advantage of the changes/fixes.

It's quite the reverse.  Msged has been tested with ONE particular version
of MSGAPI.  I know it works with that one, otherwise I would have had bug
reports.  By changing the DLL, you are basically running a completely
untested combination.  AND you have experienced problems when you did that
too, which is how this convo started.

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

If I do an INT 21 call under DOS, and in DOS 6.2 they make a performance
increase, then we all get to take advantage of that, same as Linux.  It is
then the operating system's jobs to be very very careful to make sure that
they stick to the interface.  In the case of MSGAPI, when a new version is
released, I will evaluate it and decide whether a new version of MSGED
should have it.  Which is precisely what I did, and then promptly ditched
it when I found that the new version wasn't as good as the old version.  If
the reverse had been the case, I would have tested the new code with msged,
and if it had worked, I would have used it, and if it had failed (due to
either a new bug in MSGAPI, or a dormant bug in MSGED), I would have fixed
it if I could, before creating a new MSGED .exe.  Either way, the MSGED
.exe would have been tested with the combination.  Same as if there is a
new compiler.  You experienced this yourself, something that compiled with
Watcom C 10.0 did NOT compile + run under Watcom C 10.5.  Not a big
problem, since it was compiled and tested under 10.0, so the .exe is fine. 
BFN.  Paul. 
@EOT:

---