On Aug 05, 1996 at 04:49, Paul Edwards of 3:711/934.9 wrote:

 PE> Between bugfixes, maybe 1% of the code changes, but I still ship 100% of
 PE> the executable.  That's the nature of creating an executable, or would
 PE> you have me separate every single source file, or maybe even every single
 PE> function, into a separate DLL?

Of course not, don't be ridiculous.  If the core component is 64Kb and the
remainder is 120Kb, then instead of shipping around 184Kb all the time you
need only ship 120Kb most of the time, a separate 64Kb when updates to that
portion occur.  Yes, this is a contrived and very small example to
illustrate a point - exercised on a grander scale, the benefits are far
greater.

What if all those EMX-built applications all shipped with static-linked
libraries instead of dynamic links to the EMX*.DLL family?  Ouch...

 PE> No thanks.  MSGAPI38 is just one set of routines, just like the *.MSG
 PE> reading routines are just another set.  I didn't notice you getting so
 PE> worked up about the *.MSG routines being statically linked.

Simple, Simon - the *.MSG stuff is built into Msged and not as a separate
component that better lends itself to dynamic linking.  Of course, the
*proper* way would be to throw the *.MSG stuff into a separate DLL (or just
use the *.MSG support in MsgAPI), but that would be far messier at present
- I did tell you that MsgEd was in a pretty poor state.

 PE> Yes, you could get everyone organized and find out if we could save 1k
 PE> of your disk space, but it's an entirely useless exercise.

A single "1Kb", sure - but "1Kb" multiplied by many
hundreds of instances, well now you're talking .. we may have plenty of
disk space to play with, but that's no reason to waste it (we may have more
important things to store in those itty bitty sectors, y'know!  *grin*).

 PE>> What you are talking about you have never actually done, just dreamed
 PE>> about. BFN.  Paul.
[...]
 PE> WHAT BUGS THAT YOU WERE EXPERIENCING?

Irrelevant, Paul - you claimed I hadn't actually done the deed, not whether
or not I had experienced the bugs that the newer code claimed to fix.

 PE> The theoretical ones, yes, know all about those ones.

Of course, the world's foremost authority on theoretical bugs, aren't you,
Paul?!  ;-)

 db>> any static-linked executables must be re-linked in order to take
 db>> advantage of the changes/fixes.
 PE>
 PE> It's quite the reverse.

The *reverse* - what, static-linked executables need *not* be re-linked? 
How do you expect the new code to work in old executables, by osmosis from
one binary to the next?!  C'mon, Paul...

 PE> By changing the DLL, you are basically running a completely untested
 PE> combination.

In *this* case, we're actually changing products as SJD's MsgAPI and
MsgAPI38 are really not all that much alike anymore (shame), which is why I
asked in the first place whether or not all the recent changes you'd made
still left MsgAPI38 as a drop-in replacement or not - seems the answer is
now "No", and further that MsgEd has been developed specifically
for MsgAPI38, and not generically for "MsgAPI" (whichever
version/variant).

 PE> AND you have experienced problems when you did that too, which is how
 PE> this convo started.

Yup.

 PE> If I do an INT 21 call under DOS, and in DOS 6.2 they make a performance
 PE> increase, then we all get to take advantage of that, same as Linux.

Great thinking, Paul!  See, how often do you duplicate Int 21 handler code
in your applications?  Not at all, you reuse the code in DOS so any changes
to the underlying handlers are automatically used by each application
without requiring a re-link .. well done, now you're catching on!  :-)

 PE> You experienced this yourself, something that compiled with Watcom C
 PE> 10.0 did NOT compile + run under Watcom C 10.5.

Eventually, it did - this is why I periodically allude to the fact that you
really haven't got a clue when it comes to writing portable applications,
Paul;  you harp on and on about writing to the C spec, which is certainly a
start, but there is a lot more to writing portable apps than just that.  If
your "package" (source code, makefiles, etc.) had been built
properly, then the jump from 10.0 to 10.5 wouldn't have made any difference
at all.  Maybe 10.0 to 11.0 will be different (which is what changes in the
major version number generally indicate), but we've yet to see this in
practice.

And Paul, I really don't care - I asked if you used dynamic libraries
and/or if MsgAPI38 was a drop-in replacement for MsgAPI;  a simple,
"No" satisfies the query, thanks.  :-)

Cheers..

    - dave
    d.begley{at}ieee.org

---