In the past year, I have helped several clients make the transition from a 32-bit Windows environment to a mixed environment of 32-bit and 64-bit Windows. After the transition, several observant end users pointed out an "oddity" in their new 64-bit Windows systems that were running on Intel 64 processors. If you look at the PROCESSOR_ARCHITECTURE environment variable from the Control Panel's System applet or from 64-bit Cmd.exe, its value is AMD64.
Although the value might appear to specify the wrong vendor (AMD instead of Intel), the value is what it should be. PROCESSOR_ARCHITECTURE is about the architecture and not the implementation. Because the Intel 64 processors implement the AMD64 architecture, they're members of the AMD64 processor class.
I'm not pointing this out to you as a curious fact. From an IT support perspective, processor architecture means Windows architecture, and multiple Windows architectures in an organization means multiple versions of everything from Windows source files to service packs to drivers. Understanding processor architectures can help you untangle some of the problems you might encounter in a mixed 32-bit and 64-bit network environment. Therefore, I'll discuss all three current processor architectures—x86, IA64, and AMD64—although I'll be calling them Windows architectures. Then, I'll point out a few other things to watch out for when you transition to a mixed 32-bit and 64-bit Windows environment.
The x86 Windows architecture is the only remaining 32-bit non-embedded Windows architecture. Naturally, it runs on all processors implementing the x86 processor architecture. However, there are a couple of important caveats to keep in mind when Windows tells you it is x86 Windows.
The first caveat is that the AMD64 processor architecture is a superset of the x86 processor architecture, so the x86 Windows architecture can run on the AMD64 processor architecture. The bulk of computers shipped during the past five years running x86 Windows are actually running on 64-bit processors. Although you can't directly upgrade these installations to 64-bit Windows, it's quite possible to perform a clean 64-bit Windows installation on them.
Although there's no way to directly tell that 32-bit Windows is running on a 64-bit processor, you can use the built-in Windows Management Instrumentation Command-line (WMIC) utility to check the processor's name easily enough, after which you can check the processor's capabilities with the manufacturer. To check the processor name on the local machine, open Cmd.exe and run the command
wmic cpu get name
If you want to check the processor name on a remote computer named x51, you'd run the command
wmic /node:x51 cpu get name
The second caveat is that 64-bit Windows platforms will also run 32-bit x86 Windows applications in a special x86 Windows emulator. Even though the Windows OS itself is 64-bit, within the emulator, Windows looks exactly like it's x86 Windows. Part of what "exactly" means is that the PROCESSOR_ARCHITECTURE variable's value is x86. You can still tell what the real environment is, though. The x86 emulator also exposes a variable named PROCESSOR_ARCHITEW6432 that contains the architecture for Windows itself. If the variable doesn't exist, you're running on x86 Windows all the way down to the hardware.
You can also use WMIC to check the real value of PROCESSOR_ARCHITECTURE. For example, to check the true architecture of the local computer and the x51 remote computer, you'd run the commands
wmic environment where
wmic /node:x51 environment where
respectively. (Although these commands wrap here, you'd enter each command on one line.)
Every Windows version since the beginning of the Windows NT family has supported the x86 architecture, but that's about to change. Although Windows 7 supports x86 architectures, Windows Server 2008 R2 is x64 only.
AMD wasn't the only one to design a 64-bit processor architecture. Intel designed a 64-bit processor architecture named IA64. The first modern 64-bit Windows was designed to run on processors implementing the IA64 architecture. Therefore, it has a native PROCESSOR_ARCHITECTURE of IA64. The only processor families that implement IA64 are Intel's Itanium and Itanium 2. Only the Windows Server platforms currently support IA64. Although Windows XP initially supported IA64 architecture, issues with legacy support kept IA64 processors from becoming more than a rarity on desktops. Microsoft dropped support for IA64 in XP in 2005.
When Intel decided to drop backward compatibility with x86 processors with the IA64 architecture, AMD began work on an alternate 64-bit processor design that extended the x86 design in a backward-compatible fashion (just as the original Intel 80386 processors maintained compatibility with 80286 processors). AMD initially referred to the specification as x86-64, then renamed it AMD64. Microsoft's 64-bit versions of Windows built to run on this architecture also use the AMD64 name. Since the 2003 release of AMD64 XP, every release of Windows has supported the AMD64 architecture.
VIA Technologies and Intel sell processors that use the AMD64 architecture. For marketing purposes, Intel refers to the technology as Intel 64, obscuring the fact that its processors implement the AMD64 instruction set. Similarly, Microsoft has begun using the name x64 for this architecture to minimize confusion about the correct Windows architecture. Whatever the marketing name, the Intel 64 processors run precisely the same Windows builds as any other processors implementing the AMD64 architecture. In terms of the Windows versions and Windows software supported, you can treat the terms AMD64, Intel 64, x86-64, x64, and the less-known EM64T as roughly equivalent.
Other Things You Should Know
The last significant platform migration affecting the entire IT world occurred in the 1990s, when desktops moved from 16-bit Windows and MS-DOS to 32-bit Windows. The move from 32-bit to 64-bit Windows is much simpler. Network management is more centralized than it was in the 1990s, and most activities are abstracted from OS bitness.
Even though the move from 32-bit to 64-bit Windows won't be as difficult as the last significant platform migration, here are some pointers to help you avoid common pitfalls:
- Know software math—16 doesn't go into 64. Users won't be able to run 16-bit software from a 64-bit Windows OS, so you should eliminate any 16-bit software hanging around from the 1990s. If a user needs to occasionally run 16-bit software (e.g., a legacy financial package to access old data), you could provide the user access to a 32-bit platform. If you have multiple users who need to run 16-bit software occasionally, you might consider running the software on a 32-bit terminal server. Another option is providing a 32-bit virtual machine (VM). Virtualization might be the best alternative because VMs are highly portable.
- Be aware that IA64 (Itanium) is special. Windows systems using IA64 processor architectures can only run IA64 Windows. If you're repurposing existing IA64 systems, they naturally fall into a server role. The print server role could cause problems because these systems need IA64 printer drivers. The one long-term limitation on these servers is that there are fewer 64-bit applications available for IA64 Windows than for AMD64 Windows. However, IA64 will run 32-bit applications.
- Understand the incompatibilities between 32-bit and 64-bit software. The x86 Windows versions can't run 64-bit applications. AMD64 and IA64 Windows will run ordinary 32-bit software, but not within the same process. Since 64-bit applications can't use 32-bit binaries, 64-bit versions of software applications won't be able to load 32-bit add-ons or components. If you depend on 32-bit components, you need to use a 32-bit version of the application. This is one of the reasons that 64-bit Windows systems use 32-bit Internet Explorer (IE) by default; there's a huge installed base of 32-bit controls that vendors haven't ported to 64-bit.
- Realize that moving from 32-bit to 64-bit is a migration, not an upgrade. If you're planning to move existing PCs from 32-bit to 64-bit Windows, you can capture settings and files with tools such as Windows Easy Transfer, but you can't perform an upgrade. You can't even run the 64-bit installation for a new Windows version from within 32-bit Windows. You must perform a fresh install of Windows.
- Check your drivers. You can't use 32-bit kernel-mode drivers on 64-bit Windows. The WOW64 subsystem is available only above the OS kernel. So, checking the drivers before you migrate from 32-bit to 64-bit is crucial.
- Be ready to help users check their Windows architecture. The Windows look and feel is identical across the 32-bit and 64-bit computing lines, so users might not know whether they're on a 32-bit or 64-bit OS. IT support staff should be ready to walk end users through verifying their Windows architecture when problems arise. The Microsoft article "How to determine whether a computer is running a 32-bit version or 64-bit version of the Windows operating system" (support.microsoft.com/kb/827218) can serve as a conversational script for telephone support, or the link to the article can be sent to users.
What You Need to Remember
Although the move from 32-bit to 64-bit computing won't be simple (particularly when complicated by end-user confusion about names), it's unlikely to be an overwhelming hardship. The identical UIs across platforms and the support for existing 32-bit software make most of the change transparent. The fact that 64-bit Windows versions use 32-bit IE by default also helps make the change transparent. (If this wasn't the default, the calls about Adobe Flash Player not running in web pages alone could bring the average Help desk to its knees.) The dual IA64 and AMD64 architectures aren't a significant problem either. IA64 is generally used in high-end roles, where the lack of support for specific hardware and software can be considered a feature rather than a problem.
The most important points for the move to 64-bit computing come down to the following. Before you migrate a computer to 64-bit Windows, you need to make sure it has 64-bit drivers and eliminate (or make special arrangements for) any 16-bit software. To perform the migration, you must perform a fresh install—you can't upgrade. Finally, make sure IT support staff can help users determine whether they're running 32-bit and 64-bit when problems arise. Although this migration isn't trivial, it pales in comparison to the work that was involved in getting Windows 3.11 off the corporate desktop.