CFOG's PIP, July 1987, Volume 5 No. 9, Whole No. 57, page 4
A Response to FOG
by Steven Greenberg
This is in response to a file being circulated, STANDARD.FOG, issued by Gale Rhoades and the FOG office staff. While I understand the need for the document and the intent of it, I feel that certain sections disseminate information which is misdirected, misleading, or just plain technically incorrect. If you are not familiar with the document, it is a series of guidelines which must be used if one is to consider making a submissions to FOG. [FOG members will recognize the file as one printed in the FOGHORN in April 1987. Steven Greenberg is the author of the CRUNCH and UNCRunch programs. -- bhc]
Since the inception of CRUNCH, I have witnessed a wide variety of reactions, from very positive to quite negative. Reasons for "opposition" to CRUNCH have ranged from plain closed-mindedness to some very real questions the of "standards" and intersystem compatibility. Standdrds are very important, and they don't change overnight. Each system or person has a right to decide what is or isn't "standard", and, based on that, form appropriate guidelines. CRUNCH has gone from a relatively unknown compression format to quite a popular one. While it is now arguably a standard of some kind, the final decision on that question is of course left to the user.
I don't really care if FOG condones or condemns CRUNCH. It was written for my own interest and for the many others who find it useful (though I did make $15 on it -- an unsolicited contribution from England!). I am not in the habit of getting involved in these controversies. I am responding now, however, specifically to this FOG document, because it makes several points which I find offensively inaccurate.
Quote from STANDARD.FOG:
"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 version cannot be extracted by an earlier version."
There have only been two crunched file formats in all of history, namely "1" and "2". If there still are any type "1" files floating around, they would be uncrunched by any version 2 program with absolutely no problem. The standard current version of CRUNCH, version 2.3, was released with full source code in November '86. The statements above notwithstanding, there have been no additional releases (or known bugs) in the twenty-five or so weeks since, nor has version 2 format changed since it was first introduced some 36 weeks ago. There have been quite a number of support releases from other authors (see partial listing at the end of this article), and all work with the same version 2 format originally introduced in early September, 1986.
STANDARD. FOG continues:
"Files which contain a "Z" as the second character in the extension will be discarded until (unless) the various authors can agree on some standards 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."
Discarded indeed! (watch your .AZM files!)
Ironically, I feel it appropriate to congratulate the various authors of CRUNCH / UNCR type programs, as well as various TYPE and other utilities which support the crunched file format. Each of these programmers have conscientiously followed the existing format. We have thus evolved a system where all these programs ARE in fact compatible. I have no explanation for the statements made in the above paragraph concerning "agree[ment]" and "RELIABILITY' (emphasis theirs.. why?).
Using UNCR or equivalent, CP/M users CAN extract files made on any system which could create them. MS-DOS users CAN reliably extract crunched files created on CP/M systems (see the PRACSA messages below).
Of course CP/M users CAN create them, in a multitude of ways. At this moment, MS-DOS users cannot CREATE a crunched file, but then again neither can CP/M users create an ARC file right now. These inabilities are temporary and of secondary importance; the paramount issue is that everyone be able to reliably access the information contained in compressed files.
Consider the list [at the end of this article -- bhc], which contains as many programs as I could think of offhand which directly deal with the crunched file format. All are compatible.
Additional related programs are now being worked on in Canada, England, and elsewhere.
Another excerpt from STANDARD.FOG:
"I have yet to see a correctly named file which will not unsQueeze with NSWP."
Well I, for one, have a number of them. On 23 February 1985, Paul J. Homchick wrote a proposed standard explaining how and why files squeezed by some MS-DOS programs were incompatible, along with his proposed solution. Here is an excerpt from P. Homchick's SQDATE.DOC, referring to MS-DOS squeezers with names SQ2 and ZSQ:
"Although SQ2 added time and date stamping, it did so at the expense of downwards compatibility. A file squeezed with the time and date mode of SQ2 could ONLY be unsqueezed with the companion unsqueezer USQ2 (or ZUSQ). Thus the advantage of standardization was lost. No file squeezed with SQ2 could be unsqueezed with the older standard programs or moved to CP/M or UNIX systems. Clearly, SQ2 created a number of unfortunate consequences along with its time and date stamping."
An aside, not related to file compression: The list of "approved filename characters" includes four characters specifically NOT allowed by DRI for CP/M 3.0, namely open and close parenthesis, hyphen, and exclamation mark. The exclamation mark, in particular, is an odd inclusion insofar as it is virtually impossible to create or work with a filename containing that character in CP/M 3.
The following are messages left on the PRACSA board, sort of a culmination of a previously on-going debate. I include them here for general reference and especially for the author(s) of STANDARD.FOG. [PRACSA is an international orgaizization of sysops. -- bhc]
Subj: UNCRunching via MS-DOS
Date: 04-10-87
From: Irv Hoff
To: AllAppendix 1 below is a list is the result of an extensive test that John Allen did with his MS-DOS computer using the uncrunch program UNCR232.EXE. All the xxxx.?Z? files were downloaded from a CP/M-80 RCPM system. John says they all uncrunched fine, without loss of any information. MS-DOS owners can user the UNCR232.EXE program without hesitation for files crunched on CP/M-80 equipment using CRUNCH.
These files came from BO: of the PRACSA RCPM and were uncrunched using UNCR232.EXE on a MS-DOS computer by John Allen of the PRACSA standards committee. All parts of the files were normal and in the proper place. These files ranged from rather short to pretty long. They were more than adequate to establish the fact that UNCR232.EXE is doing its job correctly.
UNCR232. EXE should be in the library of any MS-DOS user that frequents RCPM systems that might have crunched files with xxxx.?Z? extents.
Subj: Crunch
Date: 04-13-87
From: Al Mehr
To: AllI capitulate. The "uncruncher" for DOS seems 100%. As I don't support MAC or APPLE stuff on my board, do not know what they will do, but I now agree, CRUNCH is certainly an acceptable alternative. I withdraw all my objections for using crunched files on the PRACSA BBS.
Appendix 1
Program OS Fuction Author(s) Notes
======= ==== ======= ========= =====
CRUNCH23 CP/M Crunch, Uncr, Docs Steven Greenberg w/ Z-80 source
FCRNCH11 CP/M CR, UCR, many xtras Charles Falconer w/ 8080 source
TYPELZ2x CP/M TYPE facility Steve G./Others Frm LBR's, etc.
LTxx CP/M TYPE & extras Charles Falconer Can extract to dsk
TYPEQZxx CP/M TYPE w/ wildcards John Hastwell-Batton Recognizes ASCII
TXxx CP/M another TYPE Harris Landsberg Strange language
UNCR231 ['C'] UNCR only, portable Frank Prindle Compilations below
UNCR232 MS/DOS Compiled ver of abv Prindle/ Hansen See Ref. #1
UNCR-DOS MS/DOS Compiled ver of abv Prindle/ Greenberg Similar to above
JETFIND CP/M 2 Advanced string srch Bridger Mitchell $Commercial Prgm
TRSCRNCH TRS For New TRSDOS 80 Jon Saxton / Others From Australia
UNCRNCHR MAC New, runs on MACS Prindle/ Beard New for MAC
CR23D CP/M Datestamper support Bridger Mitchell In Beta Test
Appendix 2
BEFORE:
-------
-BYE5KMD NZW 7-13-86 NZW 415BBS TZT BBS-USA TZT
BGIIFACT TZT FIFTH TZT TRAGEDY TZT ULTRA TZT
USR9600 TZT AJCBR LZT AJVAC LZT NOVBEST LZT
OCTBEST LZT PDFT0487 LZT RCPM0387 LZT ZNODES40 LZT
ZNODES41 LZT CREDIT DZC OZBYE510 DZC SNOOPY87 CZL
VICTORY FZC WRITE IZ EXCHANGE PZP UP2DATE PZP
AFTER:
------
-BYE5KMD NEW 7-13-86 NEW 415BBS TXT BBS-USA TXT
BGIIFACT TXT FIFTH TXT TRAGEDY TXT ULTRA INF
USR9600 TXT AJCBR LST AJVAC LST NOVBEST LST
OCTBEST LST PDFT0487 LST RCPM0387 LST ZNODES40 LST
ZNODES41 LST CREDIT DOC OZBYE510 DOC SNOOPY87 CAL
VICTORY FCC WRITE IN EXCHANGE PCP UP2DATE PCP