Designing for 64-bit Windows
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 |
| Firmware for 64-bit Systems |
| New Partition Format for Bootable Hard Disks |
| Drivers for 64-bit Windows |
| More Issues for 64-bit Systems |
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.
| Required ACPI 2.0 tables | ||||||||||
| Itanium-based systems must support the ACPI 2.0 64-bit fixed tables, which allow for 64-bit addressing without namespace changes, so that ACPI 1.0 namespaces will still be valid. Windows will not support the Version 0.71 interim tables. | ||||||||||
|
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
http://www.microsoft.com/whdc/system/platform/64bit/IA64_ACPI.mspx
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.
| Firmware and boot partition acronyms | |
EBR | extended boot record |
ESP | EFI system partition |
GPT | GUID partition table |
GUID | globally unique identifier |
HAL | hardware abstraction layer |
MBR | master boot record |
SAL | System Abstraction Layer |
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:
| • | Files required for booting an operating system |
| • | Platform tools that run before operating system boot |
| • | Files that must be accessed before operating system boot, for example, to perform pre-boot system maintenance |
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.
EFI Specification
http://developer.intel.com/technology/efi/download.htm 
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.
SAL Specification
http://developer.intel.com/ design/ itanium/ downloads/ 245359.htm
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.
| GPT Benefits | |
| Feature | Description |
Partition size | Can be up to approximately 18 exabytes in size. |
Number of partitions | Not constrained by temporary schemes such as container partitions as defined by the MBR EBR. |
Partition format | Well defined and fully self-identifying. Data that is critical to platform operation is located in partitions and not in unpartitioned or "hidden" sectors. |
Integrity | Uses primary and backup partition tables for redundancy and CRC32 fields for improved integrity of the partitions data structure. |
Partition format | Uses version number and size fields for future expansion. |
Unique ID | Each partition has a unique GUID and a partition content type, so no coordination is necessary to prevent partition identifier collision. Each GPT partition also has a 36-character Unicode name, which means that any software can present a human-readable name for the partition. |
MBR Issues
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
Windows and GPT FAQ
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:
| • | Three classes of new data types |
| • | New 64-bit compiler |
| • | Performing direct memory access (DMA) |
| • | Supporting 32-bit I/O in 64-bit drivers |
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.
Key Web sites for 64-bit platform issues
64-Bit System Design
Getting Ready for 64-bit Windows
Driver Porting Issues Checklist
Use
new Win64-safe data types
proper format specifiers in printf and wsprintf
PtrToLong and PtrToUlong to truncate pointers
FIELD_OFFSET macro
TYPE_ALIGNMENT macro
Be Careful
when performing unsigned and signed operations
when using hexadecimal constants and unsigned values
with NOT operations
when computing buffer sizes
with polymorphic interfaces
when calling functions that have pointer OUT parameters
to know your address space
to remember that 0xFFFFFFFF is not the same as -1
to examine all data-structure pointer usage
to watch for data-type changes in Public Kernel Structures
when using structure packing directives
Avoid
using computed or hard-coded pointer offsets
using hard-coded pointer or handle values
using different packing levels in the same header file
Do Not
cast pointers to int, long, ULONG, or DWORD
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.
Design guidelines for 64-bit systems
Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server
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
http://www.microsoft.com/whdc/winlogo/default.mspx