If your application does not require more than 2 GB of memory space or benefits significantly from new and faster x64 operations, there is no need to move away from building for 32-bit x86, given x64 100% backward compatibility (but 16-bit x86 is another matter ) - ideally simplify for your users a single executable file that can work anywhere (at least on all Windows installations anywhere).
The answer to your question depends on the target target base:
- People writing business software for internal use will (or should) know exactly what hardware they are targeting.
- If you are writing games, take a look at the regularly updated Steam Hardware survey - http://store.steampowered.com/hwsurvey/ - which (as of 2017-12-06) reports that 97.9% of users use 64-bit Windows builds - only 2.1% for 32-bit Windows, although it does not say what percentage of 32-bit Windows users actually run on x64 - hardware. But gamers on Steam, as a rule, are in the segment of “computer enthusiast”, which will run more modern equipment, so the use of 64-bit hardware and OS installation will not represent all computer users around the world.
- If you are writing general-purpose software for distribution from your own website, look at your web server log files because the
User-Agent header often tells you which OS users use a text string, which often includes an architecture processor (e.g. Chrome Win64; x64 reports Win64; x64 ). - The percentage of users in 64-bit OS systems will also differ geographically - I expect that a higher proportion of users of 32-bit OSs in "emerging markets" will be more widely used by older (especially imported used) machines than in more developed countries. Similarly, market segments that are heavily tied to legacy software, such as government departments and many businesses, will work with 32-bit Windows to maintain compatibility with 16-bit software or support 32-bit device drivers.
Instead of resorting to the 32-bit or 64-bit distribution of your executable, you can do both: although unfortunately in Windows PE executables ( .exe and .dll ), (in the case where one executable the file may contain instructions for different architectures), you can actually fake fat-binary code using the Windows workaround used by the Sysinternals utilities; which should have a 32-bit executable that contains a 64-bit binary as an embedded resource and works as follows:
- Is it a 32-bit OS? If yes, then do as usual
- Otherwise, it is a 32-bit process on a 64-bit system, so extract the 64-bit
.exe to a temporary directory - Run the extracted 64-bit version
- Self-complete