Re: HPRT v1.0 posted on comp.binaries - HOORAY!

[fadden@hkn.eecs.berkeley.edu (Andy McFadden)]

Once upon a time, Neal Pitts wrote:
>I want to say that before anyone starts posting file to FTP sites, the 
>binaries group, and even BBSsess, that we should come to a consensus on 
>how these files should be handled.  What file extension should we use?  

HardPressed depends on file type and auxtype, so they should ALWAYS be
inside a ShrinkIt archive.  You'll get like 1% compression on a file
compressed with LZSS, because of the header, but you can always tell
ShrinkIt to store the files without compression.

As I mentioned in the readme, compressing the demo files with ShrinkIt
resulted in a 223 block archive, but compressing them with LZSS and
no ShrinkIt compression resulted in a 201 block archive (the latter
included the ReadMe file as well).

The HP file format isn't meant to be used as a distribution mechanism;
that's what ShrinkIt is designed for.  HP is a file compressor, not a
file archiver.  The advantage is that, once you've downloaded the files,
they don't take up any more space than they did in the archive, and you
don't have to take any extra steps to expand them.

And if you don't like having them compressed, you can "extract" them by
doing a file copy with HPRT active (or HP in "expand only" mode).  HPRT
is also several times faster than ShrinkIt when uncompressing.

>What about distribution for shareware?

Hadn't thought about that. :-)  My feeling is that shareware programs
shouldn't need to ask WestCode for a license, but it's ultimately up to
WestCode... I've sent them some mail asking about it.  My attitude is that
the more widespread HPRT becomes, the more people will know about HP, and
the better it is for us (need to reach a maximum number of people for a
minimum of cost; the IIgs market can't support anything else).

>                                                   What type of files 
>compress well with LZSS?  (This is in the manual, but I think everyone 
>should hear it posted so people get the idea.)

Text files do well.  Source code does *really* well (2.6MB of HP assembly
sources went down to 800K, and they expand in no time at all).  The only
case where LZSS kind of chokes is on sparse files (i.e. files with long
runs of zeros in them).  It does a max of (if I remember correctly) 9:1
compression (18 characters -> 2 bytes), so it can't make things as small
as LZW can.  However, it builds longer strings faster, so in most cases
it does at least as well as LZW.

>                                                Is it okay for general 
>use, in the sense that this may become a mainstream decompressing program 
>for shareware/freeware?

Well, I certainly have no objections to it. :-)  Just bear in mind that
it's meant as a transparent file uncompressor, not a file archiver, and
that there is no stand-alone program that just expands HP files... you
have to be running HP or HPRT.  There is also no way to unpack them on
a ][+ or //e.

The files themselves are composed of a fairly obvious header (filled with
file types, file lengths, and offsets to data) and pure LZSS output.  My
code was based on the canonical LZSS implementation, so it shouldn't be
too hard to write a program that can unpack HPRT files.