Good reasons to keep 32-bit Microsoft Windows desktop OSes

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?

Solution 1:

• 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.

Solution 2:

The only reason I can think of to keep a 32-bit desktop operating system is if you use old 16 bit (e.g. DOS) programs and you do not have the windows version which supports Windows Virtual PC.

(And even then I would install a 64 bit OS and use something like DOSbox).

Edit: There actually is another reason: Hardware which fails to cope with more than 4GB address space. E.g. FireWire trying to do DMA. Or any (old) hardware with no 64 bit drivers.

Solution 3:

Anything that will run Windows 8 is already 64-bit capable, unless you happen to have some first-generation Intel Atom netbooks (and I doubt that very much). That's about the only thing I can think of.

AMD released its first 64-bit capable Opteron in 2003; and since then virtually every processor they have made has been 64-bit capable.

Intel was a year later, releasing its first 64-bit Xeon (Nocona) in 2004, and expanding to just about the entire product line by 2006. Aside from the aforementioned early Atom chips, every Intel processor today is 64-bit.

Wikipedia has a broken down processor list if you're interested in ancient history.

Solution 4:

Compatibility with Ancient Software/Hardware.

If everything works under x64, I wouldn't bother with 32 bit.