If you've recently tried to buy a server or workstation, you've probably noticed that 32-bit systems are quickly disappearing. It will only be a matter of time before you transition to a 64-bit environment.
A similar transition occurred a decade ago, when Microsoft released its first 32-bit operating system, Windows 95. Its predecessor, Windows 3.1, was a 16-bit operating system. Windows 95 was a huge technological leap forward, with many Windows features still in use today making their debut. But the transition did not go smoothly. Windows 95 was plagued with bugs, and it made administrators do many of their administrative tasks differently than the way they were used to.
Fortunately, current 64-bit versions of Windows are nowhere near as buggy as Windows 95 and the user interface for the 64-bit versions of Windows XP and Windows Server 2003 is identical to that of their 32-bit counterparts. These factors will help to make Windows administrators' transition to 64-bit easier.
Still, there are two key issues associated with moving to a 64-bit operating system:
application incompatibility and lack of 64-bit drivers. Note: There are several 64-bit platforms available, each with their own set of rules. This article assumes you'll be using an x64 platform.
If you're moving to a 64-bit environment, there's a good chance that some of your applications are not going to work . . . at least not while running a 64-bit operating system.
Don't shy away from buying x64-based systems because of this. Most x64 systems are designed to be completely backwards-compatible with 32-bit (and possibly even 16-bit) operating systems. Such systems can run 32-bit code natively. What this means is that you can install a 32-bit operating system and run any application that you can run on a true 32-bit system without ever having to worry about compatibility.
However, even though many x64 systems can natively run 32-bit code, they cannot run 32-bit code and 64-bit code at the same time. If you were to install a 64-bit version of Windows, the computer would not be able to natively run 32-bit code from within Windows.
But that doesn't mean the system can't run 32-bit code at all. It just can't do it at the hardware level. Instead, Windows uses an emulation layer called Windows on Windows 64 (WOW64) to emulate a 32-bit operating system, allowing it to run 32-bit and 64-bit code.
Because it's running within an emulator, 32-bit code runs a little slower than it would in a true 32-bit environment. However, I've been experimenting with 64-bit systems, and while I don't have any specific benchmarks, that speed difference usually negligible for everything except high-demand applications, such as games.
What x64 Windows won't run
There are primarily two types of applications that 64-bit versions of Windows won't run: 16-bit code and 32-bit applications containing kernel mode.
You can run a 32-bit version of Windows on a 64-bit machine (assuming the machine natively supports 32-bit code), and run 16-bit code with no problems. However, the WOW64 emulator has no emulation layer for 16-bit code.
The inability to run 16-bit code probably doesn't seem like a big deal. After all, 16-bit apps have been "extinct" for years. But in making my own environment 64-bit, I've been surprised by how many 32-bit apps contain pieces of 16-bit code. Some applications contain one or two files that have remained unchanged since Version 1.0, and consequently were built with a 16-bit compiler. If you have concerns about application compatibility, I recommend you buy a couple of 64-bit machines, install a 64-bit operating system, and test your applications.
Almost all 32-bit apps contain only user mode code. But a few out there do contain kernel mode code. Since the 64-bit version of Windows uses a 64-bit kernel, you can't mix in 32-bit kernel mode code.
The apps that do use 32-bit kernel mode code are primarily server applications, such as Exchange Server 2000 and 2003. You can forget about running either of these on a 64-bit version of Windows. However, Exchange Server 2007 will be designed to support 64-bit servers. In fact, a 64-bit operating system will be a requirement for Exchange Server 2007.
Lack of hardware drivers
Although 64-bit systems have been around for years, they've only recently begun to go mainstream. That delay has nothing to do with price; prices for 64-bit hardware have been relatively low for quite a while. The main thing holding back 64-bit hardware was a lack of drivers. Because, while 64-bit versions of Windows require all device drivers to also be 64-bit, not every hardware vendor is writing 64-bit drivers yet.
Recently I a new system and after installing the 64-bit version of Windows Server 2003, I installed a gigabit NIC made by a well-known vendor. I was shocked to learn that no 64-bit versions of the driver were available. So for the time being I'm stuck using the fast Ethernet interface that's integrated on the system board until I can get a driver for my gigabit NIC.
Despite my NIC experience, 64-bit drivers are relatively easy to come by as long as you stick to well-known brands . . . although sound card drivers are tough to come by.
For the most part, deploying a 64-bit version of Windows and getting your applications to run is relatively easy. But there are two other things to watch out for:
- Some anti-virus applications are hard to install in 64-bit environments.
- Some of the more elaborate printer drivers (such as drivers for multifunction devices) are difficult, if not impossible, to install.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He writes regularly for SearchWinComputing.com and other TechTarget sites.
More information on this topic:
