This question is from 2012. If you are reading this in 2019 or later, then the answer really is: No. There is no good reason in 2019 to be maintaining 32-bit desktop operating systems.
Original question below:
Server software has been 64-bit only for a while now (Since Server 2008 R2 for Windows, even earlier for Exchange and Sharepoint) and even Ubuntu are pushing you away from 32-bit versions for their server OSes.
But is there any good, quantifiable reason to keep a 32-bit desktop operating system maintained? We're preparing our Windows 8 images for the (unfortunate?) few that will be early adopters.
The majority of our desktop computers have 4gb or less of RAM, but I would love to not have to bother supporting a 32-bit flavoured operating system any more.
Any reason why I should?
Best Answer
32-bit can be slightly faster in certain use cases -- the smaller addresses means sightly more compact code, which means greater cache efficiency. In the benchmarks I've seen, that efficiency tends to be be overshadowed by 64-bit's greater computational efficiency in heavy-computation environments. But 32-bit does in fact occasionally win on some benchmarks. YMMV. The age of your software matters, as newer builds take advantage of 64-bit stuff that older builds do not.
More compact code means less disk space. Just go download the ISOs for your favorite OS in 64 and 32 -bit flavors to see the difference. It's not trivial. It's also quite a lot more once you uncompress the binaries. As pointed out by OrangeDog: Much of this space consumption comes from the fact that 64-bit OSes ship 32-bit libraries in addition to the 64-bit ones.
You still get better compatibility with legacy components and software with 32-bit. This is particularly visible in systems that dynamically compile on the host machine but pull in 3rd-party binary libraries at the same time. Microsoft's .NET framework is a great example of this: while the programs are theoretically architecture-independent, anytime you link to a native binary you tie to one arch or the other. Many developers don't even know this is happening, and ship production components that will fail to run on 64-bit systems without some tweaking to explicitly instruct .NET to run in 32-bit mode. Most people don't know how to do this.
As pointed out by Daniel B: Windows .NET development on 64-bit machines leaves you open to a frustrating inconsistency where under certain circumstances exceptions are masked by the OS.
Legacy hardware. You can't run a 32-bit driver on a 64-bit kernel.
None of this adds up to a show-stopper for most people. Still, you have to decide how these factors affect your environment.