Should I deploy 32-bit only or both 32- and 64-bit versions for Windows?

Question

I have a cross-platform application written in a compiled language.

• For Linux it is customary to have both amd64 and i386 builds available to user, so user can choose version, suitable for its current environment.
• In Mac it is customary to make Universal Binary, so it could support multiple versions of Apple computers. Or just provide 64-bit version, as all current Apple computers use 64-bit architecture and OS.

I don't want to confuse users, asking "What architecture are you?", but deploying 32-bit only is bad idea, as this program uses some 64-bit optimization magic and runs much faster on these machines.

My ideas:

• Install both 32- and 64-bit versions of application and choose at run-time. (Requires wrapper, so making click-and-launch application (like uTorrent) will be difficult).
• Detect architecture using User-agent on the website, so user could download appropriate version automatically (and make link to "alternative versions"). (It is Google Chrome style)
• Force user to use 32-bit application and make 64-bit version "expert-only"? (like VLC)

What should I do in Windows?

Answer 1

I really don't think its a huge complexity for the end user to have to select either a 32bit or 64bit option when downloading. But if you can use the user-agent strings to make a suggestion all the better.

Another option is to have your installer detect and install the correct binary for the user's platform. That makes for a larger download, but then the user doesn't have to think about it. If you go that approach, you'll want to provide some way for the user to override the detection in case they need a specific build for whatever reason.

Answer 2

Well, first find out whether using a 64-Bit version would ever be beneficial:

• Could the dataset processed ever be big enough to need a 64 Bit address-space to work?
• Is the 64 Bit version ever more efficient or faster?
• Are there any interoperability-scenarios sensitive to your programs bitness, changing the interface to make it insensitive to bitness isn't an option, and the bitness isn't yours to dictate anyway?

If the answer is no to all, consider not having a 64-Bit version at all.

Now, if there's a tangible advantage to using 64 Bit when you can:
Make it as comfortable as you can for your users without unduely penalizing those who know.

• Provide a single download if that's not too much overhead, which installs the best version by default (allow overriding with a command-line option or such for experts wanting the 32-Bit build on 64-Bit).
• Otherwise provide both separate downloads (if the potential advantage to using 64-Bit is small enough, hide that one a bit).
• While you could provide a downloader for selecting and downloading only the parts needed, which can potentially reduce download-size by orders of magnitude if there are huge optional parts, mark that prominently as an online-installer and link also to an offline-installer.
  (You can (and probably should) allow re-use of what it downloads, include an option to download everything, at least if you don't provide a full offline-installer.)

Answer 3

Nowadays, people and sites tend to handle this by themselves and let the user choose if they want to. So using User-agent string is a good way to go. IMO that also make your application and site looks more professional (people like stuff more if it is capable of making related adjustments by themselves).

Placing a choose version link/choice is good since some experts or people who wants to get a different version can go and get it.

You can also place a sticky note on the choose version page (one similar to this one) explaining how the users can check the OS System Type (a.k.a. right click Computer and choose properties blah blah...) so curious humans can check and be sure that what you offer is the right version.

Answer 4

Have a 32bit installer which doesn't contain the executable. Have it detect the target platform it runs on and then downloads the correct binary from your server.