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