Menu
Menu
Product Review: 64-bit Windows opens to an empty house

Product Review: 64-bit Windows opens to an empty house

Linux can't run roughshod over the 64-bit x86 landscape anymore. Microsoft has now shipped its 64-bit editions of Windows -- a lineup that includes Windows XP and a handful of varieties of Windows Server 2003 -- for AMD and Intel 64-bit x86 (Microsoft calls these x64, collectively) as well as Itanium 2 chips. If you weren't aware of this debut, don't be surprised. Most Microsoft customers don't know what 64-bit Windows is, whether they need it, or where to buy it.

Linux can't run roughshod over the 64-bit x86 landscape anymore. Microsoft has now shipped its 64-bit editions of Windows -- a lineup that includes Windows XP and a handful of varieties of Windows Server 2003 -- for AMD and Intel 64-bit x86 (Microsoft calls these x64, collectively) as well as Itanium 2 chips. If you weren't aware of this debut, don't be surprised. Most Microsoft customers don't know what 64-bit Windows is, whether they need it, or where to buy it.

Windows Server 2003 Enterprise x64 Edition, the focus of this review, is an unqualified hit when judged solely on technical merit. Only Microsoft's development tools spotlight the vendor's engineering prowess so well. The pity is that Microsoft didn't start evangelizing 64-bit Windows to developers soon enough, even internally. Windows Server 2003 Enterprise x64 Edition debuted with an anemic shelf of 64-bit apps. Skeptics will rejoice to learn that 64-bit Windows isn't load-and-run compatible with many, if not most, 32-bit Windows applications. But this shortcoming is balanced by the fact that 32-bit software runs beautifully on 64-bit Windows when hosted by Microsoft Virtual Server or a VMware virtualization engine.

Assembling the rig

I carried out the bulk of the testing for this review on a trio of AMD64 machines. A Tyan motherboard-based dual-processor, dual-core 2.2GHz Opteron server anchored the group. The wing positions were taken by a single-processor, dual-core 2.4GHz Athlon 64 X2 and a single-processor 2.8GHz Athlon 64 FX-57 system. All were set to dual-boot between 32- and 64-bit editions of Windows Server 2003 Enterprise.

Microsoft did a laudable job of packing the Windows Server 2003 x64 Enterprise install disc with a fat set of device drivers. That's essential -- no 32-bit device driver will work with 64-bit Windows, and at present, vendor-supplied 64-bit drivers are very hard to come by. If a device isn't on Microsoft's HCL (Hardware Compatibility List) for 64-bit Windows, take my word for it: Don't wing it. Migrating an existing server to Windows x64 will probably mean gutting it and installing expansion cards as they pop up in the HCL.

I had serious reliability and connectivity problems on the dual/dual Opteron server following installation, both with and without the driver that Tyan supplied. The trouble turned out to be related to NVidia's built-in hardware firewall, which required an arcane and undocumented process to disable. Apple's Xserve RAID array, Apple's LSI Logic PCI-X Fibre Channel adapters, and my Emulex 355 storage switch were all plug-and-play. Installing Windows x64 on the single-processor Athlon systems went without a hitch.

Windows x64 runs 32-bit applications stably or not at all; it won't allow an incompatible app to install or load. This is neither Microsoft's heavy hand nor bad engineering. It is genuinely impossible to run a great many 32-bit applications directly on AMD64 and its Intel derivative in pure 64-bit mode. But 32-bit Windows apps are very much at home running under Microsoft Virtual Server 2005, so much so that I believe a limited copy of that software, supporting maybe just a couple of virtual machines, should be bundled with Windows Server 2003 x64 editions. The preceding caveat about device drivers still applies: Virtual Server simulates 32-bit devices, but it still uses the host operating system's drivers. Even so, the vast majority of the Windows application library would be restored.

How does Windows x64 get along with systems cut from different cloth? Don't make any assumptions. Getting Windows x64 and Mac OS X to share authentication and directory and name services was like playing a game of Whack-a-Mole: They list one another's shares, then they don't, then I see the shares but can't authenticate, then the shares disappear again, and so on. To its credit, Microsoft addresses some of the basic glitches in its Knowledge Base; it wasn't obliged to do that. But Samba, the open source Windows file-sharing software used by open source operating systems, has a good deal of catching up to do before it will peer seamlessly with Windows x64. As for demanding that Windows Server 2003 Enterprise x64 Edition cozy up to Windows 2000 Server, forget it. I'm no fan of forced upgrades, but it's time to leave Win2K behind, and 64-bit Windows drives that point home by making it clear that engineers had better things to do than make 64-bit Windows rust-for-rust compatible with the outdated OS.

Now what?

My pet proof case for 64-bit Windows on AMD64 is Terminal Server. Windows x64 pops the tight caps that 32-bit Windows places on resource usage. As a result, Terminal Server users will experience manyfold improvements in performance, capacity, and latency on 64-bit systems that have large amounts of memory. This has to be seen to be believed. Memory paging is the No. 1 killer of Windows server application performance on machines with more than 4GB of RAM. Windows Server 2003 Enterprise x64 Edition lifts those caps not just for Terminal Server but for the whole OS. You need a budget for lots of RAM, but an extra 8GB of RAM is cheaper than a second server.

The pairing of Windows x64 and Microsoft Virtual Server, VMware Workstation, or VMware GSX Server doesn't overwhelm like Terminal Server does, but it still makes a very accessible case in favor of 64-bit Windows. But indirect access to peripherals, especially storage, takes a heavy toll on performance. I can't recommend virtualized servers for continuous use, but as a way to manage availability or to reallocate compute cycles by task, I'm very pleased with the difference between 32-bit and 64-bit Windows.

In general, if you rely primarily on software that Microsoft bundles with Windows, you'll find a 64-bit migration both safe and beneficial, as long as you stick to Microsoft's HCL.

How you get 64-bit Windows is a matter of timing. If you act before the end of July, Microsoft will swap you a 64-bit Windows Server 2003 license for every 32-bit license you surrender. After that, editions of 64-bit Windows will be priced to match 32-bit Windows. I expect the editions to stay in functional lockstep from here.

Hardware migration is a no-brainer -- go straight to 64-bit servers. And I won't restate my case for AMD's on-CPU memory controllers and glueless interprocessor links except to point out that these come in mighty handy when you're running grown-up server software. Migration to 64-bit Windows isn't cut-and-dried. It's very likely that you'll run 32-bit and 64-bit Windows side by side for some time, even after you've cut all your Linux servers over to 64 bits. That will keep the playing field tipped in Linux's favor, but at least Microsoft has a piece on the board now. -- InfoWorld (US)

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.
Show Comments