In This Chapter
Understanding 64-bit architecture.
Running 32-bit applications.
Comparing 64-bit and 32-bit Windows .
If any modern technology has earned the term venerable, it's Intel's 32-bit processor architecture. Even today's newest Pentium computers have an architecture deeply rooted in the 286 and 386 processors of more than a decade ago. The 32-bit architecture has served us well, acting as the primary hardware platform for every version of Windows NT, but it's definitely time for something new: Intel's 64-bit Itanium processor family.
Servers based on these 64-bit processors are already available, and Intel is hard at work on new editions of the Itanium processor that run faster and provide additional features. Microsoft provided Windows Advanced Server Limited Edition—essentially a pre-release, production-ready version of 64-bit Windows Server 2003—to give 64-bit servers a network operating system, and of course Windows Server 2003 offers two 64-bit editions. But there's a great deal more to 64-bit computing than a new processor and operating system. Itanium servers include a new memory architecture, new peripheral bus, new disk-handling mechanisms, and much, much more. This chapter provides you with an overview of the world of 64-bit computing, introduces you to the 64-bit hardware platform, and shows you how 64-bit Windows differs from its 32-bit cousin. It also explains how Windows Server 2003's 64-bit editions provide compatibility for your existing 32-bit applications, so that you're not left to scramble for new versions of your software.
Both Microsoft and Intel are pushing 64-bit servers like there's no tomorrow. Many of the touted advantages are perfectly real, such as the truly enormous memory support included in the 64-bit architecture. 64-bit servers are perfect for memory-hungry database and data warehousing servers, and the 64-bit architecture offers throughput that makes it perfect for file serving, Internet content caching, and more.
Intel's 64-bit architecture is based around its Itanium processor family. The Itanium is not only a 64-bit processor, but also includes a number of general enhancements over Intel's latest Pentium processors. One major new feature is EPIC, Intel's Explicitly Parallel Instruction Computing architecture. EPIC provides far superior parallel computing, prediction capabilities, and other features that allow Itanium processors to effectively process more instructions at one time. Even though the initial Itanium processors had a clock speed less than half of the then-current Pentium processors, Itaniums were still faster due to their capability to process more instructions in parallel, rather than in sequence.
Itanium 2's system bus runs at a blazing 400MHz, almost triple the speed of the fastest Pentium system busses (and faster than the original Itanium's 266MHz bus). Itanium also includes enterprise-class reliability features, such as enhanced error detection and correction capabilities and an integrated error reporting mechanism—all features that can exist because Itanium isn't based on what came before but is instead a radically new architecture. Obviously, the capability to support up to 256 processors in a single system presents exciting new ideas for some amazingly powerful (and expensive) servers.
As you'll read later in this chapter, Itaniums can fully emulate a Pentium processor, enabling Windows to more easily support 32-bit applications under a 64-bit environment. This backward-compatibility is a good sign for Itanium's longevity in the marketplace because businesses won't have to immediately scrap all their 32-bit software to implement 64-bit computers.
64-bit's “big gun” is memory support. Although the Pentium's 4GB memory limit was impressive several years ago, 4GB doesn't go very far with today's high-end server applications. Itanium processors' memory support depends on their accompanying support chipset: Original Itanium computers supported 16GB of RAM per processor, whereas newer Itanium 2 computers support up to 64GB of RAM per processor—with up to 256 processors. That's a lot of RAM and should be enough for quite a few years. Itanium 2 processors also have three levels of cache memory, running at extremely high speeds. These caches help reduce the processor's need to access main memory by storing frequently used information within the caches. Sun Microsystems offers an interesting analogy that puts 64-bit memory capabilities into perspective: A 32-bit computer has enough addressing space to store the name and address of every person who has lived in the United States since 1997. A 64-bit computer can address enough memory to store the name and address of everyone who has ever lived on Earth.
Itanium 2 computers will also include support for Infiniband, the replacement for the PCI peripheral bus architecture you're already familiar with. PCI, as you know, supports the use of busmastering devices that can directly access main memory, removing some processing burden from the computer's main processor. Infiniband, however, uses a completely switched architecture, giving every device direct access to main memory and the processors. This architecture is analogous to a switched network environment, in which every network device has dedicated bandwidth, rather than having to share that bandwidth with other devices. Infiniband is faster, too, with bandwidths of up to 6Gbps. That's hundreds of times faster than even the fastest PCI bus.
Itanium machines use a radically new change to disk partitioning. Your 32-bit servers rely on a master boot record (MBR), which identifies the partitions on a disk by their cylinders, sectors, and head locations. The MBR also includes the partition's type, which can include primary, non-DOS, extended, and so forth. The MBR tracks which partition is active (bootable), as well. Unfortunately, the MBR scheme was designed decades ago when nobody could imagine hard disks so large that more than four partitions would be needed, so the MBR supports a maximum of four partitions. Itanium machines are built for the future, though, and use a much more flexible scheme called the GUID Partition Table (GPT).
Each GPT-based disk assigns two globally unique identifiers (GUIDs) to each partition on the disk. One GUID identifies the partition, whereas the other represents a partition type. Partition types include
EFI System Partition (ESP)—. This partition holds the operating system-specific boot loaders for the operating systems on your server. I'll discuss these in more detail in the next section, “Boot Architecture.” Each server has only one ESP, which is at least 100MB in size and no larger than 1GB. The ESP is usually sized at 1% of the disk's total size. The ESP doesn't show up in Windows at all and is accessible only from the server's EFI command processor.
Microsoft Reserved partitions (MSRs)—. This special type of partition stores information for dynamic disks. I explain MSRs in more detail in the sidebar titled “Understanding MSRs.”
Microsoft Data partitions—. These are regular partitions created in Explorer or the Disk Manager console, and they can be accessed by other operating systems installed on your server, unless of course you protect them by using NTFS permissions.
OEM partitions—. These are created by some server vendors and include special diagnostic utilities, setup utilities, and so forth. Vendors' utilities access the partition by its GUID because these partitions don't appear in Explorer. You can access them in the Disk Management console.
Itanium machines' partition management is extensible and much more flexible than the partition management system on 32-bit machines (which dates back to IBM's original PC computer from 1980).
One of the most noticeable changes in the Itanium architecture is its completely new boot architecture, which bears a closer resemblance to RISC-based computers (such as the Alpha) than to the traditional PC boot process, which is more than 20 years old. To quickly review, PCs use their BIOS settings to determine from which device—CD-ROM, floppy, hard disk, or network—to boot. The BIOS then looks for a boot sector on the appropriate device and loads it into memory. The boot sector contains code that looks for an operating system loader, such as Windows 2000's Ntldr. The operating system loader is responsible for getting the operating system up and running. In Windows's case, that includes running Ntdetect.com to find out what basic hardware is present, loading a SCSI driver (Ntbootdd.sys) if necessary, and so forth. Special provisions abound, including the El Torito bootable CD-ROM specification, which is supported by most servers. All this complexity makes it very difficult to create machines that can boot to different operating systems, troubleshoot missing or corrupted boot sectors, and so on.
Itanium machines work completely differently: They store boot information in a special nonvolatile memory called firmware. Intel has developed an interface called Extensible Firmware Interface (EFI), which controls the settings in the firmware. Itanium machines also store their boot sector code right in the firmware, and not on disk. As a result, Itanium machines don't need Ntldr or a Boot.ini file. Itanium machines also use a secondary boot loader stored on disk, named Ia64ldr.efi. Note the .efi file extension, which indicates a file that can be executed by the EFI firmware. The EFI itself contains a command processor that is accessible from a boot menu and lists all the partitions available to it. You can execute the command processor's Map command to redisplay the list if necessary. The list includes
A GUID for each partition—. This is a long ID number, such as
FD47389-87D4-116B-9488 849B7298A657.A sequence number—. Indicates the partition's location on the disk. These are listed as
blk0,blk1, and so forth.An alias—. If a partition is formatted with a file system that EFI can read (which currently includes FAT, FAT32, and Joliet CD-ROMs), the partition is assigned an alias, such as
fs0orfs1.
Within the command processor, you can type a block name followed by a colon to access a particular partition. For example, entering blk1: and pressing Enter takes you to the second partition (the first partition is blk0). If the partition's file system is readable by EFI, you can use a standard Dir command to display a directory listing. For partitions with an alias, such as fs0:, you can also enter the alias name to access the partition: Type fs0: and press Enter.
Another important change is that EFI doesn't support El Torito bootable CD-ROMs, so you can't just pop a Windows Server 2003 CD in the drive and restart the computer to launch Setup. However, EFI does natively recognize the Joliet CD-ROM file system, so you can access the contents of the CD-ROM from within the command processor and launch Setup that way.
For example, if your Windows Server 2003 CD-ROM is assigned the partition alias fs2:, you can load the command processor, type fs2:, press Enter, and simply execute the Setup bootloader (Setupldr.efi). All 64-bit-compatible operating systems include an EFI-compatible Setup loader, which you can execute from the command processor.
The firmware's boot menu is essentially a macro system, allowing a single menu option to switch to a specified partition and execute a particular EFI secondary boot loader. This architecture enables you to easily set up multiboot computers without having to remember complex ARC naming paths (such as Boot.ini uses), troubleshoot the multifile 32-bit Windows boot system (Ntldr, boot.ini, Ntdetect.com, and so forth), or deal with master boot sectors and other disk-based boot schemes.
The new boot architecture takes some getting used to, though. You can think of it as a kind of mini-Recovery Console and boot menu, built right into the server hardware itself. After you're accustomed to using the new architecture, you'll find that it's more flexible and powerful than the decades-old system 32-bit servers use.
Neither Microsoft nor Intel planned to leave its 32-bit users in the dust. Both 64-bit Windows and the Itanium architecture provide ample backward-compatibility with the 32-bit world, making it easier to implement these new products in your environment. The next two sections cover the software compatibility provided by Windows and the hardware compatibility provided by Intel's architecture.
Ever since the first version of Windows NT, administrators have become familiar with WOW, the Windows On Windows subsystem. Essentially, WOW emulates 16-bit Windows, allowing Windows NT to run 16-bit Windows applications for backward-compatibility. Although WOW was more commonly used on clients than on servers, where native 32-bit applications reign supreme, WOW is making a fresh appearance in 64-bit Windows. All editions of 64-bit Windows include WOW64, a 32-bit Windows subsystem that hosts 32-bit Windows applications. These applications run in what is basically an emulated 32-bit Windows environment, so they tend to be a bit slower than if they were running on 32-bit hardware in a 32-bit operating environment. Also, 64-bit Windows doesn't include the original WOW, making it tougher to run any 16-bit applications you still have laying around. Certain 16-bit applications will still run, perhaps most notably certain 16-bit Setup utilities used to distribute some older 32-bit applications.
So, by and large, any application written for 32-bit Windows will work fine (albeit a bit more slowly) with 64-bit Windows. You won't be running the 32-bit edition of SQL Server on 64-bit Windows, but you can certainly run 32-bit utilities and administrative tools. And, in case you're wondering, Microsoft will probably release a 64-bit edition of SQL Server around the same time as Windows Server 2003, and Microsoft is hard at work on 64-bit editions of its other popular .NET Enterprise Servers (such as SQL Server), Visual Studio, and more.
Speaking of Visual Studio, software developers don't need to wait for a 64-bit edition to start creating 64-bit applications. They can develop 64-bit applications on 32-bit Windows computers and compile them as native 64-bit applications; 64-bit Windows itself was, after all, written under 32-bit Windows. A Visual Studio 6 service pack has introduced a special 64-bit thunking layer, which enables developers to write 64-bit code on a 32-bit operating system.
64-bit Windows must boot from a GPT partition, but it allows you to use the older MBR scheme to partition other disks. This feature enables you to easily add existing MBR-based disks to your Itanium servers, primarily for migration and coexistence purposes. Because 32-bit Windows can't read GPT-based disks, MBR-based disks provide a convenient common ground for the two architectures. For example, removable drives such as Zip and Jaz drives can't be partitioned with GPT; the 64-bit architecture considers these to be superfloppies and supports only MBR-based partitioning. Other removable drives, including USB and IEEE-1394 (FireWire), must also be partitioned with MBR and can be easily transported between 64-bit and 32-bit machines.
As we've implied, most of your 32-bit peripheral equipment will work fine on 64-bit servers, especially external USB and IEEE-1394-based devices. Early Itanium servers still use PCI devices, as the new Infiniband hardware is just coming to market. SCSI and IDE disks work fine in Itanium machines, as do other IDE and SCSI peripherals such as CD-ROM and DVD-ROM drives.
64-bit Windows doesn't include every bell and whistle of its 32-bit cousin. After all, both 64-bit Windows and Itanium-based server hardware are marketed (and priced) as enterprise solutions; you would no more configure an Itanium server to be a fax server than you would use a Ferrari to pick up the soccer team after practice. Some of the “missing features” between 32-bit and 64-bit Windows are simply features that an enterprise wouldn't use on 64-bit Windows. Other missing features reflect the intense amount of development that went into 64-bit Windows; not everything fit in under the deadline. Here are the major feature differences between 32-bit Windows Server 2003 and the equivalent 64-bit editions:
The .NET Framework isn't included with 64-bit Windows—. Expect that to change in the future; the whole point of the .NET Framework is that Microsoft (or someone) simply has to create a new common language runtime (CLR) in order to move the Framework to a different hardware platform. You'll see a 64-bit edition of the CLR in the future.
For more information on the .NET Framework and the CLR, see “The .NET Framework,” p. 146.
ASP.NET isn't available in 64-bit Windows—. This is because it's part and parcel of the .NET Framework. As soon as the Framework has a 64-bit CLR, ASP.NET should run just fine.
Obviously, the 32-bit editions of Windows Server 2003 don't take advantage of improvements in the Itanium architecture—. Windows Server 2003's 64-bit editions have additional features that leverage Itanium's native error logging mechanisms and much more. Although it's theoretically possible (according to Intel) to run 32-bit Windows on an Itanium, you wouldn't see much of an improvement in the operating system's performance, and you wouldn't see any additional features.
Only 64-bit editions of Windows include support for 64-bit software development via group policy—. New options in the user interface will enable you to specify whether 32-bit applications should be deployed to 64-bit computers, as well. This feature will provide interoperability in a mixed 32-bit and 64-bit environment.
Windows Installer on 64-bit editions of Windows also includes specific 64-bit application support—. This enables packages to include both 32-bit and 64-bit components. This capability allows a single installer package to support both 32-bit and 64-bit computers, reducing administrative overhead and software maintenance.
64-bit Windows includes printing support for 32-bit clients—. This enables administrators and users to manage and connect to printers that are hosted by a 64-bit edition of Windows from their 32-bit client operating systems.
64-bit editions of Windows include new driver installer routines—. These can choose available 64-bit drivers over 32-bit drivers, if both are provided during an installation. INF files, which list the drivers needed by a particular device, can include 64-bit-specific lists in addition to 32-bit driver lists.
64-bit Windows doesn't include, at least for now, Product Activation—. Microsoft doesn't feel that piracy, the reason Product Activation exists, will be an issue in the 64-bit world for the time being.
For more information on Product Activation in 32-bit Windows, see “Activating Windows,” p. 13.
64-bit Windows lacks some common media applications—. These include NetMeeting and Windows Media Player. This lack isn't critical in a server operating system, but you'll see 64-bit versions of these applications made available as free downloads and targeted at the 64-bit edition of Windows XP.
64-bit Windows doesn't support power management—. With no 64-bit portable computers on the near horizon, you probably won't miss this feature anyway. Another common portable computer feature, infrared communications, isn't supported in 64-bit Windows, either.
64-bit Windows does not include Remote Assistance—. Windows Server 2003 does include Terminal Services, so the underpinnings of Remote Assistance are available, but the actual feature isn't implemented.
Native CD burning isn't included in 64-bit Windows—. There's nothing stopping a third-party manufacturer from writing a CD burning application, however, and those will no doubt become available after 64-bit operating systems have enough market penetration.
Some other, minor features are not included in 64-bit Windows, but these mainly affect the client operating system—Windows XP. Speech recognition, for example, isn't included in Windows XP 64-bit. Altogether, Microsoft claims a 99% feature parity between 32-bit and 64-bit editions. As mentioned, some of the parts missing from 64-bit today, such as the .NET Framework, will undoubtedly be released in a future update.