Chapter 4 - Getting the Windows Logo for Hardware

Download 0.7 Mb.
Hajmi0.7 Mb.
1   2   3   4   5   6   7   8   9   ...   22

Chapter 4 - Getting the Windows Logo for Hardware

The guidelines for submitting systems for Windows Logo Program testing are defined on the web at This chapter provides a brief overview.
To submit a system for Logo Program testing

  • Follow the submission rules at
To submit a device for Logo Program testing

  • Determine the Test Category and Logo Program for your device, based on the list at, and follow the related rules for submission.
When WHQL Receives a Submission

WHQL will acknowledge all Test Submissions within three days of when they receive the submission. If you send a test submission to WHQL and do not receive this confirmation e-mail, please contact with STATUS REQUEST in the Subject line. Please include the following information in the body of the message: the type of equipment, date shipped, and how to contact you if there are any questions.

Customers can check the WHQL Submission Status web page at for submission-related information during this time.

When your device or system completes WHQL processing, you will receive a Test Report that includes technical feedback on any problems that were found. If your device passes Windows Logo Program testing, you will also receive additional information, depending on the agreements you signed when you submitted your product for testing.

Appendix A - System Requirements Checklist

This appendix presents the detailed checklist of requirements for systems. The current versions of these requirements are provided on

Requirements apply for all of the following tested operating systems unless otherwise indicated:

Windows XP Home Edition (32-bit)
Windows XP Professional (64-bit and 32-bit)
Windows Server 2003 family (64-bit and 32-bit)


  • There are no specific requirements for workstations or Entertainment PC systems in the Windows Logo Program. Instead, Windows Logo Program compliance is evaluated based on components present in the system submitted for testing.

  • These requirements apply to all systems and peripherals displaying the "Designed for Windows" Logo, as the system or device/peripheral is shipped to a customer.

Statements within this document relating to "testing requirements" or "systems submitted for Microsoft Windows Logo Program Testing" indicate test submission requirements; such statements do not reduce these Logo Program requirements.

A customer may request that the system supplier omit a particular component from a system configuration as shipped to that customer; however, such a customer request does not remove or reduce any related requirements for that system to support that component's functionality when and if the customer installs a Logo’d component of that class into the system.
See also:

  • Conventions Used in This Document

  • How to Use the Appendixes

A1.0 General System Requirements

A1.1 General System - Windows Compatibility

A1.1.1 Devices meet all Windows compatibility requirements

As defined in Appendix B, "Device Requirements Checklist"
A1.1.2 ACPI system board and ACPI firmware

ACPI BIOS must be Windows-ready:

  • x86-based client and server systems: ACPI-compliant as defined in ACPI 1.0b, Section 1.6
    The system board and BIOS must support Advanced Configuration and Power Interface Specification, Revision 1.0b.
    System board devices not power managed or configured via standard bus specifications must comply with ACPI 1.0b.

  • Itanium-based systems: ACPI 2.0 plus 64-bit fixed tables; see A5.4.1.
A1.1.2.1 DELETED
A1.1.2.2 Power management and Plug and Play capabilities are ACPI compliant.

A1. All system-board power management or Plug and Play features comply with the ACPI 1.0b. This requirement applies even if a particular feature is not a specific requirement or recommendation in ACPI 1.0b.

A1. System supports S3, S4, and S5 states. Desktop and single-processor workstation systems must support the S5 (soft-off) state as required in the ACPI 1.0b specification, plus the S3 and S4 states. Every system must support wake from all implemented sleep states, except S4 and S5, for all wake-capable devices and buses.

Mobile PC Note
Mobile PCs are required to support S1 or S3, in addition to S4 and S5. Mobile PCs are not required to wake from S3 or S4.

Server Note
Server systems are not required to support wake from D3. At a minimum, SOHO servers must support S1.

A1. If software fan control is implemented, thermal design and fan control comply with ACPI 1.0b. A thermal model and fan control must be implemented as defined in Section 12 of the ACPI 1.0b specification as a means of running the PC quietly while it is working and of turning the fan off while it is sleeping. Notice that hardware override is permitted only to handle thermal conditions when the operating system is not running, the operating system has put the system in a sleep state, or safe operating parameters have been exceeded.

A1.1.2.3 Windows driver support: “Power Management” in the Windows DDK.

See Appendix B for device class-specific requirements for power management in drivers.
A1.1.3 All components correctly implement Plug and Play

A1.1.3.1 Each bus and device provided in a system must meet the current Plug and Play specifications related to its class, including requirements defined in Section 6 of the ACPI 1.0b specification and clarifications published for some Plug and Play specifications. This guideline includes requirements for automatic device configuration, resource allocation, and dynamic disable capabilities.

A1.1.3.2 Any legacy components remaining in a legacy-reduced system must meet the requirements defined in Legacy Plug and Play Guidelines.

PCI components implement System IDs (SIDs) and Subsystem Vendor IDs (SVIDs) as defined in "Specification for Use of PCI IDs with Windows Operating Systems" at

For Windows XP, SIDs and SVIDs are not required for PCI-PCI bridges and some other core chipset classes. For the specific list of exceptions, see Appendix D of PCI 2.2.

A1.1.4 System BIOS requirements

For complete Itanium-based firmware requirements, see A5.0.
A1.1.4.1 Correctly configure PCI-to-PCI bridges if the system has a VGA device behind a bridge.

The system BIOS must correctly configure PCI-to-PCI bridges if the system has a VGA device behind a bridge. Specifically, the BIOS must correctly set the VGA Enable and ISA Enable bits on the bridges, to avoid causing the bridges to be in conflict with each other. See
A1.1.4.2 DELETED
A1.1.4.3 Support booting from CD or DVD device per El Torito v. 1.0 No Emulation mode.

BIOS supports booting the system from CD or DVD. The system BIOS or option ROM must support the No Emulation mode in “El Torito”—Bootable CD-ROM Format Specification, Version 1.0, by IBM and Phoenix Technologies, for installing Windows from optical media, such as bootable CD media.

The primary optical device must be bootable. This applies to the primary optical storage provided and the primary bus to which the device is attached.

A1.1.4.4 Windows XP Professional desktop/Windows Server 2003: Support Preboot Execution Environment (PXE) based on PXE Specification, v. 2.1:

A1. x86-based servers: Provide PXE-based support if a network adapter with remote boot capabilities is provided with the system.

A1. x86-based Windows Professional desktop and Itanium-based clients: Provide PXE-based support in all cases.

Mobile PC Note
See A3.4.2 for mobile BIOS PXE requirement.
A1.1.4.5 Support boot-drive determination in multiple-drive systems via CIP BIOS Boot of EFI boot manager

The BIOS must comply with the implementation of boot-drive determination in multiple-drive systems as defined in Section 5.0 of the Compaq-Intel-Phoenix BIOS Boot Specification, Version 1.01. Windows uses this format for determining the boot drive when new bootable devices are introduced to a PC. Itanium-based systems must use EFI boot manager capabilities.
A1.1.4.7 DELETED
A1.1.4.8 DELETED
A1.1.4.9 x86-based: Support Int13h Extensions on BIOS boot-based system for correct support of high-capacity hard drives.

BIOS and option ROMs support Int 13h Extensions as defined in the “Layered Block Device Drivers” section of the Windows DDK. This requirement also applies for redundant array of inexpensive disks (RAID) controllers when implemented, to support booting from Int 13h Extension devices.

Support for drives with capacities greater than 8.4 GB must be provided through the extended services (functions 4xh and greater) of the Int 13h Extensions as defined in Enhanced BIOS Services for Disk Drives [T13-1226DT], Revision 7.

A1.1.4.10 DELETED
A1.1.4.11 Provide PCI interrupt routing information

Use a _PRT object per ACPI 1.0b Section 6.2.3 for x86-based systems or ACPI 2.0 Section 6.2.8 for Itanium-based systems.
A1.1.4.12 x86-based: Support logical block addressing (LBA) for ATA disks (if present in the system).

The system BIOS must support the use of logical block addressing (LBA) for drives with LBA addressable area greater than 16,515,072 sectors, and the system BIOS must use LBA for all read and write operations to the device. The ATA 1226 technical report defines the proper implementation of LBA.
A1.1.4.13 Provide boot support for USB keyboards and hubs

For USB host controllers that provide only internally-accessible USB ports and that are not connected to a keyboard or hub: such controllers are not required to provide boot support for keyboards and hubs. If a downstream keyboard is attached to such a host controller, the keyboard and any intermediate hubs must be supported at boot time.

See “Server Note” at A1.4.3 for systems that provide headless server support.

A1. BIOS handles long descriptors read from USB device attached at boot time. When a USB host requests the configuration descriptor for a device, the device returns the configuration descriptor, all interface descriptors, and endpoint descriptors for all interfaces in a single request (see section 9.4.3 of the USB 1.1 specification). The maximum size of the returned data is 64 KB.

To enumerate the USB and configure boot devices, the BIOS must make a configuration request to every device encountered. Therefore, the BIOS must be capable of handling a maximum length descriptor if such a descriptor is returned. However, the BIOS is required to configure only boot devices. Nonboot devices can be left in the addressed USB-visible device state.

A1. BIOS provides boot support for USB keyboards and hubs. This BIOS support, as defined in Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.1, with particular attention to the Keyboard Boot Protocol, must provide the ability for the user to enter the BIOS setup utility and also provide enough functionality to install and boot an operating system that recognizes USB peripherals. USB keyboards built as stand-alone devices, part of a composite device, or part of a compound device must all be recognized and usable. The BIOS is required to support keyboards behind at least two levels of external hubs.

A1. For systems with multiple USB host controllers, BIOS support for USB keyboards and hubs is required for all host controllers that are integrated on the system board (that is, not add-on cards).

A1. Keyboard and pointing devices must be functional for all modes of the operating system, including booting, loading, safe mode, and operating system setup and installation.

A1. USB external connectors and USB input device support must be enabled by default in the BIOS, and the BIOS must make USB input devices, such as keyboards and pointing devices, available at boot time.

A1.1.4.14 If bootable ATAPI devices are included in the system, firmware support complies with ATAPI Removable Media Device BIOS Specification 1.0 and ATA/ATAPI-5

ATA BIOS or option ROM must provide boot support for the primary ATA Packet Interface (ATAPI) bootable floppy disk drive in compliance with ATAPI Removable Media Device BIOS Specification, Version 1.0. Complying with this specification provides Int 13h and Int 40h support for bootable floppy drives as the primary or secondary floppy disk device.

The system BIOS must configure the drive and host controller so they are optimized for ATA operation. The programmed I/O mode must continue to work. The ATA/ATAPI device driver must also support restoration of these settings using the ACPI control methods _GTM, _STM, and _GTF when the ATA controller is power managed across a suspend and resume cycle.

The AT Attachment with Packet Interface – 5 (ATA/ATAPI-5) standard defines the enumeration process for all ATAPI devices.

A1.1.4.16 x86-based client: For a system board that supports a riser card, provide a unique identifier for the riser

The BIOS for a system board that supports any type of enumerable riser card, such as AMR, Advanced Communications Riser (ACR), and Communications and Networking Riser (CNR), must include the following support:

  • Detecting and enumerating each function on that type of riser device.

Representing each function on that device so the relevant Windows bus enumerator (such as a PCI bus enumerator) can detect it, and then locate and install appropriate drivers.

The system BIOS must provide a unique PCI SID for any riser card, assigned by the codec manufacturer. This is identical to current Logo Program requirements for audio and modem devices on a PCI add-on card—except these are system-board devices, so the PCI SID must reflect that of the system-board manufacturer.

If an OEM chooses a riser card and driver from any riser card driver manufacturer, the BIOS must populate the fields as follows:

  • The PCI SVID must reflect the Vendor ID assigned by the PCI Special Interest Group (SIG) to that OEM.

  • The SID must be unique for each AC ‘97 device configuration. For example, for a modem-on-motherboard (MoM), modem riser (MR), or audio modem riser (AMR) device, each SID must be unique.

If an OEM chooses a system board from a manufacturer that works with one or more codecs, the following applies:

  • The SVID must reflect the Vendor ID assigned by the PCI SIG to that system-board manufacturer.

  • The SID must be unique for each AC ‘97 codec/device configuration. For example, for a MoM, MR, or AMR device, each SID must be unique.

  • For an AMR riser, the system BIOS must properly implement the detection algorithm from Intel to verify that the hardware on an AMR/MR riser extension is actually present. The detection algorithm is available at

Similar provisions exist in the CNR and ACR specifications.

See also AC ‘97 and AMR Plug and Play Design (

A1.1.4.17 DELETED
A1.1.4.18; A1.1.4.6 If system is PXE-capable, firmware supports remote boot via CIP BIOS Boot or EFI boot manager

PXE-capable systems must support booting from network per Compaq-Intel-Phoenix BIOS Boot Specification, Version 1.01, Appendix C (x86-based systems) or EFI boot manager (Itanium-based systems).

Mobile PC Note
These requirements only apply to mobile PC systems that include either a system board network adapter or a preinstalled mini-PCI LAN adapter.

See A5.0 for complete Itanium-based firmware requirements.

A1.1.5 Multiprocessor system compatibility requirements
A1.1.5.1 Comply with ACPI specification for multiprocessor support

x86-based: Comply with ACPI 1.0b.

Itanium-based: Comply with Multiple APIC Description Table (MADT) in ACPI 2.0, Section
A1.1.5.2 DELETED
A1.1.5.3 Implement PCI IRQ routing as described in PCI IRQ Routing on a Multiprocessor ACPI System

A1.1.5.4 Multiprocessor x86-based desktop systems support S1, S4, and S5

Support for S3 is optional for multiprocessor systems.

A1.2 General System - Industry Standards

Note: This list provides complete titles and web locations for references cited. The listing of a reference here does not imply that complete compliance with that reference is a Windows Logo Program requirement.
A1.2.1 Advanced Configuration and Power Interface Specification, Revision 1.0b and 2.0
A1.2.2 Plug and Play specifications plus Legacy Plug and Play Guidelines
A1.2.3 Industry bus specifications

Links from; see also detailed requirements in Appendix B, "Device Requirements Checklist"
A1.2.4 Windows Hardware Instrumentation Implementation Guidelines (WHIIG)
A1.2.5 Compaq-Intel-Phoenix BIOS Boot Specification, v. 1.01 El Torito—Bootable CD-ROM Format Specification, v. 1.0
A1.2.6 Preboot Execution Environment (PXE) Specification, v. 2.1
A1.2.7 Debug Port Specification, V. 1.0
A1.2.9 System Management BIOS Reference Specification, Version 2.3
A1.2.10 Open Group Common Application Environment (CAE) Specification

A1.3 General System - Quality

WHQL Test Specification References:
Chapter 1: Introduction to HCT Test Specifications
Chapter 3: ACPI Test Specification
Chapter 22: Driver Quality Test Specification
Plus technology-specific test specifications
A1.3.1 Product passes related Windows Logo Program testing

Product is submitted to the appropriate WHQL test program and passes all testing for the Windows Logo Program for hardware:

  • Windows XP/Windows Server 2003 family: Pass tests in HCT 11.0 (or later), as described in detail in the WHQL Test Specification and the Microsoft Windows Hardware Compatibility Test Kit documentation.
A1.3.2 – DELETED
A1.3.3 - See A1.4.12
A1.3.4 DELETED - See A5.4.4.

A1.4 General System - Windows Experience

Design Guideline References:
OnNow and ACPI implementation notes -
A1.4.2 See A1.1.4; WL-6 x86-based client: System and all components correctly implement power management
A1.4.2.1 DELETED
A1.4.2.2 DELETED
A1.4.2.3 DELETED
A1.4.2.4 Uniprocessor desktop system must support S1, S3, S4, S5.

A system preinstalled with Windows XP must enable S3 by default in the BIOS. System test submissions for Windows Me and that also support Windows 2000, Windows XP, or both must use the same BIOS for all submissions. In this case, S3 may be disabled in the BIOS for the Windows Me test passes but S3 must remain enabled in the BIOS for Windows XP/Windows 2000 test passes.

  • Desktop systems must support wake from all supported sleep states, except S4 and S5.

  • System power supply must provide standby power for system wake-up events.

Note: For multiprocessor desktop sleep states and wake requirements, see A1.1.5.
A1.4.2.5 Devices must correctly implement D3 state such that the operating system can correctly hibernate and resume from all sleep states supported on the system.

A1. Devices must correctly implement the D3 state such that the operating system can enter into and resume from all sleep states supported on the system, including S3. Devices must be fully functional upon resume from the S3 state. Any PCI devices that support wakeup capabilities must correctly support wake from D3cold.

To ensure that a device meets these requirements, it must be tested in an S3-capable system. This is a requirement for the Windows Logo Program with the release of Windows XP.

The device categories affected by this requirement are: Audio, Modem, Network, Storage, USB/IEEE 1394, Video.

Driver requirements for power management are defined at B1.4.5. Individual device class and bus requirements for power management are defined in Appendix B.

A1. System power supply provides standby power for system wakeup events. At a minimum, the system must provide power for the core chipset, including memory and all integrated wake devices, for wakeup from the keyboard, a pointing device, and a single network device such as a LAN or wide area network (WAN) adapter connected via an external bus or open PCI slot when the system is in the ACPI S3 state. This requirement applies for S4 if the system supports wake from the ACPI S4 state.

IEEE 1394 host interface does not have to provide standby power for system wakeup events.

Mobile PC Note
This requirement for the system power supply does not apply to mobile PCs. See A1.4.2.4
A1.4.3 System contains required devices and buses
A1.4.3.3 DELETED
A1.4.3.4 DELETED
A1.4.3.5 One or more USB ports accessible by the user, with USB standard connector for all USB ports and devices

(see related requirements for each system type)
A1.4.3.6 DELETED
A1.4.3.7 No ISA slots or devices
A1.4.3.8 DELETED
A1.4.3.9 DELETED
A1.4.6 See B11.2
A1.4.7 DELETED See A1.4.3.7
A1.4.8 DELETED – See A4.4.11 (only applies to legacy-free systems)
A1.4.10 DELETED See B3.
A1.4.11 DELETED – See A4.4.12 (only applies to legacy-free systems)
A1.4.12 x86-based: Desktop or server system includes APIC support

Implemented per Multiple APIC Description Table (ACPI 1.0b, Section 5.2.8).

For background information about APIC, see Key Benefits of the I/O APIC at

For technical information about how to implement this requirement, see the related chipset guide from your chipset vendor.

A1.4.12.1 All hardware interrupts are connected to an IOAPIC.
A1.4.12.2 DELETED

Mobile PC Note: Requirement A1.4.12 does not apply for mobile systems.

Note: For SAPIC requirements for Itanium-based system, see A5.4.4.

A1.5 General System - FAQs

A1.5.1 Current general FAQs

A1.5.2 Updated at A1.4.12
A1.5.3 Updated at A1.1.4.16
A1.5.4 Updated at A1.1.4.1
A1.5.6 Refer to A1.1.5.4
A1.5.7 Updated at A1.1.4.4

Related requirement deleted

Related requirement deleted

Related requirement deleted
A1.5.12 See B10.1.4.8
A1.5.13 Updated at A1.1.3

Related requirement deleted.

Related requirement deleted.
A1.5.17 Updated at A1.4.2.4

Related requirement deleted.

Related requirement deleted.

Related requirement deleted.

Related requirement deleted.
A1.5.22 Updated at A1.1.2

A1.R General System - Future Requirements

A1.R.1 Announcement of additional future requirements will be published on the Windows Logo Program web site
A1.R.3 – See A1.4.3

Download 0.7 Mb.
1   2   3   4   5   6   7   8   9   ...   22

Download 0.7 Mb.

Bosh sahifa

    Bosh sahifa

Chapter 4 - Getting the Windows Logo for Hardware

Download 0.7 Mb.