bluewave.htm

刚刚看到本站有Visual C++数字图象处理（人民邮电出版社）的电子书

upl_rec)</a><br>
=====================================<br>
<br>
the *.upl file consists of two &quot;parts&quot;: a header, which contains<br>
information about the reader used to create the reply packet, and a<br>
series of records that contain the information on all messages con-<br>
tained in the reply packet.<br>
<br>
most of the fields in the *.upl file are self-explanatory. the fol-<br>
lowing, however, deserve extra attention, starting with upl_header:<br>
<br>
upl_header_len length of upl_header used in the reply<br>
packet. reader authors are required to fill<br>
this field; door authors should use this<br>
field to properly parse the *.upl file.<br>
refer to the header file (under the<br>
inf_header section) for more information on<br>
using this field.<br>
<br>
upl_rec_len same as above, but specifies the length of<br>
the upl_rec structure.<br>
<br>
reader_tear contains the abbreviated name of the reader<br>
that created the reply packet (i.e. &quot;blue<br>
wave&quot;, &quot;q-blue&quot;, &quot;wave rider&quot;, etc.). this<br>
text can be used by the door to append tear<br>
lines and other reader-identifying lines to<br>
the message text, if desired. (door authors<br>
should take steps to use alternate text in<br>
case this field is not filled; using the name<br>
of the door is usually a good alternative.)<br>
<br>
likewise, here is additional detail on several fields in the upl_rec<br>
structure:<br>
<br>
unix_date the date/time that the reply message was<br>
written, specified as the number of seconds<br>
since 01/01/1970 (i.e. &quot;unix-style&quot;). this<br>
value can easily be obtained by c programmers<br>
via the time() function; in addition, the<br>
ansi c standard library contains additional<br>
functions to manipulate a unix-style time<br>
field, enough to satisfy most any require-<br>
ment (provided your compiler has support<br>
for them, though any compiler that claims to<br>
be ansi c compliant will contain all those<br>
functions and more).<br>
<br>
filename the name of the file that contains the text<br>
of the message. there is no requirement on<br>
how this file is to be named; such schemes<br>
are left to the individual. (the blue wave<br>
reader uses &quot;xxx.yyy&quot;, where &quot;xxx&quot; is the<br>
area number -- derived from the &quot;areanum&quot;<br>
field in inf_area_info -- and &quot;yyy&quot; is a<br>
unique number for each message that corre-<br>
sponds to that area. note that this is only<br>
provided as an example; you are not required<br>
to use this scheme, so long as the filenames<br>
are properly specified.)<br>
<br>
area_flags this field is used internally by the blue<br>
wave reader; as such, it *must not* be used<br>
by any other application.<br>
<br>
net_dest used to specify the destination address, as a<br>
text string, on messages destined for non-<br>
fidonet networks. (fidonet addresses are<br>
specified by the &quot;destzone&quot;, &quot;destnet&quot;,<br>
&quot;destnode&quot;, and &quot;destpoint&quot; fields in<br>
upl_rec.) the format of the address is,<br>
naturally, dependent on the network in ques-<br>
tion. if the message is for a non-networked<br>
message area, this field is ignored.<br>
<br>
<br>
<a name="the *.upi (upi_rec) and *.net (net_rec) files">the *.upi (upi_rec) and *.net
(net_rec) files</a><br>
=============================================<br>
<br>
the *.upi and *.net files are similar to the *.upl file, in that they<br>
specify the information for all messages in the reply packet (*.upi<br>
for non-netmail messages, *.net for netmail messages only). the<br>
fields in these files are similar in form and function to those in the<br>
*.upl file, thus they will not be elaborated upon here.<br>
<br>
*.upi and *.net were used in older versions of the blue wave reader,<br>
and have effectively been replaced by the more informative (and<br>
flexible) *.upl file. however, some older blue wave doors cannot<br>
handle the new *.upl file; for this reason, authors should provide<br>
support for *.upi and *.net, as well as *.upl. readers should create<br>
all three files, and doors should include code to process all three<br>
(giving preferential treatment to *.upl, of course). eventually,<br>
*.upi and *.net will be phased out altogether.<br>
<br>
<br>
<a name="the *.req file (req_rec)">the *.req file (req_rec)</a><br>
========================<br>
<br>
the *.req file is simply a list of files that the user wishes to<br>
obtain (download) from the host system. the implementation of such a<br>
feature is left to the individual programmer.<br>
<br>
note: current blue wave doors do not allow wildcard characters<br>
(&quot;*&quot; and &quot;?&quot;) in filenames, nor do they provide support for<br>
requesting more than 10 files. these are limitations of the<br>
blue wave doors themselves, *not* of the blue wave file<br>
specifications. this information is provided merely for<br>
informational purposes; authors should not feel bound by<br>
these restrictions in their own programs.<br>
<br>
<br>
<a name="the *.pdq file (pdq_header &amp; pdq_rec)">the *.pdq file (pdq_header &amp;
pdq_rec)</a><br>
=====================================<br>
<br>
the *.pdq file is used to perform offline configuration of the door<br>
via the reader. this file consists of two parts: a header, which<br>
contains non-message area configuration information, and a series of<br>
records that indicate the message areas to enable for scanning.<br>
<br>
the fields in both pdq_header and pdq_rec are mostly self-explanatory,<br>
though the process of selecting message areas needs elaboration. if<br>
the pdq_area_changes flag is set (in the &quot;flags&quot; field of pdq_header),<br>
the door should enable all the message areas (specified in pdq_rec<br>
records) that follow the header. this is most easily accomplished by<br>
first turning off all message areas that were active, then turning on<br>
each area indicated by the pdq_rec records (provided the user has<br>
access to them on the host system, of course). this is the method<br>
used by the blue wave doors, as it seems to be the easiest way to<br>
accomplish the task.<br>
<br>
note: this method of performing offline configuration will change<br>
in a subsequent revision of the blue wave specifications, so<br>
be ready for it!<br>
<br>
<br>
<a name="appendix a - how to create a blue wave mail packet">appendix a - how to create a
blue wave mail packet</a><br>
==================================================<br>
<br>
the following steps outline the basic method for creating a blue wave<br>
mail packet. note that this outline is highly generalized; the<br>
details of such a process are left to the programmer to implement as<br>
desired.<br>
<br>
1. open the *.inf, *.mix, *.fti, and *.dat files for writing; if<br>
they currently exist, they should be truncated and overwritten.<br>
<br>
2. fill the inf_header structure and write it to the *.inf file.<br>
<br>
3. obtain the information for the first message area, fill the<br>
inf_area_info structure, and writing it to the *.inf file.<br>
<br>
4. repeat step 3 for all remaining message areas.<br>
<br>
5. scan through the messages for the first message area and<br>
determine how many messages need to be packed. if messages need<br>
to be packed, fill the mix_rec structure and write it to the<br>
*.mix file, then perform the following steps:<br>
<br>
a. read the next new message from the message area.<br>
<br>
b. fill the fti_rec structure and write it to the *.fti file.<br>
<br>
c. write the message text to the *.dat file.<br>
<br>
d. repeat steps a through c until all messages are packed.<br>
<br>
6. repeat step 5 for all remaining message areas.<br>
<br>
note: an alternate method for the actions described in steps<br>
5 and 6 is to scan through the message base and write<br>
the fti_rec records and the *.dat text first, then<br>
write the mix_rec. as mentioned above, however, the<br>
method you use is entirely up to you.<br>
<br>
7. use an archiving utility (arc, pkzip, etc.) to pack the *.inf,<br>
*.mix, *.fti, and *.dat files into an archive file. the file<br>
should be named according to the naming convention specified<br>
earlier in this document.<br>
<br>
note that these steps do not take into account such things as bulletin<br>
files, keywords, filters, macros, and so forth, but again, these are<br>
the details which are left to the programmer to implement.<br>
<br>
<br>
<a name="appendix b - how to create a blue wave reply packet">appendix b - how to create a
blue wave reply packet</a><br>
===================================================<br>
<br>
unlike creating a mail packet, the creation of a reply packet is not a<br>
linear process; there is no outline that can be followed. basically,<br>
when the reader creates a reply message, a upl_rec record is filled<br>
and written to the *.upl file for each reply created by the reader; if<br>
the *.upl file doesn't exist, then it will have to be created (natu-<br>
rally) by filling and writing a upl_header to the *.upl file before<br>
adding upl_rec records. this process is performed on-the-fly, at the<br>
time the user creates reply messages.<br>
<br>
the reply archive itself is created by an archive utility (arc, pkzip,<br>
etc.), using the filename conventions specified earlier in this docu-<br>
ment. in order to prevent &quot;orphaned&quot; files -- messages deleted by the<br>
reader -- from showing up in the reply archive, reader authors should<br>
delete the archive before running the archive utility; this will force<br>
a &quot;fresh&quot; file, free from excess clutter, to be created from scratch.<br>
<br>
<br>
<a name="appendix c - the blue wave structures and turbo pascal">appendix c - the blue
wave structures and turbo pascal</a><br>
======================================================<br>
<br>
the blue wave packet structures are provided as a header file for c<br>
compilers, since the blue wave offline mail reader and the blue wave<br>
offline mail doors from cutting edge computing are written in c.<br>
however, for the convenience of programmers who write programs using<br>
borland's pascal compilers (turbo pascal and borland pascal), a header<br>
file for use in pascal programs (bluewave.inc) is provided. please<br>
note the following changes and restrictions from the c header imple-<br>
mentation:<br>
<br>
1. as implemented, the pascal header is to be included within a<br>
source file, i.e.:<br>
<br>
{$i bluewave.inc}<br>
<br>
industrious pascal programmers can easily convert this header<br>
file to a unit if so desired.<br>
<br>
2. the structure names and constants remain identical, i.e. mix_rec,<br>
fti_rec, and so on, and are defined as &quot;record&quot; data types.<br>
thus, defining a structure is similar to any other pascal data<br>
<br>
type, i.e.:<br>
<br>
var infheader : inf_header;<br>
infrec : inf_area_info;<br>
mixrec : mix_rec;<br>
ftirec : fti_rec;<br>
<br>
also note that unlike c, pascal is not case-sensitive with re-<br>
gards to variable and type names. thus, inf_header can also be<br>
accessed as &quot;inf_header&quot;, &quot;inf_header&quot;, or even
&quot;inf_header&quot;.<br>
<br>
3. due to a conflict with reserved keywords in pascal, the &quot;from&quot;<br>
and &quot;to&quot; fields in fti_rec, msg_rec, upi_rec, and upl_rec have<br>
been renamed to &quot;mfrom&quot; and &quot;mto&quot;. all other field names are<br>
identical between the c and pascal headers.<br>
<br>
4. bit flags are defined as sets in the pascal header, and are set<br>
and reset using the pascal set operators (+ and -). for example,<br>
to set the inf_echo and inf_netmail flags, the following state-<br>
ment:<br>
<br>
infrec.area_flags := infrec.area_flags + [inf_echo,<br>
inf_netmail];<br>
<br>
can be used.<br>
<br>
5. with one exception, data types in pascal are stored identically<br>
to their c counterparts (i.e. pascal &quot;longint&quot; and c &quot;long int&quot;<br>
are stored, identically, in 4 bytes.). the lone exception is<br>
strings. in c, strings are stored as a series of characters<br>
terminated with a 0 byte. in pascal, strings are stored as a<br>
length byte followed by the characters that make up the string.<br>
since the blue wave format is centered around the c language,<br>
pascal programmers will have to convert strings between c and<br>
pascal formats. to aid in this endeavor, strings in the pascal<br>
header are defined as arrays of bytes (i.e. &quot;array[1..43] of<br>
byte&quot;), but you will have to devise your own routines to convert<br>
strings between the two formats.<br>
<br>
there are undoubtedly other areas where c and pascal differ, but this<br>
should get you started in the right direction.<br>
<br>
please note that cutting edge computing does not provide support for<br>
pascal programmers using these structures. the pascal header is<br>
provided solely for your convenience; other than that, you are on your<br>
own. thus, it is recommended that only pascal programmers with some<br>
experience in using data created by (and expected by) c programs use<br>
these structures, as handling the differences between the languages is<br>
not something that is easily handled by the novice.<br>
<br>
<br>
<a name="appendix d - serial numbers in mail and reply packets">appendix d - serial
numbers in mail and reply packets</a><br>
=====================================================<br>
<br>
the serial number fields in the *.inf, *.upi, and *.upl structures are<br>
used mainly by the blue wave reader and doors from cutting edge com-<br>
puting (using what is, naturally, a proprietary algorithm to determine<br>
the actual serial numbers). authors are free to use these fields as<br>
they see fit, though the values in the fields will undoubtedly be<br>
meaningless to other blue wave-compatible programs. in fact, unless<br>
you're creating your own series of blue wave-compatible doors and<br>
readers, the serial number fields are practically useless to third-<br>
party authors.<br>
<br>
(as an example, the blue wave doors will examine the reader name field<br>
in the *.upl header to determine if a reply packet was created by the<br>
blue wave reader. if it was, then the serial number is used to deter-<br>
mine if &quot;[nr]&quot; should be added to the tear line. on the other hand,<br>
if the packet was created by a different reader, the blue wave doors<br>
will ignore the serial number and never put &quot;[nr]&quot; in the tear line.)<br>
</td>
</tr>
</table>
</center></div>
<p align="center"><a href="../index.htm">返回</a></p>
</body>
</html>