After writing about what a great client operating system Windows Server 2008 can be, I’ve just spent 2 days fighting to get everything working on my 64-bit installation. It’s not a problem with Windows but with original equipment manufacturers (OEMs) and independant software vendors (ISVs) who provide patchy support for 64-bit operating systems and it is stifling the adoption of 64-bit computing.
The operating system installed flawlessly and all the major components had x64 driver support, but then there were the minor things, like memory card readers, hotkeys, a smart card reader, Bluetooth, etc. which needed specialist drivers that took some tracking down. I got precious little help from my system’s OEM but a colleague tracked down the drivers I needed from another company’s website. Then I started on the applications. 
Again, no problem for the major applications – 32-bit versions of Office 2007 and even the Vodafone Mobile Connect software installed without issue on a 64-bit platform. The problem came with the more specialist applications – for example the Cisco VPN client, which flatly refused to install on a 64-bit OS.
It’s not Microsoft’s fault. They provide 32-bit and 64-bit versions of their operating systems to respond to customer demand and then get caught in a vicious circle where vendors are reluctant to invest in updating their product to work with a 64-bit version of Windows and customers will not deploy the a 64-bit operating system unless their hardware works and their application software requirements can be met. I will caveat this though – there is an elephant in the room – Microsoft ISA Server 2006 is, inexcusably, a 32-bit only application.
Microsoft needs to cut itself free from some of the legacy features in Windows – including 32-bit releases. The problem is that Windows has such a broad reach that even the most minor issues become big news. If Apple decides to discontinue support for legacy features (e.g. Mac OS Classic application support) then no-one is really bothered but for Microsoft even the most obscure legacy technologies are still in used by many people – take a look at the post I wrote a few years ago about a customer having problems with FoxPro for MS-DOS on Windows XP and people are still leaving “me too” comments there! For another example, consider the criticsm that Microsoft took for Vista “breaking” applications or for hardware not working with the new operating system – they’d been warning OEMs and ISVs for years about the changes that they were making and some of them still don’t support Windows Vista – fifteen months after it was released.
Who needs a 64-bit operating system anyway? Well, I do. And, over the next few years, so will everyone. When Windows 2000 Workstation was new, I recommended that everyone who bought a new PC made sure they had at least 512MB of RAM so that they had enough to run the applications of the day but also to move to the next operating system release without needing upgrade their hardware. A few years later, Windows XP Professional would run comfortably with 256MB of RAM but it was probably best to buy a gig. With falling memory prices and higher application demands, for Windows Vista Enterprise I reckon 2GB is about right but if you want to run some virtual machines too, then you should be looking at about 4GB… and that’s the problem. 32-bits are only enough to address 4GB of RAM and 32-bit Windows operating systems will let you access about 3GB of that. By installing a 64-bit edition of Windows I can use all 4GB in my notebook, or all 8GB on my server (and much more if I had sufficient physical memory installed).
The need to access ever-more memory is not just a Windows issue either – I have 4GB of RAM in my MacBook because the photo and video editing that I do needs not just a fast processor but a decent amount of memory. And whilst Linux can run in a small footprint, if I want to do the same sort of things that I do under Windows or on the Mac, then I’ll need a decent amount of memory there too.
As for processors, anyone who has bought a PC in the last couple of years already has a 64-bit CPU. And anybody who is using older hardware is probably already weighing up their options for Windows Vista and shouldn’t be thinking about running the next version of Windows – managed diversity may be better in the short term with new hardware later.
64-bit computing is here. Right now. Microsoft should make Windows Vista the last 32-bit Windows release and it’s time for OEMs and ISVs to get with the programme.
Another elephant for the room: Office Communications Server 2007
Another thing: the 32-bit 4GB limit doesn’t have to be so. PAE allows up to 64GB, but you can only get it in the server editions of Windows. Brad Wilson has regularly tweeted about giving up on x64 and going with x86 Windows Server 2003/2008 to get the PAE support for 4GB and above. If larger memory is what you’re after, without the pain of poor x64 support – it’s an option to consider.
@Duncan. Fair comment, but PAE was really intended for stretching out the life of 32-bit servers and there is no real reason why it is necessary today as most people have 64-bit hardware.
I needed x64 for another reason – Hyper-V – but, now I’ve found all the drivers (and I did find them all eventually), I’m pretty pleased with the performance on this system.
For servers from mainstream OEMs, 64-bit support is largely OK. On the desktop it’s more patchy – and as far as I can see, the only way to force the issue is to scrap 32-bit Windows altogether (or make it less desirable using a pricing model that favours x64).
Of course when even some of the product groups in Redmond fail to ship 64-bit versions of Microsoft’s own products, then that’s not much of an incentive for other software vendors…
With PAE the process space is still 2 GB, so each process can still access a limited amount of memory.
Sites worth checking out for 64-bit information include:
A further (small) elephant: Virtual Server Migration Toolkit. No idea why this won’t work on x64, although it could be as simple as some in-process library can’t be loaded into a 32-bit process. That said, it looks like the COM interfaces used by the scripts are implemented by the vssrvc.exe process (Virtual Server service) rather than an in-process DLL, and the marshalling is done by the Automation marshaller so there’s no custom stub to cause failures.
Anyway, it’s pretty inconvenient when you built out your VM server as 64-bit so you could use lots of memory!