RESPONSE.FOG Steven Greenberg, 10 May 1987 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 docu- ment, it is a series of guidelines which must be used if one is to consider making a submissions to FOG [Ref. #2]. Since the inception of CRUNCH, I have witnessed a wide variety of reactions, from very positive to quite negative. Reasons for "opposi- tion" to CRUNCH have ranged from plain closed-mindedness to some very real questions the of "standards" and intersystem compatibility. Standards 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 writ- ten 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 contro- versies, such as the recent PRACSA discussions concerning the "sanc- tioning" of crunched files (see Ref #1 below). 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 v2 program with absolutely no problem. The standard current version of CRUNCH, (v2.3), was released with full source code in November of '86. The statements above not- withstanding, there have been no additional releases (or known bugs) in the twenty-five or so weeks since, nor has v2 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 be- low), and all work with the same v2 format originally introduced in early September, 1986. 1 STANDARD.FOG continues: | "Files which contain a "Z" as the second character in the exten- | sion will be discarded until (unless) the various authors can | agree on some standards and build RELIABLE and easy-to-use prog- | rams 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 pro- grammers 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 equiv., 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 Ref #1 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 following list, which contains as many programs as I could think of offhand which directly deal with the crunched file format. ALL ARE COMPATIBLE. Program OS Function 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 TYPER 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 Additional related programs are now being worked on in Canada, England, and elsewhere. =============================================================================== 2 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 Feb. '85, 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 ex- pense 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. Clear- ly, 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 "(", ")", "-" and "!". 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. ====================================================================== APPENDIX: "Ref #1" Here is "Ref #1" mentioned several times above. These 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 especial- ly for the author(s) of STANDARD.FOG. ----- Area: MS-DOS Msg # 179 04/10/87 11:08 PDT Subj: UNCRunching via MS-DOS From: Irv Hoff To: All The following 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. 3 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 These files came from B0: 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. It is available on G0: of the PRACSA RCPM. ----- Area: PRACSA Msg # 219 04/13/87 22:39 PDT Subj: crunch 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 crunch files on the PRACSA BBS. Al Mehr SERVU ---------------------------------------------------------------------- Ref #2: The actual document, STANDARD.FOG, a file uploaded by Gale Rhoades, is available on the PRACSA RCP/M as "STANDARD.FZG". ---------------------------------------------------------------------- 4