30 years ago operating systems (and hardware) were mostly 8 and 16 bit. As the largest number that can fit in 16 bits is 2^16 (=65536), the addressable memory capacity of these systems was severely limited. If your whole RAM is limited to 65536 bytes, you can't put many 10 megapixel pictures in it! Early versions of Windows (up to v3.1) used a mongrel near/far pointer model that expanded the memory capacity to a few megabytes, but that was hell for programmers.

When the 32 bit revolution arrived (Windows 95 for microsoft) both users and programmers were really happy. With 32 bits available the theoretical RAM limit is 4GB (=2^32) which is a marked improvement from 65KB, and more than any normal person would require. The flat 32 bit addressing model was a boon for programmers which, combined with a good looking and well documented user interface, made 32 bit Windows the success that it is.

In the past few years hardware manufacturers have started selling 64 bit capable processors (which can also run in 32 bit mode for backward compatibility). It wasn't before long that 64 bit versions of Windows appeared, but there was hardly any excitement about this 'progress'. If you are walking barefoot and somebody hands you a car, you are really happy, but what can you do with a 10 litre war tank? Sure enough you get a theoretic memory capacity of 18,446,744,073,709,551,616 bytes, but I don't have a datacenter so I don't need so much RAM. As for performance, there's not much improvement. Programming for 64 bits isn't very simple either.

And there are problems. Most of the programs and software tools we own are still 32 bit executables, so operating systems have to support both 32 and 64 bit simultaneously. This translates to various double folders and registry hives with the unavoidable overhead. But the real problem comes from plugins, the various DLLs used here and there for a variety of tasks:

• shell extensions (context menu items, thumbnail generators, column handlers, etc)
• activeX controls (IE flash player)
• audio/video codecs
• system DLLs

If you have a 32 bit plugin (DLL) that e.g plays flash video in internet explorer, and you want to use it in 64 bit windows, you must either use the 32 bit IE version, or search for the 64 bit version of the flash plugin. You can't have a 32 bit DLLs loading in a 64 bit program and vice versa. As many popular plugins don't have 64 bit equivalents yet, and some do, you end up running two versions of everything. Not many people know that when you browse the internet on 64 bit windows you actually use the 32 bit internet explorer, and now you know why!

Same goes for a file manager like xplorer². Windows shell extensions are built on DLLs. If you have 10 favorite addons, e.g. your context menu archiver and RAW thumbnail generator, you have to be extremely lucky to find 64 bit versions for all of them to match the 64 bit xplorer². Otherwise you must use the normal 32 bit version at least some of the time. A waste of hard disk space and your time installing double the tools.

So let's summarize: with 64 bit windows you get nothing you really need, and inherit a few warts you could do without. It is also common sense that 64 bit programs and drivers are also relatively more unstable as their 32 bit versions have been around and tested for longer. You can draw your own conclusions... Personally I have W7 32 bit as my operating system; when I need 64 bits for testing I use virtual box.

ps. Many of you ask me if there is a native 64 bit version of the free xplorer² lite; there isn't, but the 32 bit version runs well on 64 bits too (you will just be unable to browse a few system folders)

Post a comment on this topic