Hi, Paul.

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

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

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

I have FILES, it's easier to ask here to find out what's the right thing
to look for. I'll freq the 2 files next run, not QWK*.* 'cos that would
get me some other, irrelevant, stuff.

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

PE> FM> Anything which has bugs, or which makes unreasonable and/or
PE>undocumented
PE> FM> (not in the source code!) demands of the user environment, is badly
PE> FM> written.

PE>I'm not sure whether you are saying being documented in the source
PE>code is acceptable or not (assuming the source code is distributed).
PE>That phrase of yours can be interpreted two totally different ways.

Yes, I'm saying documented in the source code is not sufficient. *I*
certainly didn't read it, until I had to. And, the TinyPoint batch
actually disregards that restriction. Of course, better that the bug not
exist.

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

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

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

But what good is a standard which nobody (well, at least "Mark and most
of the rest of the world") uses?

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

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

PE>I tend to stick to utilities, with a command-line interface.

I didn't mean UI in the sense of GUI vs CLI, I meant the whole
environment in which the user interacts with the program. IMHO it's
just as important to get that right in a CLI utility, anything which is
going to interact with users, including how they might happen to have
their machine set up. I have less quarrel with you assuming that the
packets are good, they're coming from a program, although personally I
would tend to include the error checking in that circumstance.

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

PE> FM> But real users use real machines that they can see. AFAIK there are

PE>Which are a superset of the one defined by ISO C, so I always get
PE>it right.

Well, except for the problems with, eg, file names. :-)

PE> FM> versions of ZIP available for other machines - how do they handle the
PE> FM> above? I'm sure it's not an insoluble problem.

PE>Probably conditional compiles, that's what I normally see.

Makes sense.

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

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

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

As I said, I wasn't referring to a "fancy UI", but all the details of
how the CLI program interacts with the user and his environment. I agree
with the rest of your comments, but I believe the utility should be as
bullet-proof as possible.

Regards, FIM.

 * * Ignorance is temporary. Stupidity is forever...
@EOT:

---