PE>> I can't remember.  You can FREQ the QWK specs and the source to
 PE>> PQWK and that will give you everything you should need.  BTW,

 FM> OK, what file name? And the PKT specs?

You should grab a copy of my files list (FREQ "FILES"), as it has
all the files you can get in there.  The FTS docs are FTS*.*.  The
QWK docs are QWK*.*.

 PE>> PVERT may be pretty badly written, but it is the best public

 FM> Anything which has bugs, or which makes unreasonable and/or undocumented
 FM> (not in the source code!) demands of the user environment, is badly
 FM> written.
 
I'm not sure whether you are saying being documented in the source
code is acceptable or not (assuming the source code is distributed). 
That phrase of yours can be interpreted two totally different ways.

 PE>> domain one around (except for PQWK which is derived from it),
 PE>> so unless someone writes a replacement, there's not much you
 PE>> can do about it.  Personally I would have written it so that
 PE>> it worked on AmigaDos too, instead of lame-brained-C-programmer
 PE>> style that Mark and most of the rest of the world uses.

 FM> Ah, so C isn't the 'standard' language many of its supporters claim!
 FM> Might as well write it in Turbo Pascal!

If you're not going to follow the standard, yes, you may as well be
writing in Turbo Pascal.  Pick up a C program written for Unix,
and cringe when you go to another machine.  Pick up one for MSDOS,
cringe similarly.  You can pick up most of my programs and compile
them any damn place you want.  C has a very well-defined standard,
which is very very good.  Anything you can depend upon is documented.

 PE>> Nope, when I first started using archivers I thought to myself "I
 PE>> wonder if it can do this".  I do like the fact that it does, but
 PE>> that's another issue.

 FM> I think the UI is *the* most important part of programming. It's worth
 FM> sacrificing portability, at least to the extent of conditional compiles,
 FM> for. I write for 2 platforms (DOS, Windows), and I have a common library
 FM> of stuff I find useful - I use conditional compilation to separate the
 FM> stuff which is platform-specific so I the user see a common interface.
 
I tend to stick to utilities, with a command-line interface. 

 PE>> What about the way DOS automatically converts the filename specified
 PE>> into uppercase.  I would have to do a case-insenstive search to handle
 PE>> that.  What about in DOS it automatically truncates the name under
 PE>> certain circumstances.  I very rarely put any code in that is in any
 PE>> way machine-dependent.  I write all my programs as if I'm writing on
 PE>> a machine defined by ISO/IEC 9899-1990.  I can't see the machine yet,

 FM> But real users use real machines that they can see. AFAIK there are
 
Which are a superset of the one defined by ISO C, so I always get
it right. 
 
 FM> versions of ZIP available for other machines - how do they handle the
 FM> above? I'm sure it's not an insoluble problem.
 
Probably conditional compiles, that's what I normally see. 

 PE>> It does.  Preconditions are that you have a valid PKT file and no
 PE>> *.NDX files lying around and you have sufficient disk space and
 PE>> memory.  BFN.  Paul.

 FM> A well-written UI/machine interface should take those things into
 FM> account.

A fancy UI can be built on top of pkt2qwk for anyone who cares to
do so.  I think it's good to have the low-level utilities in the
public domain so that people can build other pd/shareware/commercial
programs on top of them without having to reinvent the wheel.  The
main reason people reinvent the wheel is because there's no
suitable wheels around in the first place (where not being public
domain may be one of the reasons for it being unsuitable).  At
least with PD stuff you can change the design of the wheel if you
don't like it.  That's exactly what I did to create PQWK from
PVERT.  BFN.  Paul.
@EOT:

--- Mksmsg