Xref: utzoo gnu.emacs.help:1748 comp.emacs:10546
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!unreplyable!garbage
From: EVERHART@arisia.dnet.ge.com
Newsgroups: gnu.emacs.help,comp.emacs
Subject: RE: Possible danger in lzh or zip modes
Message-ID: <9104151304.AA12675@crdgw1.ge.com>
Date: 15 Apr 91 14:03:00 GMT
Sender: daemon@tut.cis.ohio-state.edu
Followup-To: gnu.emacs.help
Organization: Gatewayed from the GNU Project mailing list help-gnu-emacs@prep.ai.mit.edu
Lines: 24

Lharc sources (which create .lzh files) are readily available. The
algorithm is adaptive Huffman coding, not LZW; that much is clear from
the sources. The code has been dedicated, I believe, to public domain. It
originated, by the way, in Japan, though the comments have by now been
translated to English. The commenter who replied he thinks lharc uses
LZW as an algorithm has obviously not looked at the code.
   ZIP uses different algorithms. I've heard comments about the zip
system using two algorithms, one of which is lzw, in series. However
this remains hearsay and I have not examined the pd unzip programs to
check. Lharc performs comparably to Zip, but not identically. In fact
it tends to compress better.
   I have not examined the lzw patent, but if it is specific to the
lzw algorithm, I'd say lharc is and will remain in the clear. Its'
roots appear to lie in some PD code off JApanese bulletin board
systems, and is a recent development. Incidentally, I find lharc archives
easier to work with than compressed tar, since extraction of
individual files is trivial, and directories can be listed without
decompressing everything.
   I believe you'll find the code needed to pull apart lharc files
considerably more complex than needed to do LZW uncompression, but
have not checked this in any detail.
   Lharc source for unix have appeared in comp.sources.misc, I believe,
or alt.sources.
Glenn Everhart