💾 Archived View for spam.works › mirrors › textfiles › programming › compfile.txt captured on 2023-07-22 at 20:42:58.
⬅️ Previous capture (2023-06-16)
-=-=-=-=-=-=-
======================================================= COMPRESSING YOUR EXECUTABLES --- SOMETHING FOR NOTHING? ======================================================= by Dickford Cohn Ah yes, the current "rage" in PC-land: EXECUTABLE FILE COMPRESSION! Does it work? Yes! Very well! Is it "something for nothing?" Well, you be the judge --- in my experience, it is VERY useful. This article is intended to "corral", in one place, most of the "bits and pieces" of what is known about these programs and to offer performance comparisons and operating tips gleaned from those who have used them. This article centers upon the THREE most common methods available to us --- those that I've used and tested. --WHAT IS EXECUTABLE FILE COMPRESSION? It is simply a method by which an EXECUTABLE file (.COM or .EXE) is made small- er on disk (outwardly similar to PKZIP). If you have a lot of executables, you can save substantially on disk space. When a file is "compressed" a small addi- tion is made to the code that UNCOMPRESSES the executable to "full size" when it is loaded into RAM. It's that simple (yeah, the programming is a LOT more involved than that!) --IS EXECUTABLE FILE COMPRESSION SOMETHING I CAN USE? It depends on how you use your system and what you have on it. For example, if your PC emulates your office PC in that you have 50-60 executables and you pri- marily have spreadsheet/word processing programs on your hard disk, an execut- able file compressor would probably not be worth the expense of a download. On the other hand, if your system has LOTS of executables, executable file com- pression is quite effective in re-capturing valuable disk space. In my own case I have almost 950 executables that, at normal size, take up almost 25Meg of disk space. I have compressed over 500 of these executables, re-capturing almost 9Meg of disk space --- representing about 15% of my TOTAL OCCUPIED DISK SPACE! TWO IMPORTANT NOTES: (1) Executable file compression is NOT a replacement for other disk management techniques (i.e. good housekeeping): It IS an effective tool to add to your arsenal. (2) Executable file compression is NOT A GOOD IDEA in the office setting --- unless YOU are SOLELY responsible for your PC: In the hands of the uninitiated, these programs can be dangerous. --IS EXECUTABLE FILE COMPRESSION DANGEROUS? ANY program that can OVERWRITE an existing file is dangerous! You MUST have a BASIC UNDERSTANDING of what you are doing and employ the standard safeguards that ANYONE would employ (i.e. backups) when dealing with programs that have this capability. With that in mind, it must be said that ALL the programs des- cribed here in detail are thoughtfully designed and have certain safeguards built in. However, there is NO EXCUSE for NOT READING THE DOCUMENTATION --- it is BRIEF and CONCISE. ===================================== ADVANTAGES OF COMPRESSING EXECUTABLES ===================================== There are TWO distinct advantages to compressing executable files: 1. You can achieve a substantial savings in disk space by using these util- ities: Typically, you can re-capture 35-40% of the disk space now occupied by your executables. You have to determine if the OVERALL space gained is worth the effort. 2. A less-heralded but equally significant benefit of executable compression is that compression (a form of encryption) offers some protection against viruses that overwrite program code. Since the "file header" is relocated, the virus can't find it (to attach itself); hence the virus cannot over- write code. However, the executable is still "externally infected" --- it CAN load the little critter into RAM, ready to "pounce" on some uncompress- ed executable. At least, your executable is not TRASHED. ====================== GENERAL TIPS FOR USAGE ====================== 1. DO NOT COMPRESS DOS's COMMAND.COM, or ANY CRITICAL DOS FILES --- if you don't know which DOS files are CRITICAL, don't compress ANY OF THEM. (Watch for my upcoming article, HARD DISK MANAGEMENT TIPS, which will include a section on DOS files you can "dump" or replace with "modern" equivalents: Saves about 300k on your disk!) 2. If you choose to compress executables at all, pick ONE method and stick with THAT ONE. The confusion caused by "mixing 'em up" is not worth it. 3. When compressing executables for the first time, or experimenting, create a separate directory and COPY your "target" executable to it (this precludes damage caused by "typos" at the command line and such --- if you screw up, all you have to do is RE-COPY the file and try again.) When you are satisfied with the result, RENAME the ORIGINAL executable, and copy the COMPRESSED executable to its original directory. Now, TEST the "new" executable --- call up your program and see if ALL of its functions work. I mention this because SOME programs will compress just fine (i.e. with NO WARNINGS from the compression program) and yet they MAY NOT work properly, if AT ALL. 4. Some programs have a companion "configuration" program that WILL NOT WORK on a compressed executable. Just UNCOMPRESS the executable, re-configure (via the config program) what you want and then RE-COMPRESS the executable. ================= WHAT'S OUT THERE? ================= At this writing, I am aware of EIGHT executable file compression programs: - AXE ...A program from Systems Enhancement Associates. This is a commercial software package ($65) that, outwardly at least, offers no significant advantages over other methods (see COMPARISON) and is NOT reviewed here. - EXEPACK ...A MicroSoft product, NOT generally available but packaged with certain software (MASM 5.1). Although, apparently the FIRST such program of this type (1986 copyright), it is NOT in the same league as those reviewed here, although you are LIKELY to encounter this method with some executables. - DIET ...A program by the author of LEXEM (functions like PKZIP and apparently in wide usage in Japan). DIET is reviewed here. - LEXEM ...Not currently distributed in the U.S. (Likewise, you are NOT likely to encounter files compressed with this method) - LZEXE ...By Fabrice Bellard; the first generally available program of this type --- reviewed here. - PKLITE ...Shareware from PKWARE ($46) --- reviewed here. - SHRINK ...An experimental method, not in the same class as those re- viewed but interesting to those who may want to delve into the "mysteries" of compression. - TINYPROG ...Shareware from Tranzoa Associates. Only slightly more eff- ective than EXEPACK: No UNCOMPRESS available. Not reviewed. ==================== PROGRAM DESCRIPTIONS ==================== +------------+ The "newest" of the three tested, by Teddy Matsumoto, the author | DIET10.EXE | of LEXEM an "archive" program used in Japan. This program app- +------------+ ears well written -BUT- by the authors own subtle admonition, it is experimental. It SEEMED to work slightly better than the other two -BUT- and this is a big BUT: IT DOES NOT CHECK FOR EXECUTABLES THAT USE OVERLAYS --- IT JUST COMPRESSES THEM! YOU WILL NOT BE ABLE TO RESTORE THE EXECUTABLE WITH THE '-R' SWITCH, EITHER --- THE FILE IS DESTROYED! (That's WHY you maintain back-ups). The program DOES ALLOW you to make back-ups however, so you should be safe. When I attempted to compress a 1 Meg+ executable (that I knew used overlays), the error that came up was "insufficient memory" (more about this later). DIET also compresses using wildcards and WILL COMPRESS virtually any file EXCEPT one that is already compressed by another program. PRICE: The current version on EXEC-PC (DIET10.ZIP) is **FREE** +------------+ Developed by Fabrice Bellard (current version is 0.91, backward | LZEXE.EXE | compatible with version 0.90). This program was the FIRST +------------+ generally available executable file compressor --- and is the most widely used (see SUPPORT PROGRAMS). It also is programmed with some forethought: For example, it can recognize the MicroSoft EXEPACK compression method in executables; it can UN-compress EXEPACK'd files and RE-compress them with it's own method (the savings is significant). It's error prompts work as advertised -BUT- they're too polite! For example, if you decide to go ahead and compress an executable that uses over- lays, you'll NEVER restore it with the un-compressor UNLZEXE.EXE However, since LZEXE DOES NOT OVERWRITE your ORIGINAL FILE, you are safe! LZEXE copies your original file to an ".OLD" exten- sion: You simple erase the "bad .EXE" and RENAME the ".OLD" file to an ".EXE" extension. The original program's prompts are in French (there is a program in English --- ENGLZEXE.ZIP): I would recommend LZESHELL to sensibly use LZEXE. LZEXE also com- presses .COM files, but it first converts them to .EXE files and THEN compresses them. This measurably slows down the process AND you CANNOT restore "converted" .EXE to .COM files (the .OLD file is STILL created, though). This program comes with LZEXE (the compressor), UPACKEXE.EXE (unpacks EXEPACK'd files) and COMTOEXE.EXE (converts .COM files to .EXE). You MUST also have UNLZEXE.EXE, by Kou Kurizono, to UN-compress LZEXE'd files! PRICE: The current version on EXEC-PC (LZEXE91.ZIP) original French version -OR- (ENGLZEXE.ZIP) English version, are **FREE** +------------+ Developed by PKWARE (the purveyors of PKZIP, et al) this program | PKLITE.EXE | is a textbook example of "completely developed" software. +------------+ Unlike the other two examples, there are no "cliffs" to fall over; no unforgiving "surprises". Performance was slightly less than the other two overall --- the difference is nominal. The elements I liked best are: This is a COMPREHENSIVE package, fea- turing a logical selection of command line options; it IS INTUITIVE; -AND- unlike the other two, it could COMPLETELY RE- CONSTRUCT an executable with overlays that it had COMPRESSED! This program compresses (and UN-compresses) .COM and .EXE only. PKLITE WILL NOT COMPRESS Windows Executables (A SAFETY FACTOR). PRICE: The current version on EXEC-PC (PKLTE103.EXE) costs **$46** =================== SUPPORTING PROGRAMS =================== The following is a PARTIAL listing of programs that provide support for the compression programs above (files on EXEC-PC): ? LZESHL21.ZIP - Excellent English Language shell for LZEXE 0.91 --- enables and TRANSLATES ALL functions of LZEXE from within. By Pete Petrakis **FREE** ? DRX100.ZIP - User-configurable shell, provides directory/subdirectory display of COMPRESSED/UNCOMPRESSED executables (AXE,DIET PKLITE, EXEPACK, LZEXE and TINYPROG). Allows you to sel- ect COMPRESS/UNCOMPRESS method: Offers "point-n-shoot" file selection. By Raymond T. Kaya **FREE** ? CHK4.ZIP - Re-directable compressed file reporter, with many report options. Now "sees" ALL compressed executables on the entire drive, by subdirectory. By John Land **FREE** ? UNLZEXE5.ZIP - REQUIRED FOR LZEXE. UN-compresses both versions of LZEXE (Vers .090/.091). By "Kou" Kurizono **FREE** Note that there are OTHER programs available, but these are the ones I've used, so I can attest to their reliability: They're all EXCELLENT! ======================= PERFORMANCE COMPARISONS ======================= The test data shown in the table(s) below are relative, and by no means, exhaustive: Timing was performed with a Turbo C++ shell that converts standard "timer ticks" to fractions of a second. I must stress that since you're likely to use these programs only once on a given executable, execution TIME is NOT A SIGNIFICANT FACTOR. Programs were also tested to see if the various safeguards outlined in the DOCS actually worked: I'm happy to report that they performed flawlessly in ALL cases. File/Original Size ----------------------- ....Compressed with.... ...UNcompressed with.. QWIK.EXE/8873 Bytes DIET LZEXE PKLITE DIET UNLZEXE PKLITE ----------------------- COMPRESSED SIZE 4937 5070 5164 -- -- -- TIME (seconds) 1.8 1.3 1.9 1.9 2.8 1.9 SIZE REDUCTION: 44% 43% 42% ============================================================================ ----------------------- ....Compressed with.... ...UNcompressed with.. FW.EXE/26510 Bytes DIET LZEXE PKLITE DIET UNLZEXE PKLITE ----------------------- COMPRESSED SIZE 20236 21131 20970 -- -- -- TIME (seconds) 1.9 2.6 2.8 2.2 3.8 2.8 SIZE REDUCTION: 24% 20% 21% ============================================================================ ------------------------- ....Compressed with.... ...UNcompressed with.. CSHOW1.EXE/89904 Bytes DIET LZEXE PKLITE DIET UNLZEXE PKLITE ------------------------- COMPRESSED SIZE 53584 52211 55572 -- -- -- TIME (seconds) 3.0 8.6 9.3 3.1 5.3 4.5 SIZE REDUCTION: 40% 42% 38% PERFORMANCE COMPARISONS (Continued) ------------------------- ....Compressed with.... ...UNcompressed with.. TURBO.EXE/156321 Bytes DIET LZEXE PKLITE DIET UNLZEXE PKLITE ------------------------- COMPRESSED SIZE 107350 110398 107765 -- -- -- TIME (seconds) 4.5 16.8 22.9 4.1 6.1 6.2 SIZE REDUCTION: 31% 29% 31% ============================================================================== SUMMARY: Average Time:(Secs/Kbyte) .0398 .1041 .1310 Average Size Reduction: 34% 33% 32% ============================== As you can see by this modest "test", ALL of these units performed about the same --- differences are negligible. Overall, DIET was nominally "quicker" AND compressed more "tightly" (for you performance enthusiasts). It WAS INTERESTING to NOTE that the effectiveness of the compression is apparently related to the development method (programming language) of the executable. Note, for example, the DIFFERENCE in the SIZE REDUCTION between QWIK.EXE and FW.EXE. I KNOW that FW.EXE is programmed entirely in ASSEMBLER, while QWIK.EXE is programmed in Turbo C++: I DON'T KNOW enough about the technical aspects of compression to comment intelligently on why this happens. One other item was noted: Compressed executables do SEEM to take a slight bit longer to do their thing --- anywhere from a fraction of a second to three seconds: This on a 16Mhz PS/2 --- the differential is GREATER on slower machines: (When tested on an IBM "Turbo" XT (8Mhz) --- execution time is proportionately slower). During the tests, PKLITE was used with the "create backup file" switch ON (strangely, it seemed to work faster that way). DIET was used BOTH ways (create backup/just overwrite) with no apparent difference in time. ====================== COMPARISON OF FEATURES ====================== DIET LZEXE PKLITE ------ ------ ------ ?-Tests for/Warns of Executables that use OVERLAYS NO(1) Yes(1) Yes(1) ?-Indicates File Already Compressed NO(2) Yes(2) Yes(2) ?-Identifies Compression Method NO(2) Yes(2) Yes(2) ?-Safeguards Against Compressing WINDOWS Executables NO NO Yes ?-Restores Compressed Executables that use OVERLAYS NO NO Yes ?-Automatic Back-Up of Original NO Yes NO ?-Back-Up Option (Switch) Yes NO Yes ?-Compresses Files OTHER than Executables Yes(3) NO NO ?-Compresses .COM and .EXE Yes Yes(4) Yes ?-Compresses ANY SIZE File NO(5) Yes Yes ?-UN-compresses Files it Compresses Yes NO(6) Yes ?-Support Limited Limited FULL ?-Documentation Good(7) Good(7) Excellent NOTES......................................................................... (1) Both PKLITE and LZEXE warn of files using overlays: DIET just OVERWRITES the TARGET file --- you MUST SPECIFY the "create backup" ('-O') option on the command line. This is a potentially fatal flaw with DIET 1.0! NOTES (Continued)............................................................. (1a)K. Okubo (on CIS) insists that DIET DOES NOT COMPRESS executables that use overlays --- that has NOT been my experience. (2) DIET and PKLITE simply state "file cannot be compressed" --- LZEXE can detect files compressed with EXEPACK, un-compress them and re-compress them with its own method: A valuable option with some commercial software. PKLITE now has a little utility that WILL identify its own compression method --- NONE of these utilities can identify compression methods OTHER than their own. (The shell DIRX takes up the slack here). (3) DIET can compress ANY file, executable or otherwise. HOWEVER, there is no visual indicator (e.g. a .DIE extension) to tell you that they ARE com- pressed (they are NOT usable in their compressed state --- they must be "manually" uncompressed, first). I'm hard pressed to come up with a use for this option: I suppose you COULD compress entire subdirectories that were seldom used, but this could get to be tricky; particularly if you moved the files to another directory or to diskette. PKZIP is much more useful in this regard than DIET -and- more intuitive. (4) LZEXE first must convert .COM files to .EXE files, slowing down the process of compression (I would "guesstimate" that it would be roughly double the time shown in the "time trials" but remember that .COM files are limited to 64k in size, so again, time is NOT significant). Also, you must remember that you cannot convert COMTOEXE'd .EXE files back to .COM! (5) DIET apparently differs from the other two in that it seems to bring the ENTIRE target file into RAM --- if the file size exceeds available memory, DIET produces an "insufficient memory" message and does not execute. Note that PKWARE's file WHATSNEW.103 offers another potential explanation. (6) In order to UN-compress LZEXE'd files, you MUST use UNLZEXE.EXE (see SUPPORTING PROGRAMS), which is NOT bundled with LZEXE.EXE (7) Documentation runs the gamut: The DOCS for DIET are GOOD but I don't feel they adequately warn of the pitfall of compressing files with overlays: In fact, the DOCS are ebullient and enthusiastic (I would be, too, if I had written the program). LZEXE's original DOCS are in French, so they are of limited value, at best. There IS an ENGLISH version on EXEC-PC that you may want to download. PKLITE's documentation is the usual THOROUGH job, filled not only with specifics about PKLITE, but also file compression in general and even compares PKLITE to LZEXE. It is understandably biased: More significantly, it is VERY informative. SUPPORT - Support for DIET consists of a CompuServe ID (in the documentation) to which you can address correspondence (E-Mail). To the best of my knowledge, you can't contact the author of LZEXE at all. PKWARE provides FULL SUPPORT for all its REGISTERED software and operates its own BBS. There are a considerable number of FREE/SHAREWARE packages that offer additional support for ALL these programs. ======================== A WORD ABOUT OVERLAYS... ======================== Well, you've seen the mention of "...executables that use overlays" throughout this text --- THAT IS INTENTIONAL: Quite a bit of today's commercial software have executable files which use overlays. OK...what are OVERLAYS? Overlays are SECTIONS of a program's function code, which are "read" into the executable "shell" as needed by the program. Confused? Let's use an analogy: Think of your executable as the HANDLE of a SOCKET WRENCH set and OVERLAYS as being the actual SOCKETS: You simply "switch" the sockets (over- lays) in and out as needed to perform the various functions you need. While all of the functions you might want to perform are at your fingertips, you can only perform ONE AT A TIME (i.e. you can use only ONE socket at a time). This is done primarily so that you have enough room in RAM to create/edit a file -AND- load your executable. Additionally, some programs are so large that not ALL of the program could be loaded into the RAM normally available on your system (e.g. Certain spreadsheet programs use overlays extensively --- actually the spreadsheet you're working on IS AN OVERLAY ITSELF.) When a file A WORD ABOUT OVERLAYS (Continued) compressor comes along, its "algorithms" determine that the file space in the "shell" is mostly EMPTY space and proceed to re-write the file header to the "correct" file size: A FATAL nicety! Now, there is NO ROOM LEFT for the "overlay" --- i.e. the spindle for the socket is GONE! (Yeah, I know this isn't a PERFECT analogy, but you get the drift.) FORTUNATELY, with two of the three programs mentioned (LZEXE and PKLITE) you are adequately WARNED that the executable uses overlays BEFORE you can proceed. ============================= WHAT ELSE TO WATCH OUT FOR... ============================= Some executables (sometimes called "runtime modules") have the ability to actually change their size while in memory --- they write additional code to THEMSELVES in order to accomplish certain tasks or to configure themselves according to options supplied by you. NONE OF THE ABOVE-MENTIONED PROGRAMS warns you of such executables (I have no idea how they could be programmed to do this --- that is WHY you EXPERIMENT in a TEST directory): The file will simply be "hashed"! This does not occur in all cases, but it DOES occur with TWO specific files I'll bet many of you have: (1) BRUN41.EXE by MicroSoft, bundled with all versions of CompuServe's CSHOW, and (2) GRASPRT.EXE, a "GRASP" (.GL) file "animator" from Paul Mace. There are OTHERS, such as MicroSoft's CV.EXE (CodeView --- part of MASM 5.1): WINDOWS "executables" should NEVER be compressed --- this includes Versions 3.0, WIN286 and WIN386. Also, you've noticed mention of EXEPACK. This is a program copyrighted by MicroSoft in 1985-86 (probably the FIRST executable file compressor). This program is used on certain executables in some commercial software and the EXEPACK.EXE program itself is bundled with some software (MASM 5.1). The purpose of EXEPACK is not clear: The explanation on Page 322 of "MicroSoft CodeView and Utilities Guide" is curt and misleading: EXEPACK will NOT compress executables using overlays. Anyway, this is NOT a free-standing program and is NOT nearly as effective as those mentioned here. Only LZEXE can identify files compressed with EXEPACK and, at your option, re- compress them. DIET and PKLITE do not compress EXEPACK'd executables. However, you CAN use UPACKEXE.EXE (w/LZEXE) to un-compress them first, and then re-compress them with DIET/PKLITE --- with apologies to M. Bellard. ================== HOW TO USE THEM... ================== Obviously, you MUST have the desired utility in your ROOT directory or on your PATH. The following command line syntax is SUGGESTED if you're new to this or experimenting: ---------------- TO COMPRESS... ---------------- DIET - C:\>diet -o[output filename] [input filename] (compresses a COPY of INPUT filename to OUTPUT filename --- original is not altered.) [NO space between "-o" and filename] NOTE that position of INPUT/OUTPUT filename is REVERSED LZEXE - (using LZESHELL interface) C:\>lzeshell [filename] (backup copy of original executable is AUTOMATIC, w/.OLD exten- sion. Not necessary to specify ext if .EXE/MUST specify if .COM) PKLITE - C:\>pklite -b -n [filename] (create BACKUP file w/.BAK extension [-b] and NEVER compress an executable that uses overlays [-n]) ------------------ TO UNCOMPRESS... ------------------ DIET - C:\>diet -r [filename] (Restore file compressed with DIET --- DIET's DOCS call this command "Retrieve") LZEXE - C:\>unlzexe [filename] (Uncompress file compressed with LZEXE - using UNLZEXE and create BACKUP of compressed file w/.OLZ extension) PKLITE - C:\>pklite -x [filename] (eXtract file compressed with PKLITE) NOTES: 1. These commands are recommended for use in experimenting with these programs --- you are by no means limited to them. There are others included in each program, so read the documentation for proper use. 2. Remember to DELETE the BACKUP files when you're satisfied with the results --- the idea, after all is to MAKE ROOM not USE MORE OF IT. 3. Note that PKLITE creates BACKUP files with the .BAK extension --- you should keep track of these files because it is the SAME ext- ension DOS (and some utilities) use --- it could get confusing. ======================== OK...WHICH ONE DO I USE? ======================== Choosing the RIGHT compression method is a matter of personal preference: They are ALL GOOD! PKLITE seems to offer the most due to a variety of factors: Excellent, intuitive and SAFE design; the promise of ongoing development; total support (for registered users); variety of features, etc. PKWARE is the outfit that has made "ZIP" a household word: They take their products seriously and they DO KNOW something about "compression". This DOES NOT mean to imply that either Mr. Bellard or Mr. Matsumoto takes his product any LESS SERIOUSLY --- the quality of BOTH products proves otherwise. Why pay 46 bucks for a product when you can get it for FREE? Well, SUPPORT is a two-way street: Whether we want to believe it or not, SOMEBODY paid for the development of all this great software. Mr. Bellard and Mr. Matsumoto BOTH paid with their time and talent: Considerable, in BOTH cases. PKWARE also PAID with their time and talent, with the slight prospect of recouping these costs through license fees. Nobody works for NOTHING! I think PKWARE also lent some credence to this heretofore obscure "niche" in PC utilities with their entry into the "fray" --- something to consider, eh? ========== CONCLUSION ========== To answer our original question: Yes, we get something for remarkably little effort. I was immediately struck by the fact that ALL of the programs are well-crafted, possessing common sense and foresight: They can be very useful tools for the average PC user. The companion utilities described in SUPPORTING PROGRAMS also deserve quite a hand for their quality and development skill. They make life a lot easier for those of us prone to using executable compres- sion. Very thoughtfully programmed stuff that, I'm sure, took considerable effort, time and skill. The mere fact that ALL of this excellent programming is available to us, belies the oft-noted selfishness claimed to be "today's credo". IT AIN'T SO! These folks deserve our respect and thanks! In conclusion, it could be stated that "compressing" your executables is an idea whose time has come. You will definitely save disk space and might even defer the three to five hundred dollar outlay for ANOTHER disk drive. It's worth considering when you have available the utilities discussed here.