bbs/deb-mbse
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Cleanup of HTML code

Browse Source
This commit is contained in:
Michiel Broek
2002-02-17 13:24:26 +00:00
parent 6d0764770a
commit ed20c3a0fa
61 changed files with 3313 additions and 3253 deletions
Download Patch File Download Diff File Expand all files Collapse all files

663
html/misc/filefind.html
View File

@@ -1,331 +1,332 @@
<HTML>
<HEAD>
<TITLE>Implementation and Usage of FileFind Utilities.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: fsc-00xx
Version: 0.6
Date Aug 30, 1995
Title: Implementation and Usage of FileFind Utilities
Authors: Robert Williamson FidoNet#1:167/104.0 robert@ecs.mtlnet.org
Intro
A portion of the document is derived from information in
AllFix.DOC by Harald Harms @ 2:281/910
with additional sections from
FQuery.DOC by Robert Williamson @ 1:167/104
The MSdos program ALLFIX by Harald Harms first introduced the idea
of searching for files via echomail. The term applied to this function
is 'FileFind'. A FileFind system allows sysops, points and BBS users
to search for files by placing a message to 'ALLFIX' in an echo
designated for the purpose of finding files. All FTN sites running a
FileFind processor which is configured to scan that echo will reply to
that user if there any files matching his query. This system provides
a method for searching many FTN sites throughout the world, with a
single message.
FileFind programs work by either scanning through defined message
bases or scanning packets for defined AREA tagnames for messages to the
default name ALLFIX. All FileFind programs MUST respond to the name
ALLFIX, but may also respond to the name FILEFIND and the name of the
particular FileFind program in use or defined for the echo. The
FileFind program will process these messages, examining the Subject
field for search queries. If any valid query is found, the FileFind
program will search the sites files database for files matching the
users's query.
If the FileFind program finds any matches, it will generate a reply
containing a list of the files found, and some basic information ABOUT
the system posting the reply. When the user who initially wrote the
request reads the reply, he will then be able to decide if any of the
reported files meet his needs, and from the ABOUT included in the
reply, learn where and how he may get those files.
FileFind Query Message Structure
To: name_of_FileFind program
The message must be addressed to ALLFIX so that all FileFind programs
can respond. To use features specific to a particular FileFind
program, or to limit the responses to a particular platform, the
message should be addressed to that program's name. Some FileFind
programs will respond to more than two names.
Subject:
A space-separated list of file specifications, keywords or quoted
strings.
keyword - single word preceeded by a '/' with no intervening spaces,
must be at least 3 characters, not including the '/'.
a keyword search is in actually a substring search of the
site's filelist.
description - string enclosed in double-quotes,
if a single word, must be more than 3 characters.
filespec - single word, no spaces, no double-quotes or preceding /,
must be at least 3 characters, not including any wildcard
or pattern matching charcaters, such as '*'.
Messages addressed to ALLFIX must not have any embedded
pattern matching characters.
The minimum number of characters for description, keyword and
filespec queries is an implementation detail of the FileFind program.
These values should be configurable, but should never be settable to
values of less than 3.
Each implementation should allow the operator the ability to
configure a list of disallowed keywords.
NetMail Queries
Some FileFind programs may also have the ability to process file
search queries received as netmail and addressed to the name of the
particular FileFInd program with this capability. In this case, all
replies are via netmail also.
NetMail Commands
FileFind Netmail commands are identifed by a leading '%'.
Implementation of netmail commands is optional. If implemented,
compliant FileFind utilities should be able to process the following
minimum NetMail command set.
%HELP - netmail only, returns an extended help text for the
FileFind program, the ABOUT of the the site and a list
of MAGIC freqable names.
%ABOUT - netmail only, returns the ABOUT of the site and a full
or %MAGIC list of MAGIC names.
%NEWFILES - netmail only, returns the NEWFILES list of the site
or %NEW via netmail.
Extended NetMail Commands:
Implementation of the following netmail commands is optional and
not required for compliance with the FileFind NetMail Command set.
%REPORT <tagname>
- sends a configuration report for echo <tagname>
this allows an echo moderator to check if a site running
a FileFind utility is compliant with the rules of the
filefind echo.
%REQUEST <filename>
- if found, will place requested file on hold for remote
site
%UUREQUEST <filename>
- if found, and the filesize after uuencoding is less
than 60K, it will be sent as multiple netmail messages
The Site ABOUT
Obviously, a system that neither accepts file requests nor allows
users to download on their first call should not be responding to
FileFind messages. If there are any limitations for the caller to
acquire any of the files that the site has advertised as being
available in it's FileFind response, these limitations MUST be listed
in the reply. This information should be included in the ABOUT file
that the FileFind program user creates.
The site ABOUT should contain the following information. The
FileFind program implementor should instruct his users on these
requirements.
- sitename
- site operator's name
- complete phonenumber
- baud rate
- hours during which filerequests are accepted, if at all
- hours during which users can download
- conditions for file requests and user downloads
NOTE: the above information should be within the first 14 lines.
optional:
- a list a MAGIC names
- an indication if magic names are also available to terminal users.
Searching for Files and Creating Replies
The method used by the FileFind program to search for requests is
up to the implementor. However, if searching a list, the FileFind
program should confirm the actual existance of all files that match the
query specification.
The FileFind program should only process description strings,
filespecs or keywords that contain more than 3 valid characters and
should have configuration options to define greater minimum lengths on
a per-echo basis.
For filespecs, the wildcard character '*' IS considered a valid
specification as well as the '?' wildcard, but only the '?' is to be
counted as a character when determining the length of query. File
extensions are not necessary and any characters AFTER a '*' are to be
ignored. The FileFind program should be configurable so as to allow
replacement all of the file extensions with '.*' or '#?' dependant on
platform. This results in queries being independant of the various
archivers in use.
Replies
Replies created by FileFind utilities are expected to be in
compliance with the following FTN specifications:
FTS-0001 - packed message format
FTS-0009 - MSGID/REPLY
FSC-0046 - PID and tear line
In addition, a FileFind utility may use the FID: control line for
any information needed that cannot be put in a PID: without violating
that specification.
^AFID: ascii text CR
Must be less than 80 characters including ^A and terminating CR.
There are three ways in which the FileFind program can create replies:
- write the replies in the echo in which the query appeared.
- write the replies in an echo that has been specifically
designated for that purpose in the particular FTN or for
a gorup of echos in that FTN.
- reply via routed netmail.
Since each FTN site connected to a particular FileFind program area
is capable of creating an information reply, there is much concern as
to the amount of traffic that can be generated, FileFind program
developers must be sensitive to these concerns by providing the means
to their users to limit the traffic on a per-echo basis. For example,
various FileFind echos have rules limiting the size or number of
replies, or the length of the system information that may be included
in a reply.
Limiting replies
It is strongly suggested that some default limitations be built-in.
Limiting Site Header (ABOUT):
If the site's ABOUT, (the text that has been configured in order to
add the system's information and Magic names list to the reply), is
greater than 14 lines, the remainder should NOT be posted. A line
should be added to the response indicated this, and the user may be
invited to either Freq or download the MAGIC name's ABOUT or MAGIC, for
a full list of magic names. The FileFind program may optionally send
the full system information and magic name list via routed netmail.
Limiting Match List due to ambiguity of query:
If the list of matches (note: not the size of the message itself)
is greater than 32K, the FileFind program should post a message to the
user to indicate that his query may have been too ambiguous and perhaps
invite him to freq or download the MAGIC name FILES for a full list.
Splitting Match List into Multiple Messages:
If the list of matches is greater than 10K, it should be split into
multiple messages of no more than 8K. Although the backbone permits
messages up to 16K in length, 8K is a more readable size. Only the
first split message may contain the ABOUT information of the site.
Each message must be given both a unique Subject field (eg: prepended
by "Part n/n") and a unique MSGID:. This because some tossers may use
either or both for dupe detection.
Limiting Number of Split Messages:
If the number of messages is greater than the preset limit of the
echo, and the FileFind Program does not have an option to forward the
replies via netmail, the replies should be discarded and the user
informed that his request may have been too amibiguous.
NetMail Reply:
The FileFind program may have an option to forward all replies via
routed netmail, or to do so under certain conditions as outlined above.
Obviously, if the FileFind program can process netmail queries, it MUST
respond via netmail.
User NetMail Reply Request:
Alternativly the user can request a netmail reply for his echomail
query by preceeding the query with either "%" or "!".
eg;
Subject: % /fsc /fts
If the FileFind program does not support this feature, it must
ignore any echomail query message that has a "%" or "!" as the first
WORD of the Subject field.
Second Reply or Extended Response Request:
The FileFind site indicates availablility of Second Reply by
placing the string 'program_name 4d_address' in the From: field of the
message.
eg: FROM: FQUERY 1:167/104.0
When a user replies to a FileFind reply, the message will be to the
FileFind program @ {network address}. When processing the FileFind
conferences, the FileFind program will treat any message to itself that
includes the site address as a Second Reply Request.
If this feature is available, the FileFind program will include up
to a maximum of 15 files (maximum 12K match list) in it's replies. If
the user wants a more detailed listing, he simply replies to the
FileFind program's reply. Only the system that posted the original
reply will respond to that new request. This second, specific reply,
will contain up to 50 files (32K of matchlist) either including or
SKIPPING the first 15. These numbers may be replaced by byte limits in
some implementations.
No Second Reply in Designated Reply Echo:
The Designated Reply Echo method does not allow replies to be made,
because the FileFind program may not be permitted to scan a Designated
Reply Echo. The FileFind program should automatically report up to 50
files for any requests. Therefore, the traffic limitaion features may
be disabled for networks that require the FileFind program to reply in
a Designated Reply Echo, and disallow Second Reply in that echo.
Disable Local Messages:
The FileFind program must be able to to disable the processing of
local messages. What this means is that the FileFind program will not
process any messages generated on that FTN site, including messages by
the sysop using an offline reader, or by a site's BBS or off-line
reader users. This should NOT exclude messages from a site's points.
Limit by Age:
The FileFind program must be configurable so that the operator can
limit the age of an query message that is acceptable for processing.
This should be in number of days. The FileFind program may be
configured to process all the FileFind requests regardless of how old
they are. Age should never be greater than 365 days.
LinkMGR Support:
Implmentors may choose to support the LinkMGR proposal for netmail
queries and commands. In this proposal, the queries and commands do
not appear in the subject field but rather, in the the BODY of the
message. The subject field wil contain the LinkMGR password.
Use of the LinkMGR method allows the user to send multiple commands
to the fIleFind program.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Implementation and Usage of FileFind Utilities.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
Document: fsc-00xx
Version: 0.6
Date Aug 30, 1995
Title: Implementation and Usage of FileFind Utilities
Authors: Robert Williamson FidoNet#1:167/104.0 robert@ecs.mtlnet.org
Intro
A portion of the document is derived from information in
AllFix.DOC by Harald Harms @ 2:281/910
with additional sections from
FQuery.DOC by Robert Williamson @ 1:167/104
The MSdos program ALLFIX by Harald Harms first introduced the idea
of searching for files via echomail. The term applied to this function
is 'FileFind'. A FileFind system allows sysops, points and BBS users
to search for files by placing a message to 'ALLFIX' in an echo
designated for the purpose of finding files. All FTN sites running a
FileFind processor which is configured to scan that echo will reply to
that user if there any files matching his query. This system provides
a method for searching many FTN sites throughout the world, with a
single message.
FileFind programs work by either scanning through defined message
bases or scanning packets for defined AREA tagnames for messages to the
default name ALLFIX. All FileFind programs MUST respond to the name
ALLFIX, but may also respond to the name FILEFIND and the name of the
particular FileFind program in use or defined for the echo. The
FileFind program will process these messages, examining the Subject
field for search queries. If any valid query is found, the FileFind
program will search the sites files database for files matching the
users's query.
If the FileFind program finds any matches, it will generate a reply
containing a list of the files found, and some basic information ABOUT
the system posting the reply. When the user who initially wrote the
request reads the reply, he will then be able to decide if any of the
reported files meet his needs, and from the ABOUT included in the
reply, learn where and how he may get those files.
FileFind Query Message Structure
To: name_of_FileFind program
The message must be addressed to ALLFIX so that all FileFind programs
can respond. To use features specific to a particular FileFind
program, or to limit the responses to a particular platform, the
message should be addressed to that program's name. Some FileFind
programs will respond to more than two names.
Subject:
A space-separated list of file specifications, keywords or quoted
strings.
keyword - single word preceeded by a '/' with no intervening spaces,
must be at least 3 characters, not including the '/'.
a keyword search is in actually a substring search of the
site's filelist.
description - string enclosed in double-quotes,
if a single word, must be more than 3 characters.
filespec - single word, no spaces, no double-quotes or preceding /,
must be at least 3 characters, not including any wildcard
or pattern matching charcaters, such as '*'.
Messages addressed to ALLFIX must not have any embedded
pattern matching characters.
The minimum number of characters for description, keyword and
filespec queries is an implementation detail of the FileFind program.
These values should be configurable, but should never be settable to
values of less than 3.
Each implementation should allow the operator the ability to
configure a list of disallowed keywords.
NetMail Queries
Some FileFind programs may also have the ability to process file
search queries received as netmail and addressed to the name of the
particular FileFInd program with this capability. In this case, all
replies are via netmail also.
NetMail Commands
FileFind Netmail commands are identifed by a leading '%'.
Implementation of netmail commands is optional. If implemented,
compliant FileFind utilities should be able to process the following
minimum NetMail command set.
%HELP - netmail only, returns an extended help text for the
FileFind program, the ABOUT of the the site and a list
of MAGIC freqable names.
%ABOUT - netmail only, returns the ABOUT of the site and a full
or %MAGIC list of MAGIC names.
%NEWFILES - netmail only, returns the NEWFILES list of the site
or %NEW via netmail.
Extended NetMail Commands:
Implementation of the following netmail commands is optional and
not required for compliance with the FileFind NetMail Command set.
%REPORT &lt;tagname&gt;
- sends a configuration report for echo <tagname>
this allows an echo moderator to check if a site running
a FileFind utility is compliant with the rules of the
filefind echo.
%REQUEST &lt;filename&gt;
- if found, will place requested file on hold for remote
site
%UUREQUEST &lt;filename&gt;
- if found, and the filesize after uuencoding is less
than 60K, it will be sent as multiple netmail messages
The Site ABOUT
Obviously, a system that neither accepts file requests nor allows
users to download on their first call should not be responding to
FileFind messages. If there are any limitations for the caller to
acquire any of the files that the site has advertised as being
available in it's FileFind response, these limitations MUST be listed
in the reply. This information should be included in the ABOUT file
that the FileFind program user creates.
The site ABOUT should contain the following information. The
FileFind program implementor should instruct his users on these
requirements.
- sitename
- site operator's name
- complete phonenumber
- baud rate
- hours during which filerequests are accepted, if at all
- hours during which users can download
- conditions for file requests and user downloads
NOTE: the above information should be within the first 14 lines.
optional:
- a list a MAGIC names
- an indication if magic names are also available to terminal users.
Searching for Files and Creating Replies
The method used by the FileFind program to search for requests is
up to the implementor. However, if searching a list, the FileFind
program should confirm the actual existance of all files that match the
query specification.
The FileFind program should only process description strings,
filespecs or keywords that contain more than 3 valid characters and
should have configuration options to define greater minimum lengths on
a per-echo basis.
For filespecs, the wildcard character '*' IS considered a valid
specification as well as the '?' wildcard, but only the '?' is to be
counted as a character when determining the length of query. File
extensions are not necessary and any characters AFTER a '*' are to be
ignored. The FileFind program should be configurable so as to allow
replacement all of the file extensions with '.*' or '#?' dependant on
platform. This results in queries being independant of the various
archivers in use.
Replies
Replies created by FileFind utilities are expected to be in
compliance with the following FTN specifications:
FTS-0001 - packed message format
FTS-0009 - MSGID/REPLY
FSC-0046 - PID and tear line
In addition, a FileFind utility may use the FID: control line for
any information needed that cannot be put in a PID: without violating
that specification.
^AFID: ascii text CR
Must be less than 80 characters including ^A and terminating CR.
There are three ways in which the FileFind program can create replies:
- write the replies in the echo in which the query appeared.
- write the replies in an echo that has been specifically
designated for that purpose in the particular FTN or for
a gorup of echos in that FTN.
- reply via routed netmail.
Since each FTN site connected to a particular FileFind program area
is capable of creating an information reply, there is much concern as
to the amount of traffic that can be generated, FileFind program
developers must be sensitive to these concerns by providing the means
to their users to limit the traffic on a per-echo basis. For example,
various FileFind echos have rules limiting the size or number of
replies, or the length of the system information that may be included
in a reply.
Limiting replies
It is strongly suggested that some default limitations be built-in.
Limiting Site Header (ABOUT):
If the site's ABOUT, (the text that has been configured in order to
add the system's information and Magic names list to the reply), is
greater than 14 lines, the remainder should NOT be posted. A line
should be added to the response indicated this, and the user may be
invited to either Freq or download the MAGIC name's ABOUT or MAGIC, for
a full list of magic names. The FileFind program may optionally send
the full system information and magic name list via routed netmail.
Limiting Match List due to ambiguity of query:
If the list of matches (note: not the size of the message itself)
is greater than 32K, the FileFind program should post a message to the
user to indicate that his query may have been too ambiguous and perhaps
invite him to freq or download the MAGIC name FILES for a full list.
Splitting Match List into Multiple Messages:
If the list of matches is greater than 10K, it should be split into
multiple messages of no more than 8K. Although the backbone permits
messages up to 16K in length, 8K is a more readable size. Only the
first split message may contain the ABOUT information of the site.
Each message must be given both a unique Subject field (eg: prepended
by "Part n/n") and a unique MSGID:. This because some tossers may use
either or both for dupe detection.
Limiting Number of Split Messages:
If the number of messages is greater than the preset limit of the
echo, and the FileFind Program does not have an option to forward the
replies via netmail, the replies should be discarded and the user
informed that his request may have been too amibiguous.
NetMail Reply:
The FileFind program may have an option to forward all replies via
routed netmail, or to do so under certain conditions as outlined above.
Obviously, if the FileFind program can process netmail queries, it MUST
respond via netmail.
User NetMail Reply Request:
Alternativly the user can request a netmail reply for his echomail
query by preceeding the query with either "%" or "!".
eg;
Subject: % /fsc /fts
If the FileFind program does not support this feature, it must
ignore any echomail query message that has a "%" or "!" as the first
WORD of the Subject field.
Second Reply or Extended Response Request:
The FileFind site indicates availablility of Second Reply by
placing the string 'program_name 4d_address' in the From: field of the
message.
eg: FROM: FQUERY 1:167/104.0
When a user replies to a FileFind reply, the message will be to the
FileFind program @ {network address}. When processing the FileFind
conferences, the FileFind program will treat any message to itself that
includes the site address as a Second Reply Request.
If this feature is available, the FileFind program will include up
to a maximum of 15 files (maximum 12K match list) in it's replies. If
the user wants a more detailed listing, he simply replies to the
FileFind program's reply. Only the system that posted the original
reply will respond to that new request. This second, specific reply,
will contain up to 50 files (32K of matchlist) either including or
SKIPPING the first 15. These numbers may be replaced by byte limits in
some implementations.
No Second Reply in Designated Reply Echo:
The Designated Reply Echo method does not allow replies to be made,
because the FileFind program may not be permitted to scan a Designated
Reply Echo. The FileFind program should automatically report up to 50
files for any requests. Therefore, the traffic limitaion features may
be disabled for networks that require the FileFind program to reply in
a Designated Reply Echo, and disallow Second Reply in that echo.
Disable Local Messages:
The FileFind program must be able to to disable the processing of
local messages. What this means is that the FileFind program will not
process any messages generated on that FTN site, including messages by
the sysop using an offline reader, or by a site's BBS or off-line
reader users. This should NOT exclude messages from a site's points.
Limit by Age:
The FileFind program must be configurable so that the operator can
limit the age of an query message that is acceptable for processing.
This should be in number of days. The FileFind program may be
configured to process all the FileFind requests regardless of how old
they are. Age should never be greater than 365 days.
LinkMGR Support:
Implmentors may choose to support the LinkMGR proposal for netmail
queries and commands. In this proposal, the queries and commands do
not appear in the subject field but rather, in the the BODY of the
message. The subject field wil contain the LinkMGR password.
Use of the LinkMGR method allows the user to send multiple commands
to the fIleFind program.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

773
html/misc/fileid.html
View File

@@ -1,386 +1,387 @@
<HTML>
<HEAD>
<TITLE>FILE_ID.DIZ Information.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
FILEID.TXT v1.8 by Richard Holler [CIS 73567,1547]
Last Revision 05/05/94
This text file was prepared at the request of the ASP (Association of
Shareware Professionals), but the information contained in it may be of
value to any shareware author.
FILE_ID.DIZ INFORMATION
-----------------------
Basically, the FILE_ID.DIZ file is a straight ASCII text file, distributed
inside your distribution archive file along with your program files, which
contains a description of your program. This file will be used by most BBS
(Bulletin Board System) softwares for the online file description of your
file. We recommend that the FILE_ID.DIZ file be used in all of your
distribution archives.
This text file contains a description of the FILE_ID.DIZ file, as well as a
description of the recommended distribution archive format.
WHY SHOULD YOU USE FILE_ID.DIZ?
-------------------------------
The use of this file will insure that the online description of your
program will be in your own words (and who better to describe your program
than yourself?), and that it will remain the same no matter how many
different people upload your file to various BBS systems.
As more and more BBS software makes use of this file, you can be assured
that your own description will replace such online descriptions as "Cool
Program" or "OK utility, but needs better ..."
Please note that the ASP Hub Network, the Author Direct FDN (File
Distribution Network), and the majority of other electronic distribution
services *REQUIRE* that a valid FILE_ID.DIZ file be contained in your
submitted distribution archive. If your file doesn't contain a valid
FILE_ID.DIZ file, then it simply won't be distributed by these services.
Furthermore, most BBS sysops will not accept uploads of files which do not
contain a valid FILE_ID.DIZ file, so you automatically lose out on that
distribution as well.
DESCRIPTION:
------------
FILE_ID.DIZ was created by Clark Development for use with their PCBDescribe
utility, as a means for BBS callers to upload a file without having to
manually type in a file description. It also ensures that the online
description is always the same regardless of the number of different BBS
systems the file is posted on. It has since been accepted by the BBS
industry more-or-less as the "standard" file description source. (The
extension of "DIZ" actually stands for "Description In Zip").
NOTE: The FILE_ID.DIZ file *MUST* be named exactly that, and *NOT*
something like <filename>.DIZ. It will *ONLY* be used if it is named
FILE_ID.DIZ!
The FILE_ID.DIZ file is nothing more than a straight ASCII text file which
contains the full description of the archived file containing it. It is
used by most popular BBS software to describe your program, rather than
using the description supplied by the person that uploaded your file. It
should be placed *INSIDE* your distribution archive file.
The BBS software will "look" inside the archive file. If a FILE_ID.DIZ file
is found, it will replace any existing online file description with the
text contained in FILE_ID.DIZ. It is an excellent method for making sure
that your program files are described the way that "you" want them
described. Even sysops who's software can't automatically make use of the
FILE_ID.DIZ file have found it to be an excellent source for their manually
added file descriptions.
STRUCTURE:
----------
The file consists of straight ASCII text, up to 10 lines of text, each line
being no more than 45 characters long. It should *NOT* contain any blank
lines, any form of centering or formatting, or any Hi-ASCII or ANSI
characters. (i.e. it should ONLY contain alpha & numeric characters).
We recommended that it consist of 5 basic parts:
1. the proper name of your program
2. the version number
3. the "ASP" identifier (optional, for ASP members)
4. the description separator
4. the description
All of the above parts should be separated by a single "space".
PROGRAM NAME: To set it apart from the rest, it is recommended that you use
ALL CAPS for the program name.
VERSION NUMBER: The version number should be in the form of "v12.34".
ASP IDENTIFIER: If you are an ASP author, we recommend that an "<ASP>"
identifying mark be added after the version number, to identify your
product as an ASP-authored product.
DESCRIPTION SEPARATOR: To separate the actual description text, insert a
simple "-" (dash/minus) character after the ASP identifier (or version
number, if not using the ASP identifier), and in front of the description
text.
DESCRIPTION: You should attempt to FULLY describe your product, including
its most important functions and features. Be sure to include anything
which will separate your program from it's competition, and make the BBS
user want to download your file. Also try to include any hardware or
software requirements that your product may have.
You should try to use the first 2 lines of the text to give a basic
description of your program. This is helpful for sysops who's BBS software
limits them to less than 10 lines, 45 characters. Sysops who are limited to
using shorter descriptions can simply use the 1st two lines and truncate
the rest. Thus, you can basically still supply your own description for BBS
software which does not actually utilize the FILE_ID.DIZ feature.
The remaining lines of text can be used to elaborate on the programs
features, enhancements from the prior version, information concerning
multi-file sets. Please note that older versions of some BBS software can
only use 8 lines of text. It is advisable that you create your FILE_ID.DIZ
file so that the file can be truncated to various line lengths without
destroying it's usefulness.
EXAMPLE
-------
MY PROGRAM v1.23 <ASP> - A program which will
do anything for anybody. Will run in only 2k
of memory. Can be run from the command line,
or installed as a TSR. Completely menu-
driven. Version 1.23 reduces the previous 4k
memory requirements, and adds an enhanced
graphical user interface. Also, MY PROGRAM
now contains Windows and DESQview support.
Coming soon - an OS/2 version.
From Do-It-All Software, Inc. $15.00
MULTIPLE DISK INFO
------------------
Please note that if your distribution archive requires multiple archive
files, you should create a separate, specific FILE_ID.DIZ file for each
archive. This can be utilized to describe the various contents of each
archive, and to identify each disk in the set. For example, the FILE_ID.DIZ
file for disk #1 could contain:
"MY PROGRAM v1.23 <ASP> Program Executable
Files - Disk 1 of 2"
[followed by detailed description text]
while the FILE_ID.DIZ file for disk #2 could contain:
"MY PROGRAM v1.23 <ASP> Documentation Files -
Disk 2 of 2"
[followed by more detailed description text]
Optionally, you could also create a "complete" FILE_ID.DIZ file for the
first disk, which would fully describe the program in detail, and identify
it as Disk 1 of x. Then, for each remaining file in the set, simply include
the Program Name, version number, ASP identifier, and the disk number (i.e.
"MY PROGRAM v1.23 <ASP> Disk 2 of x").
ADDITIONAL INFO
---------------
Please don't be tempted to use fancy graphic or ANSI sequences in the
FILE_ID.DIZ file, as most BBS software will not allow this, and will render
your FILE_ID.DIZ file useless. Also, don't be tempted to simply copy your
program description file to FILE_ID.DIZ. Attempting to "format" your
FILE_ID.DIZ file (i.e line centering, right & left justification, etc) will
also cause unexpected results, especially for BBS software which re-formats
descriptions to other than 10line/45char.
Fred Hill <ASP> has written a freeware utility which interactively creates
a valid FILE_ID.DIZ file. The file is called DIZGEN.ZIP and can be found on
CompuServe (GO IBMBBS, Library 2) as well as on many fine BBS systems. I
highly recommend that you download a copy of this wonderful utility for
creating your FILE_ID.DIZ files.
<*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*>
The following is a recommendation for the structure and contents of
distribution archives prepared for use on BBS systems.
DISTRIBUTION DISK RECOMMENDATIONS
---------------------------------
The following are recommendations for preparing your program files for
distribution to Bulletin Board Systems (BBSs) via the ASP's distribution
services, as well as other methods.
Two varieties of program files are defined here:
1) Program files which utilize an "install" utility and self-extracting
program archives (later referred to as "Author-Installed Programs").
2) Programs files which do not use install utilities or self-extracting
archives (later referred to as "User-Installed Programs").
AUTHOR-INSTALLED PROGRAMS:
--------------------------
These programs require a bit more work from the author, but will eliminate
many user mistakes, especially in programs which require complicated
setups.
Most "installation" utility programs will make use of program files which
have been "archived" into Self-Extracting (SFX) archives. We will attempt
to define which files should be contained in the Self-Extracting archives,
and which files should not.
1. Files which should be contained in the self-extracting program file
archive:
a. All program-specific executable files.
b. Any required configuration and/or data files required by the
program.
c. Program documentation files. Optionally, these may be left
outside of the self-extracting archive, in order to allow
them to be viewed/read by the various archive viewing utlities.
d. Any other program-specific files that are required for the
operation of the program.
2. The files described above should be compiled into a self-extracting
archive file, which will then be extracted by the install utility.
NOTE: the author is required to abide by any distribution requirements
specified by the archive utility author, and to obtain any required
distribution rights necessary. Please check to see if distribution rights
are required for your archive utility choice.
3. Files which should NOT be contained in the self-extracting program file
archive:
a. The install utility itself (obviously).
b. The FILE_ID.DIZ file. (described in detail in the section
preceding this one)
c. Any distribution/information files, such as VENDOR.TXT,
SYSOP.TXT, etc.
d. Any description or information file, such as DESCRIBE.TXT.
e. A user file (such as README.1ST), which should explain how
to use the install utility, what the user should expect
during the installation, and any preparation that the user
should make prior to the installation. This file might also
contain a brief description of your program, in case the user
is able to read the documentation files in the distribution
archive prior to downloading (many BBS systems offer this
ability to the user).
4. The actual distribution archive file (described below) should then
contain the install utility, the self-extracting program archive, and the
files described in #3 above.
USER-INSTALLED PROGRAMS:
------------------------
This type of distribution archive is much simpler than the Author-Installed
variety. It should simply be an archive file, containing all of the files
for the program described above.
Since this type of program requires the user to do all of the installation
manually, it should contain very specific and detailed information
regarding the installation requirements (such as INSTALL.TXT).
THE DISTRIBUTION ARCHIVE FILE:
------------------------------
The actual distribution archive file should merely be an archive file
containing the files described above. For BBS distribution, this archive
should be of the standard archive format, and -NOT- a self-extracting
archive. Many sysops will not allow self-extracting archives, and most BBS
software will not allow self-extracting archives to be uploaded.
There are many popular archive utilities available, such as PKZIP, LHA,
LHARC, ARJ, etc. Most BBS systems are capable of handling archives in
virtually any format. However, you should be aware that most BBS systems
will convert your archive format to the format of choice by the sysop. By
following the methods described above, this conversion process should not
affect your program, or any self-extracting files which are contained
within your distribution archive file.
You should also retain the default archive file extension defined by the
archive utility. For example, PKZIP uses a ".ZIP", LHARC uses "LZH", etc.
Changing the file extension may cause the BBS software to delete your file
because it doesn't recognize the format.
For the actual filename for your distribution archive, it is recommended
that the program filename be limited to 6 characters to represent the
program's name (i.e. MYPROG could represent "My Program"). This should be
followed by 2 numeric digits which will represent the version number of
your release. Even if this is your initial release it should include the
version number in the filename (i.e. MYPROG10.ZIP would indicate the
program called "My Program" version 1.0).
Please note that CompuServe limits filenames to only 6 characters. By
limiting the file "name" to 6 characters, you will easily be able to rename
the archive for CompuServe uploading by simply removing the 2-digit version
identifier, to make the file compatible with CompuServe libraries.
By including the 2-digit version number in the archive filename, it will be
very easy for both the user and the sysop (and yourself) to identify older
versions of your program.
MULTIPLE DISTRIBUTION ARCHIVES
------------------------------
At one time, it was recommended that your final distribution archive not be
larger than 350k, so that it would fit on a single 360k floppy disk and
still leave room for any distribution files necessary for Disk Vendors.
(i.e. Disk Vendors will often include their own GO.BAT file, or other
various small files to help their customers install the software). This
limitation is slowly falling by the wayside as more and more computer
systems have 3.5" floppy disk drives as standard.
If your program is large enough to require more than one distribution
archive, it is recommended that your filename be limited to 5 characters
rather than 6 as described above. Following the 5-character name should be
the same 2-digit version number. Then, append a single "letter" to identify
the disk (i.e. MYPGM10A.ZIP, MYPGM10B.ZIP, etc.). For uploading to
CompuServe, these filenames may then be shortened to 6 characters by
removing the version identifiers (i.e. MYPGMA.ZIP, MYPGMB.ZIP). However,
for CompuServe it is recommended that you simply create a single
distibution file, and eliminate the multi-part file set.
If your program requires multiple distribution archives, -BE SURE- to
create separate FILE_ID.DIZ files for each distribution archive. Also, each
FILE_ID.DIZ file should contain disk number information pertaining to each
individual archive (i.e. Disk 1 of 3, Disk 2 of 3, etc.).
THE DISTRIBUTION DISK
---------------------
It is recommended that your distribution disk simply contain a ZIPd version
of your product. However, If you choose to supply "unarchived" files on a
distribution disk for Disk Vendor use, it is _VERY_ important that you
specify in your documentation a suggested archive filename, so that BBS
sysops can create archived files with the proper author-specified
filenames. This information should be contained in your SYSOP.TXT (or
VENDOR.TXT) file. If you don't supply a suggested archive file name, the
sysops will be forced to create the name themselves, thus you may end up
with thousands of versions of your products on BBS systems all over the
world, but all with different filenames.
Please note that the ASP Hub Network, and nearly every other electronic
distribution service *REQUIRE* that your files be submitted as an archived
file, using the ZIP format. Also note that many BBS sysops will not go to
the trouble of ZIPing your unarchived files for you. If you don't supply
them with an archived distribution version of your product, it might not
get distributed by BBSs.
If you supply your own disk labels, it is recommended that the ASP logo, or
at least the initials "ASP" be included on the label, so that anyone can
immediately identify your disk as an ASP member's software.
SUMMARY
-------
Your distribution disk should now be ready to submit to the various BBSs,
distribution services, and Disk Vendors.
You may choose to create a separate distribution disk for use by BBSs and
Disk Vendors. However, if you follow the above steps in preparing your
distribution archive file, a separate "Disk Vendor" disk is probably not
necessary. The majority of disk vendors will be able to accept your
distribution file/disk if it is prepared in the above described format.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
</BODY>
</HTML>
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>FILE_ID.DIZ Information.</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<PRE>
FILEID.TXT v1.8 by Richard Holler [CIS 73567,1547]
Last Revision 05/05/94
This text file was prepared at the request of the ASP (Association of
Shareware Professionals), but the information contained in it may be of
value to any shareware author.
FILE_ID.DIZ INFORMATION
-----------------------
Basically, the FILE_ID.DIZ file is a straight ASCII text file, distributed
inside your distribution archive file along with your program files, which
contains a description of your program. This file will be used by most BBS
(Bulletin Board System) softwares for the online file description of your
file. We recommend that the FILE_ID.DIZ file be used in all of your
distribution archives.
This text file contains a description of the FILE_ID.DIZ file, as well as a
description of the recommended distribution archive format.
WHY SHOULD YOU USE FILE_ID.DIZ?
-------------------------------
The use of this file will insure that the online description of your
program will be in your own words (and who better to describe your program
than yourself?), and that it will remain the same no matter how many
different people upload your file to various BBS systems.
As more and more BBS software makes use of this file, you can be assured
that your own description will replace such online descriptions as "Cool
Program" or "OK utility, but needs better ..."
Please note that the ASP Hub Network, the Author Direct FDN (File
Distribution Network), and the majority of other electronic distribution
services *REQUIRE* that a valid FILE_ID.DIZ file be contained in your
submitted distribution archive. If your file doesn't contain a valid
FILE_ID.DIZ file, then it simply won't be distributed by these services.
Furthermore, most BBS sysops will not accept uploads of files which do not
contain a valid FILE_ID.DIZ file, so you automatically lose out on that
distribution as well.
DESCRIPTION:
------------
FILE_ID.DIZ was created by Clark Development for use with their PCBDescribe
utility, as a means for BBS callers to upload a file without having to
manually type in a file description. It also ensures that the online
description is always the same regardless of the number of different BBS
systems the file is posted on. It has since been accepted by the BBS
industry more-or-less as the "standard" file description source. (The
extension of "DIZ" actually stands for "Description In Zip").
NOTE: The FILE_ID.DIZ file *MUST* be named exactly that, and *NOT*
something like &lt;filename&gt;.DIZ. It will *ONLY* be used if it is named
FILE_ID.DIZ!
The FILE_ID.DIZ file is nothing more than a straight ASCII text file which
contains the full description of the archived file containing it. It is
used by most popular BBS software to describe your program, rather than
using the description supplied by the person that uploaded your file. It
should be placed *INSIDE* your distribution archive file.
The BBS software will "look" inside the archive file. If a FILE_ID.DIZ file
is found, it will replace any existing online file description with the
text contained in FILE_ID.DIZ. It is an excellent method for making sure
that your program files are described the way that "you" want them
described. Even sysops who's software can't automatically make use of the
FILE_ID.DIZ file have found it to be an excellent source for their manually
added file descriptions.
STRUCTURE:
----------
The file consists of straight ASCII text, up to 10 lines of text, each line
being no more than 45 characters long. It should *NOT* contain any blank
lines, any form of centering or formatting, or any Hi-ASCII or ANSI
characters. (i.e. it should ONLY contain alpha &amp; numeric characters).
We recommended that it consist of 5 basic parts:
1. the proper name of your program
2. the version number
3. the "ASP" identifier (optional, for ASP members)
4. the description separator
4. the description
All of the above parts should be separated by a single "space".
PROGRAM NAME: To set it apart from the rest, it is recommended that you use
ALL CAPS for the program name.
VERSION NUMBER: The version number should be in the form of "v12.34".
ASP IDENTIFIER: If you are an ASP author, we recommend that an "<ASP>"
identifying mark be added after the version number, to identify your
product as an ASP-authored product.
DESCRIPTION SEPARATOR: To separate the actual description text, insert a
simple "-" (dash/minus) character after the ASP identifier (or version
number, if not using the ASP identifier), and in front of the description
text.
DESCRIPTION: You should attempt to FULLY describe your product, including
its most important functions and features. Be sure to include anything
which will separate your program from it's competition, and make the BBS
user want to download your file. Also try to include any hardware or
software requirements that your product may have.
You should try to use the first 2 lines of the text to give a basic
description of your program. This is helpful for sysops who's BBS software
limits them to less than 10 lines, 45 characters. Sysops who are limited to
using shorter descriptions can simply use the 1st two lines and truncate
the rest. Thus, you can basically still supply your own description for BBS
software which does not actually utilize the FILE_ID.DIZ feature.
The remaining lines of text can be used to elaborate on the programs
features, enhancements from the prior version, information concerning
multi-file sets. Please note that older versions of some BBS software can
only use 8 lines of text. It is advisable that you create your FILE_ID.DIZ
file so that the file can be truncated to various line lengths without
destroying it's usefulness.
EXAMPLE
-------
MY PROGRAM v1.23 &lt;ASP&gt; - A program which will
do anything for anybody. Will run in only 2k
of memory. Can be run from the command line,
or installed as a TSR. Completely menu-
driven. Version 1.23 reduces the previous 4k
memory requirements, and adds an enhanced
graphical user interface. Also, MY PROGRAM
now contains Windows and DESQview support.
Coming soon - an OS/2 version.
From Do-It-All Software, Inc. $15.00
MULTIPLE DISK INFO
------------------
Please note that if your distribution archive requires multiple archive
files, you should create a separate, specific FILE_ID.DIZ file for each
archive. This can be utilized to describe the various contents of each
archive, and to identify each disk in the set. For example, the FILE_ID.DIZ
file for disk #1 could contain:
"MY PROGRAM v1.23 &lt;ASP&gt; Program Executable
Files - Disk 1 of 2"
[followed by detailed description text]
while the FILE_ID.DIZ file for disk #2 could contain:
"MY PROGRAM v1.23 &lt;ASP&gt; Documentation Files -
Disk 2 of 2"
[followed by more detailed description text]
Optionally, you could also create a "complete" FILE_ID.DIZ file for the
first disk, which would fully describe the program in detail, and identify
it as Disk 1 of x. Then, for each remaining file in the set, simply include
the Program Name, version number, ASP identifier, and the disk number (i.e.
"MY PROGRAM v1.23 &lt;ASP&gt; Disk 2 of x").
ADDITIONAL INFO
---------------
Please don't be tempted to use fancy graphic or ANSI sequences in the
FILE_ID.DIZ file, as most BBS software will not allow this, and will render
your FILE_ID.DIZ file useless. Also, don't be tempted to simply copy your
program description file to FILE_ID.DIZ. Attempting to "format" your
FILE_ID.DIZ file (i.e line centering, right &amp; left justification, etc) will
also cause unexpected results, especially for BBS software which re-formats
descriptions to other than 10line/45char.
Fred Hill &lt;ASP&gt; has written a freeware utility which interactively creates
a valid FILE_ID.DIZ file. The file is called DIZGEN.ZIP and can be found on
CompuServe (GO IBMBBS, Library 2) as well as on many fine BBS systems. I
highly recommend that you download a copy of this wonderful utility for
creating your FILE_ID.DIZ files.
==========================================================================
The following is a recommendation for the structure and contents of
distribution archives prepared for use on BBS systems.
DISTRIBUTION DISK RECOMMENDATIONS
---------------------------------
The following are recommendations for preparing your program files for
distribution to Bulletin Board Systems (BBSs) via the ASP's distribution
services, as well as other methods.
Two varieties of program files are defined here:
1) Program files which utilize an "install" utility and self-extracting
program archives (later referred to as "Author-Installed Programs").
2) Programs files which do not use install utilities or self-extracting
archives (later referred to as "User-Installed Programs").
AUTHOR-INSTALLED PROGRAMS:
--------------------------
These programs require a bit more work from the author, but will eliminate
many user mistakes, especially in programs which require complicated
setups.
Most "installation" utility programs will make use of program files which
have been "archived" into Self-Extracting (SFX) archives. We will attempt
to define which files should be contained in the Self-Extracting archives,
and which files should not.
1. Files which should be contained in the self-extracting program file
archive:
a. All program-specific executable files.
b. Any required configuration and/or data files required by the
program.
c. Program documentation files. Optionally, these may be left
outside of the self-extracting archive, in order to allow
them to be viewed/read by the various archive viewing utlities.
d. Any other program-specific files that are required for the
operation of the program.
2. The files described above should be compiled into a self-extracting
archive file, which will then be extracted by the install utility.
NOTE: the author is required to abide by any distribution requirements
specified by the archive utility author, and to obtain any required
distribution rights necessary. Please check to see if distribution rights
are required for your archive utility choice.
3. Files which should NOT be contained in the self-extracting program file
archive:
a. The install utility itself (obviously).
b. The FILE_ID.DIZ file. (described in detail in the section
preceding this one)
c. Any distribution/information files, such as VENDOR.TXT,
SYSOP.TXT, etc.
d. Any description or information file, such as DESCRIBE.TXT.
e. A user file (such as README.1ST), which should explain how
to use the install utility, what the user should expect
during the installation, and any preparation that the user
should make prior to the installation. This file might also
contain a brief description of your program, in case the user
is able to read the documentation files in the distribution
archive prior to downloading (many BBS systems offer this
ability to the user).
4. The actual distribution archive file (described below) should then
contain the install utility, the self-extracting program archive, and the
files described in #3 above.
USER-INSTALLED PROGRAMS:
------------------------
This type of distribution archive is much simpler than the Author-Installed
variety. It should simply be an archive file, containing all of the files
for the program described above.
Since this type of program requires the user to do all of the installation
manually, it should contain very specific and detailed information
regarding the installation requirements (such as INSTALL.TXT).
THE DISTRIBUTION ARCHIVE FILE:
------------------------------
The actual distribution archive file should merely be an archive file
containing the files described above. For BBS distribution, this archive
should be of the standard archive format, and -NOT- a self-extracting
archive. Many sysops will not allow self-extracting archives, and most BBS
software will not allow self-extracting archives to be uploaded.
There are many popular archive utilities available, such as PKZIP, LHA,
LHARC, ARJ, etc. Most BBS systems are capable of handling archives in
virtually any format. However, you should be aware that most BBS systems
will convert your archive format to the format of choice by the sysop. By
following the methods described above, this conversion process should not
affect your program, or any self-extracting files which are contained
within your distribution archive file.
You should also retain the default archive file extension defined by the
archive utility. For example, PKZIP uses a ".ZIP", LHARC uses "LZH", etc.
Changing the file extension may cause the BBS software to delete your file
because it doesn't recognize the format.
For the actual filename for your distribution archive, it is recommended
that the program filename be limited to 6 characters to represent the
program's name (i.e. MYPROG could represent "My Program"). This should be
followed by 2 numeric digits which will represent the version number of
your release. Even if this is your initial release it should include the
version number in the filename (i.e. MYPROG10.ZIP would indicate the
program called "My Program" version 1.0).
Please note that CompuServe limits filenames to only 6 characters. By
limiting the file "name" to 6 characters, you will easily be able to rename
the archive for CompuServe uploading by simply removing the 2-digit version
identifier, to make the file compatible with CompuServe libraries.
By including the 2-digit version number in the archive filename, it will be
very easy for both the user and the sysop (and yourself) to identify older
versions of your program.
MULTIPLE DISTRIBUTION ARCHIVES
------------------------------
At one time, it was recommended that your final distribution archive not be
larger than 350k, so that it would fit on a single 360k floppy disk and
still leave room for any distribution files necessary for Disk Vendors.
(i.e. Disk Vendors will often include their own GO.BAT file, or other
various small files to help their customers install the software). This
limitation is slowly falling by the wayside as more and more computer
systems have 3.5" floppy disk drives as standard.
If your program is large enough to require more than one distribution
archive, it is recommended that your filename be limited to 5 characters
rather than 6 as described above. Following the 5-character name should be
the same 2-digit version number. Then, append a single "letter" to identify
the disk (i.e. MYPGM10A.ZIP, MYPGM10B.ZIP, etc.). For uploading to
CompuServe, these filenames may then be shortened to 6 characters by
removing the version identifiers (i.e. MYPGMA.ZIP, MYPGMB.ZIP). However,
for CompuServe it is recommended that you simply create a single
distibution file, and eliminate the multi-part file set.
If your program requires multiple distribution archives, -BE SURE- to
create separate FILE_ID.DIZ files for each distribution archive. Also, each
FILE_ID.DIZ file should contain disk number information pertaining to each
individual archive (i.e. Disk 1 of 3, Disk 2 of 3, etc.).
THE DISTRIBUTION DISK
---------------------
It is recommended that your distribution disk simply contain a ZIPd version
of your product. However, If you choose to supply "unarchived" files on a
distribution disk for Disk Vendor use, it is _VERY_ important that you
specify in your documentation a suggested archive filename, so that BBS
sysops can create archived files with the proper author-specified
filenames. This information should be contained in your SYSOP.TXT (or
VENDOR.TXT) file. If you don't supply a suggested archive file name, the
sysops will be forced to create the name themselves, thus you may end up
with thousands of versions of your products on BBS systems all over the
world, but all with different filenames.
Please note that the ASP Hub Network, and nearly every other electronic
distribution service *REQUIRE* that your files be submitted as an archived
file, using the ZIP format. Also note that many BBS sysops will not go to
the trouble of ZIPing your unarchived files for you. If you don't supply
them with an archived distribution version of your product, it might not
get distributed by BBSs.
If you supply your own disk labels, it is recommended that the ASP logo, or
at least the initials "ASP" be included on the label, so that anyone can
immediately identify your disk as an ASP member's software.
SUMMARY
-------
Your distribution disk should now be ready to submit to the various BBSs,
distribution services, and Disk Vendors.
You may choose to create a separate distribution disk for use by BBSs and
Disk Vendors. However, if you follow the above steps in preparing your
distribution archive file, a separate "Disk Vendor" disk is probably not
necessary. The majority of disk vendors will be able to accept your
distribution file/disk if it is prepared in the above described format.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

3
html/misc/ipmailer.html
View File

@@ -1,4 +1,5 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>Integration of IP-Nodes in the nodelist.</TITLE>
</HEAD>
@@ -165,7 +166,7 @@ Future developments might make additions necessary, if they can not
be expressed with the existing set of flags as defined by this FSP.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>

27
html/misc/jam.html
View File

@@ -1,4 +1,5 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>JAM Message Base Proposal.</TITLE>
</HEAD>
@@ -133,7 +134,7 @@ Co-Authors..: Andrew Milner, Mats Birch, Mats Wallin
the .JHR file.
FixedHeaderInfoStruct:
ulong Signature; // <J><A><M> followed by <NUL>
ulong Signature; // &lt;J&gt;&lt;A&gt;&lt;M&gt; followed by &lt;NUL&gt;
ulong datecreated; // Creation date
ulong modcounter; // Update counter
ulong activemsgs; // Number of active (not deleted) msgs
@@ -170,7 +171,7 @@ Co-Authors..: Andrew Milner, Mats Birch, Mats Wallin
MessageHeader:
MessageFixedHeader:
ulong Signature; // <J><A><M> followed by <NUL>
ulong Signature; // &lt;J&gt;&lt;A&gt;&lt;M&gt; followed by &lt;NUL&gt;
ushort Revision; // Revision level of header (1)
ushort ReservedWord; // Reserved for future use
ulong SubfieldLen; // Length of subfields (2)
@@ -289,7 +290,7 @@ Co-Authors..: Andrew Milner, Mats Birch, Mats Wallin
This is also referred to as ^aVia information in FTNs. It contains
information about a system which the message has travelled through.
The format of the field is <YYYYMMDDHHMMSS><Network address> where:
The format of the field is &lt;YYYYMMDDHHMMSS&gt;&lt;Network address&gt; where:
YYYY is the year (1992-9999)
MM is the month (01-12)
@@ -314,7 +315,7 @@ Co-Authors..: Andrew Milner, Mats Birch, Mats Wallin
ID=10, Name=ENCLOSEDFILEWALIAS
Identical to ENCLOSEDFILE with the exception that the filename is
followed by a <NUL> (00H) and an alias filename to be transmited to
followed by a &lt;NUL&gt; (00H) and an alias filename to be transmited to
the remote system in place of the local name of the file.
@@ -325,8 +326,8 @@ Co-Authors..: Andrew Milner, Mats Birch, Mats Wallin
regarded as an update file request. If this subfield is present in a
message header, the ATTRIBUTE must include the MSG_FILEREQUEST bit.
To indicate that a password is to be transmitted along with the
request, a <NUL> (00H) character followed by the password is
appended. E.g. SECRET*.*<NUL>MYPASSWORD.
request, a &lt;NUL&gt; (00H) character followed by the password is
appended. E.g. SECRET*.*&lt;NUL&gt;MYPASSWORD.
ID=12, Name=ENCLOSEDFILEWCARD
@@ -342,7 +343,7 @@ Co-Authors..: Andrew Milner, Mats Birch, Mats Wallin
One or more files attached to the message. The filename points to an
ASCII file with one filename entry per line. If alias filenames are
to be used, they are specified after the actual filename and
separated by a <NUL> (00H) character, e.g. C:\MYFILE.LZH<NUL>NEWS.
separated by a &lt;NUL&gt; (00H) character, e.g. C:\MYFILE.LZH&lt;NUL&gt;NEWS.
Wildcard characters are not allowed.
@@ -442,7 +443,7 @@ Co-Authors..: Andrew Milner, Mats Birch, Mats Wallin
MSG_ESCAPED bit enabled, in which case the legal range of data is 20H
through 7eH.
An escaped character is stored as \<hex> where <hex> is the two digit
An escaped character is stored as \&lt;hex&gt; where &lt;hex&gt; is the two digit
hexadecimal ASCII value of the character. A single \ is stored as \\
or \5C. The case of the hexadecimal ASCII value is irrelevant, i.e.
5c is treated as 5C.
@@ -556,13 +557,13 @@ Co-Authors..: Andrew Milner, Mats Birch, Mats Wallin
In the description of the different fields below, the following
messages and message numbers will be referred to:
1 -> 2 -> 4 -> 5
1 -&gt; 2 -&gt; 4 -&gt; 5
: :
: +--> 8
: +--&gt; 8
:
+--> 3 -> 7
+--&gt; 3 -&gt; 7
:
+--> 6
+--&gt; 6
Message number two, three, and six are replies to message number one.
Message number four and eight are replies to message number two.
@@ -631,7 +632,7 @@ Co-Authors..: Andrew Milner, Mats Birch, Mats Wallin
Sweden mw@fido.lu
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35">Go Back</A>
</BODY>
</HTML>

3
html/misc/usleep.html
View File

@@ -1,4 +1,5 @@
<HTML>
<!-- $Id$ -->
<HEAD>
<TITLE>System load and the usleep() call.</TITLE>
</HEAD>
@@ -54,7 +55,7 @@ Michiel.
</PRE>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0">Go Back</A>
</BODY>
</HTML>