Date : Sun, 24 May 1987 13:35:13 EDT
From : "Keith B. Petersen" (WSMR|towson) <w8sdz@BRL.ARPA>
Subject: FOG standards - CRUNCH author replies
F.O.G., the First Osborne Group, recently released a file called
STANDARDS.FOG which detailed certain requirements for submitting
files to FOG. In the file below, the author of CRUNCH responds
to inaccuracies in the FOG document. I fully agree with the
rebuttle enclosed below. Many of the files available from my
RCP/M and SIMTEL20 are crunched. There have been no problems
and the savings in storage and download time are quite impressive.
Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZ
RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis), 9600 (USR HST)
--cut-here--RESPONSE.FOG--cut-here--
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
--cut-here--