db>  portion occur.  Yes, this is a contrived and very small example to 

Contrived is certainly the best way to describe it.  In actual fact, you
have no problem at all, you're just inventing problems.

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

Doesn't worry me in the slightest.  I would normally link a standalone .EXE
as the cleanest thing to have (no stupid messages about out of date DLLs
etc), but recently, supporting DOS took priority over clean .EXEs.

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.

db> Simple, Simon - the *.MSG stuff is built into Msged and not as a separate 
db> component that better lends itself to dynamic linking.  Of course, the 

It could be though, ref where I asked whether you wanted every source file,
every function etc separated out in MSGED.

db> *proper* way would be to throw the *.MSG stuff into a separate DLL (or just 

No it isn't.  The proper way is to link everything together and then test
it out.  The only thing you then have to worry about is the OS changing
under your feet.  Didn't you mention recently that Watcom didn't work
properly for something under Warp?  It's bad enough with the OS changing,
never mind your message-access routines. You're just inventing theoretical
problems.  Most people only report bugs.

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.

db> A single "1Kb", sure - but "1Kb" multiplied by
many hundreds of instances, 

WHAT hundreds of instances?  Just how many applications do you have that
access squish messagebases, and who gives a shit if each of them are
static-linked?  At least the executable has been tested as-is.

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

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

A simple "none, I was just making up theoretical problems" would
have sufficed.

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

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

Hey, I'm the one who reports bugs that I really experienced - FREQ
"MYST*.*" to get a look at some of them.  You're the one
reporting imaginary bugs.

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.

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

The reverse being that the dynamic-linked ones are the ones that get the
disadvantage of an untested combination.

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

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

I don't know the answer is "No", I have no idea.  I do know that
when SQDEV200 came in, he broke the interface, using __FTSCdate or
something instead of FTSCdate.  I changed the interface in MSGAPI38 to
match, the idea being that you might be able to link with SQDEV200 instead
of MSGAPI38.

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

db> Yup.

An untested combination, unlike MSGED/MSGAPI38.  Despite the interface
being supposedly identical.

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.

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

Yes, and that's where you get the "oh shit, the application has
stopped working with the new MSDOS".  That's why the OS developers
have to bend over backwards trying to ensure complete upward compatibility.
 With static link, you just say "stiff shit, a few developers have to
change their code next time they compile", which was exactly what I
had to change in Tobruk when SQDEV200 broke the interface.

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

db> Eventually, it did - this is why I periodically allude to the fact that you 

Yes, you have found out for yourself what untested combinations do. In this
case, MAKEFILE.WAT and Watcom 10.5.

db> really haven't got a clue when it comes to writing portable applications, 

Actually, this is the first I've ever heard you say that.

db> Paul;  you harp on and on about writing to the C spec, which is certainly a 
db> start, 

Actually, it's a finish too.

db> but there is a lot more to writing portable apps than just that.  If 

Actually, there isn't.  Have fun showing me some strictly conforming code
that breaks on a conforming compiler.  I know of one such instance.

db> your "package" (source code, makefiles, etc.) had been
built properly, then 

You're talking about Binkley 2.50.  THAT is an example of non-portable
code.  Tobruk is an example of portable code.  You're getting the authors
mixed up.  I don't wish to take the blame for Vince's code.

db> the jump from 10.0 to 10.5 wouldn't have made any difference at all.  Maybe 

I see, I'm meant to predict in advance that Watcom might change the default
structure alignment option between 10.0 and 10.5 and stick that in to
MAKEFILE.WAT.  Yeah, it's all so much clearer to me now.

db> 10.0 to 11.0 will be different (which is what changes in the major version 
db> number generally indicate), but we've yet to see this in practice.

You might want to drop a note to Watcom not to change compiler defaults
between .5 versions, I *really* *truly* didn't have any say in that
decision.

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

You're the one who answered "No", not me.  And it wasn't a simple
query either, you made a snide comment about MSGAPI38 being a
"wasteful, static library", which is when I thought I'd let you
know what I thought of your theoretical bugs.  Why do you do it, David? 
Why don't you just FREQ "MYST*.*" and "NETCOMM.*" and
"USRPROB.*" etc and complain about some *REAL* bugs?  Oh, and the
OS/2 Fixpack too.  Although they have actually fixed those bugs, so you
probably shouldn't complain about them either.  BFN.  Paul. 

P.S. I should let you know there was a bug in SQDEV200 that someone
reported to me in an MSDOS version (complaining about a bug in MSGED) and I
fixed the bug by going back to MSGAPI38. From memory the bug was to do with
reply-linking.  I did not investigate further.  Just don't bother reporting
the same bug to me in MSGED, because it's already been fixed.
@EOT:

---