Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!mensa.usc.edu!chanel
From: chanel@mensa.usc.edu (chanel summers)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: PKLITE, what's the catch???
Message-ID: <33983@usc.edu>
Date: 30 Jun 91 01:46:05 GMT
References: <11230005@hplsla.HP.COM> <1991Jun29.052850.2121@netcom.COM> <1991Jun29.150110.19766@midway.uchicago.edu>
Sender: news@usc.edu
Organization: University of Southern California, Los Angeles, CA
Lines: 27
Nntp-Posting-Host: mensa.usc.edu

In article <1991Jun29.150110.19766@midway.uchicago.edu> valley@gsbsun.uchicago.edu (Doug Dougherty) writes:
>To me, that doesn't sound like much of a selling point; you should
>maintain originals of any program you compress anyway, just as you
>should maintain sources of any program you compile.

I disagree.  The purpose of compressing executables is to save space.  Saving
the executable in compressed format and original format seems redundant.  Sure,
you can back it up on a floppy, but that's like saying that everyone should
keep a copy of their ZIP files *and* the contents of the ZIP files uncompressed
which is obviously silly.

I compress all executables I can.  If I need to, I uncompress them (though I've
never needed to -- except when they don't work right in compressed mod).

If you use PKLITE or another uncompressable compression routine, the version
of the program you get when you uncompress it is IDENTICAL -- completely and
exactly -- to the original (unless you mess with it while compressed, but
that will destroy it anyway).  I just use common sense when selecting files
to compress.  I never compress something that modifies itself.

Also, LZEXE messes up the EXE header table.  Nothing so severe (I've been told)
that the program won't run, but why take the chance?  I like the fact that
other programs give you the option of getting back JUST what you put in.
Finally, if you LZEXE a program, UNLZEXE it, and then try to compress it with
another compressor, often you get an error from the second compressor.

Chanel