Are There Any Downsides to Using Upx to Compress a Windows Executable

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

... there are downsides to
using EXE compressors. Most notably:

• Upon startup of a compressed EXE/DLL, all of the code is
  decompressed from the disk image into
  memory in one pass, which can cause
  disk thrashing if the system is low on
  memory and is forced to access the
  swap file. In contrast, with
  uncompressed EXE/DLLs, the OS
  allocates memory for code pages on
  demand (i.e. when they are executed).

• Multiple instances of a compressed EXE/DLL create multiple
  instances of the code in memory. If
  you have a compressed EXE that
  contains 1 MB of code (before
  compression) and the user starts 5
  instances of it, approximately 4 MB of
  memory is wasted. Likewise, if you
  have a DLL that is 1 MB and it is used
  by 5 running applications,
  approximately 4 MB of memory is
  wasted. With uncompressed EXE/DLLs,
  code is only stored in memory once and
  is shared between instances.

http://www.jrsoftware.org/striprlc.php#execomp

Use UPX (executable compresser) on release builds?

I have heard - not tested - that some programs perform better on startup when compressed because reading from the harddisk is more expensive than decompressing.

Sometimes the opposite is true because the program only needs to load code pages on demand. But it can't do this is the exe is compressed.

If you have multiple instances of your executable running, then the memory will be shared between each instance. But if you compress them this is no longer the case.

As for downloading, surely what is downloaded is an install package which is compressed.

In short, I really don't think executable compressors are worthwhile.

Can I use upx packer to compress a commercial program?

Yes, you can.
Please have a look at the UPX license. There's a special exception for commercial applications so they can use UPX.

Note to Zifre: UPX is GPL, but it's not the same as creating an image with GIMP, since part of the UPX code is added to the commercial application (the decompressing part). That's why the exception in the license is required.

how do i use UPX safely?

You can't avoid this issue.

The problem is that malware authors often use UPX and other packers to reduce size and try to conceal content, and therefore all of the virus scanners look for signs of those packers (especially UPX, because it's readily available).

If you don't want UPX to cause your app to be identified as being a virus, stop using UPX.

Pack calc.exe with UPX

I would guess the issue is related to the MUI resource and MUI satellite DLLs.

Try using the --compress-resources=0 UPX option. If you want to compress some of the other resources you can try --keep-resource= instead.

If you move/rename Calc.exe you must also make sure you do the same with the .mui file:

md myCompressedCalc
cd myCompressedCalc
copy %windir%\System32\calc.exe .\
md .\en-us
copy %windir%\System32\en-US\calc.exe.mui .\en-us\
upx --compress-resources=0 .\calc.exe

is it OK to use compressed dll(s)?

This is not something that "works by chance", UPX is intended to compress Win32-PE (and many other formats), whether that's executables or DLLs.

As for "Is it OK?", well yes, of course it is "OK", as long as you don't violate another party's license.
This is highly unlikely to happen with anything related to Qt, but in principle, it is a possibility. One could for example be using some DLLs which have a license clause such as "distribution in binary form, blah blah, not allowed to modify". Say, something like a MSVC or DirectX redistributable, or some graphic card vendor's proprietary API. In any case, it's not a mistake to keep this in mind and check the licenses before risking to violate them.

Wording your question "Is it OK?" slightly different: "Is it wise?", the answer is: probably not. A few megabytes extra on the disk normally don't matter a lot. When you pack everything into an installer, and a user downloads it over the internet, the data is compressed anyway, so it's the same in that respect.

However, compression, whether you use UPX or another executable packer, or Windows' filesystem compression, has side effects. It causes additional address space fragmentation, it disables asynchronous transfers, and it forfeits the operating system's ability to discard pages from the DLL from the working set and to transparently reload them from the PE image upon access.

That last sentence means the operating system must make an allocation in the page file and it must write pages to the page file when your process' working set is moved out to make room for something else. There is no other way. Now what if the user has disabled page files...

Are there any executable packers (like UPX) for iOS?

You can't use it, iOS doesn't allow you to create executable pages or to run custom binaries from a file.

Delphi EXE compressor?

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.

Why does my application use more memory after I compress it with UPX, and what can I do about it?

That's how EXE compressors work. They compress the disk file, not the executable code. To make the compressed file executable again, it needs to be uncompressed, and that uncompressed data is stored in memory. With an ordinary, non-compressed EXE file, the OS will load only the portions of the file that are required at the moment. The rest can stay on disk. Since your entire uncompressed application is in memory, that's why your memory usage appears higher.

Furthermore, the disk file can be shared by multiple users, whereas the memory containing the uncompressed executable is not shared. Each user running your program has a separate copy of the uncompressed program.

The 26 MB of disk space that you're saving by compressing your program are practically nothing on a shared remote-desktop server. Don't bother compressing the file. If you want to compress the file to save on bandwidth during distribution, then package your program in an installer that uncompresses the file once at installation time instead of an EXE compressor that needs to uncompress the file every time anyone runs it.

---

Related Topics