Guidelines for products that work well with the Microsoft® Windows® xp and Windows Server 2003 operating systems


Appendix B - Device Requirements Checklist



Download 0.7 Mb.
Page11/22
Date29.07.2017
Size0.7 Mb.
#24771
1   ...   7   8   9   10   11   12   13   14   ...   22

Appendix B - Device Requirements Checklist


This appendix presents the detailed checklist of requirements in support of the Windows Logo Program requirement WL-4: "All components and devices meet Windows compatibility and quality design guidelines."

The current versions of these requirements are provided on http://www.microsoft.com/winlogo/hardware/

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, Standard and Enterprise Editions (64-bit and 32-bit)
See also:

  • Conventions Used in This Document

  • How to Use the Appendixes

B1.0 General Device and Driver Quality


All devices must comply with these general requirements for device and driver compatibility and quality.

Each device, device driver, and installation of either device or driver must comply with all requirements defined in this guide for the related device class, whether the device is provided in the PC system as an expansion card or as an external device.


B1.1 General Device/Driver - Windows Compatibility

B1.1.1 DELETED
B1.1.2 OnNow and ACPI compatibility and implementation notes

http://www.microsoft.com/hwdev/tech/onnow/

Note: This is a general reference, not a requirement.
B1.1.3 WDM driver implementation notes (for device classes supported under WDM)

http://www.microsoft.com/hwdev/driver/wdm/

Note: This is a general reference, not a requirement.

B1.2 General Device/Driver - 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.
B1.2.1 Advanced Configuration and Power Interface Specification (ACPI)

http://www.acpi.info/index.html
B1.2.2 Device Class Power Management Reference Specifications

http://www.microsoft.com/hwdev/resources/specs/pmref/
B1.2.3 Plug and Play specifications

http://www.microsoft.com/hwdev/tech/pnp
B1.2.4 Each device or connection meets requirements for its bus class

See B2.0.

B1.3 General Device/Driver - 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
B1.3.1 Hardware and its drivers pass Windows Logo Program testing

All hardware and associated drivers must be submitted to the appropriate WHQL test program and passes all testing for the Windows Logo Program for hardware:

Pass tests in Windows HCT, as described in detail in the WHQL Test Specification and the related Microsoft Windows Hardware Compatibility Test Kit documentation.

If a system with the in the box drivers loaded is capable of passing the HCT system-level tests, then OEMs can use the in the box driver and not re-submit the driver for digital signature.

B1.3.2 Vendor-supplied drivers pass Driver Verifier tests

As provided in the in Windows HCT
B1.3.3 Device driver has properly formatted INF

Tested via INFCatReady.exe

See "Creating an INF File" in the Windows DDK.

INFCatready (InfCatR.exe) is included in the Windows HCT.

B1.3.4 Vendor-supplied drivers have digital signatures

Requirements for digital signatures are defined at http://www.microsoft.com/hwdev/driver/digitsign.asp

WHQL guidelines and processes for digital signatures are defined at http://www.microsoft.com/hwdq/hwtest/userguide/default.asp?chapter=4


B1.4 General Device/Driver - Windows Experience

B1.4.1 Device can be enumerated and automatically disabled

Each device connected to an expansion bus must be able to supply its own unique ID. The following are the specific requirements for Plug and Play device IDs:

  • Each separate function or device on the system board must be separately enumerated; therefore, each must provide a device ID in the manner required in the current Plug and Play specification for the bus it uses.

  • If a device on an expansion card is enumerated, it must have a unique ID and its own resources according to the current device ID requirements for the bus to which the card is connected. This includes devices that are separately enumerated on multifunction cards or multifunction chips.

  • Requirements and clarifications for automatic device configuration, resource allocation, and dynamic disable capabilities for legacy components such as serial and parallel ports, as defined in Legacy Plug and Play Guidelines at http://www.microsoft.com/hwdev/tech/pnp.

Dynamic disable capabilities must be supported for all devices. All devices must be capable of being automatically disabled by the system. Also, disabling the device must result in the freeing of all its resources for use by other devices.

The following are exceptions to the requirements for a unique Plug and Play ID:



  • Legacy devices attached to the Industry Standard Architecture (ISA) bus on the system board set do not have unique Plug and Play IDs—for example, serial ports, parallel ports, or PS/2-compatible port devices. The method for device identification is defined in Plug and Play ISA Specification, Version 1.0a, and the ACPI specification. Itanium-based systems must comply with ACPI 2.0; x86-based systems must comply with ACPI 1.0b.

  • Standard system devices. The system can reserve static resources for devices such as programmable interrupt controllers (PICs) 1 and 2, timer (8254-2), keyboard controller (8042), real-time clock, DMA page registers, and DMA controllers 1 and 2. For IA-32 systems, these fixed resources are located at I/O addresses under 100h and can also include a NMI.

  • Devices that are completely invisible to the operating system, such as out-of-band systems management devices or I2O hidden devices; however, these devices still must properly reserve resources using ACPI methods to avoid potential conflicts.

  • Some multifunction devices (such as Super I/O) might include devices that do not have unique Plug and Play IDs or unique PCI Subsystem IDs, but that are supported by drivers provided with Windows.

  • A device such as a multifunction PCI device that supports a number of functions but uses only a single set of relocatable resources does not have to provide separate identifiers for each function included on the device.

  • Some devices are completely invisible to or are not managed by the operating system, such as out-of-band systems management devices or I2O system and I2O hidden devices. Such devices are exempt from this requirement, but these devices still must properly reserve resources using ACPI methods to avoid potential conflicts.

If an OEM uses a proprietary mechanism to assign asset or serial numbers to hardware, this information must be available to the operating system using Windows hardware instrumentation technology, as defined in the Windows Hardware Instrumentation Implementation Guidelines, Version 1.0 (WHIIG).

See additional notes in specific device-class requirements.


B1.4.2 Software does not replace system components

See A5.1.1

Driver or software installation must not replace any Microsoft-authored operating system components.

Notice that each Windows product has a unique set of files protected under system file protection.

For information about protected operating system files, see SfcGetNextProtectedFile and SfcIsFileProtected APIs in the Microsoft Platform SDK.

If the manufacturer’s INF copies any files supplied by the operating system, those files must be copied from the Windows product disk (or preinstalled source files), unless the component is a licensed, redistributable component.

Driver must not use initialization files (INI) for configuration settings.


B1.4.3 Loading the driver does not reduce or eliminate functionality of other devices installed on the system
B1.4.4 Device is functional without restarting the system

Device installation does not cause the system to stop running or reboot (unless reboot is required by the operating system) without user interaction.

It is acceptable to require rebooting for the primary hard disk controller. ATA drives need not implement Cable Select (CS) settings. In all cases, however, changing configuration settings must not require the end user to make jumper changes.


B1.4.5 Device and driver comply with ACPI and power management specifications

See A1.1.2

Device and driver comply with ACPI specification, Default Device Class Power Management Reference Specification, and other relevant device class power management specification.


(See additional notes in specific device-class requirements)
B1.4.5.1 Graphics adapter and all other devices correctly implement D3 state

Implement D3 state such that the operating system can correctly hibernate and resume from all sleep states supported by the system.
B1.4.5.2 – See B7.1.4.4
B1.4.5.3 The device must be fully functional upon resume from S3.

Every device must be tested on an S3-compliant system to verify that the device allows the system to successfully enter and resume from the S3 sleep state.
B1.4.6 DELETED
B1.4.7 DELETED
B1.4.8 DELETED
B1.4.9 DELETED
B1.4.10 DELETED
B1.4.11 DELETED
B1.4.12 Hot-plugging does not damage system or device

To provide reliable support for hot-plugging capabilities, the following requirements must be met.
B1.4.12.1 USB, IEEE 1394, and PC Card devices and buses support hot-plugging.

USB, IEEE 1394, and PC Card specifications all support hot-plugging. A device designed to use any of these connections must support being added or removed while the system is fully powered on.
B1.4.12.2 Windows Server 2003, Standard Edition: System supports hot-plugging for any PCI devices that use ACPI-based methods.

Hot-plugging is not required for PCI devices. Windows supports dynamic enumeration, installation, and removal of PCI devices only if there is a supported hardware insert/remove notification mechanism. An example of an appropriate notification mechanism such as a bus standard is that provided by CardBus bus controllers. Other implementations, such as those for docking stations and hot-plugging of PCI devices, must comply with the hardware insert/remove notification mechanism as defined in Section 5.6.3 of the ACPI 1.0b specification. It should be noted that systems implementing hot-pluggable PCI capabilities compliant with the PCI Hot-Plug Specification, Revision 1.0, must still provide the hardware insert/remove notification mechanism as defined in Section 5.6.3 of ACPI 1.0b.
B1.4.12.3 All removable media support media status notification.

See B10.1.4.3.

B1.5 General Device/Driver - FAQs

B1.5.1 Current general FAQ

See http://www.microsoft.com/winlogo/hardware/.
B1.5.2 DELETED

B1.R General Device/Driver Quality - Future Requirements


Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/hardware/.


Download 0.7 Mb.

Share with your friends:
1   ...   7   8   9   10   11   12   13   14   ...   22



The database is protected by copyright ©ininet.org 2024
send message
    Main page
express written permission
entire risk
windows family