PE> I have no control over what Watcom does with their compiler.  It
PE> sounds like they've made it default to packing structures on a
PE> doubleword instead of a byte.

db> So fix BTPE to force the structure alignment you want/need and stop 
db> complaining.

You're the one complaining, David, in case you haven't noticed.
BTPE works fine.  If you wish to make it a product that does
not rely on structure alignment, feel free to make the mods
yourself.  I am happy to provide a makefile that works with
Watcom C++ 10.0, which is all I have.  If you wish to create a
makefile that works for your compiler AS WELL, then fine, and
I'll even help you make it.

PE> Have a look at the comments to see who wrote it - hint, not me.

db> Disavow blame all you like - you've already claimed that BTPE is *your* 
db> package/product, so *fix* it and stop blaming other people.

It's not broken.  It doesn't work under Watcom C++ 10.5, but then
I never claimed it did.  It doesn't work under the Sun C compiler
either.  However, it works on more 32-bit compilers than Binkley
2.50 ever did.

PE> Now go and take a look at the version 7 nodelist processing in MSGED/SQ.
PE> *I* wrote that, and it DOESN'T rely on structure padding.

db> So what are you waiting for?  Replace the V7 code in BTPE with the V7 code 
db> in Msgedsq.  You didn't *really* need me to tell you that, surely...

That would only solve the first problem.  I am not particularly
interested in enhancement for BTPE, as the code is GNU virus
licensed.  I do the minimum I need basically.  I can't be bothered
wasting time getting the V7 code replaced when I can simply
recompile with structures packed as the default, on the 4 compilers
I tested it on.

PE> You will notice that I documented a lot of Watcom bugs too.  How's that
PE> straw that you're clutching at looking now?

db> You've documented *zero* 10.5-specific bugs.  Your straw.  Fix your bug and 
db> stop complaining.

You were saying that BTPE is stuffed because it didn't recompile
under a later version of Watcom without problem, as if I had
provided a written guarantee that BTPE would compile under any
future version of Watcom C++ that Watcom chose to release.  Since
Watcom have plenty of bugs that I discovered first hand, I'm
hardly likely to make that claim, which is why you were unable
to substantiate that claim.  In this case, it sounds like Watcom
have changed the default of a parameter between releases, which
is what tripped up the code.  Good job I never claimed it worked
under Watcom 10.5 then, eh?

PE> I don't have that problem, David.  I know BTPE isn't stuffed, I
PE> use it daily.

db> Bill has used numerous models of USR modems and revisions of USR EPROMs and 
db> hasn't encountered your USR modem bug.  Your point?  Your face, egg and 
db> straw.

A bug in the USR that he hasn't discovered, is the same as a bug
in BTPE 3.05 that I hadn't discovered, but which Roy McNeill did.
He did find a bug, which I went and fixed.  Surely even you can
see the difference between Roy's bug in BTPE and your attempt to
compile it on a different (untested) platform?  If you still
can't see the difference, I don't think I have the necessary
skills to explain it to you.

db>> pretty protective of BTPE having no bugs.
PE>
PE> Let's see you back up that lie with a quote.

db> "I know BTPE isn't stuffed, I use it daily."  I've said
BTPE has at least 

When you said "stuffed" you said it in the context that it didn't
work at all.  And I know that it does work.  You didn't even have
the decency to use the supplied executable before making that
statement, you decided to try it out on an untested platform,
before declaring that it was stuffed.  When I say that BTPE isn't
stuffed, I do not mean that there are no bugs (you haven't found
any though, although Roy did), nor did I mean that it will port to
any platform you choose to name.  If that is beyond your 
comprehension, then I'm afraid I won't be able to explain it.

db> one bug, in relation to starting up without a "bossnode"
entry or somesuch;  

Nope, that's YOUR stuffup, by attempting to port it to an untested
environment.  Have a look at how many syntax errors come up when
you try to compile it on C/370 for MVS.

db> I've also said that because of that one bug, I deem BTPE to be stuffed.  

Then you're a fool, and would thus render every single program ever
written to be stuffed, because it either:

1. Doesn't compile using the Turbo Pascal compiler for DOS

or

2. Doesn't compile using C/370 for MVS.

db> Your quoted reply is that BTPE is not stuffed, and therefore has no such 
db> bug. 

"BTPE is not stuffed" is true.  "has no bug" is not
true.  "you
have not found any bug" is true.  "you have found a platform
that BTPE does not run under" is true.

db> Not *any* bug, but not *that* bug.  

?

db> If you've now flipped your story 
db> and claim that BTPE *does* have this bug, then you agree (either explicitly 
db> or in principle, it matters not which) that BTPE is stuffed.

No more than it is stuffed because it doesn't compile under Turbo
Pascal, David.

PE> If they have changed the default, then the makefile will need to be
PE> modified to force no structure padding.

db> It should be possible to change it *anyway*, since it won't affect the 
db> defaults on 10.0.

Hopefully, yes.  I am keen to see BTPE compile on as many 32-bit
OS/2 compilers as possible.  

PE>> It's a different sort of product then...
db>> It's still BinkleyTerm.  Period.  Keep wiping that egg off your face.
PE> Not period by any stretch of the imagination.

db> Absolutely;  not your product, not your definition.  Keep wiping that egg 
db> off your face.

Not sure what you're on about there.

PE> Do you really think that if BT 2.60 was released without source code
PE> that everyone would chuck out their 2.50 version of Binkley?

db> Your turn to provide proof of me saying or thinking that;  no, I *know* 

You said that there was just the one development trunk.  If 
they were to release a BT 2.60 without source code, then there
would no longer be one development trunk.

db> that not everyone would ditch their old versions of Bink (heck, some sites 
db> still carry 2.40 files).  The fact is, however, *many* people would upgrade 
db> from 2.59 to 2.60, source or no source.

Sure, some will go down that path, and some will go on the other
path.

PE> It was important enough for you to mention it, as a reason for
PE> not going to a source code version.

db> I mentioned it as *a* feature, since it was the first thing that came to 
db> mind.  You still haven't *proved* that I've ever considered it to be an 
db> "all-important" feature.

If you're silly enough to mention a whole lot of features that
you never use as the main reason to go a particular route, then
yes, you fooled me well and truly.

PE> ...are what's more important than source code.
PE> Since you have said yourself that you don't use any of those things...

db> I've said I don't use them often - the features are enabled, as I *have* 
db> said, for whenever the moment so arises that I may need any one of them (or 
db> any other feature, for that matter).  As I said before, it's like the 
db> multitude of modulation standards that modern modems support - you 
db> generally only use one or two of 'em, but the rest of them are there
"just 
db> in case".

Yes, and if you had one modem that supported 300 - 14400 bps,
and another which supported 1200-28800, you have to make a
judgement whether 300 or 28800 is more important to you.  In
your case, you opted for EMSI et al in preference to source
code.  Since you admitted yourself that the EMSI et al don't
provide you with anything you actually use, then the source code
is even less important than that (ie an EMSI which you don't use
is 28800, and source code is 300), which means BT 2.59 and
BTEE 2.50 are just the thing for you.  No need to complain about
Vince not releasing source code.  Who needs source code when you
can boast that you can use EMSI whenever you feel like it. 
Totally cool, man.

PE> then if source code is less important than that, then you wouldn't use
PE> source code either?

db> Source is used to build a binary - once per change (or set thereof);  each 
db> binary is used multiple times;  ergo, the binary is more important 
db> (regardless what the feature list happens to be).  I've said all along, 
db> Paul, that regardless of features, the usage of the product (any product) 
db> is more important to me than having source code (which is a nice side 
db> benefit).

Not a "nice side benefit", but a "trivial side issue of very little
importance to me, compared to features which I don't use".  In 
which case, fine, BT 2.59 is just the thing you're looking for.

PE> Well then there's nothing more to discuss really, is there?

db> Fine.

Yep, BT 2.59 without source code is perfectly fine, no need to get
all obsessive asking for source code to be released.  BFN.  Paul.
@EOT:

---