The guidelines for submitting systems for Windows Logo Program testing are defined on the web at http://www.microsoft.com/winlogo/submission/. This chapter provides a brief overview.
To submit a system for Logo Program testing
Follow the submission rules at http://www.microsoft.com/hwtest/systems/
To submit a device for Logo Program testing
Determine the Test Category and Logo Program for your device, based on the list at http://www.microsoft.com/hwtest/device/, 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 email@example.com 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 http://www.microsoft.com/hwtest/status/ 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.
Information Contacts for Windows Logo Testing:
The up-to-date list of contacts is provided at http://www.microsoft.com/hwtest/support/ (including additional contacts for server-related submissions).
Appendix A - System Requirements Checklist
This appendix presents the detailed checklist of requirements for systems. The current versions of these requirements are provided on http://www.microsoft.com/winlogo/hardware/system/.
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 Whistler Server (64-bit and 32-bit)
Windows 2000 Server and Professional (32-bit)
Windows Millennium Edition
Windows 98 Second Edition
Testing for all Windows versions must also include logs for Windows XP/Windows Whistler Server, even if the “Designed for Windows” Logo you are seeking does not specify Windows XP or Windows Whistler Server.
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.
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.”
ACPI BIOS must be Windows 2000-ready (for x86-based systems) or 64-bit Windows-ready (with additions for Itanium-based systems, see A5.4.1) as defined in ACPI Section 1.6 (x86-based: ACPI 1.0b; Itanium-based: ACPI 2.0).
ACPI BIOS cannot be disabled by end user.
Power management and Plug and Play capabilities are ACPI compliant.
Windows: “Power Management” in the Windows DDK.
Windows 98/Me: "OnNow Power Management for Display Device Class Drivers" and "Device Power Management for VxDs" in the Windows Me DDK.
A1.1.3 All components correctly implement Plug and Play
[SYS-0026; PCI-0126; SDG3.16]
Based on the related bus specifications; internal and legacy components meet requirements defined in Legacy Plug and Play Guidelines.
Note: PCI components implement System IDs (SIDs) and Subsystem Vendor IDs (SVIDs) as defined in PCI v.2.2. [PCI-0126; SDG3:45; see FAQ A1.5.13]
A1.1.4 System BIOS requirements
[BIOS-0005 ; SDG3:12 ]
For complete Itanium-based firmware requirements, see A5.0.
Correctly configure PCI-to-PCI bridges if the system has a VGA device behind a bridge.
[see FAQ A1.5.4]
Support calendar dates correctly; BIOS and CMOS firmware support calendar dates from January 1, 1999 through December 31, 2098. [BIOS-0007; SDG3:1]
Support booting from CD or DVD device per El Torito v. 1.0 No Emulation mode.
This applies to the primary optical storage provided and the primary bus to which the device is attached. [BIOS-0005.1; SDG3:12; SDG3:14 - Itanium-based]
Windows XP Professional/Windows Whistler Server: Support Preboot Execution Environment (PXE) based on PXE Specification, v. 2.1 as follows:
x86-based servers: Provide PXE-based support if a network adapter with remote boot capabilities is provided with the system. [SDG3:13.1]
x86-based clients, Itanium-based: Provide PXE-based support in all cases. [BIOS-0014.1 -x86-based clients; SDG3:14 - Itanium-based]
Note: This does not apply to systems preloaded with Windows XP Home Edition.
System UUID must be provided for all system types, in accordance with the Open Group Common Application Environment (CAE) Specification - http://www.opengroup.org/onlinepubs/9629399/toc.htm.
UUID is not required in print.
Windows XP Professional/Windows 2000: If PXE is enabled on a client system, provide remote lockout capability. [BIOS-0014.5]
Windows XP Professional/Windows Whistler Server: 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). Include support for F12 (or alternative) key to force a network-based system boot. [BIOS-0014.2; SDG3:13 - x86-based servers; SDG3:14 - Itanium-based]
For Windows XP Professional clients and x86-based servers, it is not required that the system include a network adapter that supports booting from the network, although such a network adapter must be available as an option at point of purchase; if the system does include such a network adapter, then it must meet the related requirements; see B184.108.40.206 for network adapter requirements.
See A5.0 for complete Itanium-based firmware requirements.
Support boot-drive determination in multiple-drive systems per Compaq-Intel-Phoenix BIOS Boot Specification, v. 1.01, Section 5 [BIOS-0005.4, SDG3:13, SDG3:150 - x86-based systems] or EFI boot manager capabilities [SDG3:14 - Itanium-based systems].
Windows XP/Windows Whistler Server/Windows 2000: Support BIOS update, security such as pre-boot password, and SMBIOS 2.3 static table data. [BIOS-0005,0006, 0008, 0009; SDG3:12]
Support console redirection of serial port or Debug Port Specification and FAQ A1.5.16. [BIOS–0010; SDG3:13.4, SDG3:15]
x86-based: Support Int13h Extensions on BIOS boot-based system for correct support of high-capacity hard drives. [BIOS-0011; SDG3:147]
x86-based client: Configure each PCI boot device IRQ to a PCI-based IRQ and write the IRQ into the interrupt line register 3Ch. [BIOS-0017]
Provide PCI interrupt routing information using 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. [PCI-0127; SDG3:46]
x86-based: Support logical block addressing (LBA) for ATA disks (if present in the system). [ATA-0117; SDG3:147]
Provide boot support for USB keyboards and hubs. [BIOS-0005.2; SDG3:13.3 - x86-based servers; SDG3:14.2 - Itanium-based]
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.
Support bootable ATA Packet Interface (ATAPI) devices (if implemented) in compliance with ATAPI Removable Media Device BIOS Specification, Version 1.0 and AT Attachment with Packet Interface – 5 (ATA/ATAPI-5). [BIOS-0018; 0019; SDG3-179]
x86-based client: For a system board that supports a riser card, provide a unique identifier for the riser so that the Windows bus enumerator can detect it, and locate and install appropriate drivers. [SYS-0034; see FAQ A1.5.3]
A1.1.5 Multiprocessor system compatibility requirements
x86-based: Comply with ACPI 1.0b.
Itanium-based: Comply with Multiple APIC Description Table (MADT) in ACPI 2.0, Section 220.127.116.11.
Use the lowest stepping processor as the bootstrap processor.
Do not include processors from different processor manufacturers; do not include mixed speeds or mixed cache sizes.
Systems designed to run the Windows 2000 Datacenter Server operating system must not contain mixed processor steppings. [see FAQ A1.5.5]
Implement PCI IRQ routing as described in PCI IRQ Routing on a Multiprocessor ACPI System at http://www.microsoft.com/hwdev/onnow/acpi-mp.htm.
Multiprocessor x86-based desktop systems support S1, S4, and S5. [SYS-0002.1]; wakeup solution implemented as described in FAQ A1.5.6.
Future wakeup requirements for Itanium-based systems are defined at A5.R.1.
A1.1.6 All PCI adapters function properly in any system with more than 4 GB of memory
This requirement applies to any 32-bit or 64-bit system (client or server) that has more than 4 GB of memory. For any system that supports more than 4 GB of system memory, all 32-bit PCI buses, host bridges, PCI-to-PCI bridges, and any 32-bit PCI adapters used on the primary data path must support the PCI Dual Address Cycle (DAC) command, with the exception of 10/100 Ethernet devices.
Mobile PC Note: PCI adapters for mobile PCs are excluded from this requirement.
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 Whistler Server: Pass tests in HCT 10.0 (or later), as described in detail in the WHQL Test Specification and the Microsoft Windows XP Hardware Compatibility Test Kit documentation.
Windows Me: Pass tests in HCT 9.6, as described in the HCT documentation.
Windows 2000, Windows 98, Windows NT 4.0: Pass tests in HCT 9.502, as described in the HCT documentation.
A1.3.2 SEE A1.4.11
A1.3.3 SEE A1.4.12
A1.4 General System - Windows Experience
Design Guideline References:
OnNow and ACPI implementation notes - http://www.microsoft.com/hwdev/onnow/PC 2001 System Design Guide, Chapter 3, "PC System" -
Hardware Design Guide 3.0 for Windows 2000 Server, Chapter 2 -
A1.4.1 Upgrade scenarios with minimal user interference
Windows 98 > Windows XP/Windows 2000; Windows NT 4.0 > Windows XP/Windows 2000.
A1.4.2 x86-based client: System and all components correctly implement power management
[SYS-0003, 0004; SDG3-if implemented]
ACPI firmware and hardware; ACPI-based power switch; USB controller that can wake the system; Fast POST; minimal start-up display; system appears "off" in any sleep state. [SYS-0003, 0004; SDG3:9, SDG3:10; SDG3:11; see FAQs A1.5.14 and A1.5.21]
If a single-button design is used, it must be the user’s primary switch interface and must be a power button as defined in ACPI 1.0b.
If a two-button design is used, the sleep button must be the user’s primary switch interface and be easily distinguishable from the power button.
System ensures optimal user experience for suspend and hibernate, including correct BIOS support for the supported sleep states plus a Fast POST implementation. [WL-6; SYS-0003, 0004]
Windows XP x86-based client: Fast system startup and fast resume, as documented at http://www.microsoft.com/hwdev/fastboot/:
Important: After January 1, 2003, x86-based client systems must meet the fast system startup and resume times. Times are measured from the time the power switch is depressed until it is possible to start a program using a Windows Desktop shortcut.
Boot to a usable state in target time:
English-language desktop systems: in 35 seconds or less
Double-byte character-set desktop systems: in 40 seconds or less
Resume from Hibernate (S4) in 25 seconds or less
Resume from Standby (S3) in 5 seconds or less
Mobile PC Note:
Boot to a usable state in target time:
English-language mobile PCs: in 40 seconds or less
Double-byte character-set mobile PCs: in 45 seconds or less
Boot options in default shipping configuration (unless excluded in this list).
System integrity and security services, such as BIOS passwords requiring user input.
PXE boot options.
Systems with multiple processors.
Systems using SCSI hard disk drives as primary hard disk.
Systems with processors loading CPU firmware in excess of 1MB.
Systems populated with ECC memory configurations.
Windows XP/Windows 2000 clients: Uniprocessor desktop system must support S1, S3, S4, S5. [see FAQs A1.5.15, A1.5.17]
Windows XP Home Edition: Uniprocessor desktop systems must support S3 after April 1, 2002; until that date, support for S1 is sufficient.
Windows XP Professional/2000: Uniprocessor desktop systems must support S3 after July 1, 2001; until that date, support for S1 is sufficient. [see FAQ A1.5.17]
Windows 98/Me: Uniprocessor desktop systems must support S1, S4, S5. [see FAQ A1.5.17]
Desktop systems must support wake from all supported sleep states, except S4 and S5. [SYS-0002]
If S3 is implemented, system power supply must provide standby power for system wake-up events. [SYS-0003.5; SDG3:10.5]
Note: For multiprocessor desktop sleep states and wake requirements, see A1.1.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. [SYS-0003; SDG3:10.2]
For PC desktop and mobile systems only, any PCI devices that support wakeup capabilities must correctly support wake from D3cold. [SYS-0003; SDG3:10.2]
Future wakeup requirements for Itanium-based systems are defined at A5.R.1.
A1.4.3 System contains required devices and buses
Keyboard and pointing device.
Support for installing the operating system.
[see FAQ A1.5.10]
One or more USB ports accessible by the user (see related requirements for each system type), with USB standard connector and icons for all USB ports and devices.
Server Note: If you implement headless support in one of the following ways, a USB controller and port in the server is not required:
System that implements headless capabilities without management service processor provides serial headless support. [SDG3.20]
System that implements management service processor and external serial headless capability supports required external serial port and remote system reset. [SDG3.21]
System that implements a management service processor but no external serial connection meets reset and display redirection requirements. [SDG3.22]
All expansion slots in the system are accessible for users to insert cards. [SDG3:203; see FAQ A1.5.8]
No ISA slots or devices. [SYS-0041; SDG3:64-66]
Industry-standard connections and icons for external keyboard, mouse, parallel and serial devices (legacy systems only). [SDG3:202]
Device and bus requirements are defined in Appendix B.
Note for Configure to order / Build to order requirements: PC clients shipped into retail markets must have at least the minimum hardware support listed in these requirements. Retail markets include:
Retail “on-shelf” configurations.
A default configure-to-order or build-to-order system configuration.
It is recognized that OEMs may configure PC systems to meet the requirements of a specific end-user or corporate customer. For systems built based on specific customer requests, where customers request systems without either a CD or DVD optical drive, the system may be configured without an optical storage drive. However, the system must support the addition of a CD or DVD optical drive, and the system firmware must support booting from a CD or DVD device using El Torito Version 1.0 No Emulation Mode if a supporting optical drive is added.
Furthermore, systems may be configured on request without a graphics adapter or network adapter. All retail market desktop systems must include a graphics adapter and support installation of an operating system by including either a CD/DVD drive or network adapter. [see A1.4.3, A1.1.4]
A1.4.5 Windows XP clients: System and component design practices follow accessibility guidelines
[WL-7; SYS-0020; see also FAQ A1.5.18]
Ensure that the keyboard and other input devices work correctly with the Microsoft Accessibility features in Windows. For example, StickyKeys should work with all keys in any keyboard design.
Make all modifier keys capable of being read and operated by software. This capability allows users to access these keys and the functions that rely on them through operating system features, such as StickyKeys and SerialKeys, and through third-party software, such as voice recognition.
A1.4.6 System with DVD-Video correctly implements playback capabilities
[WL-3; SYS-0035; SDG3:194]
Related requirements are defined in Appendix B, "Device Requirements Checklist"
Note: If a system advertises DVD-Video playback capability or compatibility, then an MPEG decoder is required that meets all DVD requirements. However, if a system includes a DVD-ROM drive and is not capable of DVD-Video playback, then an MPEG-2 decoder is not required.
A1.4.7 Peripherals included with client system offer a non-legacy interface such as PCI, USB, IEEE 1394, or CardBus
Keyboards and mice are excluded.
Accessibility peripherals included with a system are excluded, provided that a non-legacy interface peripheral is not available to fulfill the same function.
A1.4.8 x86-based client: System is capable of recovery and upgrade of the hard drive image and upgrade of the BIOS, independent of an FDC-based floppy disk drive
A1.4.9 x86-based client: ROM BIOS interrupt handlers preserve values in all registers
A1.4.10 Windows XP Home Edition/Professional: Audio is "digital ready"
To be digital ready, the audio subsystem must not utilize analog mixing of audio sources for output. All audio sources should be available as digital audio streams accessible to the system-wide kernel mixer. This includes the CD/DVD drive, TV tuner, hardware synthesizer, and so on. All audio content should be available at both the analog jack and USB port.
Eliminating analog mixing is key to making PC audio easier to configure and easier to use, removing a major obstacle for USB audio rendering devices.
Digital Audio White Papers and "Windows Support for HID-based Audio Controls" at http://www.microsoft.com/hwdev/audio/
A1.4.11 x86-based client: ROM BIOS ensures that the timer is on at system boot and timer interrupts are occurring as part of POST or RESET
A1.4.12 x86-based: Desktop or server system includes APIC support
[SYS-001.3; SDG3:24; see FAQ A1.5.2]
Implemented per Multiple APIC Description Table (ACPI 1.0b, Section 5.2.8).
All hardware interrupts are connected to an IOAPIC.
The IOAPIC is connected to the local APIC in the processor.
Mobile PC Note: This requirement does not apply for mobile systems.
Note: For SAPIC requirements for Itanium-based system, see A5.4.4.
A1.4.13 System includes headset microphone if system is speech capable
If a system is represented as speech capable or includes speech-recognition software (not including Microsoft Office XP), the system must include a headset microphone that meets the requirements defined in B18.104.22.168.
A1.4.14 Onboard graphics device can be used as a primary VGA boot device
For background information about APIC, see Key Benefits of the I/O APIC at http://www.microsoft.com/hwdev/newpc/io-apic.htm.
For technical information about how to implement this requirement, see the related chip-set guide from your chip-set vendor.
FAQ date: new revision June 20, 2000
A1.5.3 Riser Cards [Logo Program Clarification]
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.
This is a Windows Logo Program compliance testing requirement as of July 1, 2000.
FAQ date: December 22, 1999; revised May 9, 2000
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 ftp://download.intel.com/ial/scalableplatforms/audio/ac97bios.pdf.
Similar provisions exist in the CNR and ACR specifications.
For information about WHQL testing for riser cards, see http://www.microsoft.com/hwtest/.
See also AC ‘97 and AMR Plug and Play Design (http://www.microsoft.com/hwdev/audio/AMR.htm).
FAQ date: June 2, 1999; revised May 9, 2000
A1.5.4 PCI-to-PCI bridges [Clarification]
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 http://www.microsoft.com/hwdev/pci/pcibridge-cardbus.htm.
FAQ date: March 12, 1999
A1.5.5 Multiprocessor Systems Compatibility Testing [Clarification]
As of mid-1999, WHQL accepts multiprocessor submissions for Windows Logo Program and Windows XP/Windows 2000/Windows Whistler Server compatibility testing that contain mixed processor steppings. However, the following requirements for multiprocessor systems must be met:
Systems must use the lowest stepping processor as the bootstrap processor.
Systems must not contain processors from different processor manufacturers or with mixed speeds or mixed cache sizes.
Systems designed to run the Windows 2000/Windows Whistler Datacenter Server operating system must not contain mixed processor steppings.
Note, however, that inherent support for mixed steppings is not currently a design feature supported by Microsoft on either Windows NT-based or Windows 2000-based systems. See http://www.microsoft.com/hwdev/desguid/smp.htm.
FAQ date: August 26, 1999
A1.5.6 Multiprocessor Wakeup [Clarification]
A problem has been uncovered with certain multiprocessor systems that will prevent them from properly waking up from a Sleep state under Windows 2000. This pertains to dual-processor or multiprocessor systems that transition all processors from an active state to a STPCLK state, and more specifically to systems where all processors receive their STPCLK# request from one source. For multiprocessor systems submitted for Windows Logo Program testing for 1999-2000, the vendor must implement a solution for this problem as described in this notice.
The following information has been provided by Intel to help manufacturers correct the problem. For technical questions regarding this issue, please contact Intel. For questions related to support under Microsoft Windows operating systems, please send e-mail to firstname.lastname@example.org with Multiprocessor Wakeup in the Subject line.
Prior to transitioning from a STPCLK state to a Sleep state or lower power state, all processors must generate a Stop Grant bus cycle. It is essential that all processors have transitioned to the STPGNT state before it is safe to: 1) transition to a lower power state such as Sleep, or 2) externally shut off the processor clocks to allow for flushing buffers, cache maintenance, and other internal activities.
For dual-processor and multiprocessor systems using a single STPCLK to all processors and a single SLP pin to all processors, the transition to the Sleep state should not be used. Behavior of the system during removal of the processor clock—such as transitions from STPCLK to Sleep state—cannot be guaranteed unless all STPGNT bus cycles are received.
For example, Intel Xeon II Specification, "Section 4.2.5 Sleep State-State 5," specifies that for a multiprocessor system, all processors are required to complete the Stop Grant bus cycle before the subsequent 100 BCLK waiting period and before the assertion of SLP# can occur. When multiple processors are serviced by a single STPCLK# request to all processors and a single SLP#, there is no provision to guarantee that all Stop Grant bus cycles are received before the assertion of SLP#.
As another example, in 450NX-based platforms from Intel, the STPCLK# from PIIX4E is connected to all processors, and SLP# from PIIX4E is connected to all processors. The following sequence occurs:
t0. Operating system writes PMCNTRL register.
t1. PIIX4E asserts STPCLK#, then waits for Stop Grant acknowledgment.
t3. The processor acknowledges with Stop Grant ACK cycle.
t4. PIIX4E asserts SLP# after receiving this.
This sequence works for uniprocessor systems (which is what the PIIX4E was originally designed for). However, in multiprocessor systems, SLP# might be asserted to a processor that is not in Processor Sleep State 3 (that is, not yet acknowledged). This premature SLP# assertion might result in a wakeup problem.
To work around this problem, processors are put to Processor Sleep State 3 (not State 5) during ACPI S1 state. That is, the OEM must remove SLP# assertion to all the processors in 450NX-based platforms.
Intel provides additional information about this issue through the Intel Technical Support Hotline at 1-800-628-8686 (outside North America at 916-377-7000).
Note: Please remove SLP# assertion to all the processors on multiprocessor PIIX4-based platforms. Disabling the Sleep Enable bit in the PIIX4 Processor Control Register does not actually disable the assertion of SLP# as documented in the PIIX4 specification.
FAQ date: March 19, 1999; revisions May 28, 1999
A1.5.7 BIOS support for preboot execution environment, with UUID provided in print [Clarification]
References to PXENV system identifier in Network PC System Design Guidelines, Version 1.0b, are superseded by PXE. [see A1.1.4]
UUID is not required in print.
Mobile PC Note: See A3.4.2 for mobile BIOS PXE requirement.
FAQ date: March 19, 1999, revised January 15, 2001
A1.5.8 AGP and requirement for expansion slots to be accessible to end users [Clarification]
For designs implementing the Accelerated Graphics Port (AGP) Pro specification, the two PCI slots adjacent to the component side of the AGP Pro slot may be blocked and used by an AGP Pro Adapter. When the AGP Pro connector is used by a "standard" AGP board, the PCI connectors must be accessible and available for use with PCI cards.
FAQ date: December 7, 1998
A1.5.9 Color coding [Clarification]
Color-coding is only recommended, not required, for both systems and retail peripherals. Recommended color codes are listed at http://www.pcdesguide.org/documents/pc99icons.htm.
A1.5.10 Floppy disk support [Clarification]
The use of a legacy floppy drive is discouraged, but not disallowed; system designers are encouraged to seek other alternatives for both the installation boot drive and casual storage.
FAQ date: March 19, 1999
A1.5.12 USB mass storage [Logo program clarification]
USB-based mass storage devices cannot be the primary method of normal system booting. They are expected to be a replacement for booting to load an operating system on the primary boot drive, or as a replacement for legacy floppy drives.
FAQ date: August 26, 1999
A1.5.13 PCI SVID/SID for PCI functions on system boards [Clarification]
See "Specification for Use of PCI IDs with Windows Operating Systems" at http://www.microsoft.com/hwdev/pci/pciidspec.htm.
Note: 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.5.14 Resume from Sleep State Requirements [Logo Program Change]
Resume from sleep state (S1-S3) to operating system handoff occurs within 1 second (PC99a:3.4.2 previously stated S1-S4).
This requirement does not apply to servers.
For sleep states S1, S2, and S3, the time to operating system handoff is measured from when the processor starts running (first instruction) to the time that the BIOS jumps to the Waking Vector in the Firmware ACPI Control Structure table, as described in Section 5.2.6 in the ACPI 1.0b specification.
A1.5.15 Windows logo testing for S3 system state under Windows XP [Clarification]
For Windows XP, the Windows Logo Program for hardware includes the following requirements:
System ensures optimal user experience for suspend and hibernate, including correct BIOS support for the supported sleep states.
A uniprocessor desktop must support S1, S3, S4, and S5, and support wake from all supported sleep states, except from S4 and S5. [see A1.4.2]
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. Note that this is not a new requirement; earlier versions of HCTs didn't enforce this area of testing.
The device categories that will be affected by this requirement are: Audio, Modem, Network, Storage, USB/IEEE 1394, Video.
S3 sleep state is defined in the ACPI specification:
Related design guidelines are defined in PC 2001 System Design Guide.
Device Class Power Management Reference Specifications
Windows implementation guidelines, specifications, and white papers for power management
Driver support for power management: see A1.1.2.
See also "Display Adapter Drivers and Windows Millennium Hibernation" at http://www.microsoft.com/hwdev/video/Mill_D3display.htm.
FAQ date: June 30, 2000
A1.5.16 Debug Solutions for Legacy-Free PCs [Clarification]
Microsoft has defined possible debug solutions for Windows-based PCs in the Debug Port Specification at http://www.microsoft.com/hwdev/NewPC/debugspec.htm.
Windows Me and Windows XP support IEEE 1394-based debug solutions, as described at http://www.microsoft.com/hwdev/1394/.
Important: For any system design that does not include a built-in serial port, the debug solution must be shipped with the system. This is a requirement for the "Designed for Windows" logo for legacy-free and legacy-reduced systems. The solution must consist of one of the following:
For serial ports with non-legacy addresses, the internal header must be exposed in such a way as to be available, but not obvious.
For LPC solutions, the header for the dongle connection must be exposed.
IEEE 1394 debug.
Systems equipped with one or more standard OHCI-compliant, Windows Logo'd IEEE 1394 controllers can utilize a standard IEEE 1394 port for connecting a host machine with one or more targets (up to 62 on a single bus). The host controller can be on the motherboard or attached via PCI, Mini-PCI, or CardBus.
If the IEEE 1394 controller is not on the motherboard, the system does not have to ship with the IEEE 1394 solution included. Rather, it must contain at least two slots for the addition of an IEEE 1394 card by the debug technician, which can be any combination of PCI, Mini-PCI and CardBus slots. This allows debugging of systems configured with another PCI-connected peripheral. Standard IEEE 1394 cables can be used for this purpose.
Note: For legacy-free or legacy-reduced sub-notebooks that are designed to implement IEEE 1394 as the debug solution, a combination of a Mini-PCI slot and CardBus slot is one possible solution. However, debugging over a mobile docking station with a PCI bridge is not a viable solution.
FAQ date: August 28, 2000; revised September 1; October 25, 2000
A1.5.17 S3 support and system test submissions (Revision)
A system preinstalled with either Windows 98 or Windows Me can provide a BIOS switch that disables S3. A system preinstalled with Windows XP/Windows 2000 must enable S3 by default in the BIOS. System test submissions for Windows 98, Windows Me, or both 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 98 and Windows Me test passes but S3 must remain enabled in the BIOS for Windows XP/Windows 2000 test passes.
For information about the effective dates for the S3 requirement, see A1.4.2.
FAQ date: January 31, 2001
A1.5.18 Accessibility requirements and regulations (Clarification)
PC 2001 System Design Guide specified keyboard keys F1-F12 as having to be capable of being read and operated by software. This is incorrect; the guideline should have referred to the Fn key, an OEM-specific key often used on mobile PCs to control mobile-specific functions such as backlight brightness, CRT/LCD display switching, and so on.
Windows does not provide a keyboard scan code for the Fn key. StickyKeys cannot provide support for OEM-specific keys. System designers should provide access to all system functionality, including those functions only available through keyboard sequences involving the Fn key. The system BIOS can provide this StickyKey-like functionality.
Note: On December 21, 2000, the U.S. Access Board issued final standards for electronic and information technology under Section 508 of the Rehabilitation Act. OEM and IHVs are encouraged to review these standards as they pertain to their hardware designs. See http://www.access-board.gov/.
FAQ date: February 28, 2001
A system is considered "speech capable" when the offering to customers indicates that speech is a viable input method for that system, which would therefore require a microphone to make that capability available. For example, if the platform includes an application that has the sole purpose of adding speech functionality to the system, then the system will be considered "speech capable.” However, if the system includes an application that merely supports speech input as an alternate input method, then that system is not considered "speech capable."
Note also that the inclusion of an array microphone that meets the microphone performance requirements in B22.214.171.124 also meets the requirement defined in A1.4.13.
FAQ date: April 30, 2001
A1.5.20 Number of USB ports required by system type [Clarification]
To facilitate migration away from legacy connections for keyboards, pointing devices, serial devices, and parallel devices, the logo program requirements identify how many USB ports are required for each system type. These requirements are defined in the various system type sections of Appendix A. This FAQ provides a summary:
General system requirement: One or more USB ports accessible by the user (A1.4.3)
Desktops: Two USB ports, with at least one accessible USB port supporting end-user expansion when keyboard and pointing device are attached (A2.4.1)
Mobiles: One USB port (A3.4.4)
Legacy-Free: Two USB ports, with at least one accessible USB port supporting end-user expansion when keyboard and pointing device are attached (A4.4.2)
Servers: One USB port (A6.4.2)
FAQ date: May 08, 2001
A1.5.21 System fans allowed to run in ACPI S1 state [Logo requirements change]
System fans may be run in the S1 state to cool the system. It is recommended that systems support advanced features like stopping the PCI clock when in S1 to allow the fans to be turned off.
FAQ date: May 08, 2001
A1.5.22 System board devices meet ACPI 1.0b [Clarification]
System board devices not power managed or configured via standard bus specifications must comply with ACPI 1.0b.
FAQ date: May 08, 2001
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.2 For systems that include integrity or authentication services for downloaded remote boot images, support BIS
Support Boot Integrity Services (BIS); comply with Boot Integrity Services, Version 1.0.
A1.R.3 Consumer systems support IEEE 1394
IEEE 1394 has been supported in Microsoft operating systems since the release of Windows 98. This future requirement will add IEEE 1394 connectivity to the Windows experience on all consumer platforms.