BBS: Inland Empire Archive Date: 01-26-93 (01:26) Number: 340 From: DIK COATES Refer#: NONE To: MARVIN HART Recvd: NO Subj: Qwk format Part 1/3 Conf: (2) Quik_Bas
>>>> QUOTING Marvin Hart to All <<<<
Start Part 2 of 3
MH> Can anyone help me fig. this out. It doesn't appear to be all that
MH> hard if a person can find the documentation. I'm trying to read and
There is a file on Steve's BBS in Oshawa, Ontario, Canada (416) 666-8935
called QWKLAY15.ZIP. This is an 18K file that expands to about a 50K
text file on the QWK format. It may be available on other boards in your
area. I have copied the information on the specific areas below. Just
a caution from their front end (I don't know if a format can be copyrighted,
but they have the note... Have stripped out some blank lines...
The QWK-format is Copyright 1987 by Sparkware.
All program names mentioned in this document are either Copyright or
Trademark of respective owners. (I don't know if they can do this
either, but from the .ARC suit, I would guess the names...)
MH> MESSAGES.DAT
[3.9] Message file (MESSAGES.DAT)
The MESSAGES.DAT file is the most important. This is where all of the
messages are contained in. The QWK file format is based on PCBoard
12.0 message base format from Clark Development Corporation (maker of
PCBoard BBS software).
The file has a logical record length of 128-bytes. The first record
of MESSAGES.DAT always contain a copyright notice saying "Produced by
Qmail...Copyright (c) 1987 by Sparkware. All Rights Reserved". The
rest of the record is space filled. Actual messages consist of a 128-
bytes header, plus one or more 128-bytes block with the message text.
Actual messages start in record 2. The header block is layed out as
follows:
Offset Length Description
------ ------ ----------------------------------------------------
1 1 Message status flag (unsigned character)
' ' = public, unread
'-' = public, read
'*' = private, read by someone but not by intended
recipient
'+' = private, read by official recipient
'~' = comment to Sysop, unread
'`' = comment to Sysop, read
'%' = sender password protected, unread
'^' = sender password protected, read
'!' = group password protected, unread
'#' = group password protected, read
'$' = group password protected to all
2 7 Message number (in ASCII)
9 8 Date (mm-dd-yy, in ASCII)
17 5 Time (24 hour hh:mm, in ASCII)
22 25 To (uppercase, left justified)
47 25 From (uppercase, left justified)
72 25 Subject of message (mixed case)
97 12 Password (space filled)
109 8 Reference message number (in ASCII)
117 6 Number of 128-bytes blocks in message (including the
header, in ASCII; the lowest value should be 2, header
plus one block message; this number may not be left
flushed within the field)
123 1 Flag (ASCII 225 means message is active; ASCII 226
means this message is to be killed)
124 2 Conference number (unsigned word)
126 2 Logical message number in the current packet; i.e.
this number will be 1 for the first message, 2 for the
second, and so on. (unsigned word)
128 1 Indicates whether the message has a network tag-line
or not. A value of '*' indicates that a network tag-
line is present; a value of ' ' (space) indicates
there isn't one. Messages sent to readers (non-net-
status) generally leave this as a space. Only network
softwares need this information.
Fields such as To, From, Subject, Message #, Reference #, and the like
are space padded if they are shorter than the field's length.
The message text starts in the next record. You can find out how many
blocks make up one message by looking at the value of "Number of 128
byte blocks". Instead of carriage return and line feed combination,
each line in the message end with an ASCII 227 (pi character) symbol.
There are reports that some (buggy) readers have problems with messag-
es which do not end the last line in the message with an ASCII 227.
If a message does not completely occupy the 128-bytes block, the re-
mainder of the block is padded with space or null.
Note that there seems to exist old doors which will use one byte to
represent the conference number and pad the other one with an ASCII 32
character. The program reading this information will have to deter-
mine whether the ASCII 32 in byte 125 of the header is a filler or
part of the unsigned word. One method is to look in the CONTROL.DAT
file to determine the highest conference number.
Even though most mail programs will generate MESSAGES.DAT files that
appear in conference order, this is not always the case. Tomcat!
(mail door for Wildcat! BBS) generates MESSAGES.DAT that is not in
conference order. This is due to how Wildcat! itself stores mail on
the BBS. Another known system that behaves this way is Auntie, which
has its mail door QWiKer.
Note that some mail doors offer the option of sending a mail packet
even though there may be no messages to send -- thus an empty
MESSAGES.DAT file. This was tested with Qmail 4.0 door and it sent a
MESSAGES.DAT file that contains a few empty 128-bytes blocks. Other
mail doors seem to be able to produce QWK files without the MESSAG-
ES.DAT file at all! Apparently, there was no standard established in
this procedure.
End of Part 1 of 3
... Hey ! I see you're wearing one of my original taglines -Dik
___ Blue Wave/QWK v2.10
--- Maximus 2.00
* Origin: Durham Systems (ONLINE!) (1:229/110)

Books at Amazon:
Back to BASIC: The History, Corruption, and Future of the Language
Hackers: Heroes of the Computer Revolution (including Tiny BASIC)
Go to: The Story of the Math Majors, Bridge Players, Engineers, Chess Wizards, Scientists and Iconoclasts who were the Hero Programmers of the Software Revolution
The Advent of the Algorithm: The Idea that Rules the World
Moths in the Machine: The Power and Perils of Programming
Mastering Visual Basic .NET