On Aug 15, 1996 at 23:03, Paul Edwards of 3:711/934.9 wrote:

 PE> I don't care for anyone else's theoretical bugs, nor their theoretical
 PE> complaint about 1c worth of theoretical disk space for a free product.

What "bugs", Paul?  Since none of this is theoretical, you're
still off in fairy land.  It's a poor design decision, first and last -
you're the one fixated on this being a "bug".

 PE>> (no stupid messages about out of date DLLs etc)
 db>> You're talking about something you have never actually experienced.  In
 PE> I do experience that.

Those messages, like:

    libc for emx 0.8g WARNING: emx 0.8g or later required

are neither "stupid" nor fatal - they are as indicated, a
"warning".  Don't like 'em?  Disabled 'em.  'nuff said.

BTW, your Linux ELF binary is dynamic linked - better fix it, otherwise
people will change the C library out from under your application.

 db>> But at the moment, it's not - ergo, I said nothing about it.
 PE> Neither is MSGAPI at the moment...

Yes it is - if it wasn't, you wouldn't need to download
"MSGAPI38" separately.

 db>> On your part, that's either extreme sarcasm or extreme ignorance about
 db>> dynamic linking.
 PE> Or you're wrong.

Nope.

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

Yes it is.

 PE> Someone's bright idea to delete a static-linked library?

Static-linked object file, yes;  it's no longer required in Warp or above
since that functionality has been merged into a DLL.  All the more reason
for you to dump OS/2.  :-)

 PE>> You're just inventing theoretical problems.
 db>> Nope.
 PE> Yep.

Nope.

 PE>> Most people only report bugs.
 db>> Most people are morons.
 PE> People who only report real bugs, instead of reporting theoretical bugs,
 PE> are morons.  Ok, I understand now.

Good!

 PE>> At least the executable has been tested as-is.
 db>> If your application is so marginal that it requires a certain form of
 db>> linking just to work...
 PE> No, it requires a working library.

Wrong, you're completely avoiding the issue of *which* "library"
is used, and concentrating on the fact that it *must* be static-linked
otherwise it won't work.  Bullshit.

 db>> then your application is broken.
 PE> Tell me the sequence of keystrokes you used for the bug to occur, and
 PE> I'll see if I can fix it for you.

Why bother, you're so hell-bent against the philosophy of reusable objects,
now I can see why you've stuck with C and haven't migrated to C++.

 PE> Tell me the sequence of keystrokes, and I might believe you.

"m", "s", "g", "e", "d", [Enter].

 PE> You will be the first person to report that problem if it is the case...

Which of course means that it's my system at fault, since I'm the only one
reporting the "fault".  Shit yeah, we all know how this story
ends...

 db>> Do you plan on recompiling everything in Linux to be static-linked,
 db>> Paul?
 PE>
 PE> No, why should I care how my operating system is implemented?

You said so yourself - untested combinations of libraries and executables; 
everything you compile by default is going to be dynamically linked to
whatever libraries are on your system today, not necessarily what will be
there tomorrow, nor what will be on other people's systems.

 db>> You're going to be disgusted when you find out just how much of the
 db>> system really *is* dynamic-linked.
 PE>
 PE> No I won't, I don't care.

Sure.  ;-)

 db>> I'm not reporting a "bug"...
 PE> Then what's the problem?

You're right, USR modems don't have bugs at all, so there's no problem.

 PE> Design faults cause real-world problems.

You're right, USR modems don't have bugs at all, so there's no problem.

 PE> Please let me know your REAL problem with MSGED, and I'll address that,
 PE> whether that be a bug in quick.c, template.c, msged.c, config.c,
 PE> msgapi38.zip, etc.

You're right, USR modems don't have bugs at all, so there's no problem. 
(BTW, I pick "msgapi38.zip".)

 PE> Failure to auto-baud-detect is a REAL bug/design fault, it causes REAL
 PE> problems.

For you alone, not anyone else.  Should that be all the required reason to
dismiss this problem?  Does the way in which it is implemented, despite the
fact that it works one way and not another way, constitute a
"bug" or a "design fault"?  Whatever your answer is,
that's what's wrong with Msged being so tightly married to MsgApi38.

 PE> I can tell you the sequence of operations you need to perform
 PE> to reproduce the problem.  I'm still waiting for your keystroke-list.

See above.

 PE> Ever seen a BBS fail with a stupid error about zmodem being unavailable
 PE> because DSZ wasn't in their path and they were using GT?  I have.

So have I.  So?  Can't avoid luser stupidity (your own or someone else's).

 db>> (a)  wait for Microsoft to write a fix;  or,
 db>> (b)  provide your own work-around in your application.
 PE> Or (c) fix the dormant bug in your own code that suddenly became 
 PE> undormant.

Good show.

 PE> The petty problems are the imaginary bugs that you report.

I'm not reporting a bug, so this is entirely within your own imagination.

 db>> Don't you think incompatibilities through new versions happen
 db>> all the time?
 PE> It's normally only OS changes that cause problems with executables.

Nope - some applications are even sensitive to other applications running,
or changes in the date, resolution of the screen, colour depth and a whole
host of other environmental issues, none of which actually changes the
operating system underneath.

 PE> It was actually caused by the COMBINATION.  Neither the makefile
 PE> (designed to work with Watcom 10.0) NOR the compiler (with a
 PE> presumably-documented default packing) had a bug in them.  However, YOU
 PE> ran an untested combination of the two.

No shit, you tell me I'm wrong then proceed to restate my story from an
alternative perspective!  Paul, the compiler was fine, the Makefile was
wrong for assuming that a particular default packing would be used,
*independent* of version (ie., the same problem could be caused with 10.0).

 PE> THEY changed their compiler.

Not in relation to this they didn't.

 db>> That's what portability is all about - getting the
 db>> assumptions right.
 PE>
 PE> Is that right?

Yes.

 PE> Did you get the assumptions right on the last makefile you wrote?

Yes - supported about eight compilers across five or six platforms, too.

 PE> Did you assume that they used Watcom or did you assume they used
 PE> Borland?

Gave them the option of either - I wasn't fussy, since my code was
*portable* and not *compiler-specific* (ouch).

 PE> Absolutely sure that was the right assumption?

Perfectly - even tested every possible combination, and gave the end-user a
generic "fallback" if necessary.  Didn't even need a separate
Makefile for each compiler/platform, it was all in the one Makefile and
only had a single section dedicated to chosing the compiler/options - the
rest was all portable and worked the same in each case.

 db>> I said, I've been alluding to it for a while.
 PE> Well you've been alluding very abstractly then.

No, you're just obtuse.

 PE> I am not responsible for the actions of those you call "commercial
 PE> programmers", I merely stated a fact.

An incorrect fact - the C spec is *not* all there is to portability, it's
only a *start*.

 db>> The idea is to port to a *function* or *feature*, *not* to a *platform*
 db>> or...
 PE>
 PE> The idea is to write to a STANDARD actually.

How many genuine *standards* (as opposed to de facto standards) do you know
are tied to a platform, as opposed to a *function* or *feature*?  Take a
look at the C spec sometime and see how many *platforms* it guarantees to
support.  NONE.  It talks about the generic *features* of any/all
platforms, Paul.  That's portability, not *caring* what platform you're on.

 PE> Write to the STANDARD and you'll cover them ALL, not just "more".

Nope - the C spec doesn't cover all features, therefore it can only be a
*start* and not an *end*.  If you wrote to *multiple* standards (for
example, the C spec for the language and standard library, POSIX for
additional library and environmental features, etc.) then you'd be getting
closer to the mark, which is as I said, more than just the C spec.

 db>>> but there is a lot more to writing portable apps than just that.
 PE>> Actually, there isn't.
 db>> You'll learn.
 PE> You might too.

I *know*, Paul.  Working with so many bloody UNIX variants, you quickly
learn just what the word "standard" really means.

 db>> You've committed to migrating to Linux, so in time, you'll learn.
 PE> I ported Tobruk to Linux about a year or two ago.  And like I said above,
 PE> if you write to the standard, it simply works.

Congratulations, you've made your first step - but your journey has quite
some time to go.

 PE> Read above, I said a conforming compiler, not a buggy compiler.

Are you now denying that you have ever said that either Borland C++ and/or
GCC were truly ISO C conforming compilers?  Never mind, we'll use whatever
compiler you want.

 PE> And if you have a bug in the compiler, no matter HOW you write your
 PE> code, there is no way you can predict the bug in advance.

Name one compiler that is 100% guaranteed bugfree in every possible
environment, Paul.

 PE> I have about 5 OS/2 compilers, and if your strictly conforming program
 PE> doesn't compile on one of them, I'll admit defeat.

Whatever.

 db>> Yup.  And Msged isn't that much better - both of them are just hack
 db>> after hack after hack in order to work on different platforms.
 PE> You're getting confused again:

Nope.

 PE> Don't quote other people's crap back at me, I don't defend the
 PE> indefensible.

Hey, you're the one defending MsgAPI38 and Msged, not me.

 db>> I'm not blaming you for anything, I'm just in total disagreement with
 db>> your design decisions regarding Msged.
 PE>
 PE> I didn't design MSGED.

Initially, no - but you've been behind every design decision wherein you
have made changes to Msged.

 PE> I don't even particularly understand the design.  All this
 PE> collect_events stuff etc etc.

It's an attempt to fake an event-driven user interface in an allegedly
non-event-driven environment.

 PE> Actually, you never did confirm that, you just complained about it. I

Yes I did (to both).

 PE> took a guess that you were too embarassed to admit that you had stuffed
 PE> up, that it wasn't the code breaking between 10.0 and 10.5, it was the

I hadn't "stuffed up", but I was "caught out" by the
poor assumptions made in the Makefile, yes.

 PE> bloody compiler changing, and that I had hit the nail on the head with
 PE> the packing default.

The compiler changing made no difference.  Yes, you hit the nail on the
head with the packing default, but that was an environment variable not the
compiler controlling it.  Try it under 10.0, the same thing happens.  It's
a poor assumption in the Makefile (ie., it should specify the required
packing explicitly - simple fix).

 PE>> Oh, and the OS/2 Fixpack too.
 db>> Any particular one?  FP17 runs fine here.
 PE> That was more so that you could get a list of REAL bugs, and then
 PE> complain that OS/2 3.0 has a whole lot of bugs in it, which it does.

It most certainly does!  And changing DLLs can so easily fix 'em without
requiring relinks of everything.  Shit, now we're back to that again...

 PE> No, but you might use SQDEV200.  The DOS version used to, the OS/2
 PE> version didn't.  The bug only occurred in the DOS version.

I don't use DOS, don't code for DOS, don't care.  Thanks for the thought,
though.  I agree, SQDEV200 and SJD's MsgAPI stuff is as crappy as they
come, but that doesn't excuse poor decisions elsewhere.

    - dave
    d.begley{at}ieee.org

---