routh@eltanin.rtp.semi.harris.com (Kevin Routh x622) (06/26/91)
I just got a neat program called PKLITE version 1.05 and have decreased my hard disk usage by 4 Meg. What's tha catch (aside from the obvious extra second or two it take to load a exe)? Are there any gotcha's associated with using PKLITE? E-mail responses are fine, let's not clutter the net. -- Kevin Routh (routh@rtp.semi.harris.com) Harris Corporation, Durham, NC (919) 361-1622
valley@gsbsun.uchicago.edu (Doug Dougherty) (06/26/91)
routh@eltanin.rtp.semi.harris.com (Kevin Routh x622) writes: >I just got a neat program called PKLITE version 1.05 and have decreased >my hard disk usage by 4 Meg. What's tha catch (aside from the obvious >extra second or two it take to load a exe)? Are there any gotcha's >associated with using PKLITE? E-mail responses are fine, let's not >clutter the net. As far as I know, no catches. Obviously, it doesn't work with some files. What I'd like to know is what the comparison (on the usual criteria) is between the various EXE compressors. (Diet, PKlite, LHEXE) I've been using LHEXE (I think that's the name; it seems to have slipped my mind - ANyway, it's the one from France) and it seems to work OK. Just wondering if any of the others are any better... -- (Another fine mess brought to you by valley@gsbsun.uchicago.edu)
bstocker@diana.cair.du.edu (Bob Stocker) (06/27/91)
In article <1991Jun26.141813.29418@midway.uchicago.edu> valley@gsbsun.uchicago.edu (Doug Dougherty) writes: >routh@eltanin.rtp.semi.harris.com (Kevin Routh x622) writes: > >>I just got a neat program called PKLITE version 1.05 and have decreased >>my hard disk usage by 4 Meg. What's tha catch (aside from the obvious >>extra second or two it take to load a exe)? Are there any gotcha's >>associated with using PKLITE? E-mail responses are fine, let's not >>clutter the net. > >As far as I know, no catches. Obviously, it doesn't work with some files. > There is one possible catch: Most virus scanners won't pick up viruses that are embedded in a PKLITE, DIET or whatever file. The latest versions of fprot do, however, detect self-decompressing executables and documentation that comes with that program suggests that future versions of fprot will be able to check these files for viruses as well. In the meantime, it would certainly make sense to check you files for viruses before turing them into self-decompressors. -- Internet: bstocker@du.edu BITNET: BSTOCKER@DUCAIR HockeyNet: The DU Pioneers!
pss1@kepler.unh.edu (Paul S Secinaro) (06/27/91)
In article <1991Jun26.193811.24507@mercury.cair.du.edu> bstocker@diana.cair.du.edu (Bob Stocker) writes: >>As far as I know, no catches. Obviously, it doesn't work with some files. >> >There is one possible catch: Most virus scanners won't pick up >viruses that are embedded in a PKLITE, DIET or whatever file. Also, some programs (Qedit comes to mind) have configuration programs that work by directly modifying the executable. If the executable is compressed, the configuration program probably won't work, and you'll have to decompress, run the config program, and recompress any time you want to change any of the defaults (screen colors, etc.). -- Paul Secinaro | Synthetic Vision and Pattern Analysis Laboratory pss1@kepler.unh.edu | Department of Computer and Electrical Engineering p_secinaro@unhh.unh.edu | University of New Hampshire (603) 862-3287
ressler@CS.Cornell.EDU (Gene Ressler) (06/27/91)
In article <1991Jun26.193811.24507@mercury.cair.du.edu> bstocker@diana.cair.du.edu (Bob Stocker) writes: >>As far as I know, no catches. Obviously, it doesn't work with some files. >> >There is one possible catch: Most virus scanners won't pick up >viruses that are embedded in a PKLITE, DIET or whatever file. Will these EXE compressors work if the EXE contains overlays? If so, how do they do it? Just curious. Gene
ericb@hplsla.HP.COM (Eric Backus) (06/27/91)
>>I just got a neat program called PKLITE version 1.05 and have decreased >>my hard disk usage by 4 Meg. What's tha catch (aside from the obvious >>extra second or two it take to load a exe)? Are there any gotcha's >>associated with using PKLITE? E-mail responses are fine, let's not >>clutter the net. >As far as I know, no catches. Obviously, it doesn't work with some files. Catches: 1. Compressed files take longer to execute (the bigger the executable, the bigger the delay). 2. Files which try to modify their own executable (to create a registered version, for example) will probably no longer work. But you can just uncompress them when you want to do this. 3. Windows 3.0 executables can't be compressed. 4. Some executables with overlays can't be compressed - but I've found that many of them work fine. 5. If the uncompressed version has a virus, compressing it probably hides the virus from most virus scanners. 6. Files which check for virus contamination usually refuse to run if you compress them. >What I'd like to know is what the comparison (on the usual criteria) is >between the various EXE compressors. (Diet, PKlite, LHEXE) >I've been using LHEXE (I think that's the name; it seems to have slipped >my mind - ANyway, it's the one from France) and it seems to work OK. >Just wondering if any of the others are any better... I've never done a REAL test, but here are my impressions based on playing with Diet, PKLite, and LZEXE. They will all compress within a few percent of each other. LZEXE seems to do slightly worse. PKLite seems to do slightly better. PKLite seems to be slightly faster at unpacking when you execute the file. Diet seems to be slightly faster at compressing the original. All three can be undone if you decide that you don't want the executable compressed anymore, but LZEXE does NOT restore the original exactly. Diet understands about disk cluster sizes and won't bother replacing a file if the compressed version uses the same number of disk clusters (not sure if PKLite or LZEXE do this). I believe that Diet provides a TSR which intercepts disk reads and writes, allowing you to keep data files in compressed form on disk, but I've never tested that. Personally, I use Diet. It works very well. -- Eric Backus ericb%hplsla@hplabs.hp.com (206) 335-2495
cpm5479@zeus.tamu.edu (Christopher Menzel) (06/27/91)
In article <1991Jun26.213817.25508@cs.cornell.edu>, ressler@CS.Cornell.EDU (Gene Ressler) writes...
=>Will these EXE compressors work if the EXE contains overlays?
=>If so, how do they do it? Just curious.
PKLITE won't; it warns you when an executable file contains internal overlays,
and lets you abort the compression.frisk@rhi.hi.is (Fridrik Skulason) (06/27/91)
>What I'd like to know is what the comparison (on the usual criteria) is >between the various EXE compressors. (Diet, PKlite, LHEXE) The compressors I know of are PKLITE, LZEXE, DIET, ICE, TINYPROG and EXEPACK. I believe there may also be one named AXE, but it is a commercial program, not shareware or freeware like the others. I was looking at the programs because my virus scanner has to be able to recognize the packed programs, but not because I was interested in the performance. Nevertheless, I have some observations. Don't bother with EXEPACK - low compression ratio, and it will only compress EXE files. LZEXE gets a high compression ratio, but it can only handle exe files directly, although there is an utility included for converting COM files to EXE files, so they can be compressed as well. PKLITE seemed always to be able to handle files containing overlays without problems - at least better than the other programs, so I would generally recommend it. ICE is also able to compress data files, and unpack them dynamically when you read from them. DIET has a serious problem when compressing files containing overlays, but generally it had the highest compression ratio. -frisk
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (06/28/91)
In article <11230004@hplsla.HP.COM> ericb@hplsla.HP.COM (Eric Backus) writes: | Catches: | 1. Compressed files take longer to execute (the bigger the | executable, the bigger the delay). I assume you mean that they take longer to load, I can't see any theory which would make them run more slowly. And, as someone noted here recently, I many cases they load faster off a floppy, since the CPU is faster than the i/o. I'm not disagreeing, but trying to clarify. I recently compressed a bunch of stuff to make it fit on an emergency boot floppy, and it does load a bit faster on a fast machine. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) GE Corp R&D Center, Information Systems Operation, tech support group Moderator comp.binaries.ibm.pc and 386-users digest.
carlf@agora.rain.com (Carl Fago) (06/28/91)
In article <11230004@hplsla.HP.COM> ericb@hplsla.HP.COM (Eric Backus) writes: >Catches: > 1. Compressed files take longer to execute (the bigger the > executable, the bigger the delay). What I have found is that even with a slow machine (8088 at 4.77 MHz) the time savings in disk reads during loading substantially makes up for any executable slow down while decompressing. Maybe its my imagination but it sure seems faster overall to me. -- +---------------------------------------------+------------------------------+ | *-=Carl=-* INTERNET - carlf@agora.rain.com | Time is nature's way to keep | | DELPHI - WULFGAR | everything from happening | | Carl Fago Portland, OR | all at once. -anon. |
ericb@hplsla.HP.COM (Eric Backus) (06/29/91)
>| Catches: >| 1. Compressed files take longer to execute (the bigger the >| executable, the bigger the delay). > > I assume you mean that they take longer to load, I can't see any >theory which would make them run more slowly. And, as someone noted here >recently, I many cases they load faster off a floppy, since the CPU is >faster than the i/o. Right, that's what I meant. -- Eric Backus ericb%hplsla@hplabs.hp.com (206) 335-2495
mrs@netcom.COM (Morgan Schweers) (06/29/91)
Greetings,
The SCAN and NETSCAN programs will scan inside of LZEXE'd and PKLITE'd
programs, and we may be supporting Diet in the future. (Not sure about
that one yet.) If a virus has been compressed, it will be detected.
Another thing to look at (between LZEXE and the rest of them) is that
LZEXE is truly freeware. If you wish to commercially distribute software
that has been LZEXE'ed, you can. You cannot do this with either PKLITE,
or AXE. I don't know the status of all the others, but the LZEXE fits
best with the GNU concept. *grin* (Guess which I use?)
(As a side note: AXE was the first, originally by SEA. It didn't
fly very well, and it's compression was abysmal. It was also commercial
(as befits SEA, of course.) LZEXE came next, and was written by
Fabrice Bellard of France. It's not updated much anymore but it is
the freest of all the packages. PKLite is a good compressor, but
really wins in the area of being able to decompress exactly the file
you compressed. It also wins because it's able to handle internal
overlays better. It, however, costs. I haven't used DIET, or any of
the others mentioned by frisk.)
I imagine there will be wars over this, like there have been over
the various compression programs. Suffice to say, it depends on where
your priorities lay.
-- Morgan Schweers
--
mrs@netcom.com | Morgan Schweers | Good code, good food, good sex. Is
ms@gnu.ai.mit.edu| These messages | anything else important? -- Freela
Kilroy Balore | are not the +--------------------------------------
Freela | opinion of anyone.| I *AM* an AI. I'm not real...valley@gsbsun.uchicago.edu (Doug Dougherty) (06/29/91)
mrs@netcom.COM (Morgan Schweers) writes about EXE compressors: > (As a side note: AXE was the first, originally by SEA. It didn't >fly very well, and it's compression was abysmal. It was also commercial >(as befits SEA, of course.) LZEXE came next, and was written by >Fabrice Bellard of France. It's not updated much anymore but it is >the freest of all the packages. PKLite is a good compressor, but >really wins in the area of being able to decompress exactly the file >you compressed. It also wins because it's able to handle internal >overlays better. It, however, costs. I haven't used DIET, or any of >the others mentioned by frisk.) Most of the responses I have gotten to my query about this (which is better???) have said PKLITE and said so because of the ability to restore the original. 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. This leads me to ask, however, ... Question: If not to the original, what does LZEXE recontruct to? Something functionally similar or what? -- (Another fine mess brought to you by valley@gsbsun.uchicago.edu)
chanel@mensa.usc.edu (chanel summers) (06/30/91)
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
mrs@netcom.COM (Morgan Schweers) (06/30/91)
Some time ago chanel@mensa.usc.edu (chanel summers) happily mumbled: >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. > Greetings, Actually it's not that silly. You keep the original disks that your programs came on, don't you? It's basically the same. I keep a set of HD 3.5" disks which contain the originals of my executables. (named *.OLD, of course.) I agree, mostly, with Doug. It's really not much of a selling point. UNLZEXE was *NOT* (as far as I could tell) written by the same person who wrote LZEXE. Furthermore, it's not always right about the uncompression. However, there is rarely a reason to uncompress your executables. (Unless you're using a virus scanner which doesn't support whichever format you're using.) However, this brings up a *MAJOR* reason to at least keep backups. If, for some reason, your copies of the .EXE files get damaged (FAT problems, a wild program, a virus, whatever) you're stuck. Obviously if you have backups you're fine. (*PLUG PLUG*! MAKE BACKUPS OFTEN!) If you don't, then at least maybe you'll have backups of your executables, and you'll be able to use them. This too may sound silly, I suppose. However, I *DO* keep .ZIP copies of all the software I pick up backed up on floppies. (Yes, a *LOT* of floppies.) However, it's only the software I decide to use. This saves me a lot of time in doing backups. (Especially since I devoted a drive to my utility software. I no longer have to back that drive up.) It doesn't help with apps, though, since the *MOST* important thing to do is to keep the data safe. That I do also (along with my code) every night. Do I delete the files after I've zipped them? Of course not! I need them to do work the next day. Anyhow, it's all a matter of taste. Each program (PKLITE, LZEXE, Diet, etc.) has it's own features which make it a good program. However, the features are usually not related to the compression, but to policy, or features, or what-have-you. No, it's not really free. LZEXE is free, but UNLZEXE isn't perfect. PKLITE costs, but PKLITE -x *DOES* work almost perfectly. I think, however, that whatever program you choose you've got to thank Fabrice Bellard for making the concept popular. A stroke of genius, frankly. >Chanel -- Morgan Schweers -- mrs@netcom.com | Morgan Schweers | Good code, good food, good sex. Is ms@gnu.ai.mit.edu| These messages | anything else important? -- Freela Kilroy Balore | are not the +-------------------------------------- Freela | opinion of anyone.| I *AM* an AI. I'm not real...
pshuang@athena.mit.edu (Ping-Shun Huang) (07/01/91)
In article <1991Jun29.150110.19766@midway.uchicago.edu> valley@gsbsun.uchicago.edu (Doug Dougherty) writes: > Question: If not to the original, what does LZEXE recontruct to? > Something functionally similar or what? I think UNLZEXE decompresses the previously-compressed .EXE file to the same thing that the little header on it would have decompressed into memory. So if the .EXE file doesn't work for whatever reasons, the UNLZEXE'd version wouldn't load correctly, either. I do not know, however, how PKLITE does a better job of restoring the original .EXE than UNLZEXE does -- not that I'm not curious, just not curious enough to try to follow what PKLITE is doing, machine instruction at a time. Anyone know? -- Above text where applicable is (c) Copyleft 1991, all rights deserved by: UNIX:/etc/ping instantiated (Ping Huang) [INTERNET: pshuang@athena.mit.edu]