Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: PKZIP filenames (was Re: Bugs in v0.90 of PKZIP...)
Message-ID: <6128@bsu-cs.UUCP>
Date: 15 Mar 89 05:18:13 GMT
References: <129.241A07B5@mudos.ann-arbor.mi.us> <4397@drivax.DRI>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 26

In article <4397@drivax.DRI> davison@drivax.UUCP (Wayne Davison) writes:
>Personally, I'd prefer to see zoo enhanced to use a more efficient algorithm
>rather than adopting a new archiver package.  I am not sure if this would be
>something that Rahul would enjoy doing to zoo, though, since it is currently
>free of multiple compressions and incompatibilities with older versions.

The line count in the zoo source code is as follows:

     compression/uncompression code:   615 lines
     all other source files:          9248 lines

This means that the compression/uncompression that zoo does is but a
tiny fraction of everything.

Thus it's tempting to add new compression code.  But remembering the
confusion that squashing caused, I'm very reluctant to do it.

However, if a new compression algorithm were added, and the archive
extension changed to something else, the new zoo would retain upward
compatibility without confusing users.

I would rather beat pkzip by another 5% than rush to imitate it.  Does
anybody have any compression technique ideas to do this?
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
                    ARPA:  dhesi@bsu-cs.bsu.edu