db> The only person complaining here Paul is you - complaining about my refusal 
db> to run BTPE.

I'm not actually, I'm complaining about you complaining about
Binkley 2.60's unavailability when you have an alternative
available now.

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> "No" he didn't do it himself, or "No" he didn't
do it to spite us?  In the 
db> first case, what evidence do you have that he ripped off our efforts?  In 
db> the second case, I most certainly *do* think he's aware of MSGAPI38 and 
db> released his version to spite us.  You said yourself that MsgApi 2.x is 
db> stuffed and isn't half as good as MSGAPI38, so why on earth should he have 
db> bothered?

I'm sure he didn't do it to spite us.  He had his version available
for YEARS before releasing it.

PE> What do you mean it's stuffed?

db> I ran it up, it complained that there was no boss in the nodelist, and 
db> promptly exited.  Stuff it, I don't have time to toy with crap that claims 
db> to deliver the world yet it can't even get started.

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

PE> I'm using it, I think Bill is using 3.04 and Jeff Green and Roy McNeill
PE> are also using it.

db> That's hardly a large following from which you claim to be in control of 
db> the "main development tree"...

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

db> In case you've missed it, the world is finally waking up to (aging) 32-bit 
db> technology;  having to shackle your development efforts merely to support 
db> 16-bit DOS is a complete waste, IMHO.

Who's shackled?

db> It is *right* to write your code in a manner that is most likely to be 
db> portable to a wider range of platforms;  that's why I'm more interested in 
db> linear virtual memory 32-bit environments (even if that includes DOS), not 
db> this 16-bit segmented bullshit.

db> Why should I care if my data is near or far?  That's for the compiler and 

Do a grep on "far" and "near" in msged.  Ok, so there are 3
instances which I missed - so sue me.

db> From what I've heard, Jim has given up on Msged, just as John has.  But, to 
db> satisfy your desire for accuracy (which is not a bad thing), we now have:

I've heard as much about Jim's MSGED as Vince's Binkley.

PE> I couldn't even get him to acknowledge receipt of bug reports.

db> Your version of "Hello" is to stick a musket up someone's
nose and mumble, 
db> "That's an ISO violation - this is your first and last
warning."  No wonder 
db> he wouldn't acknowledge bug reports.

It was before I had recompiled the code.  In the early days of
writing the Devil Dialer I used a product code of 0x0202.  That
crashed Binkley.

db> BinkleyTerm is *not* your product - you do not own copyright and BT's users 

BTPE *IS* my product.  Yes, it uses code under license from 3rd
party products.  So what?

PE> Certainly more official than your BTEE which you are happy to run.

db> Less official by leaps and bounds - BTEE enhancements have been rolled back 
db> into the main development tree;  BTPE enhancements haven't.

You don't know whether either of those are true until you see
Binkley 2.60.

PE> Ok, the fax would be useful (sounds like you've never used it
PE> though).

db> Irrelevant - BTEE has it and BTPE doesn't (I actually still have the full 
db> init string from my old M7F still hanging around to enable fax receive in 
db> BTEE).

Not at all.  It's about irrelevant as the fact that BTPE supports
the "Afterconnect" keyword.

PE> BTPE and BT 2.59 also have 32-bit OS/2 native versions.  Only BTPE
PE> has source code though.

db> Correct, very correct;  as I've already said, I *want* source - but it's 
db> importance is lower than actually using the product, therefore I'm happy to 
db> run what I have even though no source is available.

So there's no problem with BT 2.59, no need to complain.

PE> I hope your life insurance policy includes protection against
PE> expiry before BT 2.60 is released.

db> Hello - wakey, wakey;  anybody home, Paul?!  To you, source may be 
db> paramount;  but to the rest of us, it's secondary to actually using the 
db> damn thing.

Fine, you're the one that started complaining.

db>> BTW, WTFITPO "-DPRIVATE_IDAHO"?!?!  You *really*
oughtta get out more
db>> often, Paul.
PE>
PE> Tell that to the people who wrote BT 2.50.

db> Nah - Vince needs to take a dose of reality, but you *really* oughtta get 
db> out more often.

PE> I didn't change that bit, since changing it added no value to me.

db> So answer the question - WTFITPO "-DPRIVATE_IDAHO"?!?!

I think if you have it defined it puts the word "alpha" in
various spots.  It should be commented out.

PE> Zero support...

db> The best products require *zero* support;  I've not once had to rely on 
db> "support" for BTEE.  During what hours is the BTPE free
support hotline 
db> open?  1-800, I assume...

No, a message in PUBLIC_DOMAIN will be fine.  Ask Roy how long 
it took him to get a fix for his reported bug.  Now ask anyone
how long it took to get the same from Microsoft.

PE> Pardon?  You have a V34 (and lower) modem until the ITU-T comes
PE> up with V34bis.  What's the problem?

db> That's *exactly* my point - the modem has *everything* in it, and there is 
db> *no* point worrying about V.34bis until it is rolled back into the "main 
db> development tree" and appears in modems with everything else built-in;  
db> just as you wouldn't bother buying a beta V.34bis-only modem, many people 
db> won't use "alternatives" until the functionality appears
in the main 
db> product (and BTEE's functionality *does* appear in the main product).

*YOU* are the one running a non-standard V34bis-equivalent.  *I*
will quite likely be upgrading to Binkley 2.60 when it comes out.
Binkley 2.60 will then be the successor to BTPE 3.05.  A lot of
code rework etc.  So what.

db>> development tree.  It also *lacks* things that are in the main 
db>> development 
PE>
PE> No it doesn't.

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 fields 
db> in BTPE.  They're just not there.

They're not in BT either, and BTEE has not been released.

PE> BT 2.50 being the only released competitor, it has all the features
PE> in it.

db> Now *you're* dreaming - it's like saying that OS/2 Warp had no competition 
db> from Win95 until it was officially released, despite the fact that people 
db> had beta copies already.  

Damn right.  Remember all those people saying Windows NT stood
for "Not There"?  It was available in beta for a year or 
something.  So Microsoft were on time after all?  And on time
for Windows 95 as well.  Fat chance.

PE> Presumably people who don't think that source code is important.

db> Of the list of people you named as running BTPE, how many of them have 
db> *ever* bothered to compile BTPE, or see theselves *ever* compiling BTPE?  
db> (Yourself excluded, of course since the answer there is obvious.)  Of the 
db> list of people I named, I'd say some are most definitely intrested in 
db> source code - but they recognise that it's not *paramount* above all else.

I don't think any of them have.  However, when we were having
some problems, I was ready to put in code changes to both lots
of code until we had it resolved.  It actually looks like it was
a Spirit/Microcom? bug dropping characters at V42bis, as the
reproducable problem went away when using V42 and when using the
USR.

PE> In fact, there's very little, if anything, that BTEE actually
PE> gives you.

db> Big deal;  you're the only one with a hang-up on EMSI.

I don't have a hang up with EMSI at all.  You're the one with the
hang up, considering EMSI to be desperately important when you
don't even use it.

PE> No, user-interface to an automatic dialler doesn't get any points.

db> Yes it does.  Ask people why they use Win95 instead of Win3.1 or OS/2, and 
db> many will say because it *looks* better.  Win95 is a competitor to Win3.1 

And Win95 is not an automatic thing.  Your mailer is (or should be).

PE> There was a reason for that - Spirit double-send problem.  I will
PE> be happy to enable that when I get my new modem.

db> You coded around the Spirit bug, did you not?  

I did, but it relies on one-directional sending to work.  ie
zmodem is fine, Janus/Sealink/Xmodem are not.  I was basically
concerned about people dialling me from OS and getting a bad
Janus.

db> You're not using a Spirit at the moment, are you?

Indeed I am not.  Which is why I said I can enable Janus when I
get my new modem.  I'm not interested in experimenting with 
Binkley whilst I still have an interim modem.

PE> In other words, it did the same effect as an Aftercall, even though
PE> it is an init string - just like I told you.  BFN.  Paul.

db> In other words, adding ATI6 did sweet FA - just like I told you.  FU2.  
db> Dave.

*YOU* were the one questioning whether putting a command in your
init string would help as an aftercall.  *I* corrected you.  I
have no idea what ATI6 does on your modem, not owning one, so
was making no comment on the viability of ATI6.  BFN.  Paul.
@EOT:

---