pottera@cs.glasgow.ac.uk (Alan T Potter) (04/06/90)
I recently pulled down LZEXE91.(ARC? ZIP? - can't remember) from Simtel20. This package compresses .EXE files on disk, then automatically decompresses them when they are loaded into memory. Having tried it on a couple of .EXE files, I am *very* impressed, and intend to start using it for all of my .EXEs. However, I am still wary - you don't get something like this for nothing! Are there any 'gotchas' I should beware of? Does anyone have any bad experiences of using the system? Thanks, Alan -- | GM7GLJ | Alan T Potter, SH, Comp Sci, The University, Glasgow, UK G12 8QQ | | Janet : pottera@uk.ac.glasgow.cs | USEnet : mcsun!cs.glasgow.ac.uk!pottera | | ARPAnet: pottera@cs.glasgow.ac.uk | Comp Sci, Glasgow Univ, Scotland, UK | Oh, Isn't your life extermely flat with nothing whatever to grumble at! - WSG
wjin@cs.purdue.EDU (Woochang Jin) (04/08/90)
In article <4953@vanuata.cs.glasgow.ac.uk> pottera@cs.glasgow.ac.uk (Alan T Potter) writes: >I recently pulled down LZEXE91.(ARC? ZIP? - can't remember) from Simtel20. >This package compresses .EXE files on disk, then automatically decompresses >them when they are loaded into memory. Having tried it on a couple of >.EXE files, I am *very* impressed, and intend to start using it for all >of my .EXEs. >However, I am still wary - you don't get something like this for nothing! >Are there any 'gotchas' I should beware of? Does anyone have any bad >experiences of using the system? I don't see anything wrong unless the .EXE file checks itself or other .EXE files while it is running. ------ W. Jin
melkins@jarthur.Claremont.EDU (Michael R.G. Elkins) (04/08/90)
In article <4953@vanuata.cs.glasgow.ac.uk> pottera@cs.glasgow.ac.uk (Alan T Potter) writes: >However, I am still wary - you don't get something like this for nothing! >Are there any 'gotchas' I should beware of? Does anyone have any bad >experiences of using the system? Well, it works fine on some the programs, but there are a few that just 'stopped' working after a few uses, and now I have to get them *again*. -me -- +---------------------+-------------------------------+-----------------------+ | Michael R.G. Elkins | melkins@jarthur.claremont.edu | "Aack!!! | | Platt Campus Center | ...uunet!jarthur!melkins | It's not just a word, | | Harvey Mudd College | melkins@hmcvax.claremont.edu | but a state of mind." | | Claremont, CA 91711 | melkins@hmcvax.bitnet | --the Bard's Tale II | +-----------------------------------------------------+-----------------------+ | DISCLAIMER: Nobody cares what the hell I say anyway. | +-----------------------------------------------------------------------------+
sbnicol@rose.waterloo.edu (Scott Nicol) (04/08/90)
In article <5954@jarthur.Claremont.EDU> melkins@jarthur.Claremont.EDU (Michael R.G. Elkins) writes: >In article <4953@vanuata.cs.glasgow.ac.uk> pottera@cs.glasgow.ac.uk (Alan T Potter) writes: >>However, I am still wary - you don't get something like this for nothing! >>Are there any 'gotchas' I should beware of? Does anyone have any bad >>experiences of using the system? > >Well, it works fine on some the programs, but there are a few that just >'stopped' working after a few uses, and now I have to get them *again*. It works fine for most .EXE files (and .COM files too, using the same author's COMTOEXE program). The program ALWAYS writes a backup of the original file (with the extension .OLD), so you shouldn't have any trouble recovering the original if the compressed program doesn't work (I'm assuming that you don't erase the .OLD file before you test the new .EXE file). Also, there is an UNLZEXE program, which should be able to recover the original from the compressed program. Any program that uses overlays is definitely out, though (the program warns you about possible overlays). - Scott Email: sbnicol@rose.waterloo.edu -or- ...!uunet!watmath!rose!sbnicol SlowMail: 546 FallingBrook Dr., Waterloo, Ont., Canada, N2L 4N4. Phone: (519) 725-1980
LC.YRS@forsythe.stanford.edu (Richard Stanton) (04/08/90)
In article <23005@watdragon.waterloo.edu>, sbnicol@rose.waterloo.edu (Scott Nicol) writes: >file). Also, there is an UNLZEXE program, which should be able to >recover the original from the compressed program. > I had problems using UNLZEXE on MS-KERMIT 3.00 which I had compressed using LZEXE .90 (NOT .91). It reported everything being OK, and knew which compressor version I had used, but the newly decompressed program did not work. I haven't had this with any programs compressed with the new version of LZEXE, and I use this for a lot of my large .EXE files. It seems great. Richard Stanton
rreiner@yunexus.UUCP (Richard Reiner) (04/08/90)
In article <4953@vanuata.cs.glasgow.ac.uk> pottera@cs.glasgow.ac.uk (Alan T Potter) writes: >I recently pulled down LZEXE91.(ARC? ZIP? - can't remember) from Simtel20. >However, I am still wary - you don't get something like this for nothing! >Are there any 'gotchas' I should beware of? Does anyone have any bad >experiences of using the system? It's just the usual case: you're trading speed for space. The only 'gotcha', other than the incompatibility with software that keeps overlays in the .exe file, is greatly increased startup time. I'd only reccomend this solution (and the other more elegant variants, like Disk Doubler software, which compresses *all* files on the disk, and hooks the disk read services to uncompress on demand) if you have more cpu speed than disk space -- if you're running a 20M disk on a 386/33, for instance. --richard
"Arnold G. Gill" <GILLA@QUCDN.QueensU.CA> (04/08/90)
In article <5954@jarthur.Claremont.EDU>, melkins@jarthur.Claremont.EDU (Michael R.G. Elkins) says: > >In article <4953@vanuata.cs.glasgow.ac.uk> pottera@cs.glasgow.ac.uk (Alan T >Potter) writes: >>However, I am still wary - you don't get something like this for nothing! >>Are there any 'gotchas' I should beware of? Does anyone have any bad >>experiences of using the system? > >Well, it works fine on some the programs, but there are a few that just >'stopped' working after a few uses, and now I have to get them *again*. Gee, can you say `BACKUP'?? ------- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Arnold Gill | | | Queen's University at Kingston | If I hadn't wanted it heard, | | BITNET : gilla@qucdn | I wouldn't have said it. | | X-400 : Arnold.Gill@QueensU.CA | | | INTERNET : gilla@qucdn.queensu.ca | | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
"Arnold G. Gill" <GILLA@QUCDN.QueensU.CA> (04/08/90)
In article <8847@lindy.Stanford.EDU>, LC.YRS@forsythe.stanford.edu (Richard Stanton) says: > >In article <23005@watdragon.waterloo.edu>, >sbnicol@rose.waterloo.edu (Scott Nicol) writes: >>file). Also, there is an UNLZEXE program, which should be able to >>recover the original from the compressed program. >> >I had problems using UNLZEXE on MS-KERMIT 3.00 which I had >compressed using LZEXE .90 (NOT .91). It reported everything being >OK, and knew which compressor version I had used, but the newly >decompressed program did not work. I haven't had this with any >programs compressed with the new version of LZEXE, and I use this >for a lot of my large .EXE files. It seems great. Now that people have mentioned it, I always wondered if one could reverse the LZEXE process. Where does one get UNLZEXE? I especially liked the change to MS-Kermit - from 131000 to 75000 bytes, and it still works as far as I can tell. ------- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Arnold Gill | | | Queen's University at Kingston | If I hadn't wanted it heard, | | BITNET : gilla@qucdn | I wouldn't have said it. | | X-400 : Arnold.Gill@QueensU.CA | | | INTERNET : gilla@qucdn.queensu.ca | | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
) (04/09/90)
In article <90098.132427GILLA@QUCDN.BITNET>, GILLA@QUCDN.QueensU.CA (Arnold G. Gill) writes: > Now that people have mentioned it, I always wondered if one could > reverse the LZEXE process. Where does one get UNLZEXE? > > I especially liked the change to MS-Kermit - from 131000 to 75000 bytes, > and it still works as far as I can tell. > ------- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > | Arnold Gill | | > | Queen's University at Kingston | If I hadn't wanted it heard, | > | BITNET : gilla@qucdn | I wouldn't have said it. | > | X-400 : Arnold.Gill@QueensU.CA | | > | INTERNET : gilla@qucdn.queensu.ca | | > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- I got my copy from Simtel20. -- ------------------------------------------------------------------------------- Santanu Sircar BITNET: ssircar@umaecs.bitnet University of Massachusetts/Amherst INTERNET: ssircar@ecs.umass.edu |------------------------------------------------------------------------------| "A pig ate his fill of acorns under an oak tree and then started to root around the tree. A crow remarked, `You should not do this. If you lay bare the roots, the tree will wither and die.' `Let it die,' said the pig. `Who cares so long as there are acorns?'" -Anonymous ------------------------------------------------------------------------------
LC.YRS@forsythe.stanford.edu (Richard Stanton) (04/09/90)
In article <90098.132427GILLA@QUCDN.BITNET>, GILLA@QUCDN.QueensU.CA (Arnold G. Gill) writes: >Where does one get UNLZEXE? It's also on SIMTEL Richard Stanton pstanton@gsb-what.stanford.edu
eggbert@bucsf.bu.edu (Eugene Wang) (04/10/90)
In article <4953@vanuata.cs.glasgow.ac.uk> pottera@cs.glasgow.ac.uk (Alan T Potter) writes: >However, I am still wary - you don't get something like this for nothing! >Are there any 'gotchas' I should beware of? Does anyone have any bad >experiences of using the system? I've been using LZEXE for two weeks now, and I've not run into any problems at all. As mentioned, the only problems occur with overlayed programs, programs that save options, like configurations, within the program itself, and programs that verify themselves before running. Everyone should be use the latest version .91 since the earlier version would create compressed files that would take more memory than the original program, because of the way Microsoft compilers can pack .EXE files. Get a copy of UNLZEXE. It should have a copy of the source code for UNLZEXE so that the curious can gain a little insight into what LZEXE does. Another freeware program, LZESHELL, will make working with LZEXE a lot easier. It is a shell that automates the process of converting .COM files, unpacking Microsoft EXEPACK files, running UNLZEXE, and translates the French prompts into English all at one time. For the security conscious, the various virus-checking programs will not detect a virus in a LZEXE-compressed program, obviously since the virus would have been compressed into something else. There are also programs available that will scan for the presence of a LZEXE-compressed file. Eugene Wang@bucsf.be.edu
nelson@sun.soe.clarkson.edu (Russ Nelson) (04/10/90)
In article <9770@yunexus.UUCP> rreiner@yunexus.UUCP (Richard Reiner) writes: In article <4953@vanuata.cs.glasgow.ac.uk> pottera@cs.glasgow.ac.uk (Alan T Potter) writes: >I recently pulled down LZEXE91.(ARC? ZIP? - can't remember) from Simtel20. >However, I am still wary - you don't get something like this for nothing! >Are there any 'gotchas' I should beware of? Does anyone have any bad >experiences of using the system? It's just the usual case: you're trading speed for space. The only 'gotcha', other than the incompatibility with software that keeps overlays in the .exe file, is greatly increased startup time. I wouldn't say "greatly increased". In fact, I found that tc loaded at the same speed straight off my hard disk, compressed or not. Of course, out of the disk cache, uncompressed was faster. Equally obvious, compressed was faster off the floppy... -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 Violence never solves problems, it just changes them into more subtle problems
doak@cadnetix.COM (Doak Heyser) (04/10/90)
In article <9770@yunexus.UUCP> rreiner@yunexus.UUCP (Richard Reiner) writes: >It's just the usual case: you're trading speed for space. The only >'gotcha', other than the incompatibility with software that keeps >overlays in the .exe file, is greatly increased startup time. I'd ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Are we using the same program? I'm running an XT 8086 pig and I can't tell any difference with startup time. IMHO, startup time is not a factor. ******************************************************************************* doak@cadnetix.com | cadnetix!doak {nbires,boulder,ncar}!cadnetix!doak
rreiner@yunexus.UUCP (Richard Reiner) (04/11/90)
nelson@sun.soe.clarkson.edu (Russ Nelson) writes: >I wouldn't say "greatly increased" [startup time of LZEXE'd files] You're right; I spoke before I had done any careful measurements. Here's what my measurements showed: Program: jove.exe. Uncompressed size: 104K. Compressed size: 64K. Test: load and immediately exit. Hardware: 12MHz v20, 28ms 240K/sec disk. Times: uncompressed compressed 2.4 sec 3.5 sec Hardware: 4.77 Mhz 8088, same disk: Times: uncompressed compressed 5.1 sec 7.6 sec Hardware: 4.77 MHz 8088, 360K floppy drive: Times: uncompressed compressed 10.7 sec 10.8 sec --richard
msschaa@cs.vu.nl (Schaap MS) (04/11/90)
In article <9770@yunexus.UUCP> rreiner@yunexus.UUCP (Richard Reiner) writes: >In article <4953@vanuata.cs.glasgow.ac.uk> pottera@cs.glasgow.ac.uk (Alan T Potter) writes: >>I recently pulled down LZEXE91.(ARC? ZIP? - can't remember) from Simtel20. >>However, I am still wary - you don't get something like this for nothing! >>Are there any 'gotchas' I should beware of? Does anyone have any bad >>experiences of using the system? > >It's just the usual case: you're trading speed for space. The only >'gotcha', other than the incompatibility with software that keeps >overlays in the .exe file, is greatly increased startup time. I'd >only reccomend this solution (and the other more elegant variants, >like Disk Doubler software, which compresses *all* files on the disk, >and hooks the disk read services to uncompress on demand) if you have >more cpu speed than disk space -- if you're running a 20M disk on a >386/33, for instance. > I've used LZEXE a lot of times, (on an 8086 machine) and I have never noticed more than about half a second delay for loading an EXE file. So that is definitely NO reason not to use LZEXE. Michael.
"Arnold G. Gill" <GILLA@QUCDN.QueensU.CA> (04/12/90)
Is the use of LZEXE a partial safeguard against viruses? With the encoded file, is a virus able to simply infect it as it would a normal .EXE file? Or does that not make much of a difference? I was just thinking that the decoding step would corrupt the virus and make it unworkable - essentially kill it. Or is it not just that simple? ------- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Arnold Gill | | | Queen's University at Kingston | If I hadn't wanted it heard, | | BITNET : gilla@qucdn | I wouldn't have said it. | | X-400 : Arnold.Gill@QueensU.CA | | | INTERNET : gilla@qucdn.queensu.ca | | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
nacer@hpmcaa.mcm.hp.com (Abdenacer Moussaoui) (04/12/90)
How about a set of tools that would archive a whole package directory? Say I have software in \123 \AUTOCAD \VENTURA \WINDOW which I use once a while, it would be nice to have a program run at regular intervals that would compress these directories (say using ZIP) if they have not been reference since X days. Another utiliy would uncompress them on demand after checking there is enough disk space before starting the de-compression. This would provide more space then just compessing binaries. Note that some software install themselves in multiple root directories say \GEMBOOT \GEMSYS \GEMAPPS
frank@hpuamsa.UUCP (Frank Slootweg CRC) (04/12/90)
Abdenacer Moussaoui writes: > Say I have software in \123 \AUTOCAD \VENTURA \WINDOW which I use once > a while, it would be nice to have a program run at regular intervals > that would compress these directories (say using ZIP) if they have not > been reference since X days. Another utiliy would uncompress them on > demand after checking there is enough disk space before starting the > de-compression. This would provide more space then just compessing > binaries. I think you are looking for DCOMPRES and PCMANAGE from PC Magazine. I have never used them and have no detailed reference at the moment (I am in a hurry to go on vacation). Mail me if you can't find it anywhere. Frank Slootweg, frank@hpuamsa.hp.com
rreiner@yunexus.UUCP (Richard Reiner) (04/12/90)
GILLA@QUCDN.QueensU.CA (Arnold G. Gill) writes: > Is the use of LZEXE a partial safeguard against viruses? With the >encoded file, is a virus able to simply infect it as it would a normal .EXE >file? Or does that not make much of a difference? I was just thinking that >the decoding step would corrupt the virus and make it unworkable - essentially >kill it. Or is it not just that simple? The decoding step might kill it -- one would have to probe into LZEXE internals to know for sure. However, a bigger issue is that the compression would make infected executables appear clean to ViruScan and simialr programs. There have been reports of this kind of thing, involving AXE, which is a (much slower) functional equivalent of LZEXE. --richard
CMH117@psuvm.psu.edu (Charles Hannum) (04/14/90)
In article <9960@yunexus.UUCP>, rreiner@yunexus.UUCP (Richard Reiner) says: > > AXE, which is a (much >slower) functional equivalent of LZEXE. BTW: The reason that AXE is much slower is that it uses a better compression algorithm (generates smaller files), but in exchange sacrifices some of the startup speed of LZEXE, which appears to do merely a simple LZW compression of the executable. I don't use AXE because it's just TOO damned slow. But on a reasonably fast machine, it might be worthwhile if it cuts the executable size down enough. Virtually, - Charles Martin Hannum II "Klein bottle for sale ... inquire within." (That's Charles to you!) "To life immortal!" Please send mail to: "No noozzzz izzz netzzzsnoozzzzz..." hannum@haydn.psu.edu "Mem'ry, all alone in the moonlight ..."
pvarner@blackbird.afit.af.mil (Paul A. Varner) (04/15/90)
In article <90101.182631GILLA@QUCDN.BITNET> GILLA@QUCDN.QueensU.CA (Arnold G. Gill) writes: > > Is the use of LZEXE a partial safeguard against viruses? Actually, it is my understanding that LZEXE can be a harbor for viruses. The reason is that a virus can be put into a program and then compressed. Once the program is compressed, I know of no virus checker that will find the virus. So I would recommend that the compressed exe files be uncompressed and then run through a virus checker, and then recompressed. Standard Disclaimer applies. Paul Varner