db>> Since a simple recompile WITH DEFAULTS can break it, then the source is
db>> of no value and "BTPE" is stuffed.
PE>
PE> I tested it against Watcom C++ 10.0.  Did you compile with that?
PE> NO.

db> Since your source code is so compiler version-specific as to break from one 

I don't actually know how compiler version-specific it is.  I
do know that it compiles on 4 different compilers that I tested
it on, which is a pretty bloody good start.

db> version to the next (not even a major upgrade, either), then your claims of 

I have no control over what Watcom does with their compiler.  It
sounds like they've made it default to packing structures on a
doubleword instead of a byte.  I thought I said this in my last
message?  Did you check that?

db> portability are hollow and BTPE is stuffed.  

If you think compiling on 4 OS/2 compilers and 2 DOS compilers
means that "my claim" of portability is stuffed, then I'd like
to see your version.  I don't recall making this claim though,
since to me portability means it compiles and runs on MVS as
well.  In this case, relying on the structure padding, is
something unportable which I hate.  You can take a look at the
code in question, the version7 nodelist processing.  Have a look
at the comments to see who wrote it - hint, not me.  Now go and
take a look at the version 7 nodelist processing in MSGED/SQ.
*I* wrote that, and it DOESN'T rely on structure padding.  THAT
one is portable, and I'll bet that it works under your version
of Watcom.

db> Still.  What are you doing, 
db> coding to rely on 10.0 bugs?  Paul, Paul, Paul...

Not sure what you're talking about there.

db>> I've now encountered a "bug" (by design or accident) in the BTPE
db>> package, and ergo (just as the USR is shit) BTPE is stuffed.  Deal
db>> with it.
PE>
PE> That's like saying there's a bug in the Netcomm modem because it
PE> doesn't report stats on ATI6.

db> Wrong again - part of the BTPE package's claim-to-fame is its 
db> cross-platform portability, and the usefulness of the included software;  

Cross-platform portability?  Where is this claim to fame?  I
didn't even know about it, and I authored the thing.  I can
tell you right now it doesn't even fall within cooee of what
I consider to be portable.  Not a mile.  However, it's certainly
better than Binkley 2.50.

db> ATI6 is undocumented on the NetComm, so there's no claim that it does 
db> *anything* or has *any* usefulness.  Ergo, no bug.

Yeah, now pull out this mysterious claim for BTPE.  Ergo, no bug.

PE> Or saying there's a bug in BTPE because it won't compile for Unix.

db> Do you claim that BTPE will compile under UNIX?  

Do I claim that BTPE will compile under Watcom 10.5?

db> If so, then BTPE is 
db> stuffed if it won't compile under UNIX.  

And if neither claim is made, then it isn't stuffed (you were the
one claiming it was stuffed BTW, before you even tried the EXE
supplied and tested by me).

db> If you make no such claim, then 
db> it's not stuffed.  

Yay, the man has a brain.

db> A jump from 10.0 to 10.5 in the same compiler within the 
db> same environment is hardly like jumping from one operating system to the 
db> next.

It's certainly jumping from a tested environment to an untested
environment.  EMX 0.9a had a bug in it that stopped Binkley
working properly on it.  EMXFIX03 (from memory) fixed that problem.
So your point was?  Oh, and Turbo C++ 1.0 has a bug in it that
stops me compiling MSGED/SQ on it cleanly (see the #define for
TURBOFIX to see a workaround).  Oh, and Borland C++ 3.1 had a bug
that stopped MSGED/SQ working properly too.  I worked around
that by writing the code in a different manner.  I probably didn't
document that bug either.  You will notice that I documented a
lot of Watcom bugs too.  How's that straw that you're clutching at
looking now?

PE> Nope, you didn't follow the doco, which said it has been tested
PE> under Watcom 10.0, not 10.5.  Nice try at wiping the egg from
PE> your face though.

db> Your egg on your face?  Dear me, Paul, after all the complaints about USR 

I don't have that problem, David.  I know BTPE isn't stuffed, I
use it daily.  It may well have bugs present, after all, I wrote
very little of the code, but I don't recall every saying that
BTPE was bug-free.  And I'd like to see you find a quote where I
did.

db> having a bug despite what the documentation did or did not say, you're now 

The USR does have a bug/design fault (I do not know for sure which).

db> pretty protective of BTPE having no bugs.  

Let's see you back up that lie with a quote.

db> Fix it now, saving yourself from 
db> having to fix it later when you upgrade.

I am more than happy to fix it.  Since I don't have Watcom 10.5
available, I will need you to help on that.  For starters, find
out what the default on structure padding is.  If they have
changed the default, then the makefile will need to be modified
to force no structure padding.  If they have vastly changed the
options, it may require another makefile.  Hopefully the one
makefile will suffice.

db>> No I won't, because there is only one Windows NT development tree,
db>> period.  Or are you planning on releasing Windows PE soon?
PE>
PE> 2.59 is a beta of Binkley.

db> In name only - you've said yourself that the mark of a release vs beta 
db> version of BinkleyTerm is whether or not source code is released.

Yes, that is the way of telling in BinkleyTerm in the past.
That plus the fact that they don't use the word "beta".

PE> Same situation.

db> In that case, where's the source code for WinNT to prove that it has been 
db> *released*, hmm?  Where's the PD project for WinPE running on the Amiga?

PE> Windows NT is not a product that comes with source.

db> Since you don't own BinkleyTerm, there is no guarantee that every version 
db> should ever come with source, anyway.

Sure, they could well decide that starting with 2.60, releases
of Binkley do not come with source.  In which case, like Maximus
and GMD, you basically have two very different products, and 
people are likely to keep the latest version of both products.
I keep both versions of GMD for that reason.

PE> It comes with manuals though, and a box, something that I bet the betas
PE> didn't come with.

db> So the secret to release vs beta in WinNT's case is the size of the box and 
db> manuals that are included?  This gets dumber and dumber.

That plus the fact that it doesn't have "beta" written on it.
It's a bit of a giveaway that "beta", eh?

PE> It's a different sort of product then...

db> It's still BinkleyTerm.  Period.  Keep wiping that egg off your face.

Not period by any stretch of the imagination.  Do you really  
think that if BT 2.60 was released without source code that
everyone would chuck out their 2.50 version of Binkley?  No
way!  You can look around my board and others to find out what
happens when you pull a stunt like that.  oMMM is another
example that comes to mind.  MSGED is yet another.

PE>> It was YOU that was claiming it to be an all-important feature.
db>> Prove it.
PE>
PE> I have crossposted the message.

db> I've seen it, and it *still* doesn't *prove* that I have ever claimed that 
db> it's an "all-important" feature.  Try again Paul, and keep
that egg coming 
db> off your face.

It was important enough for you to mention it, as a reason for
not going to a source code version.  If that doesn't signify
importance, then I'm the pope.

PE> I notice you didn't say "Does BT 2.59 come with source code", which
PE> means that EMSI, which you don't even use, is more important to you than
PE> source code...

db> Wrong again - we were discussing EMSI and no other feature, so that's why 
db> it appears so prominently;  doesn't mean that EMSI and EMSI alone is more 
db> important to me than source code.

Of course not.  EMSI, fax and Hydra combined are what's more
important than source code.  Since you have said yourself that
you don't use any of those things, then if source code is less
important than that, then you wouldn't use source code either?

PE> ...so I don't know what you're complaining about.

db> You not having a clue.

Well then there's nothing more to discuss really, is there?
Because if you think I don't have a clue, then all that shows
up is your own foolishness.  And if you're not complaining
about BTEE and BT 2.59 not having source code, then you're a
really happy person, so there's no problem there either.

PE> It was a reason against going with a source-code version.

db> Just a single reason?  Not *the* reason?  Dear me, Paul, keep trying.

EMSI, Hydra and fax were the reason given.  So?

PE> And since you consider EMSI, Hydra, fax, none of which you use...

db> Prove it.  Prove I don't use them.  You've made an authoritative statement 
db> more than once, that I don't use *any* of these features.  Prove your 
db> claim.

You said yourself on the fax and the EMSI.  Ok, I don't actually
know what Hydra is, so you'll have to tell me on that one.  How
much does Hydra save on your phone bills, or isn't Hydra something
designed to save on your phone bills?  In which case, what does
it do?

PE> ...to be more important than source code, which you said in THIS
PE> thread that you wanted, one would have to conclude that EMSI
PE> is incredibly important to you.

db> EMSI, and EMSI alone?  Geez Paul, get serious.  What I've said is that all 

EMSI, Hydra and fax.  Do I have to write all 3 all the time?

db> these things are far more important to me than *your* source code (remember 

Ok, so you are restating it here.

db> me saying that these are *your* enhancements, not changes to the main 
db> development tree?), not source code, period.

BTW, what enhancements do you think I made?  All I did was make
it compile on my 32-bit compilers, and then proceed to fix some
bugs and add some debugging info.  Aside from that, the only
enhancements that come to mind are getting rid of some delays and
adding "Aftercall" and "Afterconnect" which were both requested
by my USR-mate Bill Grimsley.  There isn't a great deal of code
changes involved.  However, since you are more than happy with
a no-source code implementation of Binkley, there's no problem
to be solved, and no complaint about Binkley, so everyone's
happy, right?  BFN.  Paul.
@EOT:

---