📄 bluewave.htm
字号:
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=gb2312">
<title>the blue wave offline mail systemmail packet file structuresrevision level
2copyright 1990</title>
<meta name="generator" content="microsoft frontpage 3.0">
</head>
<body background="../jpg/di1.JPG">
<p align="center"><font size="5" color="#0000ff">blue wave mail packet file structures</font></p>
<div align="center"><center>
<table border="0" width="88%">
<tr>
<td width="100%"><br>
the blue wave offline mail system<br>
mail packet file structures<br>
revision level 2<br>
<br>
copyright 1990-1994 by cutting edge computing<br>
all rights reserved<br>
<br>
created by george hatchew<br>
<br>
documentation by martin pollard and george hatchew<br>
revision 2.01 - january 18, 1994<br>
<br>
<br>
<br>
===================<br>
table of contents<br>
===================<br>
<br>
<a href="#introduction">introduction</a><br>
<a href="#filename conventions">filename conventions</a><br>
<a href="#files in blue wave packets">files in blue wave packets</a><br>
<a href="#byte ordering in file structures">byte ordering in file structures</a><br>
<a href="#using the file structures">using the file structures</a><br>
<a href="#unused and reserved structure fields">unused and reserved structure fields</a><br>
<a href="#the *.inf file (inf_header & inf_area_info)">the *.inf file (inf_header
& inf_area_info)</a><br>
<a href="#the *.mix file (mix_rec)">the *.mix file (mix_rec)</a><br>
<a href="#the *.fti file (fti_rec)">the *.fti file (fti_rec)</a><br>
<a href="#the *.dat file">the *.dat file</a><br>
<a href="#the *.xti file (xti_rec)">the *.xti file (xti_rec)</a><br>
<a href="#the *.upl file (upl_header & upl_rec)">the *.upl file (upl_header &
upl_rec)</a><br>
<a href="#the *.upi (upi_rec) and *.net (net_rec) files">the *.upi (upi_rec) and *.net
(net_rec) files</a><br>
<a href="#the *.req file (req_rec)">the *.req file (req_rec)</a><br>
<a href="#the *.pdq file (pdq_header & pdq_rec)">the *.pdq file (pdq_header &
pdq_rec)</a><br>
<a href="#appendix a - how to create a blue wave mail packet">appendix a - how to create a
blue wave mail packet</a><br>
<a href="#appendix b - how to create a blue wave reply packet">appendix b - how to create
a blue wave reply packet</a><br>
<a href="#appendix c - the blue wave structures and turbo pascal">appendix c - the blue
wave structures and turbo pascal</a><br>
<a href="#appendix d - serial numbers in mail and reply packets">appendix d - serial
numbers in mail and reply packets </a><br>
<br>
<br>
============================<br>
copyright and restrictions<br>
============================<br>
<br>
the blue wave packet structures were created by george hatchew, and<br>
are the copyrighted property of cutting edge computing. permission is<br>
granted for third parties to use these structures in their own pro-<br>
grams, without any royalties or licenses required. cutting edge<br>
computing reserves the right to make any changes to these structures,<br>
at any time. as such, third parties are requested not to make any<br>
unauthorized changes to these structures, as cutting edge computing is<br>
not bound to follow these changes. any proposed changes should be<br>
brought to the attention of cutting edge computing, where they may be<br>
included in future revisions of the structures.<br>
<br>
authors that use these structures are allowed to claim that their<br>
programs are "blue wave compatible". however, to avoid confusion and<br>
complications, authors are not allowed to use "blue wave" as any part<br>
of the name of their programs (as "blue wave" is a product line from,<br>
as well as a trademark of, cutting edge computing).<br>
<br>
<br>
<br>
===================<br>
trademark notices<br>
===================<br>
<br>
the following are products, trademarks, or registered trademarks of<br>
the following individuals and/or companies:<br>
<br>
arc - system enhancement associates<br>
blue wave - george hatchew and cutting edge computing<br>
fidonet - tom jennings and fido software<br>
megareader - kip compton<br>
ms-dos - microsoft corp.<br>
pkzip - pkware inc.<br>
qwk - mark "sparky" herring<br>
silver xpress - hector santos and santronics software<br>
turbo pascal, borland pascal - borland international<br>
xrs - michael y. ratledge<br>
<br>
any omissions from this list are purely unintentional.<br>
 blue wave mail packet file structures - revision level 2<br>
<br>
<br>
<a name="introduction">introduction</a><br>
============<br>
<br>
the world of offline mail has virtually exploded since the late 1980s,<br>
due mostly to the ever-increasing interest in electronic mail networks<br>
(such as fidonet and the internet). as the flow of mail increased,<br>
more and more users became aware of the benefits of downloading mail,<br>
reading it offline, and uploading replies at a later date, thus maxi-<br>
mizing efficiency and minimizing the time spent online.<br>
<br>
several competing formats for storage of offline mail have come into<br>
existence during this period, with the minimalist qwk format emerging<br>
as the dominant one due to its open specifications. (the megareader,<br>
silver xpress, and xrs, formats also exist, but never really achieved<br>
"critical mass" due to the proprietary nature of their file formats.)<br>
qwk enjoys widespread popularity, but its technical limitations make<br>
it less than suitable for handling the wide variety of electronic mail<br>
that currently exists (and which will appear in the coming years).<br>
<br>
the blue wave format was designed as a superior method of providing<br>
offline mail capabilities, particularly for networks based on the<br>
fidonet standard (which means full support for fidonet-style private<br>
mail, or netmail). its design is simple enough that virtually any<br>
programmer can create a blue wave-compatible product in a short amount<br>
of time, yet flexible enough to provide plenty of room for future<br>
needs (such as fax capabilities). it also has basic support for non-<br>
fidonet style mail, such as that required by internet mail, usenet<br>
newsgroups, and qwk-based network mail.<br>
<br>
note that this is a reference document, not a programming tutorial. a<br>
tutorial on programming is beyond the scope of this document. thus,<br>
we do not recommend the use of these structures by the novice.<br>
<br>
<br>
<a name="filename conventions">filename conventions</a><br>
====================<br>
<br>
the blue wave format was originally designed for the blue wave series<br>
of offline mail readers and doors running on an intel-compatible pc<br>
using ms-dos (or a dos-compatible operating system). this means that<br>
filenames are limited to the dos standard "8.3" format (up to eight<br>
characters, optionally followed by a period and a one to three charac-<br>
ter extension, with no distinction made between upper and lower case<br>
letters). for maximum compatibility across different platforms,<br>
programs utilizing the blue wave format should limit filenames to the<br>
dos format as well.<br>
<br>
additionally, dos allows for some non-alphanumeric characters to be<br>
used in filenames. these characters, while suitable for dos, may<br>
cause problems on non-dos platforms. therefore, it would be wise to<br>
restrict the allowable characters in filenames to uppercase letters<br>
("a" to "z") and digits ("0" to "9").<br>
<br>
<a name="files in blue wave packets">files in blue wave packets</a><br>
==========================<br>
<br>
there are two main components to the blue wave system: mail packets,<br>
which consist of messages obtained from the host system (such as a<br>
bbs), and reply packets, which consist of messages written by the user<br>
via an offline mail reader (such as the reader that bears its name,<br>
the blue wave offline mail reader). each type of packet contains its<br>
own set of unique files.<br>
<br>
blue wave mail and reply packet filenames are based around what is<br>
called a "packet id". the packet id is a one to eight character<br>
string that uniquely identifies a particular host system, and is used<br>
as the basis for all packet files. "packets", as defined here, are<br>
groups of files contained in an archive file, which uses the packet id<br>
as the base filename and is created using a file archive utility (such<br>
as arc or pkzip, or the equivalent for non-dos platforms). the three-<br>
character extension for a mail packet is comprised of the first two<br>
letters of the day of the week, followed by a digit from 0 to 9.<br>
fidonet sysops will recognize this as the same scheme used for the<br>
extensions on echomail packets. (an alternate scheme is to use a pure<br>
numerical extension, i.e. "001" through "999".) the extension for a<br>
reply packet is "new". (note that door implementations should include<br>
code to keep track of the last mail packet extension used, so that<br>
multiple mail packets created on the same day won't have the same<br>
filename.) examples of packet archive names and internal filenames,<br>
based around the packet id, are given below (after the list of files).<br>
<br>
a mail packet consists of, at minimum, the following files:<br>
<br>
*.inf information about the host system and its message<br>
areas, as well as information about the user who<br>
obtained the mail packet.<br>
<br>
*.fti the headers for each message in the mail packet.<br>
the headers consist of such things as the from:,<br>
to:, and subject: fields, and the date/time the<br>
message was written.<br>
<br>
*.mix an index file that points to the messages for each<br>
message area, designed for quick access to messag-<br>
es.<br>
<br>
*.dat the text for all messages in the mail packet.<br>
<br>
optional text/ansi files may also be included in the archive. in<br>
addition to the "reader" files specified in the *.inf header, there<br>
are two other types of files, not defined in the *.inf header, that<br>
may be included. the first, a list of new files available for down-<br>
load, can be included as "newfiles.*" (any extension is valid). the<br>
second, system bulletins, can be included as "blt*.*" (any filename is<br>
valid, as long as it begins with "blt"). the methods used to display<br>
these bulletins is implementation dependent.<br>
<br>
<br>
a reply packet consists of, at minimum, the following files:<br>
<br>
*.upl contains the information (name, network address,<br>
message attributes, filename of message text,<br>
etc.) for each reply message. replaces the *.upi<br>
and *.net files (see below) used in older blue<br>
wave implementations.<br>
<br>
*.upi contains the information (name, network address,<br>
message attributes, filename of message text,<br>
etc.) for each non-netmail reply message. this<br>
file has been obsoleted by the *.upl file, but is<br>
documented here for compatibility purposes (as<br>
some older systems are not yet compatible with the<br>
*.upl file).<br>
<br>
*.net contains the information (name, network address,<br>
message attributes, filename of message text,<br>
etc.) for each netmail reply message. this file<br>
has been obsoleted by the *.upl file, but is<br>
documented here for compatibility purposes (as<br>
some older systems are not yet compatible with the<br>
*.upl file).<br>
<br>
*.req an optional file that specifies the information on<br>
file requests made through the offline mail read-<br>
er.<br>
<br>
*.pdq an optional file that specifies the information on<br>
remote configuration (such as adding and dropping<br>
message areas) made through the offline mail<br>
reader.<br>
<br>
to clarify, let's say a bbs is using the packet id of "wildblue". a<br>
mail packet from that bbs would contain (at minimum) the files wild-<br>
blue.inf, wildblue.fti, wildblue.mix, and wildblue.dat, and when<br>
archived, would be called "wildblue.su1" (the extension may differ,<br>
depending on the criteria described above). consequently, a reply<br>
packet destined for that bbs would contain (at minimum) the files<br>
wildblue.upl, wildblue.net and wildblue.upi (for compatibility), plus<br>
the individual files that comprise reply messages, and when archived,<br>
would be called "wildblue.new".<br>
<br>
the text of each reply message is stored in individual files in the<br>
reply packet. each *.upl record contains the name of the text file<br>
corresponding to the particular reply message. the naming convention<br>
used to assign names to each text file is up to the programmer. (the<br>
blue wave reader uses "xxx.yyy", which stands for "message 'xxx' in<br>
area 'yyy', but you are not limited to this format as long as the<br>
filename is properly stored in the *.upl, *.upi, or *.net record.)<br>
<br>
<br>
<a name="byte ordering in file structures">byte ordering in file structures</a><br>
================================<br>
<br>
since the blue wave packet structures were initially written for ibm<br>
pcs and compatible systems, the format for multi-byte fields in the<br>
data structures is expected to be in intel format (i.e. the least<br>
significant byte first, followed by the most significant byte[s]).<br>
some cpus, particularly the motorola 68000 series, store multi-byte<br>
fields as most significant byte first. if you are writing a blue wave<br>
compatible program for a system that does not store data in the intel<br>
format, you will have to write a routine that will convert data bet-<br>
ween the two formats.<br>
<br>
<br>
<a name="using the file structures">using the file structures</a><br>
=========================<br>
<br>
the file structures, as presented here, are provided as a header file<br>
for use with the c programming language. simply use the #include<br>
statement in your program source code to incorporate the header file:<br>
<br>
#include "bluewave.h"<br>
<br>
each file structure is defined as a data structure ("struct") using<br>
the "typedef" feature, making it easy to define variables. for exam-<br>
ple, to define a variable used to store the *.inf file header, simply<br>
use:<br>
<br>
inf_header infhdr;<br>
<br>
in your program.<br>
<br>
to make the structures as compatible across platforms as possible, all<br>
data types used in the structures are user-defined via "typedef". for<br>
example, to use a 16-bit unsigned integer, the data type "tword" is<br>
used instead of "unsigned int". this way, data fields are guaranteed<br>
to be the same size across platforms. (for more information, refer to<br>
the information contained in the bluewave.h file.)<br>
<br>
also, if your program is being written for a cpu that does not store<br>
data in intel format (as described earlier), you should insert:<br>
<br>
#define big_endian<br>
<br>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -