Designing for 64-bit Windows
Updated: July 8, 2008
Reviewed: July 8, 2008
The 64-bit editions of the Microsoft Windows operating system support both workstation and server computers. Implementing hardware and firmware support for a 64-bit system requires special considerations that differ from 32-bit platform design. This paper describes the special considerations for firmware, hard disk partitions, and device drivers. This paper does not address processor-related issues.
On This Page
ACPI Support for 64-bit Windows
Advanced Configuration and Power Interface (ACPI) Specification defines the system board, firmware, and operating system requirements for operating system control of configuration.
ACPI Revision 2.0 defines expanded interfaces to support 64-bit systems through extended Table definitions, new ACPI Source Language (ASL), and ACPI Machine Language(AML) 64-bit functions.
The initial release of the 64-bit edition of Windows will not include support for power management sleep states.
ACPI 2.0 and 64-bit Windows
Firmware for 64-bit Systems
Firmware provides boot support for initializing the hardware before the operating system is started. In x86-based (32-bit) systems, this capability is provided by the BIOS. Because traditional BIOS-based boot will not work with 64-bit Windows, other firmware boot solutions must be implemented.
EFIExtensible Firmware Interface
EFI is a new standard for the interface provided by the firmware that boots PCs, based on the Extensible Firmware Interface Specification, Version 1.02 (Intel Corporation). Microsoft supports EFI as the only firmware interface for booting 64-bit Windows operating systems.
Because 64-bit Windows will not boot with BIOS or with System Abstraction Layer alone, EFI is a requirement for all Intel Itanium-based systems.
In addition to protocols required in the EFI specification, Microsoft recommends that the firmware also support PXE_BC (remote/network boot), SERIAL_IO, and SIMPLE_NETWORK protocols as defined in the EFI specification. Support for these protocols is required by the "Designed for Windows" logo program for 64-bit systems.
The ESP contains the OS Loader, EFI drivers, and other files necessary to boot the system. MBR disks can also have an ESP, identified by partition type 0xEF. Although EFI specifies booting from either the GPT or MBR, 64-bit Windows does not support booting EFI from MBR disks or 0xEF partitions.
The ESP should only include:
Other value-add files or diagnostics used while the operating system is running should not be placed in the ESP because of its limited space. Value-add files are best stored in an OEM-specific partition. Just like MBR OEM partitions, the contents of GPT OEM (or other unrecognized) partitions are not exposed (given drive letters or returned in volume lists). Users are warned that deleting the partition can cause the system to fail to operate.
An OEM-specific partition should be placed before the MSR and after any ESP on the disk. Although not architectural, this placement has the same benefits as placing the ESP first. For example, it is also impossible to span volumes when an OEM-specific partition is logically between two spanned data partitions.
OEM System Abstraction Layer
The SAL is a firmware layer provided by OEMs. The implementation of this layer must conform to RS-IA-64 System Abstraction Layer (SAL) Specification, Revision 2.7 or later, including implementation of a call that will allow updates to the firmware.
SAL abstracts the uniqueness of a particular platform by providing a consistent interface to a higher level of the software stack to discover and control an Itanium-based system. SAL exports its components and their associated access details to the operating system through EFI using the SAL System Table.
New Partition Format for Bootable Hard Disks
A partition is a contiguous space of storage on a physical or logical disk that functions as though it were a physically separate disk. Partitions are visible to the system firmware and the installed operating system. Access to a partition is controlled by the system firmware and the operating system that is currently active.
For 64-bit Windows, bootable hard drives must be partitioned using the GPT mechanism defined in EFI 1.0. GPT is also the default partitioning scheme used by 64-bit Windows for all non-removable storage media. GPT complements the older MBR partitioning scheme that has been common to PCs.
Chapter 16 of the EFI specification defines the GPT format. Additional guidelines for implementing GPT support for Itanium-based systems is defined in Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server, coauthored by Intel Corporation and Microsoft Corporation.
MBR disks support only four partition table entries. If a user wants to create more partitions - a secondary structure - an extended partition is necessary. Extended partitions can be subdivided into one or more logical disks.
Only one extended partition can be present on any given drive, and the maximum number of logical drives is MAXULONG/4. All MBR disk partitions and logical drives must be cylinder-aligned, even on hardware RAID sets built from multiple different drives with no clear underlying physical geometry.
To protect GPT-partitioned disks from tools that only understand MBR - such as Windows Disk Administrator or Fdisk, which do not know how to properly access a GPT disk - each GPT disk has a Protective MBR, beginning in sector 0. This sector precedes the GPT partition table and contains one type 0xEE partition that spans the disk. The Protective MBR protects GPT disks from previously-released MBR disk tools such as FDISK or Windows Disk Administrator. These tools are not aware of GPT and do not know how to properly access a GPT disk.
Legacy software that does not know about GPT interprets only the Protective MBR when it accesses a GPT disk. These tools will view a GPT disk as having a single, encompassing (possibly unrecognized) partition by interpreting the Protective MBR, rather than mistaking the disk for one that is unpartitioned.
GPT information from Microsoft
Drivers for 64-bit Windows
The 64-bit version of Windows is designed to enable developers to use a single source-code base for both Win32-based and Win64-based applications - and to a large extent - for 32-bit and 64-bit Windows drivers.
Key considerations of 64-bit Windows for driver development include:
Microsoft provides guidelines on the Web and in the Windows DDK to help developers with porting drivers to 64-bit Windows. Application developers should see the guidelines provided in the Microsoft Platform SDK.
Driver Porting Issues Checklist
More Issues for 64-bit Systems
APIC Support. Under the "Designed for Windows" logo program for hardware, Itanium-based systems must include Streamlined APIC Advanced Programmable Interrupt Controller (SAPIC) support that complies with the 64-bit extensions defined in ACPI 2.0.
Manageability. In addition to the hardware manageability guidelines defined in Windows Hardware Instrumentation Implementation Guide, Itanium-based systems must implement hardware and firmware support for Itanium Machine Check Architecture.
USB Devices. The system firmware must provide EFI boot support for USB keyboards, pointing devices, and hubs.
Parallel and Serial Devices. Itanium-based systems must not include legacy parallel ports. However, each system must provide a legacy serial port for developers and technicians to use as a debug port.
Multiprocessor Support. For a system in which more than one processor can be installed, the system must employ those processors symmetrically; that is, all processors must be able to access all I/O buses and system memory, and cache coherency must be maintained. An Itanium-based system must also include a Multiple SAPIC Description Table that complies with ACPI 2.0.
Console Redirection. The system must provide support for redirection of all console I/O to the serial port. The driver for the serial console must be capable of supporting the capabilities documented in Extensions to the VT100 Terminal Definition. Note that unlike BIOS, EFI firmware must indicate which serial port is used for console I/O, and the configuration of that serial port through the console device path for the serial port as specified in EFI 1.0.
Other Boot Support. To ensure the system can boot from CD or DVD drives, the system must support the No Emulation mode in El ToritoBootable CD-ROM Format Specification, and the additional requirements defined in Section 16.2.2, "ISO-9660 and El Torito," in EFI 1.0.
Headless Server Support. The server editions of 64-bit Windows will provide support for headless operating.
Windows Logo Program for Hardware. Requirements for the Microsoft Windows Logo Program for hardware related to sleep state support and wake support will not apply to Itanium-family systems submitted for Logo testing until operating system support is available. All other ACPI-related requirements remain applicable for Itanium-family systems that are submitted for "Designed for Windows" logo testing.
Windows Logo Program for Hardware