home *** CD-ROM | disk | FTP | other *** search
/ Oakland CPM Archive / oakcpm.iso / cpm / gendoc / response.fzg / RESPONSE.FOG
Text File  |  1987-05-24  |  11KB  |  231 lines
  1.  
  2.  
  3.  
  4. RESPONSE.FOG
  5. Steven Greenberg, 10 May 1987
  6.  
  7. This  is in response to a file being circulated, STANDARD.FOG,  issued
  8. by Gale Rhoades and the FOG office staff.  While I understand the need
  9. for  the document and the intent of it, I feel that  certain  sections
  10. disseminate  information  which is misdirected,  misleading,  or  just
  11. plain  technically incorrect.  If you are not familiar with the  docu-
  12. ment,  it  is a series of guidelines which must be used if one  is  to
  13. consider making a submissions to FOG  [Ref. #2].
  14.  
  15. Since  the  inception of CRUNCH, I have witnessed a  wide  variety  of
  16. reactions, from very positive to quite negative.  Reasons for "opposi-
  17. tion" to CRUNCH have ranged from plain closed-mindedness to some  very
  18. real  questions  the  of "standards"  and  intersystem  compatibility.
  19. Standards  are very important, and they don't change overnight.   Each
  20. system  or person has a right to decide what is or  isn't  "standard",
  21. and, based on that, form appropriate guidelines.  CRUNCH has gone from
  22. a relatively unknown compression format to quite a popular one.  While
  23. it is now arguably a standard of some kind, the final decision on that
  24. question is of course left to the user.
  25.  
  26. I don't really care if FOG condones or condemns CRUNCH.  It was  writ-
  27. ten  for  my own interest and for the many others who find  it  useful
  28. (though  I  did  make  $15 on it-  an  unsolicited  contribution  from
  29. England!).  I am not in the habit of getting involved in these contro-
  30. versies,  such as the recent PRACSA discussions concerning the  "sanc-
  31. tioning"  of crunched files (see Ref #1 below).  I am responding  now,
  32. however,  specifically to this FOG document, because it makes  several
  33. points which I find offensively inaccurate.
  34.  
  35. Quote from STANDARD.FOG:
  36.  
  37. |   "Things  to Avoid:  These are the things which have  caused  major
  38. |   problems, especially lately."
  39. |
  40. |   "1. ALL crunch programs.  These programs are changing dramatically
  41. |   nearly every week.  In most cases, files which were crunched by  a
  42. |   later version cannot be extracted by an earlier version."
  43.  
  44. There  have  only been two crunched file formats in  all  of  history,
  45. namely  "1" and "2".  If there still are any type "1"  files  floating
  46. around, they would be uncrunched by any v2 program with absolutely  no
  47. problem.  The standard current version of CRUNCH, (v2.3), was released
  48. with  full source code in November of '86.  The statements above  not-
  49. withstanding,  there have been no additional releases (or known  bugs)
  50. in the twenty-five or so weeks since, nor has v2 format changed  since
  51. it  was first introduced some 36 weeks ago.  There have been  quite  a
  52. number of support releases from other authors (see partial listing be-
  53. low),  and all work with the same v2 format originally  introduced  in
  54. early September, 1986.
  55.  
  56.  
  57.  
  58.                                   1
  59.  
  60.  
  61.  
  62. STANDARD.FOG continues:
  63.  
  64. |   "Files  which contain a "Z" as the second character in the  exten-
  65. |   sion  will  be discarded until (unless) the  various  authors  can
  66. |   agree  on some standards and build RELIABLE and easy-to-use  prog-
  67. |   rams which allow a CP/M user to extract a file crunched on an  MS-
  68. |   DOS  system, an MS-DOS user to extract a file crunched on  a  CP/M
  69. |   system  AND  both  CP/M  and MS-DOS  users  to  create  compatible
  70. |   crunched files."
  71.  
  72. Discarded indeed! (watch your .AZM files!)
  73.  
  74. Ironically, I feel it appropriate to congratulate the various  authors
  75. of  CRUNCH  / UNCR type programs, as well as various  TYPE  and  other
  76. utilities  which support the crunched file format.  Each of these pro-
  77. grammers  have conscientiously followed the existing format.  We  have
  78. thus evolved a system where all these programs ARE in fact compatible-
  79. I  have no explanation for the statements made in the above  paragraph
  80. concerning "agree[ment]" and "RELIABILITY" (emphasis theirs.. why?).
  81.  
  82. Using UNCR or equiv., CP/M users CAN extract files made on any  system
  83. which  could create them.  MS-DOS users CAN reliably extract  crunched
  84. files  created  on CP/M systems (see Ref #1 below).   Of  course  CP/M
  85. users CAN create them, in a multitude of ways.  At this moment, MS/DOS
  86. users  cannot CREATE a crunched file, but then again neither can  CP/M
  87. users  create an ARC file right now.  These inabilities are  temporary
  88. and  of secondary importance; the paramount issue is that everyone  be
  89. able to reliably access the information contained in compressed files.
  90.  
  91. Consider  the  following list, which contains as many  programs  as  I
  92. could  think  of offhand which directly deal with  the  crunched  file
  93. format.  ALL ARE COMPATIBLE.
  94.  
  95.  
  96. Program    OS     Function              Author(s)            Notes
  97. =======   ====    ========              ==========           =====
  98. CRUNCH23  CP/M    Crunch, Uncr, Docs    Steven Greenberg     w/ Z-80 source
  99. FCRNCH11  CP/M    CR, UCR, many xtras   Charles Falconer     w/ 8080 source
  100. TYPELZ2x  CP/M    TYPE facility         Steve G./Others      Frm LBR's, etc.
  101. LTxx      CP/M    TYPE & extras         Charles Falconer     Can extract to dsk
  102. TYPEQZxx  CP/M    TYPE w/ wildcards     John Hastwell-Batton Recognizes ASCII
  103. TXxx      CP/M    another TYPER         Harris Landsberg     Strange language
  104. UNCR231   ['C']   UNCR only, portable   Frank Prindle        Compilations below
  105. UNCR232   MS/DOS  Compiled ver of abv   Prindle/ Hansen      See  Ref. #1
  106. UNCR-DOS  MS/DOS  Compiled ver of abv   Prindle/ Greenberg   Similar to above
  107. JETFIND   CP/M 2  Advanced string srch  Bridger Mitchell     $Commercial Prgm
  108. TRSCRNCH  TRS     For New TRSDOS 80     Jon Saxton / Others  From Australia
  109. UNCRNCHR  MAC     New, runs on MACS     Prindle/Beard        New for MAC
  110. CR23D     CP/M    Datestamper support   Bridger Mitchell     In Beta Test
  111.  
  112. Additional related programs are now being worked on in Canada,
  113. England, and elsewhere.
  114.  
  115. ===============================================================================
  116.  
  117.  
  118.                                   2
  119.  
  120.  
  121.  
  122. Another excerpt from STANDARD.FOG:
  123.  
  124. |   "I have yet to see a correctly named file which will not unsQueeze
  125. |   with NSWP."
  126.  
  127. Well  I,  for one,  have a number of them.  On 23 Feb.  '85,  Paul  J.
  128. Homchick  wrote  a  proposed standard explaining  how  and  why  files
  129. squeezed  by  some MS-DOS programs were incompatible, along  with  his
  130. proposed  solution. Here is an excerpt from P. Homchick's  SQDATE.DOC,
  131. referring to MS-DOS squeezers with names SQ2 and ZSQ:
  132.  
  133.     "Although  SQ2 added time and date stamping, it did so at the  ex-
  134.     pense  of downwards compatibility.  A file squeezed with the  time
  135.     and  date mode of SQ2 could ONLY be unsqueezed with the  companion
  136.     unsqueezer USQ2 (or ZUSQ).  Thus the advantage of  standardization
  137.     was lost.  No file squeezed with SQ2 could be unsqueezed with  the
  138.     older standard programs or moved to CP/M or UNIX systems.   Clear-
  139.     ly,  SQ2 created a number of unfortunate consequences  along  with
  140.     its time and date stamping."
  141.  
  142. ----------------------------------------------------------------------
  143.  
  144. An  aside,  not related to file compression:  The  list  of  "approved
  145. filename characters" includes four characters specifically NOT allowed
  146. by  DRI for CP/M 3.0, namely "(", ")", "-" and "!".   The  exclamation
  147. mark,  in particular, is an odd inclusion insofar as it  is  virtually
  148. impossible to create or work with a filename containing that character
  149. in CP/M 3.
  150.  
  151. ======================================================================
  152.  
  153.                           APPENDIX: "Ref #1"
  154.  
  155. Here  is "Ref #1" mentioned several times above.  These  are  messages
  156. left  on the PRACSA board, sort of a culmination of a  previously  on-
  157. going debate.  I include them here for general reference and especial-
  158. ly for the author(s) of STANDARD.FOG.
  159.  
  160. -----
  161. Area: MS-DOS
  162. Msg # 179 04/10/87 11:08 PDT
  163. Subj: UNCRunching via MS-DOS
  164. From: Irv Hoff
  165. To:   All
  166.  
  167. The following list is the result of an extensive test that John  Allen
  168. did  with his MS-DOS computer using the uncrunch program  UNCR232.EXE.
  169. All  the  xxxx.?Z? files were downloaded from a CP/M-80  RCPM  system.
  170. John  says they all uncrunched fine, without loss of any  information.
  171. MS-DOS owners can user the UNCR232.EXE program without hesitation  for
  172. files crunched on CP/M-80 equipment using CRUNCH.
  173.  
  174.  
  175.                                   3
  176.  
  177.  
  178.  
  179.  BEFORE:
  180.  ------
  181.  -BYE5KMD NZW    7-13-86  NZW    415BBS   TZT    BBS-USA  TZT
  182.  BGIIFACT TZT    FIFTH    TZT    TRAGEDY  TZT    ULTRA    TZT
  183.  USR9600  TZT    AJCBR    LZT    AJVAC    LZT    NOVBEST  LZT
  184.  OCTBEST  LZT    PDFT0487 LZT    RCPM0387 LZT    ZNODES40 LZT
  185.  ZNODES41 LZT    CREDIT   DZC    OZBYE510 DZC    SNOOPY87 CZL
  186.  VICTORY  FZC    WRITE    IZ     EXCHANGE PZP    UP2DATE  PZP
  187.  
  188.  AFTER:
  189.  -----
  190.  -BYE5KMD NEW    7-13-86  NEW    415BBS   TXT    BBS-USA  TXT
  191.  BGIIFACT TXT    FIFTH    TXT    TRAGEDY  TXT    ULTRA    INF
  192.  USR9600  TXT    AJCBR    LST    AJVAC    LST    NOVBEST  LST
  193.  OCTBEST  LST    PDFT0487 LST    RCPM0387 LST    ZNODES40 LST
  194.  ZNODES41 LST    CREDIT   DOC    OZBYE510 DOC    SNOOPY87 CAL
  195.  VICTORY  FCC    WRITE    IN     EXCHANGE PCP    UP2DATE  PCP
  196.  
  197. These files came from B0: of the PRACSA RCPM and were uncrunched using
  198. UNCR232.EXE on a MS-DOS computer by John Allen of the PRACSA standards
  199. committee.   All  parts  of the files were normal and  in  the  proper
  200. place.   These  files ranged from rather short to pretty  long.   They
  201. were  more  than adequate to establish the fact  that  UNCR232.EXE  is
  202. doing its job correctly.
  203.  
  204. UNCR232.EXE should be in the library of any MS-DOS user that frequents
  205. RCPM systems that might have crunched files with xxxx.?Z? extents.  It
  206. is available on G0: of the PRACSA RCPM.
  207.  
  208. -----
  209. Area: PRACSA
  210. Msg # 219 04/13/87 22:39 PDT
  211. Subj: crunch
  212. From: Al Mehr
  213. To:   All
  214.  
  215. I capitulate.  The "uncruncher" for DOS seems 100%. As I don't support
  216. MAC  or APPLE stuff on my board, do not know what they will do, but  I
  217. now  agree, CRUNCH is certainly an acceptable alternative. I  withdraw
  218. all my objections for using crunch files on the PRACSA BBS.
  219.  
  220.    Al Mehr     SERVU
  221.  
  222. ----------------------------------------------------------------------
  223. Ref #2:   The actual document,  STANDARD.FOG,  a file uploaded by Gale
  224. Rhoades, is available on the PRACSA RCP/M as "STANDARD.FZG".
  225. ----------------------------------------------------------------------
  226.  
  227.  
  228.  
  229.  
  230.                                   4
  231.