raf@cup.portal.com (Robert A Freed) (10/20/88)
In article <KPETERSEN.12439280069.BABYL@SIMTEL20.ARMY.MIL>, W8SDZ@SIMTEL20.ARMY.MIL (Keith Petersen) writes about the new MS-DOS program, GSARC, by NoGate Consulting: > This is an interesting development. A new program that makes and > extracts ARC files using a more efficient variation on LZW compression, > called "Crushing". I have included the .INF file below. Beware - the > ARCs it produces cannot be read by ARC, ARCE or PKUNPAK unless GSARC's > compatibility switch is used. The program does work, and it does > produce *signficantly* smaller ARC files. I have examined the output of this program, and it is impressive. "Crushing" consistently generates smaller files than either "Crunching" or "Squashing". And it does this without resorting to memory-hungry brute force methods (such as LZW compression with 16-bit codes, as used by the UNIX public domain COMPRESS program.) > The information below is presented "as-is". I have no connection with > NoGate Consulting and this posting should not be interpreted as an > endorsement of yet another incompatible ARC-maker. However, it does > pose an interesting question: are we to resist this just because it's > incompatible - even though it is a significant step forward in > compression efficiency? ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ Please consider this carefully, people! Most of the recent discussion pertaining to compressing archivers, such as ARC, PKPAK (nee PKARC), ZOO, DWC, and now GSARC (to name just a few :-)), has related to the issue of portability. While that is understandably of great concern to many USENET readers, it should not be overlooked that *compression efficiency* is the primary reason for the existence and popularity of these programs. Some of us, who have actively researched LZW and other data compression techniques, have known that further improvement of current methods is technologically feasible. I predict that this "Crushing" variation is not even the ultimate we are likely to see in the near future. Legal, moral, and philosophical concerns aside, I urge continued support for such advancements in the state of the art. In this spirit, I have begun making the necessary modifications to my CP/M archive extraction program, UNARC, to handle .ARC files generated by GSARC10. (Just as I did almost two years ago, when Phil Katz' PKARC20 introduced an improved compression method to .ARC files.) Bob Freed Internet: raf@cup.portal.com Newton Centre, MA UUCP: ...!sun!portal!cup!raf