Compressing Executable Files

The simplest way to decrease the size of a program is to use a file compressing utility. As for me, I like ASPack very much. You can download it from http://www.aspack.com or copy from the accompanying CD-ROM from the Programs folder (the installation file name is ASPack.exe). The program compresses EXE and DLL files very well.

Start ASPack.exe, and you will see an installation window. Just specify the path to copy the files and click the Next button. In a few seconds the program will be installed and starts. The main window contains the following tabs:

• Open File
• Compress
• Options
• About
• Help

There is only one button, Оpen, on the Open File tab. Click it and select the file you want to compress. As soon as you select the file, the program will move to the Compress tab and start compression .

The compressed file immediately overwrites the existing one, but the old, uncompressed version is saved with the BAK extension, just to be on the safe side. You can disable creation of a backup copy, but I don't recommend you to do this. A comprehensive description of this option will follow soon.

ASPack settings are few, and they all are located on the Options tab. Let's discuss them.

• Compress resources — If you use Microsoft Foundation Classes (MFC) when writing your programs and create dialog boxes in resources or store bitmap images there, the executable file will contain a large resource section. As my experience shows, images take up most of the space because they aren't compressed. If you check this checkbox, ASPack will compress this section.
• Create backup copy — ASPack will create a backup copy before compressing. The original contents will be saved in the same folder under the same name, but with the BAK extension. For example, if you compress a file named myprogram.exe, its copy will be myprogram.bak.

I recommend that you always check this checkbox because ASPack is sometimes unstable, and some parameters can damage your program. In that case you'll be able to recover the original file from the backup copy by changing the BAK extension to EXE. If you don't want to check the checkbox, I advise you to make a backup copy on your own.

When you have a complete source code of the program, you can recover the damaged file by compiling. However, when you compress another person's program, it won't be possible to recover it without a backup copy. So don't create additional problems for yourself.

After ASPack compresses your program, test its operability. In most cases, if the program starts, there won't be any problems with it in the future. Errors in certain windows are seldom, but not unlikely. Test each feature of your product before you send your customer the final version. If you create a commercial project, nobody will like error messages.

• Auto run after loading — If this checkbox is checked, ASPack will automatically start compressing as soon as you open a file on the Open file tab.
• Exit when done — self-explanatory.
• Max compression — When you use this option, the probability of failures increases, but the compressed file will be as small as possible. Test your program with the maximum compression and uncheck the checkbox if any problems arise.
• Use Windows DLL loader — There are two DLL loaders: Windows standard loader and a loader optimized for earlier Borland C++ compilers. We'll use MS Visual C++ to write programs, therefore, you should check this checkbox.
• Preserve extra data — Some programs contain extra data at the end of the executable file. If ASPack tries to compress it, the data can become unavailable. An example of such a file is an installer file. It contains the executable code of a program followed by additional data that should be copied to the computer. Sometimes this data shouldn't be compressed.

Now let's look at how the compression works. First, all program code is compressed by the packer. If you think this packer is something "fancy", you're wrong. A common packer optimized for compressing binary code is used. Second, the code of an unpacker is appended to the end of the packed code. The unpacker will unpack the program at the time of execution. Finally, ASPack changes the header of the executable file so that the unpacker runs first.

ASPack's compressing algorithm is very good, and the unpacker is quite small (less than 1 K). This is why the original file is compressed much, and only 1 K is added to it. As a result, a file of 1.5 Mb can be compressed to a size of 300 K to 400 K.

When you start your compressed program, the unpacker will start first. It will unpack the binary code to the computer memory. When it completes unpacking, it will pass control to your program.

Some people think compressed application will work slowly because of unpacking overheads. In fact, you won't feel the difference. Even if there is a slowdown, it will be unnoticeable (at least, on cutting-edge computers). This is because the packing algorithm is well-optimized for binary code. Actually, unpacking is executed once and doesn't affect the running program. Therefore, the slowdown caused by compression is unnoticeable.

In any case, a program is loaded into the memory before execution. If its code is packed, it is unpacked during loading. There are two sides of the medal: Time is spent on unpacking, but the program takes up less disk space and is read faster. A hard disk is one of the slowest components in a computer. Therefore, the less you have to load, the sooner the program starts. This is why the resulting slowdown is insignificant.

With common programming, i. e., when using advanced features such as visual and object programming, you obtain a large amount of code. However, it can be compressed by 60% to 70% with a special packer. At the same time, it is much quicker and easier to write such code.

Another "pro" when using compression is that it is difficult to break compressed code. Few disassemblers can read packed commands. Therefore, you obtain a protection against code-breakers in addition to decreasing the size of your file. To tell the truth, a professional will be able to break you program because there are many utilities on the Internet that make it possible to detect the packer and unpack the file. Nevertheless, a second-rate code breaker won't take pains to disassemble a packed binary code and will leave your program alone.

Send your comment

Your name:
Vote:	Terrible Bad Average Good Excellent
Title:
Comment:
Protection code: