On 1996-08-16 18:56, david begley of 3:711/934.4 wrote:

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

Shit David, did you need to reply so fast?  This is a long thread. Just
because I don't have a life is no reason to hassle me when I can't get to
sleep.

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.

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

YOU were the one who said you needed it to be a DLL so that you could fix
the theoretical bugs in it (which amazingly enough, all were going to fall
exactly in MSGAPI38, so you couldn't possibly wait for a new version of
MSGED, you needed to wait for a new version of SQDEV200).

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.

db> Those messages, like:

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

Yes, that's right.  I presume this means you are retracting the "never
actually experienced" above?

db> are neither "stupid" 

Yes, they are, I don't want them.  If the author couldn't get their act
together and actually provide a working executable, they have done very
poorly.

db> nor fatal 

Never said that.

db> - they are as indicated, a "warning".  Don't 
db> like 'em?  Disabled 'em.  'nuff said.

Shit, read up on the documentation for some DLL's I didn't even know about?
 This is your idea of how a commercial/professional package should be?  No
thanks.

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

True, I didn't know that.  Tell me how to fix it and I'll do that in the
next release.

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

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

You don't.

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

db> Nope.

Yep.

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.

db> Yes it is.

No it isn't.

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

db> Nope.

Yep.

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.

db> Wrong, 

You're the one who's wrong.  Msged requires a working library.

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

I didn't say that at all.  I said it needed to work.  I know MSGAPI38
creates a MSGED that works in the test environment I gave it.

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.

db> Why bother, you're so hell-bent against the philosophy of reusable objects, 

News to me.  I already use MSGAPI38 in both Tobruk and MSGED.  THAT is a
reusable object.

db> now I can see why you've stuck with C and haven't migrated to C++.

I have done that mainly because of a lack of support for new languages like
C++ on the environments I go to.  Crikey, C has been well-defined since
1989, and I STILL don't have a 100% ISO-conforming compiler on every
platform I program on.  It will be at least a decade before I can even
THINK about C++.

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

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

I have done that here, and it comes up with a green screen giving a few
details and asking you to press enter.  What does it do on your system?

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

db> Which of course means that it's my system at fault, since I'm the only one 
db> reporting the "fault".  

You obviously deleted the bit which said I would fix it anyway. And I
didn't say your system was at fault, although it is abnormal for you to be
the only one experiencing it.  Like I say, tell me exactly what the bug is,
and I'll try to fix it.  So far you've said that you type
"msged", but you didn't tell me what went wrong when you did
that.

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?

db> You said so yourself - untested combinations of libraries and executables;  

But they did test it - before they shipped the operating system.

db> everything you compile by default is going to be dynamically linked to 
db> whatever libraries are on your system today, not necessarily what will be 
db> there tomorrow, nor what will be on other people's systems.

Unless the C library is part of the defined interface of the operating
system, yes, I am silly to be relying on the C library being there at all. 
You can't ship professional applications like that.

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.

db> Sure.  ;-)

I don't care already.

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.

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

I will fix a problem with msgapi38, but so far there have been no reported bugs.

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

db> For you alone, not anyone else.  

That's not true.

db> Should that be all the required reason to 
db> dismiss this problem?  

No.  Like I have said MANY times already, tell me what the bug is, and I'll
try to fix it.  You have to be a lot more specific than "type 'msged'
and press enter".

db> Does the way in which it is implemented, despite the 
db> fact that it works one way and not another way, constitute a
"bug" or a 
db> "design fault"?  

Pardon?

db> Whatever your answer is, that's what's wrong with Msged 
db> being so tightly married to MsgApi38.

It is?  You're the one making the claim.  I can tell you that I did not
intentionally change the API.  I can also tell you that I went out of my
way, and when SQDEV200 broke the API, I broke the MSGAPI38 interface to
make it possible for *developers* to use SQDEV200 themselves, should they
wish to try out that UNTESTED COMBINATION and then FIX ANY BUGS THEMSELVES
and then SEND THE FIXES BACK TO ME. As far as any end-users of MSGED are
concerned, if they haven't got a bug, they haven't got a problem, that I'm
interested in, anyway.

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

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

You were incredibly concerned with these massive problems you were having
with MSGED, that were all due to MSGAPI (not msged.c, template.c, etc etc,
amazingly enough).

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.

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

True.

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.

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

Oh shit, you had WCL386 environment variable doing it.  Why didn't you tell
me that anyway?  Maybe I should use the option to disable the use of that
environment variable.  Would you also like me to not assume that the OS/2
version of the makefile is actually going to be producing an OS/2
executable (after all, someone might have set WCL386=-bt=msdos in there -
did you protect against that possibility in your last makefile?).

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

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

And you're quite sure that they're going to be using one of those 8
compilers, and one of those six platforms?  They're definitely not planning
on using Pacific C and then complaining because it's not called
makefile.prj, and then complaining because it doesn't work even when they
renamed it themselves?  Yeah, right.

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

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

PE> Absolutely sure that was the right assumption?

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

You mean part of it was broken from the start?  The user has to fix your
makefile before they even use it?  At least my MAKEFILE.WAT works on SOME
people's computer.  AND if you're expecting the user to fix the makefile
before using it, MAKEFILE.WAT even works on yours.  It's up to you to
tailor the options to make sure your environment variable doesn't alter
defaults.

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

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

Nope, it's a correct fact.  I'm still waiting for your strictly conforming
code that won't run on any of my OS/2 compilers, all of which are
conforming compilers, except for bugs (bugs which are highly unlikely to be
present in every single one of my compilers).

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.

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

That's what I said, David.

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

db> Nope - the C spec doesn't cover all features, therefore it can only be a 

It covers all portable features.  Any features missing from the standard
are not portable BY DEFINITION.  UNLESS they can be built PURELY from
capabilities in the standard.

db> *start* and not an *end*.  If you wrote to *multiple* standards (for 
db> example, the C spec for the language and standard library, POSIX for 
db> additional library and environmental features, etc.) then you'd be getting 
db> closer to the mark, which is as I said, more than just the C spec.

If you want to write portable C programs, you have to write to the C spec. 
If you want to write C programs that are portable to any site that has
Posix (ie not portable after all), then you need to conform to both C and
Posix.

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.

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

So my work on MSDOS, OS/2, Linux, SunOS, VMS, VM, MVS, Amigados doesn't
count?  I'll try to remember that for next time.

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.

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

It would come within an ace of working on MVS too.  How many of your
applications would?

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

db> Are you now denying that you have ever said that either Borland C++ and/or 
db> GCC were truly ISO C conforming compilers?  

I'm not sure what you think I have said.  I will say what I think, which is
all that I know.  Bugs aside, and to the best of my knowledge, both BC++
and GCC are 100% ISO-conforming compilers.  In fact, the third 100%
conforming compiler I knew of was Turbo C++ 1.0 for DOS.

db> Never mind, we'll use whatever compiler you want.

I actually use 4 of them, in case of bugs.  I have more than 4 available to
me though, depending on the exact situation.

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.

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

I give up, which one?

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.

db> Whatever.

Show me the code.

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:

db> Nope.

Yep.

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

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

You've got the story mangled again:

1. Msged is pretty shitty, and certainly not within a mile of my definition
of portable.

2. Msgapi38 is one of the biggest heaps of shit I've ever had the
misfortune to have to read.  How anyone can make a program that is designed
to read and write files, so compiler-specific, I shudder to imagine.

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.

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

And without the benefit of the time to write the thing from scratch, I did
what I needed to do to make the changes I wanted.  Even when that meant
replacing binary searches with sequential searches, so that I could rip out
code containing a copyright notice.  Bill Bond actually noticed that BTW,
much to my surprise, and it returned to a binary search, but this time
public domain.

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

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

I'm not very good with UI.  Actually, I really need a document that
explains why they needed to change what we have been doing for the previous
30 years.  It seems to me that people just decided one day that every
program needed to be rewritten in the new style, without giving a
justification as to why it HAD to be that way, why there was no better
alternative (e.g. one that didn't require a complete rewrite of all
applications).

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.

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

When the OS is bust, you fix the OS.  When the application is bust, you fix
the application.  Bloody amazing.

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.

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

The thought is not in case you were using DOS, but in case you were
thinking of using SQDEV200.  It is highly likely that the only reason the
bug was found in DOS, and not OS/2, was because only the former was using
SQDEV200.  It's not a major problem though, you can probably live with a
link against SQDEV200.  BFN.  Paul. 
@EOT:

---