64bit version is stored inside of the 32bit executable, from where it is extracted and launched to replace the 32bit version if latter detects that it is being run on a 64bit system.
a single executable to distribute
the exe comes out weighing twice as much... or does it?
The size of a 32-bit executable can be easily reduced with the help of tools called
. They work by turning the exe file into a self-extracting archive that also automatically launches the original exe after the extraction. It may sound simple but in reality it involves bundling a custom
with the packed executable (as it might not be possible to extract the exe into a temporary file before running it).
In any case, exe packing is routinely used by developers who care about the size of their products, with uTorrent being one of most notable examples. Original Bvckup was also compressed, owning its tiny size in part to the magic of
The problem lies with 64-bit executables. For a variety of reasons there are presently no exe packers that support them.
However if we store 64bit binary inside of the 32bit executable and then pass latter through a compressor, we end up with both being compressed. Ta-da!
But there's more.
When an .exe is compressed, the compressor leaves the primary application icon intact. This is done so that the app would keep its original appearance in Windows Explorer and not sport a generic "program" icon.
Starting with Vista, the app is expected to support a variety of icon sizes that quickly add up. For example, bvckup's icon weighs in at about 110KB. That's almost half as big as the actual code, the code that does quite a few meaningful things on top of just looking great :)
So, if we do the 64-in-32bit packaging, we end up compressing 64bit version in its entirety, including its icon, and arriving at a greater size reduction if we were to compress the exes separately.