Date   : Fri, 19 Dec 1986201:07:00-MST
From   : prindle@AMSAA.ARPA
Subject: Uncrunching on UNIX etc. here at last

I've just transferred a copy of what I consider to be a first release
of UNCR.C to simtel20.

Filename                       Type     Bytes   CRC

Directory PD:<UNIX.CPM>
UNCR231.C.1                    ASCII    12651  0052H

It is portable enough to compile and execute ok on an 8-bit CP/M system,
though about 2.5 times slower than the real UNCR 2.3.  So it's major
application is uncrunching on the host (UNIX, VMS, TOPS-20 ...)
systems.  I've tested it through all it's major paths on a Sun-3, a
VAX-11/780, and the C-128 CP/M.  Here is an abstract:

UNCR231.C is a C language implementation of the LZW decompression
algorithm utilized by Steven Greenberg's Z-80 CP/M program UNCR
Version 2.3 (from PD:<CPM.SQUSQ>CRUNCH23.LBR).  This program will
decompress (uncrunch) any file written with CRUNCH 2.x, although it
will not work with files written by CRUNCH 1.x (an earlier algorithm).
The only requirements placed on the C compiler used are that it
support a long type of at least 4 bytes (actually 21 bits will do),
and that it will read and write files in binary (no newline or ^Z
translation) using getc()/putc() when the files have been opened with
mode "rb"/"wb".  This is absolutely the case for UNIX on 32 bit
machines, but may require some coaxing on other systems, particularly
CP/M and MSDOS compilers.  Note that UNCR231.C is not recommended for
use on z-80 CP/M systems, since the real thing is over twice as fast;
rather it is meant to fill the gap and allow these "crunched" files to
be recovered on more powerful systems where speed is not an issue.
Usage is just:

$ uncr <filename> [<another filename> ...]

If your shell or O.S. does wildcard expansion, by all means use that.
Files not in "crunched" format will be skipped.  The decompressed
files will have the names of the original CP/M files (in lower case if
that is significant on your system).  This program follows in the
footsteps of usq.c and lar.c in attempting to provide a portable
implentation of a popular algorithm.

Sincerely,
Frank Prindle
Prindle@NADC.arpa