Weighing the Advantages and Disadvantages of EXE Compression
By Dave Lehman - davelehman@loewen.com
Just a follow-up to Simon Lau's UNDU tip called "Program Size Got You Down?" I just wanted to point out that while an EXE compressor sounds really good at first blush, it's not quite as simple as that. This technique can work well for small programs, but there are also significant disadvantages to using an EXE compressor that must be weighed. Jordan Russell has a good discussion about this topic on his homepage. I have included the relevant text below.
I am not saying the Simon doesn't make a good point, or that using an EXE compressor is always bad. I simply wanted to make sure users are aware of both sides of the issue.
Note: I am not associated with Jordan Russell in any way, other than I respect his obvious programming talents. He states my point succinctly and directly, so i'll quote him instead of trying to restate it myself.
Regards,
Dave Lehman
- - - - - - - - -
(taken from http://www.jordanr.dhs.org/striprlc.htm)
"If I want to reduce the size of my program, why not use a full-fledged Win32 EXE compressor?..."
Many fail to realize (or simply aren't told) that there are significant downsides to using EXE compressors... In my opinion, EXE compression is not something that should be generally applied without serious consideration. Let me explain why.
In DOS, when you started a program, all of its code got loaded from disk into memory and stayed there until the program terminated. If there was not enough available memory to load the entire program, you'd receive an "out of memory" error.
Modern multitasking OSes such as Windows 95/98 and NT use what is called a "virtual memory" system. When programs start, all of their code is not loaded into memory immediately upon startup, as was the case with DOS programs. Instead, only portions of the code being actively executed are stored into memory. For example, say your program has a Print option on its menu, and code behind it that handles the printing. This code will only be loaded into memory once the Print feature is first selected by the user. And if after the code is loaded into memory the Print feature is not used for a while the system will "discard" the code, freeing the memory it occupied, if another application desperately needs memory. This is part of a process called "paging" and is completely transparent to the program.
Another way paging under Win32 conserves memory is it causes multiple instances of a program (or DLL) to share the same memory for code. In other words, under normal circumstances there is no real difference in the amount of physical memory allocated for code between starting 100 instances of a program and starting one instance.
If all Win32 programs behaved like DOS programs, loading everything into memory and keeping it there until the program terminated and also not sharing any memory between multiple instances, you can probably imagine how quickly physical memory could run out on systems with a limited amount, causing disk swapping to start.
Yet this is precisely what current Win32 EXE compressors do to your EXE's/DLL's! They completely go against the OS's paging system by decompressing all code into memory and keeping it there until termination. And because code isn't stored in a "raw" format in the EXE file (i.e. the same way it is stored in memory), the OS is unable to share code between multiple instances.
Many choose to use an EXE compressor assuming it the ultimate weapon against code bloat. But I have to ask: Which is less expensive and more abundant, hard disk space or memory? Is it really worth increasing your application's memory requirements just to save a few kilobytes of disk space?