What's the principle of installers in windows?

Question

IMO a PE executable can't run on all platforms.

I'm guessing that the installer packs executables for various CPU architectures, and chooses the right one after some detecting work.

But is this how major companies like MS releases their products?

Answer 1

Microsoft only releases for two desktop CPU's, x86 and x86-64. They generally use separate executables for each. For example, vcredist_x86.exe (x86) and vcredist_x64.exe (x86-64).

However, they do use combined installers in some cases, such as dotNetFx40_Full_x86_x64.exe.

Answer 2

It seems like there are two schools of thought here:

• Release separate installers for each platform.

This is the most straightforward approach as you don't have to do anything special in your installer. Many of Microsoft's utilities (in particular all of the debugging tools) come in separate x86/amd64/ia64 packages; I'm not sure about their retail products, though.

• Combine 32-bit and 64-bit installers into one.

Here you have a single monolithic 32-bit installer that will run on all currently supported Windows platforms; the installer contains the binaries for each platform. In the installer you lay down the appropriate binaries depending on what platform you are running on. I would recommend against this as it requires a lot of "magic" (custom code, hacks, etc) and it also bloats your installer.

We currently distribute our product using the second method, but it has proven to be quite a headache so we're going to be changing over to the first method in the future. The only downside to the first method is that you require the customer to use the proper installer, though you could wrap this in a simple 32-bit shell that launches the appropriate installer.

Answer 3

This is actually a fairly complicated discussion involving the bitness of your components and their dependencies and there isn't any 1 size fits all to the deploymen approach. Some products are native / unmanaged ( not .NET ), compiled for x86 and distribute as an x86 package on both x86 and x64. Some will be be purely managed ( .NET ) applications that are packaged as x86 but in reality will run as x64 if possible. Some will be managed apps that have unmanaged dependencies and possibly need to do a hybrid approach such as installing x86 DLL's to the WinSXS on 32bit machines and x64 DLL's to the WinSXS on 64bit machines. Others have no direct dependencies per say but may need to register as addins / plugins / extensions to other applications such as Office or Internet Explorer.

Some packages distribute as distinct installers, some do a hybrid approach and some will split out into multiple packages wrapped via a bootstrapper. Some will try to hide the bloat via background web downloads and some will give it all to you up front to allow for offline installs.

The answer very much is: It Depends.