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?
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 recommendation is that you not:
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.
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.
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.
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.
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.
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.
PECompact is the most robust (aside from the open source ones of course) since it has plug-in architecture that lets you extend the product in about any way. However, it is a little dated now (though still maintained). .NET support is limited and x64 support doesn't yet exist.
The advantages of executable compressors are less disk size, so less data transfer time from the network, disk, or other storage medium (e.g. cassette tape ;p). Also, once loaded, it is all in virtual memory so ready. No hard page faults to get that memory loaded from disk.
It is a myth that the virtual memory of compressed executables gets loaded and just 'stays there'. No, unreferenced pages get paged out just like any other page of memory. PECompact even has a trim operation it can optimally perform after in-memory decompression.
In some cases load time can be improved if the storage medium is slow and the compression ration high (it usually is). In other cases, it can be detrimental. It all depends on the many variables.
The disadvantage of an executable compressor is that the entire file must be read from the disk, instead of on-demand (which is rare today anyway, given the relatively small size of the vast majority of executable modules). For an executable module without extra-data/overlay appended at the end, compression may be less optimal depending on how portions of it are referenced. If it references parts all over, chances are all of it will get read quickly into virtual memory anyway (because Windows will have to go 'grab' a piece here, then there, then way over there.. etc..).
Another disadvantage is that you are inherently more likely to suffer from a false alarm because malware authors love to abuse executable compressors. It is a sad reality. Here at Bitsum Technologies (oh, I am the author of PECompact btw ;p) we have had to really tighten our licensing down. We now won't license the software to anyone who can't prove they run a legitimate business. However, the pirates still manage to get their hands on PECompact. We work with the anti-virus companies to help them scan inside PECompact compressed executables, reducing the chance of a false alarm. Our rate is less than most (if not all) competitors I think, but still it happens from time to time (and is quickly fixed by the offending company and usually specific to only a few compressed executables). Having PECompact used on Google Desktop and other prominent products helps to protect us against false alarms, as this makes sure we are 'cared about' ;)
The debate is a long one, and the answer comes down to: For some people it is the right answer, for some people it is not. There is no universal 'Yes or no'. That is also true of products. One may be best for one person, but another preferable to another person. The zealots are the only ones who accept only one answer.