BL> BTW, I'm looking at pkt2qwk - and it creates numbers at the end
 BL> of the qwk message header, where the qwk packets from BlueWave
 BL> and the SPCUG have spaces. BlueWave seems happy enough to them
 BL> ignore anyway, but these numbers are not supposed to be there.

 PE> It could be uninitialized data, or it could be something in the
 PE> standard you aren't aware of.

  (grin) It could be the Martians trying to communicate through
pkt2qwk, using the last three bytes in the message header, but you're
the one who wrote the bloody thing, so I'm asking you: what the fuck 
are they? 

 PE> You should always look for the x'00' first. How are you
 PE> stripping SEENBY lines?

  I don't know yet! It's a bloody shambles! 

  I have to find each separate line (SOT, EOT, PATH, SEENBY), find
its length, and then decide whether to write into the QWK packet or
not. If I find "SOT:" I start the message there, or if not; I use the
AREA: line, and start after that.

  If I find "EOT:" I write everything before that to the buffer. If I
don't find EOT: I go on to the next step. That's the easy part.
 
  Some pkts have PATH before SEEN-BY and some are the other way
around, so I do both separately. I put "SEEN-BY" as the search string,
mark the beginning, and do the same for "^aPATH". Which ever comes
first, I write the tear line and origin line between it and "EOT:"
(or SOT or the AREA line in EOT isn't there) to the buffer. Then I 
calculate the length of the buffer in 128-btyes and pad it before I 
write to the output message.dat file.

  Messy is too small a word for it. It's bloody silly, and your SOT
and EOT don't make it any easier. Why the fuck didn't you put EOT after 
the origin line?

 BL> What do you think?

 PE> Have you actually read FSC-XXXX.000?

  Of course, and I agree with your reasoning. The PATH and SEENBY
should not be part of the message. They ought to be in the header.
but using a fixed or maximum spacing from the actual message end
doesn't change that.

 PE> It is meant to solve a specific problem, and it is meant to be
 PE> simple to create, because it's main purpose is to protect
 PE> SEENBYs in the user text from proper SEENBYs. It is to provide
 PE> a clear distinction between user text and control lines.

  It's easy enough to create (I did that in rep2pkt), but it's a
bastard to write around. In any case, having *one* purpose doesn't
preclude it being used for another. You didn't comment. I already
agree that the EOT has a function. What about the other?

   The main problem I see with the PKT standard is that there is no
way to double-check anything - that, and the fact that everything is
all over the place like a mad-woman's shit. Null-terminating is a good
way to identify a field, but if you have to read your SOT and EOT then
you may as well use that to check that you're in the same message.

  In fact, your SOT and EOT is only a bloody nuisance as it stands,
especially the EOT, with a tear-line and origin-line between the
SEEN-BY you want to protect from the message writer. You can use the
"---" tear-line or the "* Origin" line to do the same
thing. The fact
that it has a 0x01 in front of it contributes nothing, to safety or
anything else.

  I agree that the path and seen-by should be protected, with a way to
separate them from message text. Your EOT does that. They should not 
be part of the message at all, but... why the hell don't you put your 
EOT *after* the origin-line? It has to be included in the message, and
the EOT, PATH and STAND-BY have to be removed. Why make it hard?

... [later]

  I've been writing pkt2qwk again, and your SOTs and EOTs are a
menace! If I look for SOT or ^a, and if SOT is missing, I either get
a SOT in the *next* message or the ^a in PATH. 

  What I have to do, is read the bloody file *twice*, first to skip
the header because there may be 0x00 in there, and *then* the fields
because they have 0x00 terminators, and THEN find the end of the
message before I can write it to a string buffer and read the header,
SOT, EOT, and stuff. This is bloody ridiculous! I'm doing it twice.

 PE> You should always look for the x'00' first.

  So you say. Why?

  *Your* way, means I have to find every 0x00 in the fields before I
can read the 0x00 that defines the message end. Then I have to do it
*again* to actually read the fields... and finally try to read the
message clogged up with bloody useless SOT and EOT. And the buffer is
the *wrong* length, after I remove the unwanted lines and SOT, EOT, 
and PATH. No wonder pkt2qwk is so slow. And this is to create QWK 
packet that doesn't give a stuff about PKT compliance. 

  I take back what I said about SOT and EOT. They are worse than
useless. Why do you need a SOT to define the start of the message? 
All you have to do is remove the AREA: line, and that it! That's the 
start of the message. You have to do it anyway, so what is the 
purpose of the SOT?

  Why do you need an EOT to define the end of a message when you have
a tear line and origin line *following* the EOT that are part of the
message anyway! The tear line can define the end... or the origin
line.

  This is crazy, Paul. You read the end of the message at EOT, and
then you have to put the tear line and origin line on the end! It's
not the end. It's just a bloody intermission. We all go out and buy
popcorn while the program does it again! This is inside a loop for
every message. If you have a hundred messages it takes a long time!

  The way it stands now, if I don't process your packets differently
than the rest, I get annoying SOTs and EOTs in my messages, and if I
do process your SOT and EOT I end up with a non-standard program that
runs slower. Good one, Paul.

Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---