Windows Logo Program
|
|  Yüklə 1.03 Mb.
|
Chapter 4 - Getting the Windows Logo for HardwareThe 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
To submit a device for Logo Program testing
When WHQL Receives a SubmissionWHQL 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 whqlinfo@microsoft.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.
Appendix A - System Requirements ChecklistThis 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)
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:
A1.0 General System RequirementsA1.1 General System - Windows CompatibilityA1.1.1 Devices meet all Windows compatibility requirementsAs defined in Appendix B, "Device Requirements Checklist.” A1.1.2 ACPI system board and ACPI BIOS[SYS-0002; SDG3:9; see FAQ A1.5.22] 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).
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.
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]
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.
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 B7.1.4.5 for network adapter requirements. See A5.0 for complete Itanium-based firmware requirements.
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.1.5 Multiprocessor system compatibility requirements[SYS-0002.1; SDG3:2]
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]
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[SDG3:30] 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. A1.1.7 DELETEDA1.2 General System - Industry StandardsA1.2.1 Advanced Configuration and Power Interface Specification, Revision 1.0b and 2.0[SYS-0002; SDG3:2] http://www.teleport.com/~acpi/tech.htm A1.2.2 Plug and Play specifications[SYS-0026; SDG3:16] http://www.microsoft.com/hwdev/respec/pnpspecs.htm, plus Legacy Plug and Play Guidelines A1.2.3 Industry bus specificationsLinks from http://www.microsoft.com/hwdev/specs/; see also detailed requirements in Appendix B, "Device Requirements Checklist.” A1.2.4 Windows Hardware Instrumentation Implementation Guidelines (WHIIG)[SYS-0048; SDG3:229] http://www.pcdesguide.org/whiig.htm A1.2.5 Compaq-Intel-Phoenix BIOS Boot Specification, v. 1.01 El Torito—Bootable CD-ROM Format Specification, v. 1.0[BIOS-0005; SDG3:12.4, 13.2] http://www.phoenix.com/techs/specs.html A1.2.6 Preboot Execution Environment (PXE) Specification, v. 2.1[BIOS-0014.1; SDG3:13.1] http://developer.intel.com/ial/wfm/wfmspecs.htm A1.2.7 Debug Port Specification, V. 1.0[BIOS-0010; SDG3:15] http://www.microsoft.com/hwdev/NewPC/debugspec.htm A1.2.8 Obsolete: MPS 1.4 specification[SDG3:2.2] Implementation of multiprocessor support must comply with ACPI under Windows 2000 and all later versions. A1.2.9 System Management BIOS Reference Specification, Version 2.3[BIOS-0006; SDG3:12.1] http://www.phoenix.com/techs/specs.html A1.2.10 Open Group Common Application Environment (CAE) Specification[BIOS-0014.3] http://www.opengroup.org/onlinepubs/9629399/toc.htm A1.3 General System - QualityWHQL 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 testingProduct is submitted to the appropriate WHQL test program and passes all testing for the Windows Logo Program for hardware:
A1.3.2 SEE A1.4.11A1.3.3 SEE A1.4.12A1.3.4 DELETESee A5.4.4. A1.4 General System - Windows ExperienceDesign 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[WL-8] 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]
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. [SYS-0003.3; SDG3:10.3]
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. x86-based desktop:
Mobile PC Note:
System Test Configuration Notes
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]
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[WL-3]
Server Note: If you implement headless support in one of the following ways, a USB controller and port in the server is not required:
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:
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.4 DELETEDA1.4.5 Windows XP clients: System and component design practices follow accessibility guidelines[WL-7; SYS-0020; see also FAQ A1.5.18]
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[WL-5; SYS-0042] 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[SYS-0067] A1.4.9 x86-based client: ROM BIOS interrupt handlers preserve values in all registers[BIOS-0012] A1.4.10 Windows XP Home Edition/Professional: Audio is "digital ready"[AUD-0323] 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. References:
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[BIOS-0005.5] 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).
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[AUD-0332] 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 B3.1.4.13. A1.4.14 Onboard graphics device can be used as a primary VGA boot deviceSee B4.1.1.8. A1.5 General System - FAQsA1.5.1 Current general FAQsSee http://www.microsoft.com/winlogo/hardware/. A1.5.2 APIC/SAPIC Requirement [Clarification][SYS-0001.3; SDG3.24, 25] Implementation and design guidelines are defined in PC 2001 System Design Guide and Hardware Design Guide 3.0. 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:
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:
If an OEM chooses a system board from a manufacturer that works with one or more codecs, the following applies:
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/.
A1.5.4 PCI-to-PCI bridges [Clarification][PCI-0123; SDG3:37] 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.
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:
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 ihv@microsoft.com 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.
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).
A1.5.7 BIOS support for preboot execution environment, with UUID provided in print [Clarification][BIOS-0014.1; SDG3:13.1] 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.
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.11 DELETEDA1.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][SYS-0002; SDG3:9] For Windows XP, the Windows Logo Program for hardware includes the following requirements:
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. References: S3 sleep state is defined in the ACPI specification: http://www.teleport.com/~acpi/ 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 http://www.microsoft.com/hwdev/onnow/ 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.
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:
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)[SYS-0020] 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 A1.5.19 Headset microphone requirement [Clarification]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 B3.1.4.13 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:
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 RequirementsA1.R.1 Announcement of additional future requirements will be published on the Windows Logo Program web sitehttp://www.microsoft.com/winlogo/hardware/ A1.R.2 For systems that include integrity or authentication services for downloaded remote boot images, support BIS[BIOS-0014.4; SDG3:12.3] Support Boot Integrity Services (BIS); comply with Boot Integrity Services, Version 1.0. A1.R.3 Consumer systems support IEEE 1394IEEE 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. | ||||||||