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: All

Appendix 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: All

I 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