On Aug 12, 1996 at 23:58, Paul Edwards of 3:711/934.9 wrote:

 db>>  portion occur.  Yes, this is a contrived and very small example to
 PE> Contrived is certainly the best way to describe it.  In actual fact, you
 PE> have no problem at all, you're just inventing problems.

Paul, you completely ignored the meaning.  Pity.

 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...
 PE> Doesn't worry me in the slightest.

And you care not for anyone else?  So much for all your rhetoric about
"support" for end-users of your "product".

 PE> I would normally link a standalone .EXE as the cleanest thing to have (no
 PE> stupid messages about out of date DLLs etc)

You're talking about something you have never actually experienced.  In
actual fact, you have no problem at all, you're just inventing problems.

 PE> but recently, supporting DOS took priority over clean .EXEs.

Supporting DOS really doesn't have to suddenly mean that everything else
becomes broken, y'know...

 PE>> I didn't notice you getting so worked up about the *.MSG routines being
 PE>> statically linked.
 db>> Simple, Simon - the *.MSG stuff is built into Msged and not as a
 db>> separate component that better lends itself to dynamic linking.
 PE> It could be though...

But at the moment, it's not - ergo, I said nothing about it.

 PE> ...ref where I asked whether you wanted every source
 PE> file, every function etc separated out in MSGED.

On your part, that's either extreme sarcasm or extreme ignorance about
dynamic linking.  Actually, under a decent DOS extender you can support
DLLs, too.  Not that it matters much to you...

 db>> Of course, the *proper* way would be to throw the *.MSG stuff into a
 db>> separate DLL...
 PE> No it isn't.

Yes it is.

 PE> The proper way is to link everything together and then test it out.

What do you think happens at run time?!

 PE> Didn't you mention recently that Watcom didn't work properly for
 PE> something under Warp?

Yes I did, but that problem was *not* caused by dynamic libraries - it was
caused by (surprise, surprise) a *static* object file no longer being
included in Warp that was present in previous versions of the operating
system, and only affected 16-bit OS/2 compiles.

 PE> You're just inventing theoretical problems.

Nope.

 PE> Most people only report bugs.

Most people are morons.

 PE> At least the executable has been tested as-is.

If your application is so marginal that it requires a certain form of
linking just to work, then your application is broken.  *That's* the sort
of programming mentality that is driving the popularity of products like
Visual Basic and Delphi through the roof - no more stuffing around.

 db>> Irrelevant, Paul - you claimed I hadn't actually done the deed, not
 db>> whether or not I had experienced the bugs that the newer code claimed
 db>> to fix.
 PE>
 PE> A simple "none, I was just making up theoretical
problems" would have
 PE> sufficed.

'cept that the "problems" aren't theoretical.  Do you plan on
recompiling everything in Linux to be static-linked, Paul?  You're going to
be disgusted when you find out just how much of the system really *is*
dynamic-linked.

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

I'm not reporting a "bug", that's your allocation - I'm reporting
a design/engineering fault in your product, that (like the
"unusual" way in which the USRs worked, according to your own
experiences) basically leads to it being labelled, "broken".

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

Nope - you can still claim that you've tested it with *your* DLL.

 PE> Yes, and that's where you get the "oh shit, the application has stopped
 PE> working with the new MSDOS".

So you blame the new MS-DOS and either:

(a)  wait for Microsoft to write a fix;  or,
(b)  provide your own work-around in your application.

In either case, the benefits of "reusable objects" (which is what
DLLs really are) are too great to be discarded merely because of petty
problems like this.  Don't you think incompatibilities through new versions
happen all the time?  People get over it, it's not an insurmountable
problem...

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

Reality check, Paul - the problem was *not* caused by the change in
version, but by the defaults I was using for compiling having changed;  the
Makefile made assumptions about "the defaults", and in this case
those assumptions were wrong.  That's what portability is all about -
getting the assumptions right.

 db>> really haven't got a clue when it comes to writing portable
 db>> applications,
 PE> Actually, this is the first I've ever heard you say that.

I said, I've been alluding to it for a while.

 db>> Paul;  you harp on and on about writing to the C spec, which is
 db>> certainly a start,
 PE> Actually, it's a finish too.

There you go again, flaunting your ignorance.  Paul, if *only* it were that
simple, I wouldn't have to spend so many bloody hours patching people's
source code just to work in different environments or on different systems
- and these guys are meant to be commercial programmers!!

The idea is to port to a *function* or *feature*, *not* to a *platform* or
*compiler*;  do the former, and you'll cover more platforms/compilers in
one hit than the latter (plus it makes further porting much easier).

 db>> but there is a lot more to writing portable apps than just that.  If
 PE> Actually, there isn't.

You'll learn.  You've committed to migrating to Linux, so in time, you'll learn.

 PE> Have fun showing me some strictly conforming code that breaks on a
 PE> conforming compiler.  I know of one such instance.

Sure, okay.  A couple of years ago I had to write a C pre-processor as an
assignment, and in doing so I followed the C spec to the letter, creating
source specifically designed to break the pre-processor.  At the time, I
managed to show that neither Borland C++ nor GCC were strictly conforming
to the spec, so I'll dig that out and see if any of our modern compilers
still have those problems or not.

 PE> THAT is an example of non-portable code.

Yup.  And Msged isn't that much better - both of them are just hack after
hack after hack in order to work on different platforms.

 PE> Tobruk is an example of portable code.

Much better.

 PE> You're getting the authors mixed up.  I don't wish to take the blame for
 PE> Vince's code.

I'm not blaming you for anything, I'm just in total disagreement with your
design decisions regarding Msged.

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

Good - now go and do it!  :-)

 PE> You're the one who answered "No", not me.  And it wasn't
a simple query
 PE> either, you made a snide comment about MSGAPI38 being a
"wasteful, static
 PE> library"...

Which it is...

 PE> ...which is when I thought I'd let you know what I thought of your
 PE> theoretical bugs.

...which they're not (neither theoretical, nor bugs), and is beyond the
answer to the original question.  Thanks.  :-)

 PE> Why don't you just FREQ "MYST*.*"...

Got 'em, and maybe one day I'll find the time to investigate them fully.

 PE> ...and "NETCOMM.*"...

Maybe this one too, we'll see.

 PE> ...and complain about some *REAL* bugs?

I once kept a list of RealBugs(tm), including a product's inability to
handle certain file formats (which it claimed it supported), tendancy to
crash when printing or scrolling back, etc.  Doesn't change the fact that
the products still had lousy design decisions that led to those bugs.

 PE> Oh, and the OS/2 Fixpack too.

Any particular one?  FP17 runs fine here.

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

I don't use DOS.

    - dave
    d.begley{at}ieee.org

---