Question

At one point I had a nice little compression utility that smashed my Delphi compiled EXE's to a smaller download size, but now I can't find it. Any recommendations?

Also, are there any downsides to using these kinds of utilities? (I mainly use them to shorten download times for rural / dial-up users).


Related question: Are there any downsides to using UPX to compress a Windows executable?

Was it helpful?

Solution

Years ago I looked into compressing my executable to make the download smaller.

What I ended up doing, and what I recommend for you, is to use an installer program like Inno Setup instead. Not only does it create a single EXE that will install/uninstall your program, but it also compresses that EXE practically as much as a separate compressor would do to your executable alone.

When the program is installed it gets decompressed, so it never appears to be a virus and does not increase load times.

So I get the benefits of smaller download size, and a professional-looking installation script at the same time.

p.s. Inno Setup is free.

OTHER TIPS

The recommendation is that you not:

  • EXE compressors can make your application seem like a virus (self-modifying)
  • gzip/zip are just as effective at compressing and don't tinker with your app
  • EXE compressors make the load times of your app increase (unless you're just talking about the setup program which is a different matter

This crazy looking site brings up an argument I had heard in the distant past (whether it's true or not still today, I'm not sure, modern packers probably have a different strategy today) This article references Win32! :)

http://topic.csdn.net/t/20000408/08/6785.html

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.

I don't know of any that are specifically for Delphi, but UPX is very popular for this sort of thing. The only downside is that the executable has to be decompressed when it's launched, and that can eat some time. It seems to be very fast for sanely sized executables, though.

The one you are probably thinking of is ASPack - it is a EXE compressor written in Delphi, but will compress any EXE. It might do extra well on Delphi EXE's though. I would agree with the other answers that you should not use an EXE compressor just to save on download times. There may be specific situations where an EXE compress is a good idea, but generally it is not.

Instead use a good installation builder, especially if you can find one that uses 7zip compression. I know InstallAware uses 7zip internally for maximum compression. Depending on which versions of Delphi you own you may have an InstallAware license too.

If nothing else you can build a self extracting archive with basic install behavior with 7zip for free. It is a separate download for SFXs for installers.

Use UPX with lzma option for max compression.

upx --lzma yourfile.exe

The main inconvenience of a compressed EXE or DLL is that the OS cannot share the code amongst multiple instances.
So you're wasting memory, have to decompress each time you start an instance, exhibit a virus-like behavior without even an download advantage over a compressed install.
Only positive case is when launching directly from a network drive.

I believe Terminal servers (Like Citrix) will use the same memory for you're application binary if it is uncompressed. Meaning a compressed exe could smell a small disaster in a Citrix environment.

UPX should work, although it's not Delphi specific.

I would also vote for upx. Beside the downsides which were mentioned it also protects from basic reverse engineering and those lame "resource hacker" tools. Which by the way are plenty, and most of them fail to open a compressed executable.

I asked a question about the con's of using UPX on Delphi executables here on SO a while back, and I got some great responses.

Are there any downsides to using UPX to compress a Windows executable?

You can use PECompact since people can't decrypt it easily, and as test showed (showed on main page, just scroll down a bit) it's better than ASPack or UPX, i've using it on my previous Delphi projects

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top