PE> Yes, it's exactly like MSGAPI38.  Do you realise that the last mod
PE> made to MSGAPI38 was done 21/10/95?  When was the last of Scott's
PE> versions?

db> So that's your measure of the "newest version", based
purely upon the date 
db> of the most recent modification, eh?  A rather primitive metric, Paul.  Who 
db> aside from *you* is still using MSGAPI38?  Certainly not me.

Everyone who uses MSGED 3.xx straight out of the box.  In fact,
if you tried to recompile it with Scott's MSGAPI you would have
trouble unless you used the Watcom compiler, as the others were
not supported when I tried it.

PE> OUR MSGAPI38 works with EMX, CSET, Watcom, Borland. Tried that with
PE> Scott's version?

db> The version we put together may well be more portable/useful than Scott's, 

Indeed it is.

db> but it was a temporary hack from the start to finish and was never rolled 

It isn't finished, and it isn't a hack.

db> back into the main development tree.  Make as many changes as you want, 

It hasn't been rolled back into Scott's development tree.  So
what?  That's his problem.  MSGAPI38 is the more useful one
IMO.

db> keep it alive for all it's worth - but that still doesn't make it "the 
db> newest", which IMHO relies on the main development tree for any product 
db> (everything else is a sideways step, not forward).

It is the newest, and it is the main development tree.

db>>     SD 1.x [16] --+---------------------> SD 2.x [16/32] --> ... ?
db>>                   |
db>>                   +--> PE/DB 1.x [32] --> * (stop)
PE>
PE> Nope, no stop.

db> Fine, no stop - but still doesn't change the fact that the two are now 
db> *separate* developments, *not* the one development tree (they're on 
db> different branches/paths, as shown above).

So, complain to Scott, not me.  I already mentioned that it didn't
compile for my compilers and got howled down and that was the end
of that.

PE> In fact, it would have gone PE/DB 1.x -> SD 2.x...

db> No it wouldn't, because the PE/DB 1.x [32] changes were never rolled into 
db> SD 2.x [16/32] - he did those himself, to spite us most probably.  As shown 

I don't think so, David!

db> above, if Scott's version wasn't "stuffed" in your eyes
then the tree I've 
db> drawn would be the most accurate as PE/DB 1.x [32] development would have 
db> stopped without being rolled into the main tree.

If it wasn't stuffed, it would have gone PE/DB 1.x -> PE/DB 2.0
which would be exactly the same as SD 2.0.  As it is, he stuffed
up.

PE> Do you know that MSGAPI38 not only works on 32-bit OS/2, but also 16-bit
PE> DOS has been made from it too (one of the enhancements I made).

db> Nope.  Don't care, either.  I was thinking last night while I had a look at 
db> your BTPE 3.05 (it's stuffed, BTW), that maintaining support for 16-bit DOS 

What do you mean it's stuffed?  I'm using it, I think Bill is
using 3.04 and Jeff Green and Roy McNeill are also using it.

db> is a lost cause and I'm not interested in it one little bit.  I'd happily 

Tell that to the DOS users of MSGED.

db> support 32-bit DOS, but not 16-bit DOS.  Those folk content with old 
db> operating system technology can be content with old versions of everything 
db> else, too.  Fuck 'em.  I'm interested in vitual memory systems with linear 
db> address spaces, and if that means I can only support UNIX, OS/2 2.x, WinNT 
db> and MacOS, then those OS/2 1.x, Win3.1 and DOS users can get bent.

The more OS's you support the more development possibilities
there are available.  I did try to convert it to 32-bit DOS
until I realised I had to rewrite all the assembler stuff.

db>>     Jim Nutt --> John Dennis --> Paul Edwards (& Co.)
--> ... ?
PE>
PE> Nope, you stuffed up there.

db> No I didn't - you obviously *don't* understand how it works.

PE> Jim Nutt -> stop?
PE> John Dennis -> Paul + co -> ...
PE> John Dennis -> person 1, can't remember
PE>
PE> and there's others, I don't know all of them.

db> What you're saying here is that from the very beginning, there were three 
db> completely separate versions of Msgedsq, all started from scratch, never 
db> sharing code.  See how stupid that is?  What you're trying to say is:

db>     Jim Nutt --> John Dennis --+--> Paul Edwards & Co. --> ... ?
db>                                |
db>                                +--> person 1, can't remember --> ... ?
db>                                |
db>                                ...

No, what I'm trying to say is that the Jim Nutt version
continued on.  He released at least 2.07 and I believe 2.08
is available in beta.

John took 2.00 and worked from that on his alternative version.

There are SEVERAL people who have taken JD 2.2e and produced
alternative versions.

PE> One day BTPE may be upgraded to be very similar in fact to 2.60.

db> Then the development tree will change, and not before.  I've just fired off 
db> a netmail message to see what VP has to say about releasing 2.59 source 
db> code.

Right, your message will be the one that puts him over the edge.
I couldn't even get him to acknowledge receipt of bug reports.
I had to do the 32-bit port myself before I tracked down the
problem and was able to give the required source code changes.
Didn't even get acknowledgement of that!

PE> BTW, these 2.55, 2.56, 2.59, 2.50EE are betas released
PE> without source code.  There is actually only two released
PE> products, 2.50 and BTPE 3.05.

db> We're talking about the *entire* development tree, not just the
"released" 
db> products;  even then, your BTPE path does *not* merge at present with the 
db> official development tree (therefore yours is a sidestep, and all you can 
db> do is make a newer version of BTPE, but you can't make a newer BT until you
db>  remerge with the original development tree).

It's a new official development tree.  Certainly more official
than your BTEE which you are happy to run.

db> See above - you're not competing with an official development tree as that 
db> tree has definitely stopped, so you either *are* the official development 
db> tree or you're the closest thing to it.

I am competing with JN's MSGED as much as I am competing with 
VP's BT.

db> Why don't you merge your efforts with fixes/features from the other 
db> versions?

Others can do the merging, I have most of the stuff I want
already.

db> Bullshit - even the cosmetics of the EE screen are better than BTPE.  The 

Use them a lot do you?

db> entry boxes are better, as are the extra help screens.  It has built-in Fax 
db> receive, which I *can* use now if I so choose.  It's not perfect, and it's 

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

db> definitely slower at starting up than BTPE (and it's larger), but it's 
db> 32-bit OS/2 native and I like it.  When source for 2.59 becomes available, 

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

db> I can make the cosmetic changes I like/want to it and keep all the other 
db> built-ins that are present.

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

db> BTW, WTFITPO "-DPRIVATE_IDAHO"?!?!  You *really* oughtta
get out more 
db> often, Paul.

Tell that to the people who wrote BT 2.50.  I didn't change that
bit, since changing it added no value to me.

PE> There's no competition at the moment though.

db> Yes there is - I'm running it.  There's no source, but there most certainly 
db> is a *product* (beta-level in name only, perfectly stable in operation).

Zero support, zero source is not my idea of a competitor.

PE> It's like V34bis.  It doesn't exist except in beta.  When V34bis
PE> actually EXISTS, *then* I expect it to be rolled into my modem.

db> And until then - what?  Have a V.34bis-only modem?  (Does anyone know when 
db> ITU-T plans to vote on V.34bis?)  Get serious.

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

PE> In this case, BTPE is the most advanced released product.

db> It's the most "advanced" BTPE - it things that are not in the main 

It's the most advanced released product.

db> development tree.  It also *lacks* things that are in the main development 

No it doesn't.  BT 2.50 being the only released competitor, it
has all the features in it.

PE> BTPE is even more legit than both BTEE and BT 2.59.  Both of those are
PE> betas, not released products.

db> Now you're just wanking with words - both BTEE and BT2.59 are *available*, 
db> so people will use 'em, like it or not.  Ask Nigel Davies (IBM OS/2 Support 
db> bboard), David Drummond, Dave Hatch, Poe Lim, Chris Graham, Graham Stair 
db> and Vince Perriello why they're all running BinkleyTerm 2.59 instead of 
db> BTPE.

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

PE> Exactly, and how many years have you been dreaming for?

db> None - BTEE runs and works perfectly, so I haven't had to spend any time 
db> worrying or thinking about it at all.

Then there's no point complaining about not having the source
code and 2.59 not having released source code either, is there?

db> So?  EMSI isn't the only thing BTEE has.  Even BTPE has features that you 

In fact, there's very little, if anything, that BTEE actually
gives you.  No, user-interface to an automatic dialler doesn't
get any points.

db> couldn't be bothered enabling so that people can use 'em (like Janus).  
db> That *would* have been useful recently when uploading all the EMX stuff 
db> (I'd still get my downloaded email and could read it whilst the xfer kept 
db> going) and would also help your STD callers who are running Janus-enabled 
db> mailers.

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

PE> You're the one complaining about 2.60 not existing and it being
PE> a dead product.

db> I wasn't complaining, just making comments based upon a recent check of the 
db> current BT status.

Why do you need to check?  BTEE does everything you want.

PE> The last release of BTPE was 4/11/95.  Pretty recent, eh?

db> Is that American or Australian date format?  ;-)

Australian.

PE> Did it perform the ATI6 command straight after your call?

db> Yup.  "OK" was the response - just like I told you.

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

---