Subject: Re: HELP...need compression libs...

From: [email-masked] (EdNutter)
Date: 4 Jul 1994 00:53:07 -0400

In article <[email-masked]>, [email-masked] (Brad Viviano
(Thor)) writes:

Brad,

I'd better mention up front that I work for Stac electronics. I do
online & phone support for Stacker for DOS and Mac.

You didn't specify, but I assume you're talking about a PKZIP or
other Lempel-Ziv type of compressed archive. I don't think you'll be
able to do what you ask. Lempel-Ziv essentially looks across a
section of the file looking for repeating data. It makes one copy of
the data in a library, and replaces all other occurances of the data
with a pointer to the original. There are many varients of the
technique, some tuned for speed, some for sheer compression. PKZIP &
LHARC are tuned for compression.

The problem is that you can't index into the compressed file in any
reliable way without reading the library, and in effect decompressing
the data on the fly. You would be doing a sequential scan of the
whole file rather than a random seek to a known offset.

You may want to consider disk compression. Programs such as Stacker
compress on a cluster or allocation block (Mac speak for the same
thing) basis. A program accessing a file tells the OS it wants to
look at x bytes of data starting at offset y into the file. The OS
calculates that offset y will be in cluster z, and tells the disk
driver to get the corresponding sectors. If the disk driver is
Stacker, it finds the sectors containing the compressed data,
decompresses them, and shortly the OS hands the x bytes to the
application.

The tradeoffs are... Stacker uses RAM, although on modern machines
most of it lives in extended memory. The logic for a program to UNZIP
on the fly would use RAM also. Stacker only gets about 1/2 to 2/3 of
the compression that PKZIP or LHARC get. On the other hand, Stacker
is much faster than the archive programs.

Hope this was informative.

Ed, aka [email-masked]