PF> Btw -- why go to so much trouble writing a library 
PF> that already comes with 
PF> each compiler?

PE> Hi Peter.  Had another reason today.  A program of mine abended,
PE> so I recompiled with Watcom with debug on, and ran it again,
PE> and it STILL abended, but the debugger told me the problem was
PE> in some purgefile() function [or something] which was obviously
PE> a compiler library, and although I'm pretty sure there's a problem

PF> I agree that access to the library source is essential -- and one of my few 
PF> complaints about IBM's compiler (you can get the source for 
PF> ICLUI/OpenClass,  but not for the CRT!).

Well, I wouldn't go so far as to say "essential", as I've always
worked around it before PDPCLIB.  I would have solved the problem
a different (longer) way.

PF> Watcom sells theirs -- but it IS available.

And you can get PDPCLIB for free.  And if you are doing the same
sort of text processing that I do, you may well find that it's
5 times faster (with fgets() and Watcom anyway).

PF> Borland's comes on later cdrom versions of the compiler (or for about $150 
PF> for the diskette version,  or if you bought it before they started 
PF> including it in the cdrom (like I did :-())).

Yes, you get it for free now basically.

PF> I would not consider using a third party CRT,  because it has/can not be as 
PF> well tested.

You can say that about ALL third party products and about your
own code too (not going to use your own code?  :-)).  You can say
that about EMX 0.9b if you want.  After all, that's basically
what PDPCLIB is the equivalent of - library only, someone else
provides the compiler.  Of course I'm sure EMX has had a LOT
more testing than PDPCLIB, and is more complete, and also has
a lot more extensions (PDPCLIB has NO extensions), but then
PDPCLIB is not attempting to compete on that level.  Personally
I have very few applications that use floating point, the only
time I ever really use that is when I use difftime().  Maybe
I should stop using difftime() anyway, seems silly to drag in
floating point like that.

PF> I keep virtually all of my code compiler independent,  and switch compilers 
PF> when I run into such a bug I can't fix.

Sure, so do I.  However, then you may have to put up with the
compiler's CRT being worse for the application you are trying
to do.  PDPCLIB lets you use whatever compiler you want, and 
have a faster CRT than what is provided (again, assuming you are
doing the same things that I consider important), and if you 
have any problems with PDPCLIB's performance, you can change
them yourself with no strings attached.  Oh, and if you have
a bug that you can't solve, and the bug is in the CRT, then 
you can avoid having to change compiler utilities such as
debugger and profiler (e.g. I prefer Watcom for both of them).

I'm not saying everyone should quickly upgrade to PDPCLIB as
a matter of urgency, it's just you asked me why I would bother,
and have given some reasons.  The most important one to me is
performance - I don't like people using DosRead() themselves
because of a shitty CRT.  Now I can claim equal performance in
ISO C to anyone using DosRead.  Or at least I assume I can, I
didn't actually try that out, it's just that that's the way
the code has been designed, a minimum path to DosRead.  I don't
even do a multiplication usually (of size and nelem).  

IF you are writing ISO-conforming C code, which is heavy on the
text processing, and you want it to be as fast as possible, as
well as trying it out with EMX, Watcom, Borland, and CSET to see
which one has the best performance, I would suggest also running
it through PDPCLIB to see what the results are.  And if those
performance results ARE worth it, THEN you could consider using
PDPCLIB, with the knowledge that it is not as well tested as the
other one you are using.

BFN.  Paul.
@EOT:

---