home *** CD-ROM | disk | FTP | other *** search
/ CP/M / CPM_CDROM.iso / cpm / gendoc / standard.fog < prev    next >
Encoding:
Text File  |  1994-07-13  |  10.6 KB  |  248 lines
  1. Report from FOG
  2. Solution for a Major Problem
  3. by Gale Rhoades
  4.  
  5. In recent weeks, the FOG office staff has been trying to sort through a
  6. variety of submissions.  Some have been uploaded to FOG #6 (or #1) and
  7. some have arrived on disk.  The problems we've encountered surpass my
  8. ability to describe.
  9.  
  10. We have files which have been sQueezed, crunched, ARChived or LiBRaried
  11. and we have files which apparently have gone through a combination of
  12. compression programs.
  13.  
  14. We have filenames with characters which are reserved under MS-DOS and
  15. filenames with characters which are reserved under CP/M.  (Reserved
  16. characters are those which the operating system will not permit you to
  17. use when naming a file.)  We have CP/M files on MS-DOS formatted disks
  18. and MS-DOS files on CP/M formatted disks.  And we have the most horren-
  19. dous assortment of combinations.  How some of it was accomplished is
  20. totally beyond me!
  21.  
  22. Enough is enough.  Jack and I are spending hours trying to get at some
  23. of these files and we just do not have the time to continue doing this.
  24. Well, at least not if you want to continue to see the FOG publications,
  25. new library releases and all the other services which are provided by
  26. the FOG staff.
  27.  
  28. We have therefore developed some guidelines for submitting material to
  29. the FOG libraries and publications.  Exceptions will be considered but
  30. please check with us in advance.  We are willing to listen to suggestions
  31. for modifications to these guidelines but only if they are presented in
  32. an organized and well-considered manner.  As a secondary goal, I would
  33. hope that FOG can facilitate the standardization of filenames and com-
  34. pression programs.
  35.  
  36. Additionally, these guidelines are subject to revision as the authors of
  37. industry-standard utilities develop the tools which will eliminate some
  38. of the specific problems outlined below.
  39.  
  40.  
  41.  
  42.                         The Guidelines
  43.  
  44. It would be very foolish to perpetuate the argument that CP/M and MS-DOS
  45. are separate and distinct.  Far too many users find themselves switching
  46. between MS-DOS and CP/M machines.  Some have one machine at work and the
  47. other at home.  Others have both sitting side-by-side.
  48.  
  49. Legal Filenames:  Filenames may contain only the characters listed below:
  50.  
  51.      !  (exclamation mark)
  52.      #  (pound, number, or hash symbol)
  53.      %  (percent)
  54.      &  (ampersand)
  55.      '  (apostrophe)
  56.      (  (open or left parenthesis)
  57.      )  (close or right parenthesis)
  58.      -  (hyphen, dash, or minus)
  59.      @  (at symbol)
  60.      0  through  9
  61.      A  through  Z  (upper case only!)
  62.      ^  (caret or circumflex)
  63.      `  (back quote)
  64.      {  (open or left brace or curly bracket)
  65.      }  (close or right brace or curly bracket)
  66.      ~  (tilde)
  67.  
  68. It is true that both MS-DOS and CP/M permit filenames to include char-
  69. acters other than those listed above.  This list includes only those
  70. haracters which we have found to be generally acceptable to both opera-
  71. ting systems.  Note that a few of these characters are partially reserved
  72. through common usage.
  73.  
  74. For example, "Q" as the second letter of a file extension indicates that
  75. the file has been sQueezed.  NEVER use it otherwise. "Z" as the second
  76. letter of a file extension indicates that the file has been crunched.
  77. Again, NEVER use it unless the file has indeed been crunched.
  78.  
  79. The characters are listed in ascending ASCII order. The first nine often
  80. are used to place files at the head of a sorted directory because they
  81. have ASCII values less than that of a "0" or an "A".
  82.  
  83. Utility Programs:  These are the programs which compress files (to con-
  84. serve disk space) or which collect several files under a single filename.
  85.  
  86. 1. SQueezed files (those with a "Q" as the second letter of a file ex-
  87.    tension) must be compatible with Dave Rand's NewSWeeP (version 2.07
  88.    in CP/M or 1.018 in MS-DOS, both of which use Richard Greenlaw's SQ
  89.    algorithm).  I have yet to see a correctly named file which will not
  90.    unsQueeze with NSWP.  SQueezed files generally save approximately
  91.    30-35%.
  92.  
  93. Text files which are of use to both CP/M and MS-DOS users should only be
  94. sQueezed.
  95.  
  96. 2. LiBRaried files (those with the extension .LBR) are a collection of
  97.    several related files.  Often libraries include files which have been
  98.    sQueezed.  This combination is both acceptable and desirable as a
  99.    savings of 10-50% is realized.
  100.  
  101. Additionally, there are fully debugged utilities which will allow one-
  102. step viewing and extraction from .LBR files and these files are equally
  103. usable on either MS-DOS or CP/M systems.  Generally these files are
  104. created on CP/M systems.
  105.  
  106. 3. ARChived files (those with the extension of either .ARC or .ARK) are
  107.    files which contain related files.  ARC is particularly nice because
  108.    it is possible, in a single step, to both condense and collect.  Cur-
  109.    rently ARC files are created reliably only on MS-DOS systems but the
  110.    contents can be extracted with ease on either a CP/M or MS-DOS system.
  111.  
  112. The established standard is to use .ARC as the extension when the file
  113. contains programs and related files specific to MS-DOS systems.  Most
  114. MS-DOS shareware and public domain software is distributed (on the Remote
  115. Systems) in .ARC files.  Files w ith the extension .ARK are specific to
  116. CP/M systems.  ARC512 is the standard which FOG is supporting.
  117.  
  118.  
  119. Things to Avoid:  These are the things which have caused major problems,
  120. especially lately.
  121.  
  122. 1. ALL crunch programs. These programs are changing dramatically nearly
  123.    every week.  In most cases, files which were crunched by a later ver-
  124.    sion cannot be extracted by an earlier version.
  125.  
  126. Files which contain a "Z" as the second character in the extension will
  127. be discarded until (unless) the various authors can agree on some stan-
  128. dards and build RELIABLE and easy-to-use programs which allow a CP/M
  129. user to extract a file crunched on an MS-DOS system, an MS-DOS user to
  130. extract a file crunched on a CP/M system AND both CP/M and MS-DOS users
  131. to create compatible crunched files.
  132.  
  133. 2. Please DO NOT mix compression algorithms except to sQueeze a file and
  134.    then include it in a LiBRary file.
  135.  
  136. 3. ARC files created by programs not compatible with ARC512 will be dis-
  137.    carded.
  138.  
  139. 4. Files which were named using illegal characters (those not listed un-
  140.    der Legal Filenames above) will be discarded.
  141.  
  142. 5. Never sQueeze or crunch a .LBR or .ARC file!
  143.  
  144. 6. Never sQueeze or crunch a file which will later be included in an ARC
  145.    file.
  146.  
  147. 7. NEVER rename a file before submitting it to this office!  You may re-
  148.    name any file or program for your own use but please do not distribute
  149.    it to others except under the filename assigned by the author. This is
  150.    particularly important with public domain software.
  151.  
  152. 8. Please do not sQueeze, LiBRary, or ARChive a file and then rename the
  153.    file.  If you want to rename a file you created, please do so before
  154.    using your favorite utility.  Renamed files cause serious problems
  155.    when we are extracting several files on the same disk.
  156.  
  157.  
  158.                            Submissions
  159.  
  160. It is amazing how many submissions (both for the libraries and the
  161. publications) arrive with nothing to identify the sender, the disk
  162. format, the intent of the sender, etc.
  163.  
  164. Each disk submitted should have a label to tell us:
  165.  
  166. 1. The name and address (and membership number) of the sender.
  167.  
  168. 2. The format of the disk.
  169.  
  170. 3. If text files are included, what word processor was used.  If it is
  171.    possible, we would prefer that the files be submitted in WordStar or
  172.    standard ASCII format.
  173.  
  174. 4. If it is not a submission, please include a cover letter so we know
  175.    WHY it was sent.
  176.  
  177. 5. If it is a submission, what would you like back?  Volunteers do most
  178.    of the copying to overwrite the disks before they are returned to the
  179.    senders.  Normally the volunteers are not able to look up your address
  180.    and we do not have records of the library disks you already have or
  181.    the disk formats you can read.
  182.  
  183. 6. If possible, include a file with the CRC values so that we can check
  184.    for damage to the files if we encounter problems.
  185.  
  186. 7. Keep the filename unique. Please do not use FOGHORN, FOGLIGHT, FOG,
  187.    LETTER, or similar filenames.
  188.  
  189.  
  190. Files uploaded to FOG #6 or #1 should:
  191.  
  192. 1. Include sender's name, address, and membership number.  If you are
  193.    uploading a textfile, place this information at the beginning of the
  194.    file.  If you are uploading a library submission, include this infor-
  195.    mation in a "README" file.
  196.  
  197. 2. If more than a single file is being uploaded, please collect all re-
  198.    lated files in either a LiBRary or ARChive file.  Be sure the "README"
  199.    file is included.  SQueeze text files before adding them to a LiBRary
  200.    file; do NOT sQueeze them before using ARChive.
  201.  
  202. 3. If possible, include a file with the CRC values of each member.
  203.  
  204. 4. Keep the filename unique.  Please do not use FOGHORN, FOGLIGHT, FOG,
  205.    LETTER, or similar filenames.
  206.  
  207.  
  208.               Submissions for the FOG Publications
  209.  
  210. Lately, we have been receiving a large number of lengthy letters and
  211. articles by mail.  This is great except for one small problem - these
  212. letters are not in computer-readable form.
  213.  
  214. Therefore, we wonder if authors realized that, in order to publish the
  215. submission, we have to first retype these otherwise excellent submis-
  216. sions?  We have reluctantly begun returning such letters with the request
  217. that they be returned on disk.
  218.  
  219. Remember folks, we will return your disk overwritten with a disk from the
  220. library -- just tell us which disk you'd like to have.
  221.  
  222. Effective immediately, we will be unable to rekey a submission which is
  223. longer than two paragraphs.
  224.  
  225. If you have artwork which accompanies the submission, please continue
  226. sending that as hardcopy.  Just insert it into the disk mailer.
  227.  
  228. Please include your name and address at the start of each article.  It
  229. is much faster to delete a couple extra lines than to search for the
  230. information.
  231.  
  232. Please omit (or delete) ALL print control codes, regardless of what you
  233. think we can read or use.  We are experimenting with a variety of "desk-
  234. top publishing" software packages and print control codes can make a file
  235. nearly useless.  If you want to assist us, include a hardcopy of the
  236. formatted file.  Please avoid indents, tabs, and other offsets.  Keep all
  237. the margin flush left and use blank lines for separation.  Start and end
  238. non-printing comments with a tilde ( ~ ).
  239.  
  240. Submissions are always needed for the FOG publications and, of course,
  241. greatly appreciated.  To all the authors and others responsible for such
  242. submissions, our sincerest thanks for your efforts and support.
  243.  
  244.                     - Gale Rhoades
  245.  
  246.  
  247.  
  248.