db>> The only person complaining here Paul is you - complaining about my
db>> refusal to run BTPE.
PE>
PE> I'm not actually, I'm complaining about you complaining about
PE> Binkley 2.60's unavailability when you have an alternative
PE> available now.

db> Paul - for the millionth time, I was not (and am not) complaining;  I was 
db> curious one day, so I decided to have a look at the latest state of 
db> affairs, and then relayed same (along with my own observations).  Got it?!

If I have time, I might go and take a look at your original
quote on that.  I bet I might even find a couple of ":-(" on
it.

db>>> No it wouldn't, because the PE/DB 1.x [32] changes were never rolled
db>>> into SD 2.x [16/32] - he did those himself, to spite us most probably.
PE>>
PE>> I don't think so, David!
db>>
db>> "No" he didn't do it himself, or "No" he
didn't do it to spite us?
PE>
PE> I'm sure he didn't do it to spite us.

db> So he ripped us off?  Wonderful (though not surprising).

No, he didn't rip us off at all.

PE> He had his version available for YEARS before releasing it.

db> Excuse me?  *Available*?  Think again.

It was available to beta testers, not the general public.  The
fact is he had written his own before us, but it was of little
use.

PE> Are you using the Version 7 nodelist, and did you recompile
PE> BTPE yourself?  If so, which compiler and options?

db> Of course, yes, Watcom C/C++ 10.5a, defaults.

Well before claiming something is stuffed, at least have the
decency to use the executable provided before stuffing around
with it.  Since it is most likely that YOU stuffed it, by
recompiling it differently.  Most likely structures aren't
being padded.  I tested it on 4 different compilers, one of
which was Watcom C++ 10.0.  Next you'll be saying you
recompiled it on Sun/C and it came up with some errors, and
then you ran the Unix exe on OS/2 and it didn't work, ie 
BTPE is stuffed.

PE> No, it's to show that it isn't stuffed.

db> It's either a bug by accident or design, but it's still a bug all the same 
db> and therefore it's stuffed.

YOU stuffed it.

db>> From what I've heard, Jim has given up on Msged, just as John has.
PE>
PE> I've heard as much about Jim's MSGED as Vince's Binkley.

db> Ergo, Jim has given up on Msged - just as I said Vince appears to have 
db> done.

Then BT is not the main development stream anymore, just like
MSGED207 (using your logic).

db>> BinkleyTerm is *not* your product - you do not own copyright and BT's
db>> users...
PE>
PE> BTPE *IS* my product.

db> Rejoin reality, Paul - "BinkleyTerm" != "BTPE".

So?  I didn't claim that BinkleyTerm (the original) was my
product.  I probably did claim that I had the main development
stream though.

db>> Less official by leaps and bounds - BTEE enhancements have been rolled
db>> back into the main development tree;  BTPE enhancements haven't.
PE>
PE> You don't know whether either of those are true until you see
PE> Binkley 2.60.

db> Oh yeah?  Check the documentation accompanying the BT 2.59a wide beta.

Sorry, just like they changed the V32bis (or something) spec
at the last minute, BT 2.60 may be changed at the last minute
too.

PE> No, a message in PUBLIC_DOMAIN will be fine.  Ask Roy how long
PE> it took him to get a fix for his reported bug.

db> Considering I haven't encountered any bugs that would otherwise stuff-up 
db> the operation of either BTEE or my modem, I've still required *zero* 
db> support, even without source.

So BTEE is perfect, no source code needed, keep using it instead
of complaining about Vince.

PE> *YOU* are the one running a non-standard V34bis-equivalent.

db> Rubbish - almost all EE enhancements are in 2.59 .. even the expanded 
db> (zoom) outbound window (which I *do* use).

They weren't when EE was released, and you still don't know 
until 2.60, which may never be released.

PE> *I* will quite likely be upgrading to Binkley 2.60 when it comes out.

db> As will I - which is why I originally decided to have a look and see if 
db> 2.60 was any closer to being released today, than it was a year ago.

PE> Binkley 2.60 will then be the successor to BTPE 3.05.  A lot of
PE> code rework etc.  So what.

db> See?  Even you acknowledge that the original BT tree is the one to watch.

Not at all.  Just ONE of the ones to watch.  When I see something
from him (or even from BTEE) that I think is better than what
I've got currently, I'll upgrade to that.  Until then, I have
the most advanced (and main) development stream right here.  It's
not hard to beat a dead product.  If 5? years isn't dead, it's
at least in deep freeze.

db>> Bullshit;  show me the ITU-T Group III fax receive in BTPE.  Show me the
db>> EMSI support in BTPE.  Show me the "enhanced" help
screens and entry
db>> fields in BTPE.  They're just not there.
PE>
PE> They're not in BT either...

db> Fax?  Yes it is.  EMSI?  Yes it is.  Hydra?  Yes it is.  Expanded outbound 

Nope, not yet.  

db> window?  Yes it is.  When (if ever) the sources are released, I'll put in 
db> whatever is missing.  Check 2.59a for yourself and you'll see.

Sorry, that is a beta, 2.60 will be the release.  Next you'll
be saying that Windows NT was released on schedule.

PE> ...and BTEE has not been released.

db> Wanking with words - it's beta in name only;  availability of source does 
db> not affect its alpha/beta/gamma/release status.

Yes it does.  Binkley has always come with source code when it
is released.  It hasn't.

db>> Big deal;  you're the only one with a hang-up on EMSI.
PE>
PE> I don't have a hang up with EMSI at all.

db> Bullshit - if you had no hang-up about it, you wouldn't keep focussing on 
db> that one feature, and falsely claiming that I deem it an all-important 
db> feature.  Quite frankly, as I've already said before, you enabling Janus 
db> would be of more use/interest to me than EMSI.

It was YOU that was claiming it to be an all-important feature.
In netmail a few months ago.

db>> In other words, adding ATI6 did sweet FA - just like I told you.  FU2.
PE>
PE> *YOU* were the one questioning whether putting a command in your
PE> init string would help as an aftercall.  *I* corrected you.

db> Bullshit.  I said that there was no point *even* putting ATI6 in the init 
db> string, aftercall support or not, because ATI6 doesn't do anything.  You're 
db> wanking with words if you think you're correcting anybody on this point.

Ah, read the previous message on that.  BFN.  Paul.
@EOT:

---