Date : Sun, 24 May 1987 13:19:40 EDT
From : "Keith B. Petersen" (WSMR|towson) <w8sdz@BRL.ARPA>
Subject: FOG standards defined
From F.O.G., the First Osborne Group, we receive the following set of
standards. There are some inaccuracies in this file and my next
message will be a response to them.
Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie Mail: W8SDZ
RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST)
--cut-here--STANDARD.FOG--cut-here--
Report from FOG
Solution for a Major Problem
by Gale Rhoades
In recent weeks, the FOG office staff has been trying to sort through a
variety of submissions. Some have been uploaded to FOG #6 (or #1) and
some have arrived on disk. The problems we've encountered surpass my
ability to describe.
We have files which have been sQueezed, crunched, ARChived or LiBRaried
and we have files which apparently have gone through a combination of
compression programs.
We have filenames with characters which are reserved under MS-DOS and
filenames with characters which are reserved under CP/M. (Reserved
characters are those which the operating system will not permit you to
use when naming a file.) We have CP/M files on MS-DOS formatted disks
and MS-DOS files on CP/M formatted disks. And we have the most horren-
dous assortment of combinations. How some of it was accomplished is
totally beyond me!
Enough is enough. Jack and I are spending hours trying to get at some
of these files and we just do not have the time to continue doing this.
Well, at least not if you want to continue to see the FOG publications,
new library releases and all the other services which are provided by
the FOG staff.
We have therefore developed some guidelines for submitting material to
the FOG libraries and publications. Exceptions will be considered but
please check with us in advance. We are willing to listen to suggestions
for modifications to these guidelines but only if they are presented in
an organized and well-considered manner. As a secondary goal, I would
hope that FOG can facilitate the standardization of filenames and com-
pression programs.
Additionally, these guidelines are subject to revision as the authors of
industry-standard utilities develop the tools which will eliminate some
of the specific problems outlined below.
The Guidelines
It would be very foolish to perpetuate the argument that CP/M and MS-DOS
are separate and distinct. Far too many users find themselves switching
between MS-DOS and CP/M machines. Some have one machine at work and the
other at home. Others have both sitting side-by-side.
Legal Filenames: Filenames may contain only the characters listed below:
! (exclamation mark)
# (pound, number, or hash symbol)
% (percent)
& (ampersand)
' (apostrophe)
( (open or left parenthesis)
) (close or right parenthesis)
- (hyphen, dash, or minus)
@ (at symbol)
0 through 9
A through Z (upper case only!)
^ (caret or circumflex)
` (back quote)
{ (open or left brace or curly bracket)
} (close or right brace or curly bracket)
~ (tilde)
It is true that both MS-DOS and CP/M permit filenames to include char-
acters other than those listed above. This list includes only those
haracters which we have found to be generally acceptable to both opera-
ting systems. Note that a few of these characters are partially reserved
through common usage.
For example, "Q" as the second letter of a file extension indicates that
the file has been sQueezed. NEVER use it otherwise. "Z" as the second
letter of a file extension indicates that the file has been crunched.
Again, NEVER use it unless the file has indeed been crunched.
The characters are listed in ascending ASCII order. The first nine often
are used to place files at the head of a sorted directory because they
have ASCII values less than that of a "0" or an "A".
Utility Programs: These are the programs which compress files (to con-
serve disk space) or which collect several files under a single filename.
1. SQueezed files (those with a "Q" as the second letter of a file ex-
tension) must be compatible with Dave Rand's NewSWeeP (version 2.07
in CP/M or 1.018 in MS-DOS, both of which use Richard Greenlaw's SQ
algorithm). I have yet to see a correctly named file which will not
unsQueeze with NSWP. SQueezed files generally save approximately
30-35%.
Text files which are of use to both CP/M and MS-DOS users should only be
sQueezed.
2. LiBRaried files (those with the extension .LBR) are a collection of
several related files. Often libraries include files which have been
sQueezed. This combination is both acceptable and desirable as a
savings of 10-50% is realized.
Additionally, there are fully debugged utilities which will allow one-
step viewing and extraction from .LBR files and these files are equally
usable on either MS-DOS or CP/M systems. Generally these files are
created on CP/M systems.
3. ARChived files (those with the extension of either .ARC or .ARK) are
files which contain related files. ARC is particularly nice because
it is possible, in a single step, to both condense and collect. Cur-
rently ARC files are created reliably only on MS-DOS systems but the
contents can be extracted with ease on either a CP/M or MS-DOS system.
The established standard is to use .ARC as the extension when the file
contains programs and related files specific to MS-DOS systems. Most
MS-DOS shareware and public domain software is distributed (on the Remote
Systems) in .ARC files. Files w ith the extension .ARK are specific to
CP/M systems. ARC512 is the standard which FOG is supporting.
Things to Avoid: These are the things which have caused major problems,
especially lately.
1. ALL crunch programs. These programs are changing dramatically nearly
every week. In most cases, files which were crunched by a later ver-
sion cannot be extracted by an earlier version.
Files which contain a "Z" as the second character in the extension will
be discarded until (unless) the various authors can agree on some stan-
dards and build RELIABLE and easy-to-use programs which allow a CP/M
user to extract a file crunched on an MS-DOS system, an MS-DOS user to
extract a file crunched on a CP/M system AND both CP/M and MS-DOS users
to create compatible crunched files.
2. Please DO NOT mix compression algorithms except to sQueeze a file and
then include it in a LiBRary file.
3. ARC files created by programs not compatible with ARC512 will be dis-
carded.
4. Files which were named using illegal characters (those not listed un-
der Legal Filenames above) will be discarded.
5. Never sQueeze or crunch a .LBR or .ARC file!
6. Never sQueeze or crunch a file which will later be included in an ARC
file.
7. NEVER rename a file before submitting it to this office! You may re-
name any file or program for your own use but please do not distribute
it to others except under the filename assigned by the author. This is
particularly important with public domain software.
8. Please do not sQueeze, LiBRary, or ARChive a file and then rename the
file. If you want to rename a file you created, please do so before
using your favorite utility. Renamed files cause serious problems
when we are extracting several files on the same disk.
Submissions
It is amazing how many submissions (both for the libraries and the
publications) arrive with nothing to identify the sender, the disk
format, the intent of the sender, etc.
Each disk submitted should have a label to tell us:
1. The name and address (and membership number) of the sender.
2. The format of the disk.
3. If text files are included, what word processor was used. If it is
possible, we would prefer that the files be submitted in WordStar or
standard ASCII format.
4. If it is not a submission, please include a cover letter so we know
WHY it was sent.
5. If it is a submission, what would you like back? Volunteers do most
of the copying to overwrite the disks before they are returned to the
senders. Normally the volunteers are not able to look up your address
and we do not have records of the library disks you already have or
the disk formats you can read.
6. If possible, include a file with the CRC values so that we can check
for damage to the files if we encounter problems.
7. Keep the filename unique. Please do not use FOGHORN, FOGLIGHT, FOG,
LETTER, or similar filenames.
Files uploaded to FOG #6 or #1 should:
1. Include sender's name, address, and membership number. If you are
uploading a textfile, place this information at the beginning of the
file. If you are uploading a library submission, include this infor-
mation in a "README" file.
2. If more than a single file is being uploaded, please collect all re-
lated files in either a LiBRary or ARChive file. Be sure the "README"
file is included. SQueeze text files before adding them to a LiBRary
file; do NOT sQueeze them before using ARChive.
3. If possible, include a file with the CRC values of each member.
4. Keep the filename unique. Please do not use FOGHORN, FOGLIGHT, FOG,
LETTER, or similar filenames.
Submissions for the FOG Publications
Lately, we have been receiving a large number of lengthy letters and
articles by mail. This is great except for one small problem - these
letters are not in computer-readable form.
Therefore, we wonder if authors realized that, in order to publish the
submission, we have to first retype these otherwise excellent submis-
sions? We have reluctantly begun returning such letters with the request
that they be returned on disk.
Remember folks, we will return your disk overwritten with a disk from the
library -- just tell us which disk you'd like to have.
Effective immediately, we will be unable to rekey a submission which is
longer than two paragraphs.
If you have artwork which accompanies the submission, please continue
sending that as hardcopy. Just insert it into the disk mailer.
Please include your name and address at the start of each article. It
is much faster to delete a couple extra lines than to search for the
information.
Please omit (or delete) ALL print control codes, regardless of what you
think we can read or use. We are experimenting with a variety of "desk-
top publishing" software packages and print control codes can make a file
nearly useless. If you want to assist us, include a hardcopy of the
formatted file. Please avoid indents, tabs, and other offsets. Keep all
the margin flush left and use blank lines for separation. Start and end
non-printing comments with a tilde ( ~ ).
Submissions are always needed for the FOG publications and, of course,
greatly appreciated. To all the authors and others responsible for such
submissions, our sincerest thanks for your efforts and support.
- Gale Rhoades
--cut-here--