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.

db> And you care not for anyone else?  

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

db> So much for all your rhetoric about 
db> "support" for end-users of your "product".

You've been timing my turnaround time to reported bugs have you? I'd like
to see that, and then I'd like to see who you're comparing me to.

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

db> You're talking about something you have never actually experienced.  In 

I do experience that.  Whenever I get a version of software that uses the
EMX DLLs which are more recent than mine, it comes up with that warning
message.  Most recently when I was using DOS with the DPMI extender. 
That's what I like about PMW, clean, static link.

Oh, and at one stage MSGAPI.DLL was printing out stupid debug messages in
all my applications.  No thanks.

db> actual fact, you have no problem at all, you're just inventing problems.

Wrong again.

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

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

It became a whole lot less clean.  Instead of having decent, tested,
work-anywhere executables, I now rely on the user having a version of the
DLLs in their path that actually work in combination with my program. 
Although I hate that, I wanted the benefit of supporting DOS.

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...

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

Neither is MSGAPI at the moment, but you said something about it. Both are
irrelevant.

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

db> On your part, that's either extreme sarcasm or extreme ignorance about 
db> dynamic linking.  

Or you're wrong.

db> Actually, under a decent DOS extender you can support 
db> DLLs, too.  Not that it matters much to you...

Sure doesn't.  I'm far more worried about real bugs than imaginary ones. 
Not sure why.

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.

No it isn't.  That's the way you get the user to run untested combinations.
 e.g. Watcom C++ 10.5 with MAKEFILE.WAT.  

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

db> What do you think happens at run time?!

The user tests an untested combination.

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

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

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

PE> You're just inventing theoretical problems.

db> Nope.

Yep.

PE> Most people only report bugs.

db> Most people are morons.

People who only report real bugs, instead of reporting theoretical bugs,
are morons.  Ok, I understand now.

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, 

No, it requires a working library.  I have one of them, I know it works, I
tested it out, I use it live.  I can therefore ship it knowing that it at
least works to some degree.  Plug in a DLL I've never used before, and I
wouldn't have a clue what happens.

db> then your application is broken. 

Tell me the sequence of keystrokes you used for the bug to occur, and I'll
see if I can fix it for you.

db>  *That's* the sort 
db> of programming mentality that is driving the popularity of products like 
db> Visual Basic and Delphi through the roof - no more stuffing around.

Whatever.

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.

db> 'cept that the "problems" aren't theoretical.  

Tell me the sequence of keystrokes, and I might believe you.  You will be
the first person to report that problem if it is the case, which is not to
say that the bug doesn't exist, just that it's rare.  In either case, tell
me the sequence of keystrokes, and I'll try to reproduce it here.  I have
been using MSGED for quite some time, and haven't noticed whatever bug it
is you're pretending to report.

db> Do you plan on recompiling 
db> everything in Linux to be static-linked, Paul?  

No, why should I care how my operating system is implemented?  Same as
OS/2.  I only care about applications that I write, that I know what state
it is in.  It's someone else's job to make sure the OS is correctly
installed.  It's my job to make sure the application works, and yes, I do
run into problems because I can't test on every version of the operating
system (including future ones).  I can sure as hell make sure the Squish
messagebase access routines work though.

db> You're going to be 
db> disgusted when you find out just how much of the system really *is* 
db> dynamic-linked.

No I won't, I don't care.

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.

db> I'm not reporting a "bug", 

Then what's the problem?

db> that's your allocation - I'm reporting a 
db> design/engineering fault in your product, 

Design faults cause real-world problems.  Please let me know your REAL
problem with MSGED, and I'll address that, whether that be a bug in
quick.c, template.c, msged.c, config.c, msgapi38.zip, etc.

db> that (like the "unusual" way in 
db> which the USRs worked, according to your own experiences) 

Failure to auto-baud-detect is a REAL bug/design fault, it causes REAL
problems.  I can tell you the sequence of operations you need to perform to
reproduce the problem.  I'm still waiting for your keystroke-list.

db> basically leads to it being labelled, "broken".

"broken", as in doesn't perform which operation it is documented
to perform?

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

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

Yes, or I could just supply the source code and tell them to install that
for themselves.  It so happens I like to provide something that has very
little chance of the installer getting it wrong.  Ever seen a BBS fail with
a stupid error about zmodem being unavailable because DSZ wasn't in their
path and they were using GT?  I have.  The messier you make it, the more
unreliable it becomes.  Telix's host mode didn't suffer that problem -
Zmodem was built-in.  If telix started, you were GUARANTEED to have a
zmodem available.

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

db> So you blame the new MS-DOS and either:

Not necessarily.  It could well be a bug in my application, but it's been
dormant all this time, for example (real life):

When I wrote Tobruk (I think), I used one of Scott Dudley's sample programs
to see how to access squish messagebases.  His sample programs did NOT call
MsgapiInit() or whatever it's called.  This is a BUG in his program.  I
copied that BUG into my own program, but I didn't know about it. 
MsgapiInit() in that old version did nothing useful, so there was no
problem.  HOWEVER, Scott is *completely* within his rights to make
MsgapiInit() do something like allocate memory, which all the other
functions are dependent on.  It's my problem, it's my bug.  But I TESTED my
program on the static-linked library, and REGARDLESS of the dormant bug, I
know my executable works.  One day, when I get a new static-linked library
to link against, I will suddenly find my executable doesn't work.  Then I
will track down the bug, and then I will fix it.  THEN I will release a new
executable, which I know works, because I tested it myself.

BTW, I had exactly the same problem with TCXL, except in that case, they
changed the Init() routine so that it was REQUIRED.  Once again, the
problem was found and fixed by the developer, not the user.

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

Or (c) fix the dormant bug in your own code that suddenly became undormant.

db> In either case, the benefits of "reusable objects" (which
is what DLLs 
db> really are) are too great to be discarded merely because of petty problems 
db> like this.  

The petty problems are the imaginary bugs that you report.

db> Don't you think incompatibilities through new versions happen 
db> all the time?  

It's normally only OS changes that cause problems with executables.
Normally the application developers are smart enough to keep the product
under their own control, and not rely on anything other than the OS to
continue operating as per specs.

PE> People get over it, it's not an insurmountable problem...

DEVELOPERs get over static-linked libraries, USERs get over dynamic linked libraries.

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

db> Reality check, Paul - the problem was *not* caused by the change in 
db> version, but by the defaults I was using for compiling having changed;  the 

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

db> Makefile made assumptions about "the defaults", and in
this case those 
db> assumptions were wrong.  

It wasn't an assumption, it was exactly what Watcom 10.0 did.  THEY changed
their compiler.  Same as if they had changed it so that by default it
always generated Windows/NT code.  Same as if you replace Watcom with
Borland, and find that all the compile options have changed too.  It's an
UNTESTED combination.  The only TESTED combination is the one I used to
create the executable.  

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

Is that right?  Did you get the assumptions right on the last makefile you
wrote?  Did you assume that they used Watcom or did you assume they used
Borland?  Absolutely sure that was the right assumption?

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.

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

Well you've been alluding very abstractly then.

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.

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

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

db> The idea is to port to a *function* or *feature*, *not* to a *platform* or 

The idea is to write to a STANDARD actually.

db> *compiler*;  do the former, and you'll cover more platforms/compilers in 
db> one hit than the latter (plus it makes further porting much easier).

Write to the STANDARD and you'll cover them ALL, not just "more".
All compilers that genuinely conform to the C language standard of course,
as opposed to the Pascal language, or the TP7PL5 "language".

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

db> You'll learn.  

You might too.

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

I ported Tobruk to Linux about a year or two ago.  And like I said above,
if you write to the standard, it simply works.

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

db> Sure, okay.  A couple of years ago I had to write a C pre-processor as an 
db> assignment, and in doing so I followed the C spec to the letter, creating 
db> source specifically designed to break the pre-processor.  At the time, I 
db> managed to show that neither Borland C++ nor GCC were strictly conforming 
db> to the spec, 

Read above, I said a conforming compiler, not a buggy compiler. And if you
have a bug in the compiler, no matter HOW you write your code, there is no
way you can predict the bug in advance.

db> so I'll dig that out and see if any of our modern compilers 
db> still have those problems or not.

I have about 5 OS/2 compilers, and if your strictly conforming program
doesn't compile on one of them, I'll admit defeat.  In reality, so long as
you write strictly conforming programs, you will be able to get your
program to compile and run on OS/2. Even if you have to change compilers
because one of them is buggy.

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

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

You're getting confused again:

1. My name is not Vince Periello.
2. My name is not Jim Nutt.
3. My name is not John Dennis.
4. I didn't write MSGED.
5. I didn't write Binkley.
6. I hacked MSGED rather than write it properly from scratch.
7. I hacked Binkley rather than write it properly from scratch.
8. I wrote Tobruk properly from scratch.

PE> Tobruk is an example of portable code.

db> Much better.

The only one I actually authored.  Don't quote other people's crap back at
me, I don't defend the indefensible.

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

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

I didn't design MSGED.  I don't even particularly understand the design. 
All this collect_events stuff etc etc.

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.

db> Good - now go and do it!  :-)

Actually, you never did confirm that, you just complained about it. I took
a guess that you were too embarassed to admit that you had stuffed up, that
it wasn't the code breaking between 10.0 and 10.5, it was the bloody
compiler changing, and that I had hit the nail on the head with the packing
default.

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"...

db> Which it is...

Compared to a permanent-alpha, yeah, I suppose so.

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

db> Any particular one?  FP17 runs fine here.

That was more so that you could get a list of REAL bugs, and then complain
that OS/2 3.0 has a whole lot of bugs in it, which it does.

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.

db> I don't use DOS.

No, but you might use SQDEV200.  The DOS version used to, the OS/2 version
didn't.  The bug only occurred in the DOS version. Now the bug doesn't
occur in either version.  I learnt my lesson about attempting to upgrade to
SQDEV200.  BFN.  Paul. 
@EOT:

---