Microsoft Windows Logo Program System and Device Requirements

Version 2.0
Microsoft Corporation
Design and testing requirements for server, desktop, and mobile systems and devices that run the Microsoft® Windows® family of operating system

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


Copyright and Disclaimer

This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. Unless otherwise noted, the example companies, organizations, products, people and events depicted herein are fictitious and no association with any real company, organization, product, person, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 1999-2001 Microsoft Corporation. All rights reserved.

Direct3D, DirectDraw, DirectInput, DirectShow, DirectSound, DirectX, Encarta, Hotmail, Microsoft, MS-DOS, Outlook, NetMeeting, PowerPoint, Windows, the Windows logo, Win32, Win64, Windows Media, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Other product and company names mentioned herein may be the trademarks of their respective owners.

This document contains quotations from the following documents, which are co-authored by Microsoft Corporation and Intel Corporation:

  • PC 2001 System Design Guide, © 2000, Intel Corporation and Microsoft Corporation. Available at http://www.pcdesguide.org/pc2001/
  • Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server, © 2000, Intel Corporation and Microsoft Corporation. Available at http://www.microsoft.com/hwdev/serverdg.htm

Microsoft Windows Logo Program System and Device Requirements is not for sale. To obtain additional copies of this document, please download the files from the web site at http://www.microsoft.com/winlogo/hardware/ .


Chapter 1 - Introduction to Windows Logo Program for Hardware

Welcome to the Microsoft Windows Logo Program System and Device Requirements, Version 2.0.

This document provides the authoritative source for information about requirements for the Windows Logo Program for hardware that must be met by hardware vendors and system manufacturers who want to license the Windows Logo. Note, however, that these Logo Program requirements do not represent the minimum system requirements for running any version of the Windows family of operating systems.

This document describes the scope and purpose of the Microsoft Windows Logo Program, and it tells how to obtain the Windows Logo for server, desktop, and mobile systems and components that run the Microsoft® Windows® XP, Windows "Whistler" Server (codename), Windows 2000, and Windows Millennium Edition (Windows Me) operating systems.

This document is revised for each new version of the Windows operating systems. To receive update information about the Windows Logo Program for hardware by e-mail, subscribe to the mail list as described at http://www.microsoft.com/winlogo/hardware/.

In This Document …

Chapter | Description
Chapter 1, Introduction to Windows Logo Program for Hardware | Presents a summary of the Windows Logo Program and resources.
Chapter 2, Hardware Requirements for Windows Logo | Describes requirements for consistent, stable functionality under Windows operating systems.
Chapter 3, Recommendations and Future Requirements | Presents specific design practices that Microsoft encourages, and highlights important design practices that will become Windows Logo Program requirements in the future.
Chapter 4, Getting the Windows Logo for Hardware | Describes the process of preparing for and submitting hardware for Windows Logo Program compliance testing.
Appendix A, System Requirements Checklist | Provides a checklist of requirements for desktop, mobile, and server systems, and for legacy-free and 64-bit systems.
Appendix B, Device Requirements Checklist | Provides a checklist of requirements per device class.
Appendix C, Designing for Success | Lists steps to help ensure that new designs are compatible with Microsoft operating systems and meet Windows Logo Program requirements.
References | Provides a comprehensive list with Internet resources for all specifications cited in the Windows Logo Program requirements.

Next


About the Microsoft Windows Logo

Microsoft offers the Windows Logo Program to help customers identify systems and peripherals that meet a baseline definition of platform features and quality goals that ensure a good Windows experience for the end user. The Windows Logo is not intended to communicate the specific technical capabilities of any particular system.

Products that earn the Windows Logo have been tested to ensure that they meet Microsoft standards for compatibility on the Windows operating systems designated on the logo. System and peripheral manufacturers can license the Windows Logo for use on product packaging, advertising, collateral, and other marketing materials for all systems and components that pass compliance testing.

Manufacturer Benefits

Products that carry the Windows Logo for hardware include these characteristics:

  • All components install and uninstall properly and do not interfere with other system components.
  • Each component interoperates well with other system components.
  • All components function normally after the operating system is upgraded to Windows XP/Windows 2000 or any later version of the operating systems for which the system or component carries the logo.

These characteristics yield these benefits for manufacturers:

  • Increased customer satisfaction
  • Lower support costs
  • Fewer product returns

Customer Benefits

Windows Logo Program requirements are intended to support a good user experience with the Windows operating system. In this context, a "good user experience" means a reliable, consistent experience with system hardware, firmware, drivers, and related software components. In particular:

  • The user is assured that a product that has the Windows Logo will be stable when running under the operating systems listed on the Windows Logo carried by that product or listed in the Hardware Compatibility List.
  • The user can easily begin and complete component installation or removal. Installing and using a component that has the Windows Logo will not cause the system to stop working, or otherwise disrupt Windows or other Logo’d software running on the computer.
  • The user’s overall experience with the computer system and the operating system is the same or better after upgrading to a new Windows operating system.

IMPORTANT: The presence of the Windows Logo on a hardware product does NOT mean that Microsoft endorses or certifies a product. The Windows Logo is not a quality assurance seal. Microsoft does not test the quality of each hardware product or ensure that it is bug free.


“Designed for Windows” Logo Options

Windows Logo Program System and Device Requirements

Previous Next

"Designed for Windows" Logo Options

Microsoft licenses different versions of the "Designed for Windows" logo for specific operating systems on servers, desktop PCs, mobile PCs, and their components, as described in this section. The Windows Logo explicitly identifies the versions of the operating system for which the product passed compliance testing. Testing is conducted by Windows Hardware Quality Labs, as described in Chapter 4 of this guide.

The specific Windows Logo for the system or device indicates which operating system versions the manufacturer supports for the system or device. The current, comprehensive listing of available logos is provided at http://www.microsoft.com/winlogo/hardware/.

Windows Logo Program requirements vary for different classes of products (for example, server, desktop, or mobile) and for different market segments (for example, enterprise server, commercial desktop, or consumer desktop). Where system design guides and other references refer to consumer and business PC system types, the following meanings apply for the Windows Logo Program:

  • Business PC (also referred to as office PC or commercial PC): The system comes with Windows XP Professional or Windows 2000 Professional preinstalled.
  • Consumer PC: The system comes with Windows XP Home Edition or Windows 98/Me preinstalled.

Note: Test logs for Windows XP are required for all logos.


Windows Logo Program Dates

Dates for specific Windows Logo Program requirements are defined on the web at http://www.microsoft.com/winlogo/hardware/.

Windows Logo Program requirements become effective in these ways:

  • Operating System Support. Some requirements become part of the Windows Logo Program based on features in the operating system that the manufacturer preinstalls on the system.

For example, OnNow power management and multiple monitor support became Windows Logo Program requirements a few years ago when new support was introduced in Windows operating systems. These types of requirements depend on which operating system is preinstalled on the system. For example, in past years, a system with Windows NT 4.0 preinstalled was not required to fully support Windows Driver Model (WDM) requirements.

Another example is support for legacy-free designs, first introduced in the Windows 2000 and Windows Me operating systems. For this example, the OEM can choose whether to build legacy-free designs; however, if implemented, the system must meet the specific Windows Logo Program requirements for such systems.

  • Industry Advances. Some technical requirements are market driven and take time to become broadly adopted because of cost or development time.

Such technical advances are introduced as proposed guidelines in the Design Guides (jointly authored by Microsoft Corporation and Intel Corporation). Based on industry feedback about time-to-market issues identified during the Design Guide review cycle, these technical advances become part of the Windows Logo Program requirements on a timetable that the majority of the industry has agreed is technically possible and cost effective.

Some technical advances proposed in the PC and Server Design Guides include support for features in yet-to-be-released versions of Windows operating systems. For example, Advanced Configuration and Power Interface (ACPI) support was required in the Design Guides before ACPI-capable versions of Windows were available.

In special cases such as ACPI, the Logo Program requires design changes in advance of the availability of the operating system in order to ensure value in the installed base of PCs for future operating system upgrades. Actual requirements and effective dates under the Windows Logo Program are based on consensus from industry review to ensure that the platform advances can be made at an acceptable cost and in a reasonable time frame.

To plan for Windows Logo requirements based on new operating system features, participate in Microsoft design reviews and beta testing programs. For more information about how to plan and design systems that ensure operating system compatibility and that comply with Windows Logo Program requirements, see Appendix C, "Designing for Success."


What’s New in This Version

This version supersedes Version 1.1, which summarized the Logo Program requirements for PCs and peripherals for Windows 98/Me and Windows 2000.

Version 2.0 of this document adds the following new information:

  • New requirements in relation to Windows XP/Windows Whistler Server and advances in industry specifications, first presented in the "Future Requirements" sections of Version 1.1 of this document, or announced in the Windows Logo Program News and posted at http://www.microsoft.com/hwdev/winlogo/.

Most of these requirements match design guidelines defined in PC 2001 System Design Guide.

  • New checklists provide detailed requirements for servers and 64-bit systems. Most of these requirements match design guidelines defined in Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server.

Device and System "Quality" Requirements Notes

In previous versions of this document, the detailed lists of WHQL tests in the "Quality" sections in Appendixes A and B were provided to help designers identify the test requirements related to a specific system or component. However, Microsoft now publishes the WHQL Test Specification, which provides extensive details about many tests in the HCT. In addition, the HCT documentation has been revised extensively to help designers and testers easily identify the test requirements for every system and component.

Therefore, the "Quality" sections now include only WHQL Test Specification and HCT documentation cross references, rather than lists of specific tests.

In addition, some requirements were erroneously included in the "Quality" sections in earlier drafts. These have been placed in correct locations under "Compatibility" and "Windows Experience" sections, with cross-references retained in their original locations.

System-related Requirement Notes

Unless otherwise noted, the requirements apply for all versions of the Windows operating system, and general system requirements apply to PC desktops, mobile PCs, and server systems.

Mobile and Server Exceptions. In both the Mobile PC and Server sections in Appendix A, a specific list is provided of cross-references to exceptions for general device and system requirements. To view these lists, see:

A3.0 Mobile PC Client Requirements
A6.0 Server System Requirements

Client vs. Server Notations. Requirement titles clearly specify whether the item applies only for client PCs or servers. For example:

A1.4.2 x86-based client: System and all components correctly implement power management

A1.4.7 Peripherals included with client system offer a non-legacy interface such as PCI, USB, IEEE 1394, or CardBus

A5.4.12 System that provides headless server capabilities meets minimum requirements

Windows Version Notations. Requirement titles clearly specify whether the item applies only for specific versions of Windows. For example:

A1.4.10 Windows XP Home Edition/Professional: Audio is "digital ready"

B6.1.4.10 Windows Whistler Advanced Server: Data modem supports digital connection to support host-side V.90 operation

x86-based vs. Intel Itanium-based Notations. Requirement titles clearly specify whether the item applies only for 32-bit or 64-bit systems. For example:

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 5.2.10.4.

Note: In earlier versions and in the server design guide, the terms IA-32 and IA-64 were used to differentiate 32-bit and 64-bit systems.


How to Use This Document

This document provides the authoritative compilation of references to all Windows compatibility and Logo Program requirements.

Chapter | Description
Chapter 2, Hardware Requirements for Windows Logo | Describes overall requirements for consistent, stable functionality under Windows operating systems.
Appendix A, System Requirements Checklist | Provides a checklist of requirements for desktop, mobile, and server systems, and for legacy-free and 64-bit systems.
Appendix B, Device Requirements Checklist | Provides a checklist of requirements for each device class and bus class.

To understand how the Logo requirements are defined and organized, see:

  • Conventions Used in This Document
  • How to Use the Appendixes

Logo Requirements and Related Documents

This is a comprehensive checklist; however, this is not a standalone document.

To adequately review and design for the compatibility and design requirements for the Windows Logo Program for hardware, you must also have available these documents:

  • Windows Driver Development Kits (DDKs; including DDKs for Windows XP, Windows Whistler Server, Windows 2000, Windows Me, and Windows 98), available at http://www.microsoft.com/ddk/

All DDK topic references in this document are based on the current Windows DDK, published in conjunction with the Windows XP operating system.

Tip: Search for the cited topic name in your local version of the DDK documentation.

  • WHQL Test Specifications, available at http://www.microsoft.com/hwtest/
    Click to launch Click to launch
  • PC 2001 System Design Guide, available at http://www.pcdesguide.org
    Click to launch Click to launch
  • Hardware Design Guide v. 3.0 for Microsoft Windows Server, available at http://www.microsoft.com/hwdev/serverdg.htm
    Click to launch Click to launch
  • Industry specifications, such as ACPI Specification, PCI Local Bus Specification 2.2, USB 1.1 and related device class specifications, MMC-2, and so on. For links to all specifications referred to in these requirements, see References.

Logo Requirements and the Windows HCTs

When you install the Windows XP HCT 10.0, this document is automatically installed with the HCT documentation, the WHQL Test Specifications, and the PC and server design guides.

The HTML Help (.CHM) versions of these documents are designed to work interactively.

We recommend that you review the Windows Logo Program requirements with the HTML Help versions of the test specifications and design guides for easy cross-referencing among the requirements and implementation guidelines.

TIP: You can click the following kinds of links in this document to launch the related reference, if its .CHM file is installed in the same directory with this file:
Click to launch Click to launch
If you download these documents from the web, place them in the same directory to ensure that these links work. All links work automatically if you are running the versions installed the Windows HCT 10.0.

Windows Logo Program for Hardware Components


Resources for Meeting Logo Requirements

The following provides a list of Microsoft resources that can help you build hardware that meets the Windows Logo requirements. In this document, see also:

  • Appendix C, Designing for Success, for steps to help ensure that new designs are Windows compatible.
  • References, for a comprehensive list of specifications.

Resource | Address
Windows Logo Program web site | http://www.microsoft.com/winlogo/hardware/
Feedback on logo requirements and related issues | hwlogo@microsoft.com
Hardware testing tools and test submission information | http://www.microsoft.com/hwtest/
Digital signing for drivers | whqlds@microsoft.com
Windows Logo Program News mailing | Sign up at http://www.microsoft.com/winlogo/hardware/
WHQL Weekly News mailing | Sign up at http://www.microsoft.com/hwtest/
Logo artwork and other issues (after testing) | whqlinfo@microsoft.com
Knowledge Base | http://support.microsoft.com/support/
Information for manufacturers and driver developers | http://www.microsoft.com/hwdev/ E-mail: ihv@microsoft.com
General information for developers | http://msdn.microsoft.com/developer/
Windows DDK | http://www.microsoft.com/ddk/
Microsoft Platform Software Development Kits (SDKs) | Provided with Microsoft Developer Network (MSDN) Professional Subscription. To subscribe: E-mail: msdn@microsoft.com Or: http://www.microsoft.com/msdn/subscribe/


Conventions Used in This Document

Requirement and Design Guideline References

Windows Logo Program requirement citations

Specific requirements for a general, system, or device are defined for the Windows Logo Program for hardware using this format:

WL-# | General Logo Program requirement, where # represents a number defined in Chapter 2.
A#.#.# | Logo Program requirement for PC or server systems, where # represents a number defined in Appendix A.
B#.#.# | Logo Program requirement for devices and buses, where # represents a number defined in Appendix B.

PC 2001 System Design Guide cross-references

These references indicate the implementation guidelines for PCs or peripherals. For any particular reference citation within these requirements, the entire text of the PC 2001 guideline applies (unless different information is defined in this document).

These citations are in the following format, where #### indicates the PC 2001 item number:

1394-#### | INPT-#### | PRNT-####
ATA-#### | MOBL-#### | SCSI-####
AUD-#### | MOD-#### | STOR-####
BTH-#### | MON-#### | SYS-####
BIOS-#### | NET-#### | USB-####
CBUS-#### | PCI-#### | VID-####
GRPH-#### | PORT-#### | WORK-####
IMAG-#### |  |

Note: Appendix C in PC 2001 System Design Guide provides cross-references to PC 99 item numbers. - Click to launch Click to launch

Server Design Guide v.3.0 cross references

These references indicate the implementation guidelines for servers or related peripherals. For any particular reference citation within these requirements, the entire text guideline applies, as documented in Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server.

These citations are in the following format, where #### indicates the server design guide item number:

SDG3:####

TIP: Click references such as SYS-0003 » or SDG3:10 » to see the related reference in a popup window.

Terms

Add-on device

Refers to devices that are traditionally added to the basic PC system to increase functionality. Examples include audio, networking, graphics, small computer system interface (SCSI) controller, and so on. Add-on devices fall into two categories: devices built onto the system board and devices on expansion cards added to the system through a system-board connector, such as Peripheral Component Interconnect (PCI).

Client

Refers to versions of the Windows XP and Windows 98/Me operating systems running on desktop or mobile PC systems.

Design Guidelines

Indicates the source reference where precise information is provided for implementing software or hardware that is compliant with industry standards and the Windows operating system.

Exception

Indications cases in which a requirement may not apply.

FAQ

Standard subsections for each system or component in Appendix A and Appendix B, listing clarifications and corrections published for Windows Logo Program requirements. FAQs are defined in subsections numbered #.#.5 in the appendixes.

FAQ are also listed at http://www.microsoft.com/winlogo/hardware/ and published in the Windows Logo Program News available by subscription on the Windows Logo Program web site.

Future Requirement

Standard subsections for each system or component in Appendix A and Appendix B, listing new features or capabilities that are planned for future versions of the Windows Logo Program for hardware. Future requirements are defined in subsections numbered #.#.R in the appendixes.

Future requirements are also listed at http://www.microsoft.com/winlogo/hardware/ and published in the Windows Logo Program News available by subscription on the Windows Logo Program web site.

Industry Standards

Standard subsections for each system or component in Appendix A and Appendix B, listing required industry specifications, upon which operating system support is based. These references include Internet links to the source document.

Mobile PC Note

Indicates that an exception or additional information is defined for Mobile PC systems. In most cases, the details for the exception are defined in a reference document (such as PC 2001).

Must

Indicates that the statement applies as a requirement for the Windows Logo Program.

Quality

Standard subsections for each system or component in Appendix A and Appendix B, listing requirements for testing the system to ensure Windows compatibility and reliability.

Required; Requirement

The feature must be supported as defined in these guidelines for the hardware to pass testing and receive the Windows Logo.

Server Note

Indicates that an exception or additional information is defined for server systems. In most cases, the exception is defined in Hardware Design Guide V.3.0 for servers, where the complete implementation guidelines are defined.

Should

Indicates that the statement applies as a recommendation or implementation guideline for the Windows Logo Program.

Supported

Indicates that functionality is delivered in the end-user configuration. In a configure-to-order or build-to-order customer product specification scenario, this feature is the default if multiple options are presented.

System device

Refers to devices on the system board, such as interrupt controllers, keyboard controller, real-time clock, direct memory access (DMA) page registers, DMA controllers, memory controllers, floppy disk drive controller (FDC), hard disk controller (HDC), serial and parallel ports, PCI bridges, and so on. These devices are typically integrated with the supporting chip set in legacy PC designs.

Windows [version]

In bold type, used in this document to cite the specific versions of the Windows operating system for which a requirement applies. Unless otherwise stated, requirements apply for all versions of Windows tested under the Windows Logo Program.

Windows Compatibility

Standard subsections for each system or component in Appendix A and Appendix B, listing requirements that ensure the system will run correctly under Windows, based on DDK references for correct driver implementation and Microsoft white papers that describe implementation details.

Windows Experience

Standard subsections for each system or component in Appendix A and Appendix B, listing requirements that advance the Windows platform or enhance the quality of the Windows computing experience. This includes the items first described in Design Guides that are important to the success of the Windows experience.

x86-based, Itanium-based

In bold type, used in this document to cite specific types of computers based on 32-bit and 64-bit microprocessors, respectively, that use the Intel Architecture instruction set.


Chapter 2 - Hardware Requirements for Windows Logo

These guidelines define the Windows Logo Program requirements for consistent, stable operating system functionality and help ensure a satisfactory customer experience.

Compliance dates for specific Windows Logo Program requirements are defined on the web at http://www.microsoft.com/winlogo/hardware/.

Note: These requirements apply to all systems and peripherals displaying the "Designed for Windows" Logo, in the configuration shipped to a customer.
Statements in this document or in the HCT documentation related to "testing requirements" or "systems submitted for Microsoft Windows Logo Program Testing" indicate test submission requirements; such statements do not reduce or alter these Logo 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 if the customer installs a Logo’d component of that class into the system.


Summary of Windows Logo Requirements

The Windows Logo Program requirements consist of the following for each operating system for which the vendor is seeking the "Designed for Windows" logo:

  • Current Microsoft Hardware Compatibility Tests (HCTs) from WHQL, available on the web at http://www.microsoft.com/hwtest/testkits/.
  • The requirements summarized in the following sources:
  • This chapter
  • Appendix A, "System Requirements Checklist"
  • Appendix B, "Device Requirements Checklist"
  • Any clarifications, corrections, or additions listed on the Windows Logo Program for Hardware web site at http://www.microsoft.com/winlogo/hardware/

Implementation guidelines for drivers are defined in the Microsoft Windows DDK. System and component design guidelines are defined in the PC System Design Guide series published on http://www.pcdesguide.org and the Hardware Design Guide for Microsoft Windows Server series, published at http://www.microsoft.com/hwdev/serverdg.htm.

Note that the PC and Server Design Guides do not define the Windows Logo Program requirements; rather, these publications provides feature guidelines for system and component design.

Windows Logo Program Requirements

WL-1. System and devices support required operating systems

WL-2. System memory provides a satisfactory user experience

WL-3. System includes required set of buses and devices

WL-4. All components and devices meet Windows compatibility and quality design guidelines

WL-5. System and components meet reduced legacy support goals

WL-6. System and components support operating system configuration and control of devices

WL-7. System and peripherals implement ease-of-use guidelines for a good end-user experience

WL-8. System components operate correctly upon installation of later operating system

Rationale

  • For minimum memory and processor performance: These minimum requirements ensure that the system will provide an adequate user experience when running applications designed for the targeted platform.
  • For configuration, installation, and ease-of-use requirements: These requirements ensure that the hardware and drivers run in a stable, reliable manner and result in the optimal end-user experience when running under Windows operating systems.
  • For legacy removal: Requirements for "no ISA devices or slots" are specified to reduce frustration for users, reduce total cost of ownership (TCO) in the enterprise, and reduce the support burden for vendors. Also, because the ISA bus is very slow and only supports 16 MB of addressable space, ISA removal may lead to improved performance. Reduced reliance on legacy buses and components means less time required to install new devices in the system, and the system won’t stop running and devices won’t fail because of resource conflicts.
  • For migration capabilities: The goal of this requirement is to ensure that when a user upgrades the operating system, previously installed components will continue to function as before, with all preferences and privileges working after the upgrade.


WL-1. System and devices support required operating systems

At a minimum, a 32-bit system or device submitted for Windows Logo Program testing must provide 32-bit driver support for the Windows XP/Windows 2000 operating system, plus driver support for any other Windows operating systems that will be preinstalled on the system (Itanium-based systems must provide 64-bit driver support). For systems submitted for Microsoft Windows Logo Program testing, a Microsoft operating system must be preinstalled on the hard disk.

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 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.

Notes:

  • The system manufacturer must provide the customer with drivers for all devices for all operating systems for which the system has received the Windows Logo, unless a particular device class is not supported on one of the operating systems. That is, if the system has the logo for Windows 98, Windows NT 4.0, and Windows 2000, the end user must have access to all compatible drivers and utilities for each version of the operating system.
  • If the device class is supported under Windows Driver Model (WDM) in the operating system, the manufacturer-provided driver solution must use WDM.
  • The manufacturer does not need to supply a driver if the device passes Logo testing using a driver provided with the operating system.


WL-2. System memory provides a satisfactory user experience

Because objective benchmarks are not available, the intent of this requirement is to define a memory size that represents the baseline of acceptable Windows performance.

The following summarizes the Windows Logo Program performance requirements.

2001-2002 Minimum Equivalent Performance Requirements

x86-based systems | RAM
Windows 98/Me Windows 2000 Professional | 64 MB
Windows XP Professional Windows XP Home Edition | 128 MB [note 1, 2]
Windows 2000 Server Windows Whistler Server 1-2 processors installed >2 processors installed | [note 3] 512 MB 256 MB per processor
Windows 2000 Advanced Server Windows Whistler Advanced Server 1-4 processors installed > 4 processors installed | [note 3] 1 GB 256 MB per processor
Itanium-based systems | RAM
Windows XP Professional | 1 GB
Windows Whistler Advanced Server 1-4 processors installed >4 processors installed | 4 GB 1 GB per processor

Note 1: For systems with shared memory architecture and 128-MB system RAM, collectively, the drivers supporting integrated chipset functionality must not lock more than 32 MB. It is acceptable to use up to 8 MB from the 64-MB minimum in desktop and mobile PCs running Windows 98/Me or Windows 2000 Professional.

These maximum-page-locked-memory limits apply during all phases of system startup and normal operation. Page-locked graphics memory includes all frame buffers and buffers for hardware acceleration, texture and lighting, Z, and AGP. Page-locked audio memory includes all memory locked by the audio driver including all wave tables, and so on.

Dynamic memory allocation under the Windows environment is allowed, subject to the paged-locked memory limit. The driver cannot advertise or switch into a graphics mode that cannot be supported within the maximum locked memory limit.

Note 2: PC client systems must have at least the minimum system memory installed.

Note 3: Server system memory configurations specify the minimum allowed system memory to run the HCT. It is recognized that OEMs supply systems with specific feature requirements to corporations, which can include providing servers that do not include any preinstalled memory or that meet specific customer requirements for installed memory.


WL-3. System includes required set of buses and devices

The system must include the following buses, connectors, and devices, with driver solutions implemented as defined in the Windows DDK:

  • Primary storage host controller and primary hard drive.
  • Support for installing the operating system (CD/DVD drive or network adapter on desktop system).
  • Industry-standard internal buses and devices, excluding ISA slots and devices.
  • Industry-standard connectors with icons or labels.

Note: WHQL System Test Submission logs must include results with both modem and network adapter installed. Systems are not required to include a modem or network adapter in their shipping configurations.

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.
  • Published advertisements.
  • 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]

For more information about requirements for each type of system, see Appendix A, "System Requirements Checklist."


WL-4. All components and devices meet Windows compatibility and quality design guidelines

The compatibility and quality guidelines include requirements for devices, drivers, and software included with the system or retail component.

For specific feature and functionality requirements for each type of system, see Appendix A, "System Requirements Checklist."

Click to show or hide information. Device Requirements

Any buses, devices, or other components offered with a Logo’d system or offered as a retail product carrying the "Designed for Windows" logo must pass related feature tests and operating system compatibility tests published by WHQL.

For the complete checklist of device and bus requirements, see Appendix B, "Device Requirements Checklist."

Click to show or hide information. Driver and Software Requirements

These requirements ensure a good user experience when installing and using any component:

  • Windows-compatible driver support. Each device must have drivers for Windows XP/Windows 2000, plus support for other operating systems that may be preinstalled, as cited in requirement WL-1, "System and devices support required operating systems."
  • Windows-based driver installation. Driver installation and removal must use Windows-based methods, as defined in the Windows DDKs. For Windows XP/Windows 2000, this means only INF-based installation routines.
  • System component and installation integrity. Driver or software installation must not replace any Microsoft-authored system components and the driver must not bypass any operating system components. See http://www.microsoft.com/hwdev/sfp/wfp.htm.

Installation and loading of a driver must not reduce or eliminate the functionality of other devices installed on the system.

The driver must support unattended installation. That is, it must be possible to install the driver using a script or special software for supplying required parameters without the user being present during driver installation.

  • Minimum driver compatibility. Each driver must pass minimum compatibility, functionality, and stress testing as verified by the testing suites published by Microsoft WHQL for the related class.
  • Driver with special parameters includes Help file. To ensure that the user can correctly change settings, a Windows Help file must be provided if special driver parameters are used. This help file must install as part of the driver installation routine.
  • Driver Verifier. For each Windows XP/Windows 2000 driver, no errors can occur under the Driver Verifier facility provided with the operating system. Although Driver Verifier is not available for Windows 98/Me, every WDM driver should be tested with Driver Verifier on Windows XP/Windows 2000.

Poorly written kernel-mode drivers have the potential to cause the system to become unstable or stop working. Therefore, it is critical that all kernel-mode drivers be thoroughly tested to minimize this risk. For information about using Driver Verifier and diagnosing driver problems, see http://www.microsoft.com/hwdev/driver/driververify.htm.

  • Driver signing. All drivers installed on the system as shipped to the customer must be signed. Drivers submitted for Microsoft Windows Logo Program testing must meet the guidelines for driver signing as defined at http://www.microsoft.com/hwdev/desinit/digitsign.htm.

Other WHQL test programs that require digital signatures include the following:

  • Hardware Abstraction Layers (HALs): The purpose of the HAL test kit is to test third-party (non-Microsoft) HALs intended for use in server-class systems.

For details about what is tested for HALs, see Chapter 26, "HAL Test Specification," in WHQL Test Specification.

  • Anti-virus software: WHQL launched a test program, related to the "Designed for Windows XP" Applications Logo Program, for anti-virus applications that include a kernel-mode file-system filter driver. Such applications that pass testing for Windows XP will receive a digital signature for their file-system filter driver, but not the entire application.

For details about what is tested for anti-virus software, see Chapter 21, "Anti-virus File System Filter Test Specification," in WHQL Test Specification.

Note: Additional requirements related to driver and software quality may be added as tests become available.

Implementation Guidelines:
Windows DDKs at http://www.microsoft.com/ddk/.

Click to show or hide information. "New Technology" Requirements

For new or other technologies where specific compatibility tests have not been defined under the Windows Logo Program (as provided in the HCTs from WHQL), or where design guidelines have not been provided in a Design Guide, the following requirements apply:

  • Maintain system integrity. The implementation of the technology must not adversely affect the performance or stability of all functionality provided under the preinstalled operating system and under Windows XP/Windows 2000.
  • Use native operating system support whenever possible. If native support for the related feature is provided under a preinstalled version of Windows 98/Me or Windows XP/Windows 2000, comply with the related industry specification, create drivers based on Windows DDK guidelines, and meet the design requirements defined in PC 2001 System Design Guide or Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server.

For example, if the graphics adapter or monitor supports a digital video interface and is included on a system with Windows Me preinstalled, the implementation must follow the PC 2001 guidelines. Similarly, if the system supports IEEE 1394b and comes with Windows XP, comply with the industry specification, implement WDM minidriver support as defined in the Windows DDK, and follow the PC 2001 guidelines.

  • Follow the DDK and industry standards to ensure an upgrade path. If the feature is not supported natively in the preinstalled Windows operating system, comply with the related industry specification (if industry standards have been developed), follow Windows DDK guidelines for related bus and device class driver implementations, follow general Plug and Play and power management guidelines as defined in the Windows DDK, and plan an upgrade path for end users.

For example, if you design a system to include a new wireless technology for which there is no native operating system support, you must still use the related Windows driver model for adding support. In this example, driver support must be implemented as a Network Driver Interface Specification (NDIS) 5.0 miniport, as defined in the Windows DDK and cited in the guidelines for wireless devices in PC 2001 System Design Guide.


WL-5. System and components meet reduced legacy support goals

The following legacy-reduction goals are defined for the Windows Logo Program for hardware.

Click to show or hide information. Hardware Legacy Reduction Requirements

Retail components and components included with a system must not use the ISA expansion bus. The system must not include ISA expansion slots.

For desktop and mobile systems, peripherals that use the parallel or serial ports cannot be included with the system. The ports themselves are still allowed to allow connectivity for legacy hardware the user might already have.

Devices that use Super I/O and that are resource managed by ACPI are acceptable. The important issue is that Super I/O is not a legacy component in itself; however, fixing resources to Super I/O is a legacy implementation that was traditionally used before ACPI.

Click to show or hide information. Software Legacy Reduction Requirements

All software included with a system or peripheral device must be Microsoft Win32®- or Win64™-based software. The software must not require MS-DOS®-based decompression or installers.

Click to show or hide information. Windows Me Legacy Reduction Requirements

Drivers and utilities must not run in real mode under Windows Me, and must not use Config.sys or Autoexec.bat for configuration or for launching related software.

This requirement does not apply for the emergency recovery software, system or component pre-configuration software, or boot device software.

Click to show or hide information. Legacy-Free PC System Requirements

A PC system is not required to be legacy-free to receive the "Designed for Windows" logo. A PC system is considered legacy free under the Windows Logo Program if it meets the following basic criteria:

  • The LEGACY_DEVICES flag is set to 0 in the Fixed ACPI Description Table (FADT).
  • Operating system detection software does not report the presence of Super I/O-dependent components (with exceptions for 8042 controllers).
  • No components claim to use the restricted port addresses.

The complete hardware and BIOS requirements for Windows-compatible, legacy-free design are described in Appendix A, "System Requirements Checklist," including exceptions and issues for mobile PCs.


WL-6. System and components support operating system configuration and control of devices

The goal for this requirement is correct support for complete operating system management of system configuration and behavior. This requirement applies for all BIOS, bus, and device components in a system. In particular, this includes:

  • Windows 2000-ready, ACPI-compliant BIOS.
  • Correct implementation of Plug and Play and power management.

This requirement is based on fundamental operating system requirements, industry specifications, and Windows DDK implementation guidelines for Plug and Play and other functional capabilities of the operating system.

For details about operating system compatibility and design guidelines, see Appendix A, "System Requirements Checklist."


WL-7. System and peripherals implement ease-of-use guidelines for a good end-user experience

The following basic ease-of-use guidelines are cited for the Windows Logo:

  • Connections use icons, plus keyed or shrouded connectors.

Color-coding is not required. Suggestions for icons and color codes are listed at http://www.pcdesguide.org/documents/icons.htm.

  • Minimal user interaction is needed to install and configure devices, which is ensured by following the device installation guidelines defined in the Windows DDKs.
  • Driver and utility installation do not require a system reboot, unless required by the operating system.

Installation of a component should not require a reboot when installed on a system where no applications are running.

Implementation Guidelines:
Installing Drivers and Utilities without Rebooting on Windows 2000 at http://www.microsoft.com/hwdev/PlugnPlay/no_reboot.htm


WL-8. System components operate correctly upon installation of later operating system

  • System manufacturers must clearly communicate their support commitments to their customers. Customers base purchase decisions on the operating systems listed on the logo; they expect that if a system carries a "Designed for Microsoft Windows" logo with two operating systems listed that the system will support both operating systems. The requirements defined here support that customer expectation.
  • Important: System manufacturers must support the preinstalled operating system and any operating system listed on the "Designed for Microsoft Windows" Logo.

Click to show or hide information. Basic Support and Best Practices

  1. System manufacturers must provide instructions for each of the supported Microsoft operating system installation-and-recovery scenarios.

If the manufacturer makes the commitment to support only system restoration from recovery media or the installation of an operating system on an empty hard drive, then this level of support must be clearly communicated.

The system manufacturer must provide an "operating system version support" status report for each model or model family; the report must include a list of the previously available preinstallations for each of the Windows operating systems since the time that model or model family was released to manufacturing. The "operating system version support" status report must clearly communicate the manufacturer’s support commitment, including supported clean installs and upgrades, availability of drivers, and utilities required to maintain functionality after installation of an operating system.

  2. For operating system installations supported by the system manufacturer, a help file must be made available.

The help file must contain complete instructions for the end user about system preparation and changes to the BIOS, applications, and drivers that must be completed before installing an operating system on the PC.

  3. A Logo'd system and its components must be fully functional after installation of a supported operating system version.

This requirement is specific to installations in the same class of operating system, for example, desktop-to-desktop or server-to-server.

In particular, consider a system that comes preinstalled with Windows Me. When Windows XP Home Edition is installed, all features present under Windows Me that are supported in Windows XP Home Edition must be fully operational.

Click to show or hide information. Installing Windows XP or Windows 2000

OEMs must support installing Windows XP on systems that display any of the following "Designed for Microsoft Windows XP" logos:

"Designed for Windows XP" logo
"Designed for Windows XP and Windows 2000 Professional" logo
"Designed for Windows XP and Windows Me" logo
"Designed for Windows XP and Windows 98 Second Edition" logo

Similarly, OEMs must support installing Windows Whistler Server on systems that display any of the following the "Designed for Microsoft Windows Whistler Server" logos:

"Designed for Windows Whistler Server" logo
"Designed for Windows Whistler Server and Windows 2000 Server" logo

Click to show or hide information. Customer Support Requirements

These requirements apply to systems that display the logos listed earlier in "Installing Windows XP or Windows 2000."

  1. System includes Windows 2000-ready, ACPI-compliant BIOS.

Related information is available at http://www.microsoft.com/hwdev/onnow/.

  2. Supported features are functional after installation.
  • Features supported in Windows 2000 and present on a system must be fully operational after the installation of Windows XP.
  • Features supported in Windows Millennium and present on a system must be fully operational after the installation of Windows XP.
  • Features supported in Windows XP Home Edition and present on a system must be fully operational after the installation of Windows XP Professional.
  3. OEM preinstalled system applications and utilities are "Windows XP/Windows 2000 ready."

System applications, utilities and system tray applets that are included with a system must be capable of running after the system is installed with either Windows 2000 or Windows XP, unless that functionality is supported natively in the operating system.

OEMs should provide access to up-to-date application files for customers who perform ‘clean’ operating system installations, or for customers who do not have access to internet-based help and support, as well as for customers who have access to the Internet.

Internet Availability Requirement for Preinstalled Software. Customer-support must be provided by making available Internet downloads of migration DLLs, patches, or replacement software applications. In addition, preinstall a link to a URL for the manufacturer’s support web site that contains the migration DLLs, patches, or replacement software which the user needs to ensure that all preinstalled applications run after installing Windows 2000 or Windows XP. This web site must be available and populated with correct files when the system is available to end users.

Non-Internet Availability Recommendations for Preinstalled Software. Any one or more of the following solutions can meet the customer-support needs in non-Internet-connected scenarios:

  • Preinstalled application is already "Windows 2000 and Windows XP ready."
  • Place a new Windows 2000-compatible version of the application on the hard disk. The user can reinstall the application after migrating to either Windows 2000 or Windows XP.
  • Place any necessary patch files on the hard disk. The user can run these "fixes" after migrating to Windows XP/Windows 2000.
  • Place a migration dynamic-link library (DLL) on the hard disk. The Microsoft General Device Driver Pack Migration DLL is available at http://www.microsoft.com/hwdev/driver/. See also http://msdn.microsoft.com/library/techart/msdn_migdbg.htm.
  • Provide application media to customers upon request.

Note: OEMs are not required to provide applications from third parties that were licensed for a particular preinstalled operating system version. In this case, the OEM must provide a notice to show where their customers can obtain versions for the later operating system.

  4. Preinstalled devices are "Windows 2000 ready" or "Windows XP ready."

For any device that does not have a driver included as part of the Windows 2000 product, a signed Windows XP/Windows 2000 driver must be available to the user.

For those devices where it is not feasible to provide common Windows XP/Windows 2000 driver files, providing operating system-specific signed drivers is acceptable; drivers must be provided for each of the operating systems supported. OEMs should provide access to up-to-date signed driver files for customers who perform ‘clean’ operating system installations and for customers who do not have access to Internet-based help and support, as well as for customers who have access to the Internet.

Internet Availability Requirement for Preinstalled Drivers. Customer-support must be provided by making available Internet downloads of signed drivers. In addition, preinstall a link to a URL for the manufacturer’s support web site that contains the drivers required during and after migrating to Windows 2000 or Windows XP. This web site must be available and populated with signed driver files when the system is available to end users.

Non-Internet Availability Recommendations for Preinstalled Drivers. Any one or more of the following solutions can meet the customer-support needs in non-Internet-connected scenarios:

  • Place signed Windows 2000 and Windows XP drivers on the hard disk drive, so that the user can reinstall the driver after migrating to Windows 2000 or Windows XP.

Note: If you provide drivers on the system hard disk drive, the drivers can be in any directory other than <winroot>\INF, <winroot>\system32, or <winroot>\system. Also, you must provide the end-user with a migration DLL, as described in the Windows DDK or on the web at http://www.microsoft.com/hwdev/driver/WinH2kDrv.htm.)

  • Provide signed drivers for Windows 2000 and Windows XP drivers for posting on Windows Update site.
  • Provide media in the "as shipped" system’s packaging to support migrating to Windows 2000 and Windows XP.
  • Provide media to the customer upon request.
  5. All features in custom utilities are available after installation of Windows 2000 or Windows XP.

For all manufacturer-provided utilities preinstalled on the system, one of the following conditions must be met:

  • If no user functionality is lost after installing Windows 2000 or Windows XP, the utility can be removed or turned off. This case applies when built-in Windows 2000 or Windows XP features such as ACPI-based power management replace functionality that the manufacturer provided under Windows NT 4.0 through custom utilities.

- OR -

  • If user functionality is lost, the manufacturer must provide customer support as described earlier in the item "Preinstalled applications and utilities are ‘Windows XP/Windows 2000 ready.’"


Chapter 3 - Recommendations and Future Requirements

This chapter describes the processes that Microsoft follows for adding new requirements to the Windows Logo Program for hardware. This chapter also presents specific design practices that Microsoft encourages to provide an optimal end-user experience when running Microsoft Windows operating systems.

Note: Future requirements currently proposed for systems and devices based on industry specification advances and new capabilities planned for future Windows operating systems are defined in the "Future Requirements" sections in Appendixes A and B of this document.


New Requirements Process

This section summarizes the general processes by which new requirements are proposed and incorporated into the Windows Logo Program for hardware.

Click to show or hide information. New Operating System Capabilities vs. Windows Logo Program

Microsoft presents preview information about new operating system capabilities related to the hardware platform in Design Previews. System and device manufacturers are invited to attend these private sessions, based on the degree of market involvement particular manufacturers have for the specific technologies. Presentations at Design Previews include sufficient detail for manufacturers to understand the technical requirements for implementing new support in hardware and firmware. Microsoft actively solicits manufacturers’ feedback at Design Previews, and Microsoft also provides information about Logo Program requirements proposed in relation to the new system capabilities.

Action for New Operating System Capabilities and Logo Preview:
If you want to request to be considered for invitation to Design Previews for specific technologies in which your company has key technical and market investments, please complete the request form at http://www.hwdev.org/EventRequest.htm

Click to show or hide information. Advances in Industry Specifications vs. Logo Program

Microsoft works with most standards bodies for PC and server technologies, and makes plans to advance operating system support based on the current industry specifications for these technologies.

When proposing new Logo Program requirements related to advances in existing specifications, Microsoft will survey Logo Program participants to determine when most manufacturers are intending to implement the advances.

Action for Advances in Industry Specifications and Logo Preview:
If you want to participate in defining or reviewing industry standards upon which operating system support is based, please join the related SIG or working groups for that technology. A list of many industry specification sources is provided at:
http://www.microsoft.com/hwdev/specs/

Click to show or hide information. New Industry Specifications vs. Logo Program

When new technologies are being defined and proposed for general industry adoption, Microsoft typically works with the industry consortium that is defining the hardware and firmware implementation. For example, new technologies such as ACPI and Bluetooth wireless technology are defined in industry consortia. Microsoft develops the related operating system capabilities in conjunction with development of the new specification.

Adoption of such technologies as Logo Program requirements is usually defined in terms such as:

If you implement Bluetooth wireless technology, comply with the industry specification and implement driver support as defined in the Windows DDKs.

The availability of Hardware Compatibility Tests (HCTs) to validate new technologies for the Logo Program typically require good availability of new hardware at Microsoft. The Microsoft development teams require a foundation of hardware implementations in order to create and validate compatibility tests.

Note also that it is rare for the Logo Program to define requirements such as ACPI, where the entire industry was required to change hardware/firmware support to advance PC platform capabilities. In cases where such universal changes are required, Microsoft will work within an industry consortium to define the technical standards and establish appropriate phases for implementing the new requirements in the Logo Program.

Action for New Industry Specifications and Logo Preview:
If you want to participate in defining new industry standard, please join the related working group. Note that typically the Logo Program does not allow driver implementations that do not follow DDK guidelines or that replace kernel Windows components.

Click to show or hide information. Proposals for New Requirements

Proposals for new requirements are published in the Windows Logo Program newsletter, which is distributed by e-mail.

To receive weekly notification of any Logo Program proposals, subscribe to the mail list as described at http://www.microsoft.com/winlogo/hardware/.

Action for Comments on Future Windows Logo Requirements
Send e-mail to hwlogo@microsoft.com. Please be sure to include your name, title, company name, and company type.

Click to show or hide information. Dates for New Requirements

As a rule, future requirements related to operating system features go into effect when the related operating system is available and the OEM begins shipping systems that contain features supported under the new operating system. See "Windows Logo Program Dates" in Chapter 1.

In general, Microsoft attempts to meet the following general guidelines for proposing new Logo Program requirements.

Change required | Advance notice
Chipset revision | 12 - 18 months
Driver revision | 6 months
Firmware revision | 6 months

For example, future Logo Program requirements related to incorporation of a new driver stack within the operating system will not be required until Microsoft provides full technology support:

  • Operating-system drivers are released.
  • DDK support is released.
  • Test kit is released by WHQL.


“Best Practices” for Systems and Devices

Expand all contracted text Show All

Windows Logo Program System and Device Requirements

Previous Next

"Best Practices" for Systems and Devices

This section summarizes design and driver quality practices that Microsoft recommends to ensure reliable, quality experiences for end users.

Click to show or hide information. Implement "Ease of Use" Recommendations from PC 2001

Chapter 2, "Easy PC Initiative," in PC 2001 System Design Guide, includes specific guidelines for making PCs easy to set up, easy to use, and easy to maintain. Designers should give high priority to implementing these recommendations in order to improve the end user experience and reduce support calls after sales.

Click to show or hide information. Follow the "Designing for Success" Tips in Appendix C

Appendix C of this document provides a series of guidelines to help ensure that system and device manufacturers can create new design that are compatible with Microsoft operating systems.

Microsoft recommends that you follow these guidelines as part of the design process, to ensure that you receive news and feedback from Microsoft that can help ensure the success of new designs.

Click to show or hide information. Ensure that Soft Devices Meet Resource Usage Guidelines

Several types of devices can be designed to migrate functions from peripheral hardware to Windows drivers, saving bill-of-materials costs at the expense of CPU resources. Examples of such devices include soft audio, soft Public Switched Telephone Network (PSTN) modems (V.34, V.90)??and soft asymmetric digital subscriber line (ADSL) modems (G.992.2). There are several risks:

  • Any soft device may undermine the system, depending on how it uses CPU and system resources.
  • Any soft device may be vulnerable to failures or performance issues created by other parts of the system, depending on how other device drivers compete with it for CPU and system resources.
  • A combination of soft devices may be much less stable than either device alone.

Requirements for soft modems are in development. These requirements will reference absolute CPU consumption rather than percentages of the available CPU.

Design Guidelines:
Guidelines for WDM-based Software Modems at http://www.microsoft.com/hwdev/modem/softmodem.htm
Windows Management Instrumentation: International Support Overview at http://www.microsoft.com/technet/win2000/winigloba.asp

Click to show or hide information. Ensure that Pre-installed Software Meets Guidelines for Globalization

These guidelines include the following:

  • Use Unicode as the character encoding to represent text.
  • Consider using a multilingual user interface: launch the application in the default user interface language, and offer the option to change to other languages.
  • Use the Win32 application programming interface (API) National Language Support functions to handle locale-sensitive data.
  • Watch for Windows Messages that indicate changes in the input language, and use that information for the spell checker, selecting fonts, and so on.
  • Use the Script APIs (Uniscribe) to lay out formatted text on a page, to allow display of multilingual text and complex scripts such as Arabic, Hebrew, Hindi, Tamil, and Thai.
  • Test applications in multiple configurations, mixing the system locale, user locale, input locale, and user interface (UI) language.

Design Guidelines: Developing International Software for Windows 95 and Windows NT, by Nadine Kano, available online at http://msdn.microsoft.com/library/books/devintl/s24ac.htm.

Click to show or hide information. Preinstall Only Applications that Conform to "Designed for Windows XP Application Specification"

If any additional stand-alone software is bundled with a device that was not tested with the device submission (for example, a printer that ships with a paint program), that software should pass the requirements for either the "Designed for Windows" Application Logo, as defined at http://www.microsoft.com/winlogo/software/ or the "Certified for Windows" logo at http://www.msdn.microsoft.com/certification/ if the product packaging is to display the "Designed for Windows" logo. In the future, this will be a Logo Program requirement.

Click to show or hide information. Implement Best Practices in Consumer Desktop PC Design Checklist for Windows XP

"Consumer Desktop PC Design Checklist for Windows XP" is provided on the web at http://www.microsoft.com/hwdev/pcdesign/. This checklist provides manufacturers with a list of capabilities and components that deliver the best performance and reliability and that deliver the exciting new end-to-end personal computing experiences that characterize a consumer desktop PC optimized for Windows XP.

Best practices in from the PC Design Checklist include the following:

General Component Guidelines

  • System does not statically lock UMA memory at boot
  • All application software components included with the PC system meet the requirements for the "Designed for Windows XP" logo for software

Startup and Power Guidelines

  • System BIOS and hardware meet Fast Boot/Fast Resume requirements
  • Power switch implementation ensures ease of use

General Device Guidelines

  • Control devices are HID compliant

Device Connectivity Guidelines

  • System includes at least four USB 1.1.compliant ports
  • System includes at least two IEEE 1394 ports
  • System implements legacy-free design

Graphics Adapter Guidelines

  • Graphics adapter supports Direct3D 8.0 features
  • Graphics subsystem performance meets PC Design Checklist
  • Graphics subsystem provides a DVI connector

Display Guidelines

  • External monitor provides native sRGB support, enabled by default
  • Monitor supports minimum resolution
  • Monitor is a flat-panel display
  • Monitor integrates auxiliary components and controls

Networking and Communications Guidelines

  • System includes Logo-compliant Ethernet adapter

Storage Guidelines

  • Hard disk is preformatted with NTFS
  • System includes Logo-compliant CD.RW and DVD devices
  • Hard disk capacity and performance meet PC Design Checklist guidelines

Physical Design Guidelines

  • System is designed for the consumer’s ease of use
  • System meets PC Design Checklist guidelines for quiet operation
  • System design features ultra small enclosure

Windows Desktop Guidelines

  • Do not place icons on the Windows desktop
  • Do not run applications at Windows startup
  • Do not display application icons in the Notification area of the Taskbar
  • Do not add multiple items to the All Programs list
  • Add links using the OEM button and Most Frequently Used list
  • Do not place multiple files in the root of the hard disk
  • Ensure that file associations are appropriate
  • Help information uses Windows XP Help and Support Services architecture
  • System includes OEM-specific OOBE for Windows Setup, user registration, and Internet access

Digital Imaging Checklist

  • System and components support digital imaging experiences
  • Digital media components use built-in Windows XP support
  • Color-capable devices provide native sRGB support, enabled by default
  • System includes the largest-capacity hard disk available
  • System without a camera includes device support for portable media
  • System includes a USB flatbed color scanner
  • System includes a photo-realistic USB printer
  • System includes a powered USB hub
  • System includes a USB or IEEE 1394 webcam

Audio Guidelines

  • System includes Logo-compliant audio with support for DirectSound, DirectSound3D, and DLS acceleration
  • Audio speaker system includes two speakers and a subwoofer
  • System supports AC-3 out and mini-disk players

TV and Video Technologies

  • Broadcast and video components use built-in Windows XP support
  • System includes HDTV tuner card
  • Graphics subsystem includes TV-out capabilities

Real-Time Communications Checklist

  • System includes microphone or headset for voice input
  • System with voice input capabilities supports AEC reference inputs
  • System includes a USB or IEEE 1394 webcam


Chapter 4 - Getting the Windows Logo for Hardware

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 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.

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

Note:

  • 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.

See also:

  • Conventions Used in This Document
  • How to Use the Appendixes


How to Use the Appendixes

Appendix Sections and Subsections

In Appendix A, "System Requirements Checklist," and Appendix B, "Device Requirements Checklist," each system and device type is identified in a separate section. These section numbers do not necessarily correlate directly with WHQL test categories. For devices, these sections are not related to how the device is attached to the computer.

Each group of system-specific or device-specific requirements is divided into the following subsections.

Subsection

Description

#.#.1 Windows Compatibility

Requirements that ensure the system or component will run correctly under Windows, including:

  • DDK references for correct driver implementation
  • Links to Microsoft white papers that describe implementation details for Windows compatibility

#.#.2 Industry Standards

Industry specifications upon which operating system support is based. These are provided as Internet links for the convenience of designers and testers.

#.#.3 Quality

Requirements for testing the system, device, or driver to ensure the quality of implementation under Windows.

#.#.4 Windows Experience

Requirements that advance the Windows platform or enhance the quality of the Windows computing experience. This includes the items first described in Design Guides that are important to the success of the Windows experience.

#.#.5 FAQs

Requirements and clarifications published for the Windows Logo Program. These include compliance date and implementation issues, plus clarification of design guidelines published elsewhere.

Each system or device topic on the http://www.microsoft.com/winlogo/hardware/ web site may contain additional clarifications and announcements of any new requirements defined after publication of this document.

#.#.R Future Requirements

Capabilities and features that may become new Logo requirements with the next release of the Windows operating system following Windows XP and Windows Whistler Server.

Each system or device topic on the http://www.microsoft.com/winlogo/hardware/ web site may contain announcements of any additional future requirements planned for future versions of Windows.


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 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).

  • 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 B7.1.4.5 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(HW_2605>SDG)», 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

[ SYS-0002.1 »; SDG3:2 »]

  • x86-based: Comply with ACPI 1.0b.
    Itanium-based: Comply with Multiple APIC Description Table (MADT) in ACPI 2.0, Section 5.2.10.4.
  • 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

[ 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 DELETED

Previous Next


A1.2 General System - Industry Standards

A1.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 specifications

Links 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

Previous Next


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
Click to launch Click to launch

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.3.4 DELETE

See A5.4.4.


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" - Click to launch Click to launch
Hardware Design Guide 3.0 for Windows 2000 Server, Chapter 2 - Click to launch Click to launch

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]

  • 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.
[SYS-0003.3 »; SDG3:10.3 »]

  • 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.

x86-based desktop:

  • 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

System Test Configuration Notes

Must be enabled

OK to disable

  • Graphics adapter and audio.
  • Keyboard and mouse attached (on desktop system).
  • 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.
  • Network connection.

Excluded systems

  • 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.
  • Itanium-based systems.
  • 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

[ WL-3]

  • 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.
  • Published advertisements.
  • 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.4 DELETED
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

[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:

  • Digital Audio White Papers and "Windows Support for HID-based Audio Controls" at http://www.microsoft.com/hwdev/audio/
  • PC 2001 System Design Guide "Audio" chapter - Click to launch Click to launch
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).

  • 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

[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 device

See B4.1.1.8.


A1.5 General System - FAQs

A1.5.1 Current general FAQs

See 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:

  • 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]

[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.
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 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.
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]

[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.

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.11 DELETED
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]

[SYS-0002 »; SDG3:9 »]

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.

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
    http://www.microsoft.com/hwdev/specs/Pmref/
  • 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.
    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)

[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:

  • 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

http://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 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.


A2.0 Desktop Client Requirements

This section describes additional requirements or exceptions to the requirements defined earlier in Section A1.0.

For Itanium-based desktop systems, all requirements in A5.0 are included by reference.

Design Guideline References:
PC 2001 System Design Guide, Chapter 3, "PC System"
Click to launch Click to launch

A2.1 Desktop Client - Windows Compatibility

See A1.1.

A2.2 Desktop Client - Industry Standards

A2.2.1 USB specifications and other USB requirements

As defined in Section B2.6 in Appendix B, "Device Requirements Checklist."

A2.3 Desktop Client - Quality

See A1.3.

A2.3.1

See A2.4.7

A2.3.2

See A2.4.8

A2.4 Desktop Client - Windows Experience

A2.4.1 Two USB ports in all systems, with system BIOS boot support for USB input devices

[ SYS-0021 », BIOS-0005.2 »; SDG3:13.3 »]

If only two USB ports are provided, system provides at least one accessible USB port supporting end user expansion when keyboard and pointing device are attached.

A2.4.2 CD/DVD drive or network adapter (for installing the operating system)

[ SYS-0039 »]

Desktop system includes CD or DVD device.

Note for configure-to-order/build-to-order requirements: PC clients shipped into retail markets must have at least the minimum hardware support that is listed in these requirements. Retail markets include:

  • Retail "on-shelf" configurations.
  • Published advertisements.
  • 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 must support installation of an operating system by including either a CD/DVD drive or network adapter. [see A1.4.3, A1.1.4]

A2.4.3

See A1.3.3

A2.4.4 DELETED
A2.4.5 If IEEE 1394 is included in a system, at least two externally-accessible sockets are required

[ SYS-0022 »]

A2.4.6 Windows XP Professional/Windows Whistler Server: Expansion devices on desktop systems can be remotely managed

[ SYS-0049 »]

A2.4.7 BIOS correctly supports input and boot devices on system boot

See FAQ A2.5.2.

A2.4.8 BIOS correctly handles long descriptors read from any USB device attached to the system at boot time

[BIOS-0005.3 »; see FAQ A2.5.2]

A2.5 Desktop Client - FAQs

A2.5.1 Current general FAQs

See http://www.microsoft.com/winlogo/hardware/.

A2.5.2 BIOS support for USB

[ BIOS-0005.2, 0005.3 »; SDG3:11 »]
Current requirements are defined at A1.1.4.

A2.R Desktop Client - Future Requirements

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


A3.0 Mobile PC Client Requirements

This section describes additional requirements or exceptions to the requirements defined earlier in Section A1.0.

A3.0.1 General System Exceptions for Mobile PCs

In addition to requirements defined in Section A3.0, the following exceptions to General System requirements are defined for Mobile PC systems elsewhere in Appendix A:

  • A1.4.12 Requirements for APIC support do not apply for mobile PCs.
A3.0.2 Legacy-free System Exceptions for Mobile PCs

The following exceptions to Legacy-Free PC System requirements are also defined for Mobile PC systems in elsewhere Appendix A:

  • A4.1.3 No components claim to use the restricted port addresses – mobile exceptions:
  • Both desktop and mobile PCs can use the 8042 controller internally, but must not include external PS/2 connectors. Legacy-free systems that use the 8042 controller internally must set the 8042 flag to 1 in the ACPI FADT.
  • Systems can provide Super I/O-based Infrared Data Association (IrDA) support through the year 2001.
  • A4.4.2 A mobile PC is required to provide only one free USB port.
  • A4.4.8 MS-DOS must not be required to install or run any utilities, games, or other software provided with the system -- required for new docking stations designed for legacy-free mobile PCs.
  • A4.5.3 CD or DVD drive requirement – exceptions for legacy-free mobile PCs.
A3.0.3 Device Exceptions and Notes for Mobile PCs

The following additional requirements, exceptions, and FAQs for Mobile PC systems, devices, and buses are defined in Appendix B:

  • B2.3.4.4 Windows XP: Mobile PC IR devices, if supported, support D0 and D3 states.
  • B3.1.4.4 Audio Record and Playback works properly—WHQL Audio test: Audio performance – mobile PC exceptions defined.
  • B4.1.1.8 Onboard graphics device can be used as primary VGA boot device (additional BIOS setup utility requirement for mobile PCs).
  • B4.1.4.13 Mobile PC system meets basic graphics requirements to reliably run Windows and applications, plus requirements for resolution capabilities. [GRPH-0393]
  • B4.1.4.14 Mobile PC system 3-D capabilities, if implemented, meet minimum requirements.
  • B4.2.1.5 Windows XP/Windows 2000: Windows Support for Mobile System Displays.
  • B4.2.4.3 Minimum graphics resolution, based on monitor size.
  • B5.1.4.6 Devices use USB or external bus connections rather than legacy serial or parallel (mobile PCs can expose the FDC bus).
  • B5.3.4.1 Mobile PC external PS/2 pointing device detected at boot and installed correctly.
  • B5.3.4.1 Mobile PC internal pointing device is disabled or dual operation enabled if external PS/2-compatible pointing device is present.
  • B11.1.4.5 Mobile system meets standard video requirements for appropriate display panel resolution if resolution is 1024 × 768 × 24 bpp or higher.


A3.1 Mobile PC Client - Windows Compatibility

A3.1.1 ACPI 1.0b-compliant support for mobile PC docking station interface and state change notification

[MOBL-0073, 0078, 0079, 0080 »]

Including fail-safe docking based on capabilities and methods in ACPI Sections 6.3 and 5.6.4.

A3.2.1 Windows XP/Windows 2000: Windows 2000 Support for Mobile System Displays

http://www.microsoft.com/hwdev/video/mobiledisplay.htm


A3.2 Mobile PC Client - Industry Standards

A3.2.1 Smart Battery Specifications

[MOBL-0062 »]
http://www.sbs-forum.org

A3.2.2 ACPI Docking for Windows XP/Windows 2000

[MOBL-0078, 0079 »]
http://www.microsoft.com/hwdev/onnow/ACPIdock.htm

A3.2.3 ICC Profile Format Specification, Spec ICC.1:1988-09 and Addendum 2, ICC.1A:1999-04

[MON-0235 »; see FAQ A3.5.5]
http://www.color.org/profiles.html


Windows Logo Program System and Device Requirements

Previous Next

A3.3 Mobile PC Client - Quality

See A1.3.


A3.4 Mobile PC Client - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 5, "Mobile"
Click to launch Click to launch

A3.4.1 Power and power management requirements

[ SYS-0002 »; MOBL-0062 »]

  • Every device in a mobile PC system functions fully on both AC and DC power.
    [see FAQ A3.5.8]
  • Mobile system implements either S1 or S3, S4, and S5 sleep states (no "wake from S3 or S4" requirement). [ SYS-0002.1 »]
  • Smart Battery or ACPI Control Method Battery. [ MOBL-0062 »; see FAQ A3.5.8]
  • Smart Battery systems that support battery calibration must use the Smart Battery System Manager optional calibrate support bits in the BatterySystemStateCont register. [ MOBL-0062.1 »]
  • Windows XP: Systems implementing processor performance states must use native Windows support. This means that all performance policy and switching must be done by the operating system. See "Windows XP Native Processor Performance Control" whitepaper at http://www.microsoft.com/hwdev/onnow/.
A3.4.2 BIOS requirements
  • Support for external pointing device. [ MOBL-0066 »; see FAQ A3.5.3 ]
  • Support PXE if system includes integrated network adapter. [BIOS-0014.1 »; see FAQ A3.5.7 ]
A3.4.3 Connector icons on back of case, wrapped to the bottom of the unit, or placed inside an access door

Color-coding is not required.

A3.4.4 Mobile system contains required devices and buses

[MOBL-006x]

  • Integrated keyboard and pointing devices use standard system-board devices; add-on devices meet Windows Logo requirements. [ MOBL-0066 »]
  • External mouse support uses a connector other than a serial port. [SYS-0042 »; INPT-0135 »]
  • One USB port free for end-user expansion. [ MOBL-0063 »]
  • One 32-bit Type-2 CardBus slot. [MOBL-0065 »; SYS-0024 »]
  • System maintains mapping of IRQ Routing Register bits to system interrupt vectors for CardBus. [PCCard-4 »; SYS-0024 »]
  • IRQ connections for CardBus can be determined by using the 0805 register. [ PCCard-5 »; SYS-0024 »]
  • Integrated graphics device minimum requirements:

2-D hardware acceleration, 640 × 480, low-resolution modes. [GRPH-0393.1 »]

If 3-D is supported, 640 × 480 × 16 bpp; no minimum texture cache, alpha blending, hardware text mapping requirements. [ GRPH-0393.3, 0393.4 »]

No multiple adapter support required in mobile unit; multiple monitor support is optional. [ GRPH-0393.7 »; see FAQ A3.5.4]

Display Data Channel (DDC) monitor detection required only for external graphics interface. [ MOBL-0069.3 », GRPH-0393.6 »]

PCI or AGP 1.x or later. For systems supporting 3-D graphics hardware, performance equivalent of AGP 1x with GART is required. [GRPH-0393.2 »]

International Color Consortium (ICC) color profile and INF preinstalled if DDC detection cannot be used. [ MON-0235 »; see FAQ A3.5.5]

A3.4.5 ATA controllers and devices on mobile unit support ATA/33 or better

[STOR-0350 »]

A3.4.6 CD drive, if present, supports transfer rate of at least 1200 KB per second when fully on
A3.4.7 Docking station requirements

[MOBL-007x]

  • Docked mobile PC meets Mobile PC system and BIOS requirements. [ MOBL-0074 », MOBL-0076 »]
  • Docked mobile PC can uniquely identify the dock. [ MOBL-0073 »]
  • Docking station supports warm docking and fail-safe docking. [ MOBL-0079 »; MOBL-0080 »]
  • Enumerate, configure, and disable non-Plug and Play devices using ACPI-based methods. [ MOBL-0078 »]
  • Docked mobile PC meets BIOS requirement for multiple adapters and multiple monitors. [ MOBL-0076 »]
  • Docked mobile PC allows user speaker selection. [ AUD-0339 »; see also FAQ A3.5.9]
  • Discrete PCI ATA controllers in mobile docking stations implement in PCI Native-Mode ATA. [ ATA-0122 »]
A3.4.8 DELETED
A3.4.9 If mobile supports a docking station, mobile unit’s BIOS supports docking-related ACPI functions

[ MOBL-0078 »]

A3.4.10 If IEEE 1394 is included in a system, at least one externally-accessible socket is required

[MOBL-0064 »]


A3.5 Mobile PC Client - FAQs

A3.5.1 Current general FAQs

See http://www.microsoft.com/winlogo/hardware/system/.

A3.5.2 Manageability requirements [Clarification]

Current SMBIOS requirements are defined in A1.1.4.
FAQ Date: May 4, 2000

A3.5.3 BIOS support of external pointing device [Clarification]

[MOBL-0066 »]

The required default BIOS option is to provide an option to disable the internal pointing device when any external PS/2-type pointing device is detected at startup. In this case, the driver for the internal pointing device must not load.
FAQ date: October 7, 1998

A3.5.4 DDC monitor detection [Clarification]

[GRPH-0393.6 »]

Because of the power limitations placed on mobile computers, they are not required to supply + 5V power via the external graphics adapter as is currently required by the VESA DDC specification.

Some display devices rely on the +5 V to power their DDC circuitry, for Plug and Play detection, or both. It is recommended that a mobile PC provide a means to enable the +5 V power when necessary.
FAQ date: March 19, 1999

A3.5.5 ICC profile for mobile PCs [Clarification]

Current requirements are defined at B4.2.4.2; design guidelines are provided in PC 2001. [ MON-0235 »]

A3.5.6 DELETED
A3.5.7 BIOS support for PXE [Clarification]

[BIOS-0014.1 »]

Current requirements are defined in A1.1.4.

A3.5.8 Battery power requirements [Clarification]

Every device in a mobile PC system should function fully on both AC and DC power. It is not acceptable for hardware or system firmware to autonomously disable, remove, or force power down of devices on an AC > DC transition. This can cause situations that result in the system shutting down, lost data, operating system failure of subsequent power management events, or at the least, warning messages displayed to the user. Internal devices must only be powered down, disabled, or removed when commanded to do so by the operating system and device drivers in accordance with bus and device power management specifications.

This clarification does not require port replicators or docking stations to operate on battery power.
FAQ date: May 28, 1999

A3.5.9 Docking station/mobile audio [Clarification]

It is not required that a mobile/docking station pair implement audio. The following provides a clarification to the requirement:

The user must be able to select speakers in the mobile unit or the docking station. System vendors can choose to automate the process either in the docking station or the mobile PC to meet this requirement. For example, instead of offering a UI where the user can select speakers, the system manufacturer can configure the pair to automatically turn on the docking station speakers and turn off the mobile PC speakers when in the docked configuration.

This requirement is defined to ensure that users can access the highest quality audio output in any given configuration. If speakers are selected automatically, the vendor should prevent multiple outputs from occurring simultaneously. If speakers are not selected automatically, then a manual selection process must be offered to the user. Additionally, the speakers should be switched off if the headphone or line-out jacks are used.
FAQ date: December 22, 1998

A3.5.10 DELETED

FAQ date: January 31, 2001

A3.5.11 Docking Station and Port Replicator Definitions [Clarification]

Port Replicator: For the purposes of the Windows Logo Program, a Port Replicator physically mates to the Mobile PC and is an acceptable method for adding the following functionality to a mobile PC. All of the following features must be compliant with their respective Windows Logo Program requirements, specifications, and standards:

  • USB hub.
  • Power Supply (if needed).
  • Cable management by passing through the following connectors and buses:

Audio, including line-in, line-out, microphone, and headphone
DVI
Floppy drive
Game port
IEEE 1394 PHY
LAN
MIDI port
Modem
Parallel or LPT port
PS/2 port
Serial port
USB connector: pass-through connector is allowed to be low power
Video
Any bus used exclusively for manageability

Docking Station: For the purposes of the Windows Logo Program, a Docking Station connects to the mobile PC’s PCI bus and includes the functionality of a Port Replicator plus additional expansion in the form of Plug and Play-enumerable devices or slots.
FAQ date: October 6, 2000


A3.R Mobile PC Client - Future Requirements

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


A4.0 Legacy-Free PC System Requirements

This section describes additional requirements or exceptions to the requirements defined earlier in Section A1.0.

A4.1 Legacy-Free PC System - Windows Compatibility

A4.1.1 ACPI legacy-free support is reported as described in "ACPI Changes for Legacy Free"

[BIOS-0015 »; SDG3:27, 28 »]
http://www.microsoft.com/hwdev/onnow/download/LFreeACPI.doc

  • LEGACY_DEVICES flag is set to 0 in the ACPI FADT as defined in ACPI section 5.2.1.
  • ACPI reset mechanism as defined in ACPI section 4.7.5.
  • 8042 flag is set to 0 in systems that do not include an 8042 controller; value is set to 1 in a mobile or desktop system that includes an 8042 controller.
  • Debug Port Table in the BIOS, as described in ACPI section 5.2.11.
A4.1.2 Plug and Play detection does not report the presence of Super I/O-dependent components

Based on addresses and exceptions listed in A4.1.3.

A4.1.3 No components claim to use the restricted port addresses

[BIOS-0045 »]

Restricted addresses:

COM = 2E8-2EF, 2F8-2FF, 3E8-3EF, 3F8-3FF
LPT = 278-27A, 378-37A, 3BC-3BE
Sound Blaster = 0220-022F
Joystick/game port = 0x200-0x20F
MPU-401 (MIDI) = 0330-0331
FDC = 3F0-3F7
Keyboard/mouse controller = 0060, 0064

The following exceptions apply:

  • An internal COM port header can be used as a debug port solution if the COM port is not exposed to the end user and does not use the I/O addresses listed in this table; these listed addresses must be claimed in the BIOS but not used. The relocated I/O address must be reported in the ACPI Debug Port table.
  • Systems that use the 8042 controller internally can use the related restricted addresses if the 8042 flag is set to 1 in the ACPI FADT. The 8042 flag must be set to 0 in systems that do not include an 8042 controller.
  • Systems can provide Super I/O-based IrDA support through the year 2001. Both desktop and mobile PCs can use the 8042 controller internally, but must not include external PS/2 connectors. Legacy-free systems that use the 8042 controller internally must set the 8042 flag to 1 in the ACPI FADT.
  • Windows Me: A system that does not have an 8042 controller must reserve I/O addresses 0060 and 0064 as reserved motherboard resources. Failure to reserve these I/O addresses will result in display of a false device in Device Manager.
A4.1.4 Support required interrupts

[BIOS-0043 »]

Required interrupts:

INT 8, INT 9, INT 10, INT 11, INT 13, INT 19, INT 1B, and INT 23
INT 15 subfunctions AH=C0, 4F, 87, 88 and AX=C2xx, E820, E801
INT 16 subfunctions AH=00h, 01h, 02h, 10h, 11h, 12h
INT 1A subfunctions AH=0x and AX=B1xx

See details in Table 2 at http://www.microsoft.com/hwdev/NewPC/LF.htm.

A4.1.5 Legacy-free debug interface per Debug Port Specification and FAQ A1.5.16

[SYS-0046 »; SDG3:15 »; FAQ A1.5.16]

A4.1.6 When 8042 is not present, A20M# is de-asserted (pulled high) or removed, with no way to mask the A20 address line

[ SYS-0047 »]

If A20M# generation logic (8042) is not present in the system, A20M# must be terminated in a deasserted state to the processor. If 8042 is present, connect in the standard legacy manner.

A4.1.7 Interrupt handlers preserve values in all registers

As described in A1.4.9.

A4.1.8 BIOS initializes USB Host Controller during boot process

The USB host controller must be in IRQ mode for keyboard and mouse input during real mode and safe mode. However, this can potentially cause the system to stop working when the system is running Windows 2000 if the interrupt is shared with the boot device and the host controller generates an IRQ before the USB ISR is chained.

The solution is for the BIOS to add logic to the ACPI Enable routine to turn off the IRQ-enable bit in PCI Config space for the USB host controller.


A4.2 Legacy-Free PC System - Industry Standards

A4.2.1 "ACPI Changes for Legacy-Free PCs"

[BIOS-0015 »; SDG3:27 »]
http://www.microsoft.com/hwdev/onnow/download/LFreeACPI.doc

A4.2.2 Debug Port Specification, V. 1.0 or later

[SYS-0046 »; SDG3:15 »]
http://www.microsoft.com/hwdev/NewPC/debugspec.htm


A4.3 Legacy-Free PC System - Quality

WHQL Test Specification References:
Chapter 18, Legacy-Free Test Specification
Click to launch Click to launch

See A1.3.

A4.3.1

See A4.4.9

A4.3.2

See A4.4.10


A4.4 Legacy-Free PC System - Windows Experience

Design Guideline References:
http://www.microsoft.com/hwdev/NewPC/LF.htm.
PC 2001 System Design Guide, Chapter 3 - Click to launch Click to launch

New docking stations designed for legacy-free mobile PCs must follow these requirements.

A4.4.1 No external serial, parallel, or PS/2-compatible ports and no ISA-based game ports or MPU-401 (MIDI) ports available for external connection or detected by the operating system

[BIOS-0045 »; see also FAQ A4.5.2]

A4.4.2 Two USB ports in all desktop systems

See also A2.4.1.

If only two USB ports are provided, system provides at least one accessible USB port supporting end user expansion when keyboard and pointing device are attached.

Mobile PC Note: A mobile PC must provide at least one accessible USB port [MOBL-0063 »]

A4.4.3 System includes a bootable CD or DVD device

[BIOS-0005.1 »; SYS-0039 »; MOBL-0072]

Mobile PC Note: See FAQ A4.5.3.

A4.4.4 No FDC detected

[SYS-0040 », BIOS-0045 »]

A4.4.5 DELETED

See A1.4.8.

A4.4.6 Peripherals provided with the system use non-legacy connectors and do not depend on real mode for installation or configuration

[WL-5; SYS-0042 »]

Keyboard and mouse must also use non-legacy interfaces.

A4.4.7 External input devices included with the system are HID compliant

[INPT-0133 »]

For example, keyboard, mouse, or game controller.

A4.4.8 MS-DOS is not required to install or run any utilities, games, or other software provided with the system

[SYS-0042 »]

Exception: Software on the recovery CD provided for Windows Me.

A4.4.9 No BIOS boot dependencies on ISA or other legacy devices, and no ISA-related components appear on BIOS setup screen

[BIOS-0013 »]

A4.4.10 BIOS supports USB input devices at boot, and does not include hardware emulation of the 8042 controller in systems where no 8042 controller is present

See details in Table 2 at http://www.microsoft.com/hwdev/NewPC/LF.htm or in Appendix A of PC 2001 ».


A4.5 Legacy-Free PC System - FAQs

A4.5.1 Current general FAQs

See http://www.microsoft.com/winlogo/hardware/system/.

A4.5.2 Early legacy-free systems [Clarification]

Removal of legacy components from the system involves two considerations:

  • The component is removed from the user’s perspective -- for example, slots, ports, and so on.
  • The operating system doesn't detect the presence of the component.

For example, "No FDC" means that the operating system does not detect the presence of the FDC and nothing uses the related restricted addresses.

However, the physical internal part does not need to be removed -- for example, removal of the Super I/O chip is not required; however, the physical ports must not be present on the system or detected by the operating system.

A4.5.3 CD or DVD drive requirement [Clarification]

For legacy-free mobile PCs, form-factor/size issues may preclude providing a built-in CD or DVD drive. In such cases, the requirement to include a CD or DVD drive can be met by offering external CD/DVD products that the user can choose to purchase separately and that attach to the mobile PC, docking system, or port replicator through an interface that allows the CD or DVD drive to act as a boot device.

In addition, systems designed to exclude user access to removable media do not have to meet the requirement to include a CD or DVD device. However, all systems (including those that do not ship with a CD or DVD device) must still comply with the requirement for BIOS boot support.
FAQ date: September 1999

A4.5.4 Debug solutions for Non-Legacy PCs [Clarification]

See FAQ A1.5.16.


A4.R Legacy-Free PC System - Future Requirements

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


A5.0 Itanium-based System Requirements

This section describes additional requirements or exceptions to the requirements defined earlier in Section A1.0.
For desktop systems, all applicable requirements in A2.0 are included by reference.
For server systems, all applicable requirements in A6.0 are included by reference.

A5.1 Itanium-based System - Windows Compatibility

A5.1.1 Windows DDK: "64-Bit Issues"

[SYS-0058 »; SDG3:68 »]

A5.1.2 "Porting Your Driver to 64-Bit Windows" and other 64-bit implementation guidelines for Windows

http://www.microsoft.com/hwdev/64bitWindows/

A5.1.3 Windows Whistler Server, 64-bit Edition: Standard Error Record Format passed by the SAL to the operating system

All Error Records passed by the System Abstraction Layer (SAL) to the operating system for all fatal and corrected CPU and Platform Machine Check Architecture (MCA) Events must be, at a minimum, compliant with the Itanium Processor Family System Abstraction Layer Specification (SAL 3.0). The SAL must maintain the Error Records in non-volatile storage across system reboots and power cycles. See Appendix B, "Error Record Structures," in SAL 3.0 specification, dated January 2001.

A5.2 Itanium-based System - Industry Standards

A5.2.1 Advanced Configuration and Power Interface Specification, V. 2.0

[SYS-0002 »; SDG3:9 »]
http://www.teleport.com/~acpi/

A5.2.2 Extensible Firmware Interface Specifications

[SDG3:14 »]
http://developer.intel.com/technology/efi/download.htm

A5.2.3 EFI-related specifications and guidelines

http://www.microsoft.com/hwdev/efi/
Including:
Microsoft Extensible Firmware Interface FAT32 File System Specification
Microsoft Extensible Firmware Interface Long File Name Specification
Microsoft Portable Executable and Common Object File Format Specification

A5.2.4 Intel Itanium Processor Family System Abstraction Layer Specification (SAL 3.0)

http://developer.intel.com

A5.3 Itanium-based System - Quality

WHQL Test Specification References:
Chapter 2: EFI Test Specification;
Plus technology-specific test specifications
Click to launch Click to launch

See A1.3.

A5.3.1 Pass Windows Logo Program testing for Itanium-based products

Product is submitted to the appropriate WHQL test program and passes all testing for the Windows Logo Program for hardware as described in detail in the WHQL Test Specification and the Microsoft Windows Hardware Compatibility Test Kit 10.0 documentation.

A5.4 Itanium-based System - Windows Experience

A5.4.1 Comply with ACPI 2.0

[ SDG3:2.3 »]

To comply with this requirement, implement the ACPI 1.0b backward-compatible portion of ACPI 2.0, plus the 64-bit fixed tables. The fixed tables that must be supported include:

  • RSDP Structure
  • Extended System Description Table (XSDT)
  • Fixed ACPI Description Table (FADT)
  • Firmware ACPI Control Structure (FACS)
  • Multiple APIC Description Table (MADT)

Itanium-based platforms must use the new Extensible Firmware Interface (EFI) GUID for the ACPI 2.0 RSDP Structure (see Section 5.2.4.2 in ACPI 2.0). The EFI GUID for the ACPI 2.0 RSDP Structure pointer is:

8868E871-E4F1-11d3-BC22-0080C73C8881

Future wakeup requirements for Itanium-based systems are defined at A5.R.1.

Note: Windows XP and Windows Whistler Server are not fully ACPI 2.0-compliant operating systems. The ACPI 2.0 Specification was written to be fully backward compatible with ACPI 1.0b.

A5.4.2 Comply with EFI 1.0, with support for USB boot devices, firmware update, and PXE_BC, SERIAL_IO, and SIMPLE_NETWORK protocols, plus Hardware Design Guide guidelines

[ SDG3:14 », SDG3:150.2 »]

See also: A1.1.4 - Support booting from CD or DVD device per El Torito v. 1.0 No Emulation mode.

A5.4.3 Provide serial port to use as debug port, using either 2F8h or 3F8h

[ SDG3:15.2 »]

A5.4.4 Provide SAPIC support

[ SDG3:25 »]

Implemented per Multiple APIC Description Table (MADT) (ACPI 2.0, Section 5.2.10.4).

A5.4.5 Provide 64-bit support in PCI subsystem

[ SDG3:31, 32 », 53 »]

See also:

  • A1.1.4 Provide PCI interrupt routing information per ACPI 2.0 Section 6.2.8.
  • B2.5.1.7 Adapters address full physical address space on a 64-bit platform; 32-bit PCI adapters used on the primary data path support the PCI DAC command, with the exception of 10/100 Ethernet devices.
A5.4.6 Provide correct device support, per Hardware Design Guide

[SDG3:Chapter 3]

A5.4.6.1 System does not include parallel port

[ SDG3:71 »]

Note: 64-bit Windows does not provide native legacy parallel port support.

A5.4.6.2 Primary graphics adapter supports 800x600x256 color and complies with VESA timing standards

[ SDG3:75 »]

A5.4.6.3 Server with no 8042 or other port 60h and port 64h based keyboard controller meets Hardware Design Guide requirements

[ SDG3:27,28 »]

A5.4.7 Provide GPT-partitioned hard drive for boot

[ SDG3:151-157 »]

A5.4.8 - A5.4.10 DELETED
A5.4.11 System includes 1 GB memory, minimum

[ WL-2]

A5.4.12 System that provides headless server capabilities meets minimum requirements

[SDG3:19, 20, 21, 22, 13.4, 14.4 »; see also A6.4.5]

A5.5 Itanium-based System - FAQs

See http://www.microsoft.com/winlogo/hardware/system/.

A5.R Itanium-based System - Future Requirements

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

A5.R.1 Server that supports S1-3 meets general Windows Logo Program power management requirements

[ SDG3:10 »]

Note: 64-bit Windows (Professional and Server) does not currently support power management; power management may be added in a future operating system release.

A5.R.2 Future version of Windows Professional 64-bit Edition: Standard Error Record Format passed by the SAL to the operating system

All Error Records passed by the SAL to the operating system for all fatal and corrected, CPU and Platform MCA Events must be, at a minimum, compliant with SAL 3.0. The SAL must maintain the Error Records in non-volatile storage across system reboots and power cycles.


A6.0 Server System Requirements

This section describes additional requirements or exceptions to the requirements defined earlier in Section A1.0.

For Itanium-based server systems, all requirements in A5.0 are included by reference.

A6.0.1 System Exceptions and Notes for Servers

In addition to the requirements defined in A6.0, the following additional notes and exceptions are defined elsewhere in Appendix A:

  • A1.4.2 Correct implementation of power management – for server systems, network adapters and other peripherals are not required to support wake from D3.
  • A1.4.5 Servers and server components are not required to follow accessibility guidelines.
  • A1.4.10 Servers do not have to provide "digital ready" audio.
A6.0.2 Device Exceptions and Notes for Servers

In addition to the requirements defined in A6.0, the following additional notes and exceptions are defined elsewhere in Appendix B:

  • B6.1.4.10 Windows Whistler Advanced Server: Data modem supports digital connection to support host-side V.90 operation.
  • B7.1.4.1 Windows Whistler Server:
  • Adapter supports filtering for at least 32 multicast addresses.
  • Adapter and driver support multicast promiscuous mode.
  • B7.1.4.12 Windows Whistler Server: Additional adapter and driver support.
  • B7.1.5.3 PCI adapters to support the PCI DAC.
  • B10.4.4.5 Windows Whistler Server: SCSI and Fibre Channel hard drives implement complete identification strings.
  • B10.4.4.4 Windows Whistler Server: Hot-swappable drive, if provided, includes a local disk drive replacement indicator.
  • B10.7.4.3 Single-backup device meets minimum capacity requirements.
  • B10.9 RAID requirements.
  • B10.10 Fibre Channel requirements.

A6.1 Server System - Windows Compatibility

See A1.1

A6.1.2 If legacy components have been removed, system includes correct FADT table entries and necessary ISR support for boot

[ SDG3:27,28 »]

Legacy component include 8042 or 60h/64h keyboard controller.
See also A4.1.1.

A6.2 Server System - Industry Standards

See A1.2.

A6.3 Server System - Quality

WHQL Test Specification References:
Chapter 22: Driver Quality Test Specification
Chapter 24: Cluster Test Specification
Chapter 27: WinSock Direct Test Specification
Chapter 29: Headless Test Specification
Chapter 30: Datacenter Server Test Specification
Plus technology-specific test specifications
Click to launch Click to launch

See A1.3.

A6.3.1

See A6.4.1

A6.3.2 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 Whistler Server and Advanced Server: Pass tests in HCT 10.0 (or later), as described in detail in the WHQL Test Specification and the Microsoft Windows Hardware Compatibility Test Kit 10.0 documentation.

See "Server Testing Overview" in the HCT documentation.

  • Windows 2000, Windows NT 4.0: Pass tests in HCT 9.502, as described in the HCT documentation.

A6.4 Server System - Windows Experience

A6.4.1 Server supports additional requirements for PCI

[ SDG3:32,39,48 »]

  • Server that supports more than 4 GB of memory supports a 64-bit PCI bus architecture. [ SDG3:32 »]
  • All 66-MHz and 64-bit PCI buses in a server system comply with PCI 2.2 and other requirements. [ SDG3:48 »]
  • PCI devices do not use the <1 MB BAR type. [ SDG3:39 »]
A6.4.2 Server includes USB controller with at least one USB port

[ SDG3:56-61 »; see also B2.6.2 ]

With firmware, device, and driver support compliant with the USB specifications.

USB hubs, if used, must be self-powered.

A6.4.3 DELETED
A6.4.4 All memory visible to the operating system as system memory is cacheable; system memory includes ECC memory protection

[ SDG3:7 »]

All system memory except for 4 MB must be completely available for the system to use at boot time and cannot be locked from use by the operating system.

Minimum system memory requirements for servers are defined in WL-2.

A6.4.5 System that provides headless server capabilities meets minimum requirements

[ SDG3:19, 20, 21, 22 », SDG3:13.4 »]

A6.4.6 Server system supports additional required devices and subsystem capabilities

[SDG3]

  • Logo-compliant network adapter. [SDG3:77 »]
  • Primary graphics adapter, if present on an x86-based system, supports 800x600x256 color and VESA timing standards. [SDG3:76 »]

VGA-compatible devices must not use non-video I/O ports. [ SDG3:41 »]

  • CD or DVD drive or other method for installing the operating system and emergency repair support. [SDG3:184 », 74 »]
  • Parallel port design, if present on an x86-based system, provides sufficient space for connector assembly. [ SDG3:207 »]

No ECP support required for parallel ports on servers. [SDG3:72 »]

  • Windows Whistler Advanced Server: System includes SCSI or Fibre Channel host controller and peripherals. [ SDG3:161 »]
  • Windows Whistler Advanced Server: System designed for deployment with MSCS clustering does not use ATA host controller or peripherals. [ SDG3:175 »]
A6.4.7 Server system additional required capabilities

[SDG3:21x]

  • Replacement of power supplies. [ SDG3:213 »]
  • Replacement of fans. [ SDG3:214 »]
  • Intelligent RAID controller with adequate storage capacity, supporting at least one of RAID 1, 5, or 1/0 (for servers designed for deployment with MSCS clustering). [ SDG3:217, 218 »]
  • Windows Whistler Advanced Server:
  • Local hot-swap power supply replacement indicators. [ SDG3:215 »]
  • Support for multiple hard drives. [ SDG3:216 »]
  • Protected forced dump switch or other mechanism for system diagnosis. [ SDG3:222 »]
  • Alert indicators for occurrence of failure and imminent failure. [ SDG3:223, 225 »]
A6.4.8 Server that supports Winsock Direct (WSD) connectivity meets requirements

[ SDG3:67 »]

  • Reliable transport through combination of WSD hardware and software.
  • Hardware, software, and driver support to facilitate access via fast alternate paths.
  • Hardware has page tables to translate user addresses to physical addresses.

A6.5 Server System - FAQs

See http://www.microsoft.com/winlogo/hardware/server/.

A6.R Server System - Future Requirements

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

A6.R.1 InfiniBand fabric connections, fabrics, and devices, if present, meet requirements for device and driver support

[ SDG3:55 »]

A6.R.2 Sever: Network adapter offloads TCP/IP checksum, IP Security encryption, and TCP message segmentation

[ SDG3:91 »]

Server-side network adapters should support task-offload mechanisms to offload TCP/IP checksum calculation, IP Security encryption, and TCP message segmentation to intelligent hardware.


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/

Note that testing for all Windows versions must also include logs for Windows XP/Windows Whistler Server, even if the specific "Designed for Windows" you are seeking does not target Windows XP or Windows Whistler Server.

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

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.

B1.1 General Device/Driver - Windows Compatibility

B1.1.1 Device drivers comply with Windows DDK requirements

Including DDKs for Windows XP, Windows 2000, Windows Me, and Windows 98.

Third-party applications implemented as defined in the Microsoft Platform SDK.

B1.1.2 OnNow and ACPI compatibility and implementation notes

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

B1.1.3 WDM driver implementation notes (for device classes supported under WDM)

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


B1.2 General Device/Driver - Industry Standards

B1.2.1 Advanced Configuration and Power Interface Specification (ACPI)

http://www.teleport.com/~acpi/tech.htm

B1.2.2 Device Class Power Management Reference Specifications

http://www.microsoft.com/hwdev/specs/Pmref/

B1.2.3 Plug and Play specifications

[ SYS-0026 »; SDG3:16 »]
http://www.microsoft.com/hwdev/respec/pnpspecs.htm
Legacy Plug and Play Guidelines »

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
Click to launch Click to launch

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:

  • Windows XP: Pass tests in HCT 10.0 (or later), as described in detail in the WHQL Test Specification and the Microsoft Windows Hardware Compatibility Test Kit 10.0 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.
B1.3.2 Windows XP/Windows 2000: Vendor-supplied drivers pass Driver Verifier test
B1.3.3 Device driver installs via an INF; tested via INFCatReady.exe

Windows XP/Windows 2000: "Creating an INF File" in the Windows DDK.

Windows 98/Me: "Installers, Device Manager, and Control Panel" in the Windows Me DDK.

B1.3.4 Vendor-supplied drivers have digital signatures

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

WHQL guidelines and processes for digital signatures are defined at http://www.microsoft.com/hwtest/signatures/.


B1.4 General Device/Driver - Windows Experience

Design Guideline References:
PC 2001 System Design Guide - Chapter 3, "PC System" - Click to launch Click to launch
Hardware Design Guide 3.0 for Windows 2000 Server, Chapter 2 - Click to launch Click to launch

B1.4.1 Device can be enumerated and automatically disabled

[ SYS-0027 », SYS-0029.3 »; SDG3:17 »]

Device ID is present, device is properly enumerated, and correct driver is found; device can be disabled automatically by Windows.
(see additional notes in specific device-class requirements).

B1.4.2 Software does not replace or bypass system components

[ SYS-0025 »; SDG3:68 »]

Driver or software installation must not replace any Microsoft-authored operating system components, and the driver must not bypass any operating system components.

Windows XP: Notice that each Windows XP/Windows Whistler Server product has a unique set of files protected under system file protection; for information about operating system files protected in Windows XP, 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 Installing and loading the driver does not reduce or eliminate functionality of other devices installed on the system

[ SYS-0025.1 »; SDG3:68 »]

B1.4.4 Device is functional without restarting the system

[SYS-0029.1 »]

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

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

[ SYS-0002 »; SDG3:10 »]

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).

  • Windows 2000/Windows Me: Graphics adapter and all other devices correctly implement D3 state such that the operating system can correctly hibernate and resume from all sleep states supported on the system.
  • Any PCI devices that support wakeup capabilities correctly support wake from D3cold.

Network adapters installed in mobile PCs, servers, and other special cases are not required to support wakeup, see B7.1.4.4 for details.

  • Windows XP client: Uniprocessor desktops that run Windows XP are required to support S3; therefore, 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.

The device must be fully functional upon resume from S3.

B1.4.6 Driver supports unattended installation

[WL-4; SDG3:68.5 »]

It must be possible to install the driver using a script or special software for supplying required parameters without the user being present during driver installation.

B1.4.7 Windows Help file is provided if special driver parameters are used

[WL-4; SDG3:68.6 »]

B1.4.8 Hardware management instrumentation, if implemented, is provided per WHIIG

[ BIOS-0014.3 »; SDG3:229 »]
http://www.pcdesguide.org/whiig.htm

B1.4.9 Device has an icon on any external connectors

[ WL-7]

Color-coding is not required. [see FAQ A1.5.9]

B1.4.10 Any supporting software included with the device is installed using Windows-based installation methods, without any manual steps or file editing

All software used for installing device support or that runs with the device must be 32-bit or 64-bit Windows-based applications; no console applications (16-bit or 32-bit) are allowed.
[see FAQ B1.5.2 ]

B1.4.11 Software installed as part of device driver installation can be removed using Windows-based software

[SYS-0025.6 »; SDG3:68.4 »]

At a minimum, any "virtual drivers" and software components (such as control panel applets) installed with the driver must be capable of being removed.


B1.5 General Device/Driver - FAQs

B1.5.1 Current general FAQ

See http://www.microsoft.com/winlogo/hardware/general/.

B1.5.2 Windows 98/Me: Display Class and Other 16-bit Windows Software [Clarification]

A 16-bit Windows device driver or application must not load Setupx.dll every time the driver is loaded. Besides wasting memory, this exposes a problem when another application calls Setupx.dll, causing an invalid temp folder to be returned and prompting the user for an installation location. Testing at Microsoft has revealed this problem with display adapter drivers, some modem drivers, and some applications installed with drivers, such as status utilities that appear in the System Tray.

For Windows 98/Me, see "Graphics Device Interface" in the Windows Me DDK documentation for information about implementing driver setup functions in a separate installer to be used only during installation, instead of containing setup functions in the driver itself.

This clarification is related to the Windows Logo Program requirement that installation and loading of a driver must not interfere with other components on the system. As of July 1, 2000, this is part of Windows Logo Program compliance testing.
FAQ date: December 22, 1999


B1.R General Device/Driver Quality - Future Requirements

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

B1.R.1 Applications meet "Designed for Windows XP Application Specification" requirements

If a retail device product included any additional standalone software that was not tested with the device submission (for example, a printer that ships with a paint program), that software must meet the requirements for either the "Designed for Windows" Application Logo at http://www.microsoft.com/winlogo/software/ or the "Certified for Windows" logo at http://www.msdn.microsoft.com/certification/ if the product packaging is to display the "Designed for Windows" logo.


B2.0 Bus/Device Controllers

B2.1 CardBus/PCMCIA Controllers and Devices

All general requirements in B1.0 are included by reference.

B2.1.1 CardBus/PCMCIA Controllers and Devices - Windows Compatibility

B2.1.1.1 Windows XP/Windows 2000: : "PCMCIA_INTERFACE_STANDARD Interface Memory Card Routines" in the Windows DDK
B2.1.1.2 Windows 98/Me: "PCMCIA Device Drivers" in the Windows Me DDK
B2.1.1.3 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/cardbus/
"Design Guidelines for PC Card and CardBus" at http://www.pcdesguide.org/library/pccard.htm or in PC 2001 System Design Guide).

B2.1.1.4 CardBus Host Controllers and Windows Compatibility

http://www.microsoft.com/hwdev/busbios/CARDBUS1.HTM

B2.1.1.5 PC Card Voltage Requirements for Windows Operating Systems

http://www.microsoft.com/hwdev/cardbus/pccardvlt.htm (implementing R2 version cards to use only 3.3 V)

B2.1.1.6 Windows XP/Windows 2000: Legacy PCI Interrupt Routing and CardBus in Windows 2000

http://www.microsoft.com/hwdev/cardbus/Spir.htm

B2.1.1.7 Windows 98/Me: Explanation of CardBus Registry Entries in Pcmcia.inf

http://support.microsoft.com/support/kb/articles/q201/0/18.asp

B2.1.2 CardBus/PCMCIA Controllers and Devices - Industry Standards

B2.1.2.1 PC Card Controller Device Class Power Management Reference Specification, V. 2.0

[PCCard-17 »; SYS-0024 »; SDG3:148 »]
http://www.microsoft.com/HWDev/specs/PMref/PMcard.htm

B2.1.2.2 PC Card Standard Guidelines

[ PCCard-1, 14 »; SYS-0024 »; SDG3:148 »]
http://www.pc-card.com/bookstore.htm

B2.1.2.3 PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges

[ PCCard-19 »; SYS-0024 »; SDG3:148 »; see also FAQ B2.1.5.3]

Provided in Volume 11, PC Card Standard, Release 7, http://www.pcmcia.org/bookstore.htm.

B2.1.2.4 PCI to PCMCIA CardBus Bridge Register Description

http://www.pc-card.com/bookstore.htm

B2.1.3 CardBus/PCMCIA Controllers and Devices - Quality

WHQL Test Specification References:
Chapter 14: PC Card Test Specification
Click to launch Click to launch

B2.1.3.1 Pass WHQL tests

See B1.3.

Windows XP: See "CardBus/PCMCIA Controllers" and device-specific topics in the HCT documentation.

B2.1.4 CardBus/PCMCIA Controllers and Devices - Windows Experience

Design Guideline References:
Design Guidelines for PC Card and CardBus »

B2.1.4.1 Controller complies with industry standards and Windows-compatible configuration

[PCCard-x; SYS-0024]

  • Exchangeable Card Architecture register set. [ PCCard-3 »; SYS-0024 »]
  • CardBus bridges. [PCCard-7 »; SYS-0024 »; see also FAQ B2.1.5.4]
  • ISA and PCI interrupts. [ PCCard-6 »; SYS-0024 »; see FAQ B2.1.5.2]
  • Writeable PCI Configuration Space bits are not shared. [ PCCard-9 »; SYS-0024 »]
  • Each 16-bit PC Card memory window has it own page register. [ PCCard-10 »; SYS-0024 »]
B2.1.4.2 CardBus cards are configured correctly

[ PCCard-14-16 »; SYS-0024 »]

B2.1.4.3 16-bit PC Cards are configured correctly; driver supports sharing of level-mode interrupts

[ PCCard-11-13 », PCCard-18; [ PCCard-23 »; SYS-0024 »]

B2.1.4.4 No user intervention; no system restart occurs when installing devices, except when required by the operating system

[PCCard-20, 21 »; SYS-0024 »]

B2.1.4.5 ZV-compatible 16-bit PC Cards comply with ZV standard definitions, and driver uses DirectDraw VPE

[ PCCard-2 », PCCard-22 »; SYS-0024 »]

B2.1.4.6 CardBus controller designed to support wake-from-D3cold supports PME# assertion from D3cold, and socket supplies Vaux power to cards in D3cold state

[ SYS-0024 »; see FAQ B2.1.5.3 ]

B2.1.5 CardBus/PCMCIA Controllers and Devices - FAQs

B2.1.5.1 Current PC Card/CardBus FAQs

See http://www.microsoft.com/winlogo/hardware/cardbus/.

B2.1.5.2 CardBus controllers support ISA and PCI interrupts [Clarification]

[PCCard-6 »; SYS-0024 »; SDG3:148 »]

To ensure that the Windows operating system can correctly assign ISA IRQs to 16-bit PC Cards, A CardBus controller with parallel ISA IRQ mode must have all ISA IRQs pins, except IRQ 0 (timer), 1 (keyboard), 6 (floppy), 8 (CMOS), and 13 (math coprocessor).

It is recommended that system vendors using parallel ISA IRQ mode always connect ISA IRQs 3, 4, 5, 7, 9, 10, 11, 12, 14, 15 and not cross wire them.

For vendors using serialized IRQ mode, the above is not relevant because they only need to connect the serial IRQ pin, and the ISA IRQ information will be sent to the PCI chip set serially; the ISA IRQ information can specify any of IRQ 0-15.
FAQ date: May 28, 1999

B2.1.5.3 Windows 2000: CardBus controllers and PCI bus power management [Clarification]

[PCCard-19 »; SYS-0024 »; SDG3:148 »]

CardBus cards (which are by definition PCI devices) must comply with PCI Bus Power Management Interface Specification, Revision 1.1 or later, in order for power management to be implemented properly under Windows XP/Windows 2000, which uses PME# as the wake-up signal. This is the only industry specification that ensures compatibility with the power management capabilities of Windows XP/Windows 2000.
FAQ date: October 7, 1998

B2.1.5.4 PC Card Bridge header types [Correction]

[ PCCard-3 »; SYS-0024 »]

PC Card and CardBus Guidelines, Version 1.1, is incorrect; it should also list header type 02h in addition to type 82h, which is listed as an acceptable header type for CardBus bridges.
FAQ date: February 28, 2001

B2.1.R CardBus/PCMCIA Controllers and Devices - Future Requirements

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


B2.2 IEEE 1394 Controllers and Devices

All general requirements in B1.0 are included by reference.

B2.2.1 1394 Controllers/Devices - Windows Compatibility

B2.2.1.1 WDM support for devices that use the IEEE 1394 bus

"IEEE 1394 Structures" in the Windows DDK.

B2.2.1.2 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/1394/

B2.2.1.3 Plug and Play Specification for IEEE 1394

[ 1394-0096 »]
http://www.microsoft.com/hwdev/respec/pnpspecs.htm#1394

B2.2.1.4 IEEE 1394 Support in Windows 98 and Windows XP/Windows 2000

http://www.microsoft.com/hwdev/busbios/1394support.htm

B2.2.2 1394 Controllers/Devices - Industry Standards

B2.2.2.1 Windows 98/Me/Windows XP: 1394 Open Host Controller Interface Specification, Revision 1.0

[ 1394-0091 »; SDG3:159 »]
ftp://ftp.austin.ibm.com/pub/chrptech/1394ohci/ohcir100.pdf

B2.2.2.2 1394 Trade Association Power Specification, Part 1: Cable Power Distribution; 1394 Trade Association Power Specification, Part 3: Power State Management

[ 1394-0102, 0103 »; see also FAQ B2.2.5.2]
ftp://ftp.p1394pm.org/pub/p1394pm/

B2.2.2.3 IEEE 1394 Standards

[ 1394-0090 »]

  • IEEE 1394-1995 or later standards, and IEEE 1394a.
  • IEEE 1212-1991 and function discovery in IEEE 1212r
    Global Engineering Documents at http://global.ihs.com/.
B2.2.2.4 IEEE 1394 devices comply with appropriate industry-recognized transport and command standards

[ 1394-0094 »; 1394-0100 »]

  • IEC 61883 Parts 1-6, including CIP (common isochronous packet) headers, CMP (connection management protocol), and FCP (function control protocol).
  • 1394TA AV/C 3.0 and the AV/C subunit family of specifications, including AV/C Digital Interface Command Set VCR Subunit Specification, V. 2.0.1.
  • National Committee for Information Technology Standards (NCITS) Serial Bus Protocol (SBP-2) transport protocols (ANSI NCITS 3.25-1998 [SBP-2).]
  • National Committee for Information Technology Standards (NCITS) T10, Reduced Block Commands (RBC).
  • National Committee for Information Technology Standards (NCITS) T10 Multimedia Command Set 2 (MMC-2).
  • Storage class devices must conform to the ANSI standards for SBP-2 with the appropriate command set: RBC or MMC-2.
  • Printing devices using the SBP-2 protocol must conform to the guidelines set in "SBP-2 Support and Windows 2000," available at http://www.microsoft.com/hwdev/print/sbp2_w2000.htm.

B2.2.3 1394 Controllers/Devices - Quality

WHQL Test Specification References:
Chapter 19: IEEE 1394 Test Specification
Click to launch Click to launch

B2.2.3.1 Pass WHQL tests

See B1.3.

Specifically see "IEEE 1394 Controllers" and device-specific topics in the HCT documentation.

B2.2.4 1394 Controllers/Devices - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 6, "Buses and Interfaces"
Click to launch Click to launch

B2.2.4.1 Windows 98/Me: Open HCI controllers and devices support advances defined in IEEE 1394a-1999

[ 1394-0095 »]

Including peak data rate requirements for Open Host Controller Interface.

B2.2.4.2 Device configuration ROM is correctly implemented

[ 1394-0098 »]

B2.2.4.3 Devices demonstrate interoperability with other devices

[ 1394-0096 »]

B2.2.4.4 Devices that initiate peer-to-peer communications support remote programming

[ 1394-0097 »]

B2.2.4.5 Devices use approved IEEE 1394 connectors and cables

[ 1394-0093 »]

B2.2.4.6 Self-powered devices propagate the power bus through each connector

[ 1394-0103 »]

B2.2.4.7 Vendor and model leafs support textual descriptor leaf format

[ 1394-0101 »]

B2.2.4.8 DELETED
B2.2.4.9 IEEE 1394-enabled system provides cable power source compliant with IEEE 1394a-1999

[ 1394-0090 »; see also FAQ B2.2.5.2]

B2.2.4.10 Support remote programming through a remote control interface

[ 1394-0097 »]

B2.2.4.11 A system with externally accessible sockets provides a method for connecting to devices that only support IEEE 1394-1995 or IEEE 1394a-2000

[ 1394-0093 »]

There must not be a mixture of IEEE 1394-like media socket types on the back panel.

B2.2.4.12 Descriptors are required for Vendor_ID and Model_ID entries in the Configuration Status Register (CSR) space

[ 1394-0101 »]

B2.2.5 1394 Controllers/Devices - FAQs

B2.2.5.1 Current IEEE 1394 FAQs

See http://www.microsoft.com/winlogo/hardware/1394/.

B2.2.5.2 Power management requirements [Logo clarification]

[1394-0090 »]

Devices and controllers are not required to comply with 1394 Trade Association Power Specification, Part 3: Power State Management. This standard version is required with the release of a future operating system.
FAQ date: May 28, 1999

B2.2.5.3 DELETED

FAQ Date: January 31, 2001

B2.2.R 1394 Controllers/Devices - Future Requirements

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

B2.2.R.1 Open HCI 1.1

http://www.microsoft.com/hwdev/1394/

B2.2.R.2 OHCI 1.1; host controller’s PHY supports data rates of S100 Mb/s, S200 Mb/s and S400 Mb/s

[ 1394-0091-0092 »]

As specified in IEEE 1394-1995 and IEEE 1394a-2000.

B2.2.R.3:Networking adapters must support Remote NDIS over SBP-2

[NET-0288 »; SDG3:88 »]


B2.3 Infrared/Wireless

All general requirements in B1.0 are included by reference.

B2.3.1 Infrared/Wireless - Windows Compatibility

B2.3.1.1 Windows XP/Windows 2000, Windows 98/Me: "IrDA Miniport NIC Drivers" and "Wireless WAN Objects" in the Windows DDK

[INPT-0146 »; SDG3:141 »]

B2.3.1.2 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/infrared/

B2.3.1.3 Windows XP/Windows 2000: IrDA Plug and Play Issues and Windows 2000

http://www.microsoft.com/hwdev/infrared/IrDAPnP.htm

B2.3.1.4 Windows XP/Windows 2000: IrTran-P, IrLPT, and IrDA Networking Support under Windows 2000

http://www.microsoft.com/hwdev/infrared/IrCOMM.htm

B2.3.2 Infrared/Wireless - Industry Standards

B2.3.2.1 IrDA documents - Serial Infrared Physical Layer Specification; Control IR Specification

[ INPT-0147 »; SDG3:141 »]
http://www.irda.org/

B2.3.3 Infrared/Wireless - Quality

WHQL Test Specification References:
Chapter 22: Driver Quality Test Specification
Plus technology-specific test specifications
Click to launch Click to launch

B2.3.3.1 Pass WHQL tests

See B1.3.

Windows XP: See "Bluetooth Controllers," "Infrared (IrDA) Controllers," and device-specific topics in the HCT documentation.

B2.3.4 Infrared/Wireless - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 7, "Input Devices"
Click to launch Click to launch

B2.3.4.1 Infrared (IR) device meets USB class specification for interfacing with IrDA Data and IrDA Control devices

[ USB-0081 »; SDG3:145 »]

See also IrDA Bridge Device Definition, 1.0 at http://www.usb.org/developers.

B2.3.4.2 System supports standard input speeds of 4 Mb/s

[ INPT-0148 »]

B2.3.4.3 System provides a separate, physically-isolated transceiver for each IR protocol supported

[ INPT-0149 »]

B2.3.4.4 Windows XP: Mobile PC IR devices, if implemented, support D0 and D3 states

[ MOBL-0152 »]

Mobile PC Note: As defined in Section 3.4 of ACPI 1.0b.

B2.3.4.5 Windows XP: Bluetooth wireless host controllers (radios with HCI) meet requirements

[BTH-0396, 0397 »]

  • Support Plug and Play on the applicable bus (for example, USB).
  • Support the Bluetooth H:1 specification for host controllers, including the mechanism for reporting the version supported.
  • Support the bus-specific transport class extensions (for example, H:2-H:4) where applicable.

See FAQ B2.3.5.1

B2.3.4.6 Windows XP: Bluetooth-connected peripherals meet requirements

[BTH-0398, 0399 »; see also FAQ B2.3.5.1]

  • Meet all device class-specific Windows Logo requirements (for example, Section B3.0 for audio, Section B5.1 for HID, Section B6.1 for modem, and so on).
  • Comply with all applicable Bluetooth specifications, including design-applicable usage profiles.
  • Support Bluetooth Simple Discovery Protocol (SDP) and the PnPInformation Service Class.

See FAQ B2.3.5.1

B2.3.5 Infrared/Wireless - FAQs

See http://www.microsoft.com/winlogo/hardware/wireless/.

B2.3.5.1 For systems that include Bluetooth, support Version 1.1 [Clarification]

After October 1, 2001, systems including Bluetooth host controllers, radios, or peripherals must comply with Specification of the Bluetooth System, Version 1.1.

The driver and firmware requirements in B2.3.4.5.and B2.3.4.6 will not be enforced until three months after release of the Microsoft’s standard Version 1.1 Bluetooth stack. After this three-month transition period, Bluetooth driver submissions must use the standard Microsoft Version 1.1 stack.
FAQ date: May 08, 2001

B2.3.R Infrared/Wireless - Future Requirements

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


B2.4 Parallel/Serial Devices

All general requirements in B1.0 are included by reference.

B2.4.1 Parallel/Serial Devices - Windows Compatibility

B2.4.1.1 Windows XP/Windows 2000: "Serial Port Devices" and Parallel Port Devices" in the Windows DDK

Windows 98/Me: "Virtual Communications Device Drivers" in the Windows Me DDK.

B2.4.1.2 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/comm/

B2.4.1.3 Windows XP/Windows 2000: Enumerating Serial Devices in Windows 2000

http://www.microsoft.com/hwdev/desinit/serddvr.htm

B2.4.1.4 Windows 98/Me: VCOMM Port Driver Power Management Interface

http://www.microsoft.com/hwdev/devdes/vcomm.htm

B2.4.2 Parallel/Serial Devices - Industry Standards

B2.4.2.1 Standard Signaling Method for a Bi-directional Parallel Peripheral Interface for Personal Computers (IEEE 1284 specification)

Global Engineering Documents at http://global.ihs.com/

B2.4.3 Parallel/Serial Devices - Quality

WHQL Test Specification References:
Chapter 1: Introduction to HCT Test Specifications
Click to launch Click to launch

B2.4.3.1 Pass WHQL tests

See B1.3.

Windows XP: See the "Motherboard" topic in the HCT documentation.

B2.4.4 Parallel/Serial Devices - Windows Experience

Design Guideline References:
Legacy Plug and Play Guidelines »

B2.4.4.1 Plug and Play capabilities and operating system compatibility

Implemented as defined in Legacy Plug and Play Guidelines

Note: The following summarizes these legacy requirements, based on Legacy Plug and Play Guidelines:

  • Serial port meets device class specifications for its bus.
  • Legacy serial port is implemented as 16550A UART or equivalent and supports 115.2K baud.
  • Legacy serial port supports dynamic resource configuration.
  • Conflict resolution for legacy serial port ensures availability of at least one serial port.
  • Parallel port meets device class specifications for its bus.
  • Flexible resource configuration supported for each parallel port.
  • EPP support does not use restricted I/O addresses.
  • Compatibility, nibble mode, and extended capabilities port (ECP) protocols meet IEEE 1284-1994 specifications.
  • Port connectors meet IEEE 1284-I specifications, at minimum.
  • IEEE 1284 peripherals have Plug and Play device IDs.
  • Device identification string provides a Compatible ID key.
  • Daisy-chained parallel port device is Plug and Play capable.

B2.4.5 Parallel/Serial Devices - FAQs

See http://www.microsoft.com/winlogo/hardware/comm/.

B2.4.R Parallel/Serial Devices - Future Requirements

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


B2.5 PCI Controllers and Devices

All general requirements in B1.0 are included by reference.

B2.5.1 PCI Controllers/Devices - Windows Compatibility

B2.5.1.1 Driver device class support in related DDKs

Bus driver support is built in to Windows; see device class-specific entries in the Windows DDK and Windows Me DDK.

B2.5.1.2 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/pci/

B2.5.1.3 PCI Device Subsystem IDs and Windows

http://www.microsoft.com/hwdev/devdes/pciids.htm

B2.5.1.4 Compatibility Testing for Hot-Plugging Support for PCI Devices

http://www.microsoft.com/hwdev/pci/hotplugpci.htm

B2.5.1.5 PCI Subsystem IDs and PCI-to-PCI bridge devices

http://www.microsoft.com/hwdev/pci/pcibridge.htm

B2.5.1.6 Windows XP/Windows 2000 PCI support

PCI IRQ Routing on a Multiprocessor ACPI System at http://www.microsoft.com/hwdev/onnow/ACPI-MP.htm

B2.5.1.7 Correct PCI implementations

[PCI-012x; SDG3:4x]

  • Device IDs include PCI Subsystem IDs. [ PCI-0126 »; SDG3:45 »; see also FAQs A1.5.13, B2.5.5.3, B2.5.5.4]
  • System does not contain ghost devices. [ PCI-0123 »; SDG3:36 »]
  • System uses standard method to close base address register (BAR) windows on nonsubtractive decode PCI bridges. [ PCI-0124 »; SDG3:38 »]
  • Bus master privileges are supported for all connectors. [ PCI-0123 »; SDG3:42 »]
  • Functions in a multifunction PCI device do not share writable PCI Configuration Space bit. [ PCI-0123 »; SDG3:43 »]
  • PCI devices complete memory write transaction within specified times. [ PCI-0125 »; SDG3:49 »]
  • Configuration Space is correctly populated. [ PCI-0126 »; SDG3:44 »]
  • Interrupt routing is supported using ACPI. [ PCI-0127 »; SDG3:46 »]
  • PCI-to-PCI bridges comply with PCI to PCI Bridge Specification 1.1. [ PCI-0124 »; SDG3:37 »]

See "Configuring PCI-PCI Bridges on Windows 2000 and Windows XP" at http://www.microsoft.com/hwdev/pci/.

  • Adapters address full physical address space on a 64-bit platform; 32-bit PCI adapters used on the primary data path support the PCI DAC command, with the exception of 10/100 Ethernet devices.

See "Large Memory Enabled Device Driver Hardware and Software Requirements" in the Windows DDK. Design guidelines are summarized at http://www.microsoft.com/hwdev/newPC/PAEdrv.htm
[see FAQ B2.5.5.2 ]

  • Bus designs implement all bus requirements on expansion card connectors. [ PCI-0123 »]
  • PCI devices decode only resources found in the Devices BAR. [ SDG3:40 »]


B2.5.2 PCI Controllers/Devices - Industry Standards

B2.5.2.1 PCI Bus Power Management Interface Specification, Revision 1.1 or later

[PCI-0130 »; SDG3:37 »; see also FAQ B2.5.5.5]

B2.5.2.2 PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges

[ PCCard-19 »; SYS-0024 »]

Note: Support of the CSTSCHG interrupt line is required only for devices that support wakeup events as defined in the PC Card standard.

Provided in Volume 11, PC Card Standard, Release 7, http://www.pcmcia.org/bookstore.htm.

B2.5.2.3 PCI Local Bus Specification, Revision 2.2 (PCI 2.2) or later

[ PCI-0123 »; SDG3:33 »]

B2.5.2.4 PCI to PCI Bridge Specification, Revision 1.1

[PCI-0124 »; SDG3:37 »]
http://www.pcisig.com/developers/specification/

B2.5.2.5 PCI-X Specification, Revision 1.0

[ SDG3:54 »]
http://www.pcisig.com/data/news/1999/pci-x_v10.pdf

B2.5.2.6 Mini PCI Specification, Revision 1.0

http://www.pcisig.com/developers/specification/

B2.5.2.7 PCI Hot-Plug Specification, Revision 1.0

http://www.pcisig.com/developers/specification/


B2.5.3 PCI Controllers/Devices - Quality

WHQL Test Specification References:
Chapter 4: PCI Test Specification
Click to launch Click to launch

B2.5.3.1 Pass WHQL tests

See B1.3.

Windows XP: Search for "PCI" to identify system-specific and device-specific topics in the HCT documentation.

B2.5.3.2

See B2.5.1.7


B2.5.4 PCI Controllers/Devices - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 6, "Buses and Interfaces" - Click to launch Click to launch
Hardware Design Guide 3.0 for Windows 2000 Server, Chapter 2 - Click to launch Click to launch

B2.5.4.1 Power management supported as defined in PCI Bus Power Management Interface Specification, Rev. 1.1 (PCI-PM)

[ PCI-0123 »; SDG3:28 »]

  • System provides 3.3 V to all PCI connectors. [ PCI-0123 »; SDG3:33 »)

System supports 3.3 Vaux if a system supports S3 or S4 states for integrated devices that support waking the system and all PCI slots including MiniPCI. [ PCI-0131 »; SDG3:51 »; see FAQ B2.5.5.5 and B2.5.5.6]

  • PCI add-on cards that use 3.3 Vaux operate correctly, using a method such as the one described in Section 7.4.4 of PCI-PM 1.1. [ PCI-0130.2 »]
  • Bus power states are correctly implemented. [ PCI-0130 »; SDG3:50 »]
  • Local area network (LAN) and modem devices support wake-up per PCI-PM 1.1. [ PCI-0132 »; SDG3:89 »]

See FAQ B2.5.5.
See also "PCI Power Management and Device Drivers" at http://www.microsoft.com/hwdev/desinit/pcipm.htm.

B2.5.4.2 DELETED
B2.5.4.3 Mini PCI devices support PCI 2.2, PCI-PM 1.1, and Mini PCI 1.0 specifications, and all other Logo requirements for PCI devices
B2.5.4.4 Hot-Plug PCI supported via compatible driver solutions or ACPI

[ SDG3:47 »]

"Compatibility Testing for Hot-Plugging Support for PCI Devices" at http://www.microsoft.com/hwdev/pci/hotplugpci.htm.

"Hot-Plug PCI and Windows Operating Systems" at http://www.microsoft.com/hwdev/pci/hotplugpci.htm.

B2.5.4.5 BIOS does not configure I/O systems to share PCI interrupts when APIC is activated

[ BIOS-0016 »]

When an I/O APIC is enabled in the platform, the BIOS must configure the I/O systems such that non-PCI interrupts are not shared with PCI interrupts. At least four of the separate interrupt inputs in the I/O APIC must be dedicated to support PCI interrupts. The system layout and BIOS must minimize sharing of the PCI interrupts.

Mobile PC Note: In mobile systems, the BIOS can configure the I/O system to share PCI interrupts.


B2.5.5 PCI Controllers/Devices - FAQs

B2.5.5.1 Current PCI-related FAQs

See http://www.microsoft.com/winlogo/hardware/pci/.

B2.5.5.2 DAC requirement [Clarification ]

[SDG3:30-32 »]

Requirements for PCI adapters to support the PCI DAC command are defined in A1.1.6. See "Large Memory Enabled Device Driver Hardware and Software Requirements" in the Windows DDK. Design guidelines are summarized at http://www.microsoft.com/hwdev/newPC/PAEdrv.htm.

B2.5.5.3 AMR/MR PCI IDs [Clarification]

[PCI-0126 »]

AMR devices and MR devices on the system board are not exempt from the requirement for SID and SVID.
May 28, 1999

B2.5.5.4 Control Method for PCI IDs [Logo Program Clarification]

[PCI-0126 »; SDG3:30, 31 »]

PC 99 System Design Guide erroneously cited _PS0 as the control method to use. However, _PS0 moves a device from Dx to D0. (The parent PCI bus is at issue in this case; thus, it is actually Bx to B0.) The problem is that a bus must be powered on before it can be assigned a bus number. Therefore, _PS0 must be run before a bus number is guaranteed to exist. However, if power hasn’t been cut to the bus, or if the bus has not been reset, there will be a bus number remaining from before the bus was placed in the Bx state. This is why _PS0 seems to work in some systems. _REG runs immediately after Windows assigns the bus number and immediately before the PCI driver scans the bus for children. That is what makes _REG the appropriate vehicle for making the children coherent.

After the operating system has control of the system, the SVID and SID registers must not be directly writable—that is, implementations that write these registers before the operating system takes control must disable writing to the SVID and SID registers after the registers have been set and before Windows assumes control of the system. For details, see http://www.microsoft.com/hwdev/devdes/pciids.htm.
FAQ Date: August 26,1999

B2.5.5.5 PCI-PM 1.1 and PME# [Logo Program Clarification9]

[PCI-0130 »; PCI-0131 »; SDG3:50 »]

  • Device requirements: PCI Bus Power Management Interface Specification, Revision 1.1 or later, is the only industry specification that ensures compatibility with the power management capabilities of Windows XP/Windows 2000, which uses PME# as the wake-up signal.
    FAQ Date: May 6, 1999; December 22, 1999
  • Bus and bridge requirements: Requirements for supporting PCI-PM 1.1 and for correctly supporting 3.3 Vaux are defined at B2.5.4.
B2.5.5.6 3.3 Vaux power requirement [Clarification]

See the clarification on the PCI specification, "9.18 - 3.3 Vaux power delivery/consumption requirements FAQ," published by the PCI Special Interest Group (PCI SIG) at http://developer.intel.com/technology/iapc/pc99vqa.htm.
FAQ Date: March 19, 1999


B2.5.R PCI Controllers/Devices - Future Requirements

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


B2.6 USB Controllers and Devices

All general requirements in B1.0 are included by reference.

Note that related BIOS and system-level requirements are included with the Windows Logo Program requirements for systems, as defined in Appendix A.

B2.6.1 USB Controllers/Devices - Windows Compatibility

B2.6.1.1 WDM support for devices that use the USB bus: "Supporting USB Devices" in the Windows DDK
B2.6.1.2 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/usb/

B2.6.1.3 USB Plug and Play IDs and Selecting Device Drivers to Load

http://www.microsoft.com/hwdev/busbios/usbpnp.htm

B2.6.2 USB Controllers/Devices - Industry Standards

B2.6.2.1 OpenHCI: Open Host Controller Interface Specification for USB, Release 1.0a

[ USB-0081 »]
http://www.microsoft.com/hwdev/respec/busspecs.htm
Universal HCI specification is also accepted.

B2.6.2.2 USB class specifications

[USB-0088 »; SDG3:60 »]
http://www.usb.org/developers/devclass.html

B2.6.2.3 USB 1.1 Specification (or later)

[ USB-0081 »; SDG3:57 »]
http://www.usb.org/developers/docs.html

B2.6.3 USB Controllers/Devices - Quality

WHQL Test Specification References:
Chapter 9: USB Test Specification
Click to launch Click to launch

See B1.3.

B2.6.3.1 Pass all applicable WHQL tests

This includes USB 1.1 Chapter 9 and Chapter 11 tests:

  • Device or hub has unique VID/Program ID (PID) combination.
  • Serial number, if implemented, is unique.
  • Hub correctly reports the number of ports accessible by the user.

Windows XP: See "USB Controllers," "USB Hubs," and device-specific and system-specific topics in the HCT documentation.

B2.6.3.2

See B2.6.3.1

B2.6.4 USB Controllers/Devices - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 6, "Buses and Interfaces" - Click to launch Click to launch
Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server, Chapter 2 - Click to launch Click to launch

B2.6.4.1 Devices comply with USB power management requirements

[USB-0087 »; SDG3:59 »]

B2.6.4.2 Connections use USB icon, per USB 1.1 specification
B2.6.4.3 USB host controller can wake the system

[ USB-0085 »]

B2.6.4.4 Devices and drivers support maximum flexibility of hardware interface options

[ USB-0084 »; SDG3:58 »]

B2.6.4.5 Devices meet requirements in related USB device class specifications

[ USB-0088 »; SDG3:60 »; see also FAQ B2.6.5.2]

B2.6.4.6 Hub or device that supports USB 2.0 complies with USB 2.0 Specification

[ USB-0081 »]

B2.6.4.7 USB devices install and perform at least some functions expected by end users for that class of device, without preloading software

[ USB-0089 »; SDG3:62 »]

Without loading a specific driver, USB devices having native operating system class driver support provide the typical functions supported by devices within each class, as defined in the USB device class specifications. After device specific driver installation, the device must be fully functional.

Driver packages can force re-enumeration by pointing to their INF file; see UpdateDriverForPlugAndPlayDevices in the Windows DDK for information.

B2.6.4.8 USB hubs are self-powered

[ USB-0086 »; SDG3:61 »]

This requirement does not apply for hubs integrated into USB keyboards.

Mobile PC Note: This requirement does not apply for hubs integrated into mobile systems.

B2.6.5 USB Controllers/Devices - FAQs

B2.6.5.1 Current USB-related FAQs

See http://www.microsoft.com/winlogo/hardware/usb/.

B2.6.5.2 USB device definition [Logo Program clarification]

[USB-0088 »; SDG3:46 »]

Any device that plugs into a USB port is tested as a USB device—that is, the device provides the capabilities of one or more functions, a hub to the host, or both. As result, these requirements apply for any device that plugs into a USB port: the USB specification and any related USB device class specification, plus the Windows Logo Program requirements for USB and the related device class.
FAQ Date: October 7, 1998

B2.6.R USB Controllers/Devices - Future Requirements

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

B2.6.R.1 USB isochronous devices do not request more than 25 percent of the total bandwidth at any time

Previous Next


B3.0 Audio Devices

B3.1 General Audio

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.

B3.1.1 General Audio - Windows Compatibility

B3.1.1.1 WDM device driver support for audio

[ AUD-0326 »; AUD-0337 »]

Device driver conforms to the WDM implementation guidelines and "Audio Drivers" reference in the Windows DDK.

See FAQ B3.1.5.8.

B3.1.1.2 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/audio/

B3.1.1.3 Audio Codec (AC) '97 and AMR Plug and Play Design

See FAQ B3.1.5.2.
http://www.microsoft.com/hwdev/audio/AMR.htm.

B3.1.1.4 WDM Audio Drivers for Windows XP/Windows 2000

http://www.microsoft.com/hwdev/devdes/wdmaudio.htm
DirectSound® driver support: see "DirectSound DDK" in the Windows DDK.

B3.1.1.5 Windows Me: USB MIDI takes advantage of built-in operating system support

See "Audio Drivers" in the Windows DDK.


B3.1.2 General Audio - Industry Standards

B3.1.2.1 AC ’97 Component Specification

http://developer.intel.com/ial/scalableplatforms/audio/index.htm

B3.1.2.2 Audio Device Class Power Management Reference Specification, V. 2.0

[ AUD-0336 »; see also see FAQ B3.1.5.7]
http://www.microsoft.com/hwdev/specs/pmref/pmaudio.htm

B3.1.2.3 DLS Specification, V. 1.0 or later

[AUD-0328 »]
http://www.midi.org/

B3.1.2.4 Personal Computer Audio Quality Measurements

http://www.cirrus.com/products/papers/meas/meas.html

B3.1.2.5 USB Device Class Definition for Audio Devices, V. 0.9 or later

[ AUD-0335 »]
http://www.usb.org/developers/docs.html

B3.1.2.6 USB Device Class Definition for MIDI Devices, V. 0.9 or later

http://www.usb.org/developers/docs.html

See B5.1.5 for HID control requirements.


B3.1.3 General Audio - Quality

WHQL Test Specification References:
Chapter 16: Audio Test Specification
Click to launch Click to launch

B3.1.3.1 Pass WHQL tests

See B1.3.
Windows XP: See "Audio" in the HCT documentation.

B3.1.3.2

See B1.3


B3.1.4 General Audio - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 11, "Audio"
Click to launch Click to launch

B3.1.4.1 No legacy audio components

[ SYS-0041 »; AUD-0322 ]

No ISA; no legacy hardware interfaces for MS-DOS-based applications.

B3.1.4.2 Full Duplex—Internet Telephony

[ AUD-0324 »; AUD-0325 »; see also FAQ B3.1.5.9]

B3.1.4.3 Plays sounds before and after Suspend/Resume

[ SYS-0003.4 »]

B3.1.4.4 Record and Playback works properly—WHQL Audio test: Audio performance

[AUD-0329 »; see also FAQ B3.1.5.3]

Mobile PC Note: Exceptions for mobile PCs are defined in the following table, "Minimum Performance Requirements."

Advances on previous requirements:

  • Full duplex operation is supported for all sampling rates; sampling rates are time synchronized. [ AUD-0325 »]
  • Digital playback and recording values are increased from 20 Hz to 30 Hz Full-scale input voltage changed from (2.0 to (1.0. [ AUD-0329 »]

Minimum Performance Requirements

Requirement

Value

Full-scale input voltage:

FSIV (A-D-PC) line input

≥1.0 Vrms

FSIV (A-D-PC) microphone input

≥100 mVrms

Full-scale output voltage:

FSOV (PC-D-A) line output

≥1.0 Vrms [note 1]

Digital playback (PC-D-A) for line output:

Frequency response (-3 dB)
48.0 kHz source material

20 Hz to 19.2 kHz [note 4]

Dynamic range (DR)

≥80 dB FS A [note 3, 4]

THD+N (-3 dB FS)

≤-65 dB FS [note 4]

Digital playback (PC-D-A) for speaker output with 8-ohm load:

Frequency response (-3 dB)
48.0 kHz source material

100 Hz to 19.2 kHz [note 4]

Dynamic range (DR)

≥80 dB FS A [note 3, 4]

THD+N (-3 dB FS)

≤-65 dB FS [note 4]

Digital recording (A-D-PC) for line input: [note 2]

Frequency response
48.0 kHz destination

20 Hz to 19.2 kHz [note 4]

Passband ripple

<+/-0.5 dB

Dynamic range (DR)

≥70 dB FS A [note 4]

THD+N (-3 dB FS)

≤-60 dB FS (input referenced) [note 4]

Digital recording (A-D-PC) for microphone input:

Frequency response (-3 dB)
22.05 kHz destination

100 Hz to 8.8 kHz

Passband ripple

<+/-0.5 dB

Dynamic range (DR)

≥70 dB FS A [note 4]

THD+N (-3 dB FS)

≤-60 dB FS (input referenced) [note 4]

Line output cross-talk:

Channel separation
between left and right line-out channels
(measured at 10 kHz)

≥60 dB [note 4]

Sampling frequency accuracy:

Playback

0.1%

Record

0.1%

Notes:

Note 1: For 3.3 V audio codec, the required Full Scale Output Voltage for line output is ≥0.7 Vrms.

Note 2: Line input to speaker output is a requirement only if a line output is not supported.

Note 3: Decibels relative to full scale (FS), measured using "A weighting" filters.

Note 4 - Mobile PC Notes:

  • The dynamic range requirements are relaxed from previous requirements by 10 dB FS.
  • The THD+N requirements are relaxed by 10 dB FS.
  • The required frequency response is 30 Hz to 15 kHz, measured using 3 dB corners.
  • The cross-talk requirements are relaxed by 10 dB FS.
B3.1.4.5 Audio subsystem supports full-duplex operation at independent sampling rates

[ AUD-0325 »]

B3.1.4.6 Analog microphone input meets jack and circuit specifications

[ AUD-0331 »]

B3.1.4.7 Audio driver reports sample position for stream synchronization

[ AUD-0326 », AUD-0334 »]

Maximum allowable latency is 1 ms.

B3.1.4.8 PCI audio device meets minimum requirements
  • Supports initiator, target, and block transfer. [ AUD-0333 »]
  • PCI device supports efficient audio buffer management. [ AUD-0334 »
  • Does not use ISA-based resources. [ AUD-0322 »]
  • Is digital ready. [ AUD-0323 »]
B3.1.4.9 USB audio device uses HID controls

[ AUD-0335 »]

B3.1.4.10 Support required for DirectX functions as specified in the DirectX DDK

Windows XP: Support Microsoft DirectX® 8 (DirectX DDK is included in the Windows DDK).

B3.1.4.11 Windows XP: Device implements DRM support as defined in Windows DDK

"Digital Rights Management Reference" in the Windows DDK.

[see FAQ B3.1.5.10]

Windows Me: If this support is implemented, see also http://www.microsoft.com/hwdev/audio/DRM.htm.

B3.1.4.12 Audio subsystem requirements

[ AUD-0330 », 0339 »]

  • Supports acoustic echo cancellation reference inputs. [ AUD-0330 »]
  • Does not rely on analog mixing. [ AUD-0339 »]
B3.1.4.13 Headset microphone used for speech recognition meets performance requirements

[ AUD-0332 »]


B3.1.5 General Audio - FAQs

B3.1.5.1 Current related Audio FAQs

See http://www.microsoft.com/winlogo/hardware/audio/.

B3.1.5.2 AC ‘97 devices on riser cards [Logo Program clarification]

[SYS-0034 »]

AC ‘97 devices on riser cards such as AMR, CNR, and MR can be tested and receive the "Designed for Windows" Logo based on the following requirements:

  • 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 SIG to that OEM.
  • The SID must be unique for each AC ‘97 device configuration. For example, for a MoM, MR, or 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.
  • 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.

For more information about WHQL testing for riser cards, see the WHQL web site at http://www.microsoft.com/hwtest/.

See AC '97 and AMR Plug and Play Design at http://www.microsoft.com/hwdev/audio/AMR.htm.
FAQ Date: June 2, 1999

B3.1.5.3 Audio Minimum Performance Requirements [Revision]

[AUD-0325-0329 »]

Data formats and performance requirements are now defined at B3.1.4.4 .

B3.1.5.4 Basic data formats for audio hardware [Revision]

[AUD-0325-0329 »]

Data formats and performance requirements are now defined at B3.1.4.4 .

B3.1.5.5 Analog microphone input [Revision]

[AUD-0331 »]

Requirements are now defined at B3.1.4.6 .

B3.1.5.6 PCI device supports non-DWORD-aligned audio buffers [Clarification]

[AUD-0334 »]

This is a recommendation, not a requirement. Replaced in B3.1.4.8.
FAQ Date: December 22, 1998; June 16, 2000

B3.1.5.7 PCI power management requirements [Clarification]

[ AUD-0336 »]

PCI Bus Power Management Interface Specification, Revision 1.1 or later, is the only industry specification that ensures compatibility with the power management capabilities of Windows 2000 and Windows XP.
FAQ Date: November 12, 1999

B3.1.5.8 WDM Audio Driver Requirements [Logo Program Clarification]

[AUD-0337 »]

WDM audio driver requirements apply based on the preinstalled operating system:

  • Windows XP/Windows 2000 and Windows Me Audio Drivers: All devices are required to use WDM drivers.
  • Audio drivers for Windows 98 Second Edition: All audio devices are required to use WDM, with the exceptions noted below. There will be an operating system update released early next year that will address the technical deficiencies. As of July 1, 2000, devices in either of the following two categories cannot use VxD drivers:
  • Exception #1: Audio devices that also contain a game port: Windows 98 Second Edition does not support WDM game ports. Audio devices that use WDM drivers must provide a VxD module for the game port. Windows 98 Second Edition has known issues with the interconnection between WDM audio devices and the VxD game port services. The operating system update will address these issues.
  • Exception #2: Audio devices that use WavePCI and provide hardware acceleration of Microsoft DirectSound: There are two classes of WDM audio drivers, WaveCyclic and WavePCI. The former is intended for those devices that utilize looping memory buffers to transfer audio to the device. The latter is geared towards PCI devices that use scatter-gather to transfer data. Windows 98 Second Edition has known issues with WavePCI and DirectSound hardware acceleration. These issues have been addressed in later operating systems.
  • Audio drivers for the initial release of Windows 98: Systems that ship with Windows 98 may use VxD audio drivers indefinitely (due to WDM audio issues in Windows 98). This does not apply to Windows 98 Second Edition.
  • Audio drivers for Windows NT 4.0: Because Windows NT 4.0 does not support WDM, the WDM requirement does not apply for testing systems under Windows NT 4.0.
    FAQ Date: November 29, 1999
B3.1.5.9 Audio subsystem supports basic data formats [Revision]

[AUD-0324 »]

Hardware sample rate conversion (SRC) is not required when the Microsoft software SRC is used. Windows 98/Me and Windows 2000 provide software mixing and SRC, which eliminate the need for hardware to support any sampling rate other than 48 kHz.
FAQ date: February 28, 2001

B3.1.5.10 DRM legacy function calls [Clarification]

Windows XP: to pass Windows Logo testing for Secure Audio Path for Digital Rights Management as DRM compliant with DRM Level = 1200 (which is the security level for Windows XP), audio drivers for Windows XP must not call DrmForwardContentToFileObject. If an audio driver calls DrmForwardContentToFileObject, it will be qualified as DRM compliant with DRM Level = 1100, which is the security level for Windows Me.


B3.1.R General Audio - Future Requirements

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


B4.0 Display

B4.1 Display Adapters/Chipsets

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.

B4.1.1 Display Adapters/Chipsets - Windows Compatibility

B4.1.1.1 Windows XP/Windows 2000: "Display and Video Miniport Drivers" and "Multiple Monitor Support in the Display Driver" in the Windows DDK

Software provided with graphics adapters must comply with the requirements defined in "Graphics Driver Design Guide" in the Windows DDK.

B4.1.1.2 Windows 98/Me: "Display Drivers" and "Multiple Monitor Support Implementation Design Notes" in the Windows Me DDK

Windows Me: Correct driver support for Get_Adapter_Power_State_Caps() and Set_Adapter_Power_State() interfaces in the Windows Me DDK.

B4.1.1.3 OpenGL support (if implemented): "Video Miniport Drivers" in the Windows DDK
B4.1.1.4 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/display/

B4.1.1.5 Windows XP/Windows 2000 Professional: Compatibility Testing Requirements for Display and Video Miniport Drivers

http://www.microsoft.com/hwdev/video/vidminiport.htm

B4.1.1.6 Windows 98/Me: Caution for Display Driver Dependencies on GDI

http://www.microsoft.com/hwdev/devdes/gdi.htm

B4.1.1.7 DirectX: Support per DirectX DDK and the DirectX SDK

The DirectX DDK is provided in the Windows DDK; the DirectX SDK is provided in the Microsoft Platform SDK.

Note: If hardware acceleration features are implemented beyond those specified in section B4.1, those features must be supported as defined in the DirectX DDK and SDK.

Microsoft Platform SDK - http://msdn.microsoft.com/directx/

B4.1.1.8 Onboard graphics device can be used as primary VGA boot device

[ GRPH-0199 »; see also FAQ B4.1.5.7]

Mobile PC Note: Systems that have the graphics chip on the system board and mobile PCs that are capable of docking in a docking station with PCI slots must provide a means in the BIOS setup utility to force the system to boot using the onboard graphics device.

B4.1.1.9 x86-based graphics adapter with motion compensation or Inverse DCT hardware acceleration uses Microsoft DirectX VA API driver

[ VID-0340 »]

See Microsoft Platform SDK and the DirectX DDK in the Windows DDK.

Note: This requirement does not apply to devices created for 64-bit systems.


B4.1.2 Display Adapters/Chipsets - Industry Standards

B4.1.2.1 Accelerated Graphics Port Interface Specification, Revision 1.0 or later

AGP 2.0: http://developer.intel.com/technology/agp/agp_index.htm.

B4.1.2.2 Digital Video Interface (DVI) Revision 1.0

[GRPH-0165 »; see also FAQ B4.1.5.3]
http://www.ddwg.org/

B4.1.2.3 Display Data Channel Standard, V. 3.0, Level 2B protocols

[ GRPH-0204 »; see also FAQs B4.1.5.2, B4.1.5.3]

Video Electronics Standards Association (VESA) BIOS Extension Standard/Core Functions 2.0 (VBE/Core 2.0) at http://www.vesa.org/standards.html.

B4.1.2.4 Display Device Class Power Management Specification, V. 2.0

http://www.microsoft.com/hwdev/specs/PMref/PMdisplay.htm

B4.1.2.5 Ergonomic timings for supported resolutions, based on VESA standards

[ GRPH-0169 »]

VESA Computer Display Monitor Timing Specification Version 1.0, Revision 0.8.
VESA Generalized Timing Formula Standard, Version 1.1.
Or DVI 1.0 (if DVI is implemented).

Optionally, 59.94 Hz variants of the 60 Hz timings.


B4.1.3 Display Adapters/Chipsets - Quality

WHQL Test Specification References:
Chapter 5: Graphics Adapter Test Specification
Click to launch Click to launch

B4.1.3.1 Pass WHQL tests

See B1.3.

Windows XP: See "Display adapter/chipset" in the HCT documentation.


B4.1.4 Display Adapters/Chipsets - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 8, "Graphics Adapters"
Click to launch Click to launch

B4.1.4.1 Multiple monitor/multiple display support

[ GRPH-0167 »; GRPH-0180, 0181 »]

B4.1.4.2 Windows XP: DirectX 7 or later driver support for hardware acceleration
  • Support CopyFourCC. The graphics adapter driver must correctly implement and act on the COPYFOURCC flag as defined by ddCaps.dwCaps2. The blt function is required to take less than 8 ms and must not be emulated in software.
  • Properly handle Flip Buffer. The graphics adapter driver must handle YUV surface flipping properly. Specifically, it must be able to cope with either directed or non-directed flips.
  • Create an RGB overlay as a 3D render target. If the hardware supports an RGB overlay, then the driver must provide the ability to render 3D content to RGB flipping overlay surfaces. All 3D drawing operations must be complete before the flip causes the surface to be visible on the screen.
  • Support Nonpower of 2 textured surfaces. If the hardware does not support nonpower of 2 textures, then this must be properly reported by the nonpower2 flag. Because Video sizes are rarely powers of 2, there is an additional DirectDraw flag called D3DPTEXTURECAPS_NONPOW2CONDITIONAL that should be set if the hardware supports nonpower of 2 textures for the Clamp addressing mode when not using mip mapping and with D3DRS_WRAP(N) set to zero for the texture co-ordinates.
  • Support for BLT_FOURCC. It is a requirement to be able to simultaneously do a BLT, stretch/shrink, and a color space conversion from a YUV surface to the current 15, 16, 24, or 32 bit desktop RGB formats.
  • If the hardware supports YUV textures surfaces and it is reported as such, then the driver must be able to process these without any intermediate transforms and function correctly.
  • x86-based system: Output of the DirectX VA MPEG acceleration process must be available as an input to the VMR renderer. This can either be in the form of a Direct3D texture or as an input to the color conversion BLTer.

Note: This requirement does not apply to devices created for 64-bit systems.

B4.1.4.3 If digital video interface is supported, implementation follows Digital Visual Interface 1.0

[ GRPH-0165 »]

B4.1.4.4 Adapter supports minimum screen resolution

[ GRPH-0168 »]

Minimum resolution is 1024 × 768 × 32 bpp, double buffered in both 2-D and 3-D modes with a 32-bit Z-buffer in 3-D mode.

Adapter meets VESA specifications for ergonomic timing rates (optionally, 59.94 Hz variants of the 60 Hz timings); screen resolution and local memory capacity meet minimum requirements.

After July 1, 2002, integrated solutions must support this minimum requirement; until July 1, 2002, integrated solutions can have a minimum screen resolution of 1024 × 768 at a color depth of 24 bpp for 2-D, and 1024 × 768 at a color depth of 16 bpp with a 16-bit Z-buffer in 3-D mode.

Mobile PC Note: Requirements are defined in B4.1.4.13

B4.1.4.5 Color support

[GRPH-017x]

  • All supported color depths are enumerated. [ GRPH-0170 »]
  • Adapter supports gamma correction performed in hardware at 24 bpp or 32 bpp without using VGA resources. [ GRPH-0178 »]
  • Driver supports dynamic color bit-depth change. [ GRPH-0206 »]
  • Graphics adapter operates properly and does not fail when Windows requests that it change the color depth or resolution; a restart must not be required to accomplish this. [ GRPH-0206 »]
B4.1.4.6 Device configuration and detection requirements

[GRPH-01xx; SDG3]

  • Graphics operations use relocatable registers only. [ GRPH-0171 »]
  • Primary graphics adapter works normally with default VGA mode driver. [ GRPH-0166 »; SDG3:75, 76 »]
  • Driver does not bypass any Microsoft-provided system components. [ GRPH-0205 »; see FAQ B4.1.5.4]
  • Adapter supports DDC monitor detection, and option ROM supports VESA Enhanced Display Data Channel Standard (EDDC), Version 1.0, Level 2B protocols (DDC2B). [ GRPH-0179 »

Mobile PC Note: Requirements are defined in B4.1.4.13.

  • Frame buffer can be accessed directly by applications. [ GRPH-0182 »]
  • System supports conflict resolution, VGA compatibility, and extended registers. [ GRPH-0196 »]
  • BIOS supports large frame buffers for graphics adapters. [ GRPH-0200 »]
  • Graphics adapter complies with VESA BIOS Extensions/Core 2.0 extensions for power management. [ GRPH-0204 »]
B4.1.4.7 Basic 2-D hardware acceleration requirements

[GRPH-018x]

  • Hardware supports transparent blter. [ GRPH-0183 »]
  • Hardware provides support to prevent tearing. [ GRPH-0184 »]
  • Chips support linear packed-pixel frame buffer, relocatable above 16 MB. [ GRPH-0197 »]
B4.1.4.8 Adapter supports hardware-accelerated 3-D graphics

[GRPH-018x]

Including these additional new 3-D requirements for hardware support:

  • Multi-texturing. [ GRPH-0186 »]
  • Source alpha blending and destination alpha blending; required texture size increases to 1024×1024 for all texture operations. [ GRPH-0185 », GRPH-0188 »]

After July 1, 2002, integrated solutions must support destination alpha blending.

Alpha blend mode | Source factor | Destination factor
D3DBLEND_BOTHINVSRCALPHA | Required | -
D3DBLEND_BOTHSRCALPHA | Required | -
D3DBLEND_DESTALPHA | Required | Required
D3DBLEND_DESTCOLOR | Required | -
D3DBLEND_INVDESTALPHA | Required | Required
D3DBLEND_INVDESTCOLOR | Required | -
D3DBLEND_INVSRCALPHA | Required | Required
D3DBLEND_INVSRCCOLOR | - | Required
D3DBLEND_ONE | Required | Required
D3DBLEND_SRCALPHA | Required | Required
D3DBLEND_SRCALPHASAT | Required | -
D3DBLEND_SRCCOLOR | - | Required
D3DBLEND_ZERO | Required | Required
  • Texture format 8:8:8:8 alpha RGB (ARGB). [ GRPH-0187 »]

After July 1, 2002, integrated solutions must support texture format 8:8:8:8 ARGB.

  • Z comparison modes and Direct3D-compatible formats. [ GRPH-0189 »]
  • Fog blending term is calculated on a per-pixel basis rather than per vertex, and is either range-based (range-based fog) or depth-based (pixel fog).

Driver support for triangle strips and fans. [ GRPH-0185.3 »]

After July 1, 2002, integrated solutions must support per-pixel fog; until January 1, 2002, integrated solutions can implement only per-vertex fog.

After July 1, 2002, integrated solutions must support MODULATEALPHA texture combinations.

Also, multitexture support with fogging and alpha blending are not required.
[GRPH-0185 », GRPH-0187 », GRPH-0188 »]

Mobile PC Note: Requirements are defined in B4.1.4.14.

B4.1.4.9 Graphics adapter uses PCI, AGP, or another high-speed bus

[GRPH-0163]

  • Equivalent of AGP 2X required for discrete solutions; AGP 1X or equivalent required for integrated solutions. [ GRPH-0163 »]
  • PCI device supports IRQ and correctly populates PCI BARs. [ GRPH-0201 »]
  • PCI system-board graphics device PCI configuration space must be visible to the Plug and Play enumeration software. [ GRPH-0202 »; see also FAQ B4.1.5.7]
B4.1.4.10 TV output capability, if present, meets requirements
  • Adapter supports underscan scaling. [ GRPH-0190 »]

Mobile PC Note: This requirement does not apply to mobile PC platforms.

  • Adapter supports flicker filter and is required to take a 1024 x 768 32-bpp input and downscale it to the TV out resolution (NTSC or PAL). [ GRPH-0192 »]
  • Adapter with television output supports both 1024 x 768 at 32 bpp VGA and television output simultaneously. [ GRPH-0194 »]
  • Software supports positioning. [ GRPH-0191 »]

Mobile PC Note: This requirement does not apply to mobile PC platforms.

B4.1.4.11 Graphics subsystem support for TV or DVD-Video playback, if present, meets performance requirements

[ GRPH-0207, 0208 », GRPH-0395 »]

For the adapter to achieve the required performance when rendering Line21, the DDCAPS_CANBLTSYSMEM cap needs to be set in the display adapter.

Mobile PC Note: Mobile platforms must support video overlay up to their native resolution and color depth or XGA where native resolution is greater than XGA (1024x768).

B4.1.4.12 Graphics adapter driver properly supports D3 state such that Windows can hibernate and restore the system from any system-supported sleep state

[GRPH-0203, 0204 »]

Windows Me: This includes correct driver support for Get_Adapter_Power_State_Caps() and Set_Adapter_Power_State() interfaces, as defined in the Windows Me DDK.

B4.1.4.13 Mobile PC system meets basic graphics requirements to reliably run Windows and applications, plus requirements for resolution capabilities

[ GRPH-0393 »]

B4.1.4.14 Mobile PC system 3-D capabilities, if implemented, meet minimum requirements

[ GRPH-0393 »]


B4.1.5 Display Adapters/Chipsets - FAQs

B4.1.5.1 Current Display FAQs

See http://www.microsoft.com/winlogo/hardware/display/.

B4.1.5.2 DDC/EDID Standards [Clarification]

[ GRPH-0179 »]

The required support defined in Version 3.0 of the DDC and Extended Display Identification Data (EDID) standards is also defined in the earlier version and revisions of these standards. As such, the Version 3.0 standards provide the correct references for Windows XP/Windows 2000 and Windows 98/Me.
FAQ Date: October 7, 1998

B4.1.5.3 Mobile PC system supports minimum +5V power requirements [Clarification]

[GRPH-0393.6 »]

Mobile PC Note: Mobile systems do not have to supply +5V to the VGA connector at any time. The DVI connector must supply +5V only during boot, when the user first enables external video, and when the system is actually outputting analog or digital video through the DVI connector.

Some display devices rely on the +5V to power their DDC circuitry, for Plug and Play detection, or both. It is recommended that a mobile PC provide a means to enable the +5V power when necessary.
FAQ Date: March 19, 1999

B4.1.5.4 Shrink and zoom requirements [Revision]

[GRPH-0207.4 »]

TV and DVD playback requirements are defined in B4.1.4.11.

B4.1.5.5 Color/color range requirements [Revision]

[GRPH-0395 »]

TV and DVD playback requirements are defined in B4.1.4.11.

B4.1.5.6 Source alpha blending requirement [Revision]

[GRPH-0185 »]

3-D graphics requirements are defined in B4.1.4.8.

B4.1.5.7 Integrated devices must support multiple monitors [Clarification]

PC 2001 System Design guidelines GRPH-0199 and GRPH-0202 state that when an add-on card is installed in the AGP slot, integrated devices must support multiple monitors. This is not a requirement of the Windows Logo Program for hardware.


B4.1.R Display Adapters/Chipsets - Future Requirements

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


B4.2 Monitors

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.

B4.2.1 Monitors - Windows Compatibility

B4.2.1.1 Windows XP/Windows 2000—monitor INF: "Creating and INF File" in the Windows DDK

See also the "Monitor" sample application in the Windows DDK for information about USB monitor control using Hid.dll.

B4.2.1.2 Windows 98/Me—monitor INF: "Sample Display INF File" of "Windows 95 Documentation Programmers Guide" in the Windows Me DDK
B4.2.1.3 Image Color Management (ICM) APIs and functionality as defined in the Microsoft Platform SDK and "Color Management for Displays" in the Windows DDK

[ MON-0235 »]

B4.2.1.4 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/video/

B4.2.1.5 Windows XP/Windows 2000: Windows Support for Mobile System Displays

Mobile PC Note: http://www.microsoft.com/hwdev/video/mobiledisplay.htm

B4.2.1.6 Display Control Panel Extensions per DDK, with Advanced Properties tab

Windows XP/Windows 2000: "Control Panel Requirements" Windows DDK.
Windows 98/Me: "Custom Refresh Rates" and "Using Control Panel Extensions" in the Windows Me DDK; see also http://www.microsoft.com/hwdev/devdes/displaycpl.htm.


B4.2.2 Monitors - Industry Standards

B4.2.2.1 Related VESA standards

[ MON-0232 »]
http://www.vesa.org/standards.html

Enhanced Extended Display Identification Data Standard (E-DID), Release A
DDC2B.
EDID Standard, V. 3.0.
VESA Display Data Channel Standard.
VESA and Industry Standards and Guidelines for Computer Display Monitor Timing.

B4.2.2.2 ICC Profile Format Specification, Spec ICC.1:1988-09 and Addendum 2, ICC.1A:1999-04

[MON-0235 »]
http://www.color.org/profiles.html

B4.2.2.3 USB Monitor Control Class Specification, Revision 1.0

[USB-0088 »]
http://www.usb.org/developers/docs.html

B4.2.2.4 DVI, Revision 1.0

http://www.ddwg.org/

B4.2.2.5 Display Device Class Power Management Specification, Version 2.0

[MON-0244 »; see also FAQ B4.2.5.5]
http://www.microsoft.com/hwdev/specs/Pmref/Pmdisplay.htm


B4.2.3 Monitors - Quality

WHQL Test Specification References:
Chapter 1: Introduction to HCT Test Specifications
Click to launch Click to launch

B4.2.3.1 Pass WHQL tests

See B1.3.

Windows XP: See "Monitors" in the HCT documentation.


B4.2.4 Monitors - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 10, "Monitors"
Click to launch Click to launch

B4.2.4.1 Color monitor is DDC2B-compliant and supports EDID 1.3 data structure

[MON-0232, 0233 »; see also see FAQs B4.2.5.2 and B4.2.5.4]

B4.2.4.2 Monitor associates an ICC profile

[ MON-0235 »]

The Windows operating system will support devices that create standard RGB (sRGB) output by default. Devices with an output other than sRGB must install (via a monitor INF) an ICC profile appropriate to the preferred display resolution (as identified in the EDID data) at 32 bpp. For an LCD or other non-CRT display device, the profile should be based on the native display mode (resolution and color depth) for which the display is designed.

Mobile PC Note: Because most Mobile PCs do not support Plug and Play for their installed LCD panel, the ICC profile must be installed manually by using an appropriate monitor INF. OEMs should install the correct configuration as part of the operating system preinstall process. If necessary, the INF will be available to the user for manual reinstallation. Mobile PCs with Double Supertwisted Nematic (DSTN) or reflective LCD panels do not require ICC profiles.

B4.2.4.3 Minimum graphics resolution, based on monitor size

[ MON-0237 »]

  • 14-inch to 15-inch external monitor = 800 × 600, noninterlaced.

Mobile PC Note: Built-in mobile PC display = 800 × 600, noninterlaced.

  • 17-inch external monitor or 13-inch to 15-inch external LCD = 1024 × 768, noninterlaced.
  • 19-inch and 21-inch external monitor or external LCDs larger than 16 inches = 1280 × 1024, noninterlaced.
  • TV-style large-format monitors (larger than 23 inches) must be capable of scanning at 1024 x 768 progressive at 60 Hz (and 59.94 Hz) for the 4:3 case, and 1280 x 720 progressive at 60 Hz (and 59.94 Hz) for the 16:9 case.
B4.2.4.4 CRT-based monitor supports ergonomic timing standards

[ MON-0240 »]

As defined in either the VESA Generalized Timing Formula, V. 1.1 or Computer Display Monitor Timing Specification, V. 1.0, Rev. 0, and a 59.94Hz variant of the 60Hz modes.

B4.2.4.5

See TV-style-large format monitors in B4.2.4.3

B4.2.4.6 Windows XP/Windows Me: Digital monitor (if implemented) supports DVI-related standards

[ MON-0241, 0242, 0243 »]

Including DVI-compliant interface, hot-plug detection, VESA VGA Text Mode 3 timings (specifically 720 x 400 at 70 Hz), and 640 × 480 at 60 Hz and 640 × 400 at 70 Hz.

B4.2.4.7 USB functionality from either a HID or USB hub, if implemented, is installed separately from the monitor INF

[ MON-0236 »]

B4.2.4.8 USB hub included on a monitor is self powered or externally powered

[ MON-0236 »]

It cannot be a bus-powered hub.

B4.2.4.9 CRT-based monitor synchronizes to a new format in less than three seconds

[ MON-0238 »]

B4.2.4.10 LCD monitor or built-in LCD display contains display characterization data

[ MON-0234 »]

B4.2.4.11 Windows XP: Monitor supports 59.94 Hz operation

Previous Next


B4.2.5 Monitors - FAQs

B4.2.5.1 Current Monitor FAQs

See http://www.microsoft.com/winlogo/hardware/display/.

B4.2.5.2 DDC standard [Clarification]

[MON-0232 »]

The required support defined in Version 3.0 of the DDC standards is also defined in the earlier version and revisions of these standards. As such, the Version 3.0 standards provide the correct references for Windows XP/Windows 2000 and Windows 98/Me.
FAQ Date: October 7, 1998

B4.2.5.3 DELETED

See B4.2.4.2 .

B4.2.5.4 EDID for analog CRTs [Correction]

[ MON-0233 »]

For analog CRTs, EDID content must indicate at least one VESA mode at 75 Hz, or better, for each resolution supported.
FAQ Date: October 7, 1998

B4.2.5.5 Monitors support D0 and D3 states [Logo clarification]

[ MON-0244 »]

Monitors are required to support only D0 and D3 states.
FAQ Date: March 20, 2000


B4.2.R Monitors - Future Requirements

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

B4.2.R.1 Cathode Ray Tube complies with Windows Color Quality Specifications

Color matching capabilities supported in a color cathode ray tube must comply with the requirements defined in Section 4 of "Windows Color Quality Specifications for Cathode Ray Tube OEMs," available at http://www.microsoft.com/hwdev/color/ In particular, the following color tolerances must be met.

Color element | Tolerance
Red primary | x=0.640 +0.020/-0.035 y=0.330 +0.030/-0.020
Green primary | x=0.300 +0.020/-0.035 y=0.600 +0.020/-0.020
Blue primary | x=0.150 +0.015/-0.015 y=0.060 +0.030/-0.015
White point | Where x(sRGB)=0.3127 and y(sRGB)=0.3290 |dx|, |dy| < 0.02 |dx – dy| < 0.02
Luminance(Y) | 80 +20/-10 cd/m2
Gamma(S-g – simple gamma) | 2.2 +0.2/-0.2
B4.2.R.2 Liquid Crystal Display (LCD) complies with Windows Color Quality Specifications

Color matching capabilities supported in a color liquid crystal display must comply with the requirements defined in Section 4 of "Windows Color Quality Specifications for Liquid Crystal Display OEMs", available at http://www.microsoft.com/hwdev/color/. Stand alone LCDs are required to use the in gamut patches specified for stand alone LCDs in Section 2 of "Windows Color Quality Specifications for Liquid Crystal Display OEMs." Integrated (laptop) LCDs are required to use the in gamut patches specified for integrated LCDs in Section 2 of "Windows Color Quality Specifications for Liquid Crystal Display OEMs". In particular, the following Delta E tolerances must be met:

Average CIE 1994 Delta E* less than or equal to 10 for in gamut colors.
Maximum CIE 1994 Delta E* less than or equal to 15 for in gamut colors.
Average CIE 1994 Delta E* less than or equal to 20 for IEC 61966-4 colors.


B5.0 Input and HID

B5.1 General Input

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.

B5.1.1 General Input - Windows Compatibility

B5.1.1.1 Windows XP/Windows 2000: "Human Input Devices" in the Windows DDK
B5.1.1.2 Windows 98/Me: Follow Windows DDK if HID device
B5.1.1.3 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/input/

B5.1.1.4 Windows XP/Windows 2000: Input Device Drivers and Windows 2000

http://www.microsoft.com/hwdev/input/drv.htm

B5.1.2 General Input - Industry Standards

B5.1.2.1 IBM Personal System/2 Common Interfaces

Part No. S84F-9809: Order from IBM Customer Publications Support:
1-800-879-2755.

B5.1.2.2 USB HID references

[ INPT-0133 »; SDG3:69 »]
http://www.usb.org/developers/docs.htm

  • USB Device Class Definition for Human Interface Devices (HID), V. 1.0 or later.
  • USB HID Usage Tables, V. 1.0 or later.
  • USB Usage Tables for HID Power Devices, Release 1.0 or later.
B5.1.2.3 Input Device Class Power Management Reference Specification, Version 2.0 or later

http://www.microsoft.com/HWDEV/specs/PMref/PMinput.htm

Legacy Plug and Play Guidelines

Legacy Plug and Play Guidelines»

B5.1.3 General Input - Quality

WHQL Test Specification References:
Chapter 1: Introduction to HCT Test Specifications
plus technology-specific test specifications
Click to launch Click to launch

B5.1.3.1 Pass WHQL tests

See B1.3.

Windows XP: See "Input and HID" in the HCT documentation.

B5.1.3.2

See B5.1.4.7

B5.1.4 General Input - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 7, "Input Devices"
Click to launch Click to launch

B5.1.4.1 Any power management buttons implemented are ACPI compliant

[SYS-0003 »; SDG3:9 »]

B5.1.4.2 Hot-plugging does not damage system or device

[SYS-0030 »; SDG3:47 »]

B5.1.4.3 All input devices support Microsoft DirectInput® and work simultaneously

[ INPT-0134 »; see FAQ B5.1.5.2 ]

See "Human Input Devices " in the Windows DDK.

B5.1.4.4 DELETED
B5.1.4.5 All Human Interface Devices (HIDs) meet USB HID specifications

[ INPT-0133 »]

B5.1.4.6 Devices use USB or external bus connections rather than legacy serial or parallel

[ INPT-0135 »]

Mobile Note

PS/2-compatible mouse and keyboard can use PS/2 connectors.

B5.1.4.7 All keys/buttons are functional at an end-user level after an INF installation

B5.1.5 General Input - FAQs

B5.1.5.1 Current input device FAQs

See http://www.microsoft.com/winlogo/hardware/input/.

B5.1.5.2 Simultaneous Input Requirement [Added reference]

The built-in class drivers support simultaneous operation of multiple input devices. For information about implementing support for other drivers, see "Human Input Devices" in the Windows DDK. See also the sample code and documentation in the Windows DDK at %NTDDK%\src\wdm\hid\.
FAQ Date: May 28, 1999; January 31, 2001 (Update DDK citation)

B5.1.R General Input - Future Requirements

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


B5.2 Keyboard

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general input requirements in B5.1 are included by reference.

B5.2.1 Keyboard - Windows Compatibility

B5.2.1.1 Windows XP/Windows 2000: "Human Input Devices" in the Windows DDK
B5.2.1.2 Windows 98/Me: Follow Windows DDK if HID device
B5.2.1.3 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/input/

B5.2.1.4 Windows XP/Windows 2000: Scan Code Mapper for Windows 2000

http://www.microsoft.com/hwdev/input/W2kscan-map.htm

B5.2.1.5 Keyboard Scan Code Specification

http://www.microsoft.com/hwdev/desinit/scancode.htm

B5.2.1.6 Legacy Support for USB Keyboards and Mice and the Host Controller Driver

http://www.microsoft.com/hwdev/busbios/usbhost.htm

B5.2.2 Keyboard - Industry Standards

B5.2.2.1 Keyboard Scan Code Specification

[ INPT-0144 »]
http://www.microsoft.com/hwdev/desinit/scancode.htm

B5.2.3 Keyboard - Quality

B5.2.3.1 Pass WHQL tests

See B1.3

Windows XP: See "Keyboard" in the HCT documentation.

B5.2.3.2

See B5.1.4.7

B5.2.4 Keyboard - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 7, "Input Devices"
Click to launch Click to launch

B5.2.4.1 Any power management buttons implemented are ACPI compliant

[SYS-0003 »; SDG3:9 »]

B5.2.4.2 Hot-plugging does not damage system or device; USB keyboard is immediately functional after hot-plugging

[ SYS-0003 »; SDG3:47 »]

B5.2.4.3 USB keyboard installation does not require reboot

[ SYS-0029.1 »]

B5.2.4.4 No interference occurs between multiple keyboards

[ INPT-0143 »]

B5.2.4.5 Scan codes conform to industry standard

[ INPT-0144 »; see FAQ B5.2.5.3 ]

B5.2.4.6 Keys for Internet browser and multimedia use Microsoft APIs

[ INPT-0145 »]

See WM_APPCOMMAND in the Microsoft Platform SDK.

For information about using filter drivers to re-purpose keys, see FAQ B5.2.5.3.

B5.2.4.7 PIN data-entry keyboard

See B5.6.4.5.

B5.2.5 Keyboard - FAQs

B5.2.5.1 Current keyboard FAQs

See http://www.microsoft.com/winlogo/hardware/input/.

B5.2.5.2 USB HID to PS/2 keyboard scan codes

[ INPT-0144 »]

The correct listing of all keyboard scan codes for Windows operating systems is available at http://www.pcdesguide.org/documents/keycode.htm.
FAQ Date: May 28, 1999

B5.2.5.3 Multimedia keyboards with extra hot buttons conform to the defined scan codes or HID usages

Microsoft has defined extended scan codes for PS/2-compatible multimedia keyboards, and the USB HID Device Working Group has defined the consumer controls page. Hardware vendors should conform to these defined values and use their default functionality in order to ensure a good user experience following an upgrade or if the user doesn’t install any supplemental software. Additional software/drivers can be written to provide software remapping functionality.

Keyboard manufacturers must use consumer control or vendor-specific, top-level collections for HID hot buttons. For PS/2, vendors must use only the Extended Scancode set for hot buttons and must provide a filter driver or use a Keyboard DLL hook to perform hot-button remapping.

B5.2.R Keyboard - Future Requirements

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


B5.3 Input/Pointing

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general input requirements in B5.1 are included by reference.

B5.3.1 Input/Pointing - Windows Compatibility

B5.3.1.1 Windows XP/Windows 2000: "Human Input Devices" in the Windows DDK
B5.3.1.2 Windows 98/Me: Follow the Windows DDK if HID device
B5.3.1.3 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/input/

B5.3.1.4 Legacy Support for USB Keyboards and Mice and the Host Controller Driver

http://www.microsoft.com/hwdev/busbios/usbhost.htm

B5.3.2 Input/Pointing - Industry Standards

See B5.1.5

B5.3.3 Input/Pointing - Quality

B5.3.3.1

See B5.3.4.1

B5.3.3.2 Pass WHQL tests

See B1.3

Windows XP: See "Pointing and Drawing Devices" in the HCT documentation.

B5.3.3.3 - B5.3.3.5

See B5.3.4.1

B5.3.4 Input/Pointing - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 7, "Input Devices"
Click to launch Click to launch

B5.3.4.1 Device functions correctly
  • Wheel support (scroll, auto-scroll, pan, and zoom) in Microsoft Office 2000 and Windows Explorer.
  • In multimedia applications that require mouse support, such as Microsoft Encarta® 99 and MS-DOS-based applications.
  • When switching on-the-fly from MS-DOS-based applications to Windows.
  • Plug and Play Device Manager validates serial devices.
  • Hot-plugging does not damage system or device; USB devices are immediately functional after hot-plugging. [ SYS-0030 »; SDG3:47 »]

Mobile PC Notes:

  • Mobile PC external PS/2 pointing device detected at boot and installed correctly.
  • Mobile PC internal pointing device disabled or dual operation enabled if external device is PS/2 -compatible.

B5.3.5 Input/Pointing - FAQs

See http://www.microsoft.com/winlogo/hardware/input/.

B5.3.R Input/Pointing - Future Requirements

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


B5.4 Input/Game

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general input requirements in B5.1 are included by reference.

B5.4.1 Input/Game - Windows Compatibility

B5.4.1.1 Windows XP/Windows 2000: "Human Input Devices" in the Windows DDK
B5.4.1.2 Windows 98/Me: Follow the Windows DDK if HID device
B5.4.1.3 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/input/

B5.4.1.4 Designing HID Game Controllers for DirectInput

http://www.microsoft.com/hwdev/devdes/hidgame.htm

B5.4.2 Input/Game - Industry Standards

See B5.1.5.

B5.4.3 Input/Game - Quality

B5.4.3.1

B5.4.4.3

B5.4.3.2 Pass WHQL tests

See B1.3.

Windows XP: See "Game Devices" in HCT documentation.

B5.4.4 Input/Game - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 7, "Input Devices"
Click to launch Click to launch

B5.4.4.1 Hot-plugging does not damage system or device; USB devices are immediately functional after hot-plugging

[ SYS-0030 »; SDG3:47 »]

B5.4.4.2 Device performs as expected with multimedia applications
B5.4.4.3 All input devices support Microsoft DirectInput® and work simultaneously

B5.4.5 Input/Game - FAQs

B5.4.5.1 Current game port FAQs

See http://www.microsoft.com/winlogo/hardware/input/.

B5.4.5.2 Game pad requirements for systems [Clarification]

[INPT-0135 »]

If a game pad or joystick is included in a system, it should be implemented using USB. It is not required to include any such devices on a system.

Note: No devices that use legacy or proprietary ports can be included in a system.
FAQ Date: October 7, 1998

B5.4.R Input/Game - Future Requirements

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


B5.5 Input/Keyboard-Video-Mouse

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general input requirements in B5.1, B5.2, and B5.3 are included by reference.

B5.5.1 Keyboard/Video/Mouse - Windows Compatibility

B5.5.1.1 Windows XP/Windows 2000: "Human Input Devices" in the Windows DDK
B5.5.1.2 Windows 98/Me: Follow the Windows DDK if HID device
B5.5.1.3 Windows compatibility and implementation notes

http://www.microsoft.com/hwdev/input/

B5.5.2 Keyboard/Video/Mouse - Industry Standards

See B5.1.5.

B5.5.3 Keyboard/Video/Mouse – Quality

B5.5.3.1

See B5.5.4.7

B5.5.3.2

See B5.5.4.8

B5.5.3.3

See B5.5.4.8

B5.3.3.4 Pass WHQL tests

See B1.3

Windows XP: See "Keyboard-Video-Mouse Switch " in HCT documentation.

B5.5.4 Keyboard/Video/Mouse - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 7, "Input Devices"
Click to launch Click to launch

B5.5.4.1 Cascading switch boxes
B5.5.4.2 On-screen display for switching between machines
B5.5.4.3 Ability to switch between machines using a keyboard
B5.5.4.4 System recognizes any Plug and Play keyboard, mouse, or monitor connected to the KVM
B5.5.4.5 System resets the device ports in case a corruption results in an incorrect output signal sent from a connected device to the operating system
B5.5.4.6 All devices and cables connected to the KVM are hot pluggable and have proper icons and colors
B5.5.4.7 All the commands listed in the device’s user manual work correctly
B5.5.4.8 Only documented commands are provided
B5.5.4.9 All buttons on the Keyboard-Video-Mouse (KVM) work properly

B5.5.5 Keyboard/Video/Mouse - FAQs

See http://www.microsoft.com/winlogo/hardware/input/.

B5.5.R Keyboard/Video/Mouse - Future Requirements

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


B5.6 Smart Card Readers

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general input requirements in B5.1 are included by reference.

B5.6.1 Smart Card - Windows Compatibility

B5.6.1.1 Windows XP/Windows 2000 and Windows 98/Me: "Smart Card Devices" in the Windows DDK
B5.6.1.2 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/smartcard/

Note: Smart Card base software components must be installed before the driver on Windows 98/Me; the base components are automatically installed on Windows 2000.

B5.6.2 Smart Card - Industry Standards

B5.6.2.1 ISO/IEC DIS 7816 Identification Cards—Integrated circuit(s) cards with contacts

[ SMRT-0153 »; SDG3:196 »]

Part 1: Physical characteristics - http://www.iso.ch/cate/d29257.html.
Part 2: Dimensions and location of the contacts - http://www.iso.ch/cate/d26536.html.
Part 3: Electronic signals and transmission protocols - http://www.iso.ch/cate/d14735.html.

B5.6.2.2 Interoperability Specification for ICCs and Personal Computer Systems

http://www.pcscworkgroup.com/

B5.6.2.3 ISO/IEC 7811

[ SMRT-0153 »]

Part 1: Embossing
Part 3: Location of embossed characters on ID-1 cards
ISO/IEC 7813:1995 Identification Cards—Financial transaction cards
ISO/IEC 10373:1993 Identification cards—Test methods

B5.6.3 Smart Card - Quality

B5.6.3.1

See B5.6.4.6

B5.6.3.2 Pass WHQL tests

See B1.3.

Windows XP: See "Smart Card Readers " in HCT documentation.

B5.6.4 Smart Card - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 7, "Input Devices" - Click to launch Click to launch;
SMRT-0162 »; SDG3:196 »
Smart Card for Windows web site at http://www.microsoft.com/smartcard/

B5.6.4.1 Driver does not cause system to stop running if required resources are not available
B5.6.4.2 Driver supports multiple instances of the same device on system without problems
B5.6.4.3 Windows XP/Windows 2000: Device works properly after system resumes from S3 or hibernation state

Note: Hibernation tests on Windows 98/Me are disabled.

B5.6.4.4 Reader supports required capabilities

[SMRT-0154-0159]

  • Direct and Inverse-convention smart cards. [SMRT-0155 »]
  • 258 byte packets in T=0 and 259 byte packets in T=1. [SMRT-0156 »]
  • Smart card insertion/removal monitor. [ SMRT-0157 »]
  • PTS not required.

Reader must support negotiable and specific modes according to ISO/IEC 7816-3 (1997-12-15) Sections 6 and 7. [SMRT-0158 »]

  • 3.5795 MHz minimum clock frequency. [SMRT-0159 »]
  • 9600 bps minimum data rate.
  • Reset command [ SMRT-0154 »]
B5.6.4.5 Input device implementing a PIN data-entry keyboard complies with ISO 13491-1

[ SMRT-0162 »]

B5.6.4.6 Hot-plugging for PC Card does not cause system to stop running or other problems; USB reader is functional upon hot-plugging

[ SYS-0030 »; SDG3:47 »]

B5.6.5 Smart Card - FAQs

B5.6.5.1 Current smart card FAQs

See http://www.microsoft.com/winlogo/hardware/input/.

B5.6.5.2 PTS and Power Down citations [Correction]

The correct citation for PTS support is ISO 7816-3 (1997-12-15) Section 7. The correct citation for Power Down command is ISO 7816-3 (1997-12-15) Section 5.4. Power Down command for ISO 7816-3 is optional, but Reset command is mandatory.
FAQ Date: October 7, 1998

B5.6.R Smart Card - Future Requirements

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


B6.0 Modems

B6.1 General Modem

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.

B6.1.1 General Modem - Windows Compatibility

B6.1.1.1 Windows Modem Development Kit: "Modem Devices" in the Windows DDK

[ MOD-0366 »; SDG3:92 »]

B6.1.1.2 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/modem/

B6.1.1.3 Unimodem Diagnostics Command Reference Specification

http://www.microsoft.com/hwdev/respec/commspec.htm

B6.1.1.4 Standard Modem Command Sets and Standard Modem INFs

http://www.microsoft.com/hwdev/modem/comndset.htm

B6.1.1.5 Guidelines for WDM-based Software Modems

[ MOD-0383 »]
http://www.microsoft.com/hwdev/modem/softmodem.htm

See also FAQs B6.1.5.6, B6.1.5.7, B6.1.5.8.


B6.1.2 General Modem - Industry Standards

B6.1.2.1 No requirement

Note: The current version of "National ISDN Basic Rate Interface Terminal Equipment Generic Guidelines" provides a collection of industry specifications and standards for Integrated Services Digital Network (ISDN); see http://www.telcordia.com/index.html.

B6.1.2.2 Bellcore Technical References

http://www.telcordia.com/index.html

B6.1.2.3 Communications Device Class Power Management Reference Specification, V. 2.0

[ MOD-0381, 0382 »]
http://www.microsoft.com/hwdev/specs/PMref/PMcom.htm

B6.1.2.4 EIA Standard #ANSI/EIA-516-88

Joint EIA/CVCC Recommended Practice for Teletext: North American Basic Teletext Specification (NABTS) - http://www.tiaonline.org/.

B6.1.2.5 ETSI (European Telecommunication Standards Institute)

http://www.etsi.org/

B6.1.2.6 ITU (International Telecommunication Union) communications standards

http://www.itu.int/publications/index.html

B6.1.2.7 USB Class Definitions for Communications Devices

[MOD-0380 »; SDG3:70 »]
http://www.usb.org/developers/docs.html

Version 1.1 for External Devices.

B6.1.2.8 PHS Internal Access Forum Specification (PIAFS)

http://mitf.arib.or.jp/e/menu.html

B6.1.2.9 SII NS-2482-30

http://www.sii.co.jp/js/nshp/product/index-e.html (English); http://www.sii.co.jp/js/nshp/product/NS2482/ns2482_30.html (Japanese).


B6.1.3 General Modem - Quality

WHQL Test Specification References:
Chapter 20: Modem Test Specification
Click to launch Click to launch

B6.1.3.1 Pass WHQL tests

See B1.3.

Windows XP: See "Modem" in HCT documentation.


B6.1.4 General Modem - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 13, "Modems" - Click to launch Click to launch
Hardware Design Guide 3.0 for Windows 2000 Server, Chapter 4 - Click to launch Click to launch

B6.1.4.1 Wake on Ring (if implemented) meets OnNow requirements

[ MOD-0381, 0382 »; SDG3:103 »]

See FAQ B6.1.5.9.

B6.1.4.2 Analog modem supports standard capabilities

[MOD-036x; SDG3:10x]

  • V.250 Extended AT Command Set (formerly V.25 ter). [ MOD-0368 »; SDG3:101 »; see also FAQ B6.1.5.3]
  • modem supports country selection +GCI. [ MOD-0368 »]
  • If implemented, wireless/cellular modem supports appropriate control commands. [ MOD-0368 », MOD-0376 », MOD-0386-0388 »; SDG3:100 »]
  • V.90 connectivity, V.42 Link Access Protocol, Modem (LAPM), V.42 bis, and V. 80 Synchronous Access data protocols. [ MOD-0369 »; SDG3:104 »]
  • Connection to two distinct V.90 host modems (such as 3Com and Conexant) at 40 Kbps or better.
  • Modem call control supports media detection using V.251. [ MOD-0370 »]
  • If implemented, modem supports caller ID reporting. [MOD-0376 »»; see also FAQ B6.1.5.10]
  • If implemented, voice modem supports ITU V.253. Voice modem optionally supports speakerphone. [MOD-0374 »; SDG3:110 »; see also FAQ B6.1.5.4]
  • Fax—14.4 Kbps (V.17) with Class 1 (TIA-578-A) command set. [ MOD-0371 »; SDG3:106 »]
B6.1.4.3 Controller-based modem supports additional capabilities
  • 9.6 Kbps connectivity to analog modem.
  • Connection to reference modem; see test documentation for list.
  • Error control and blind dial.
  • AT commands:
    ATA - accept ringing
    ATD - dial
    ATE - echo setting
    ATH - hangup
    ATI - get modem information
    S0 - S0 register (0 value is to disable to accept ringing)
    ATV - response code style
    ATZ - reset
    - - Initialize
    - - Hard/Soft flow control
B6.1.4.4 PIAFS modem supports additional capabilities
  • 32 Kbps (PIAFS 1.0) connectivity to PIAFS modem.
  • Connection to DC-6S in PIAFS 1.0 and to SII NS-2482-30 (dial-up).
  • Modem generates appropriate error messages for delayed and blacklisted numbers (where applicable). [ MOD-0372 »; SDG3:108 »]
B6.1.4.5 ISDN modem

See B7.4.

B6.1.4.6 DELETED
B6.1.4.7 Global System for mobile communications or digital cellular phone support, if implemented, includes required command and protocol support

[ MOD-0387 »]

B6.1.4.8 Analog V.90 modem tested in conjunction with digital V.90 modems commonly deployed by ISPs

[ MOD-0377, 0378, 0379 »]

Telecommunications Industry Association (TIA) TSB-38 provides detailed test procedures and criteria.

  • Operation on impairment combination 2C4 as specified in ITU-T Recommendation V.56 bis.
  • Modem must be able to repeatedly connect, with an overall call completion success ratio of 97 percent with a minimum of 50 iterations, and without the modem stalling in an unresponsive, inoperable state.
  • Modem pair must be able to sustain the connection for at least 30 minutes, at no less than 90 percent of the initial connection rate, with no more than 1 retrain, using the same TSB-3800 line I01d-loop 3 specified for use under B6.1.4.
  • E-mail: Microsoft Outlook® Express over Microsoft Hotmail®.
  • Web browsing: Internet Explorer.
  • Video teleconferencing using H.323: Microsoft NetMeeting®.
B6.1.4.9 Telephony applications meet communication and performance requirements

[ MOD-0389, MOD-0390 »]

Note: If a future ITU recommendation equivalent to TIA-3800 for the testing of pulse-coded modulation (PCM) modem operation is developed, passing such tests could become a requirement in future versions the Windows Logo Program.

B6.1.4.10 Windows Whistler Advanced Server: Data modem supports digital connection to support host-side V.90 operation

[ SDG3:105 »]


B6.1.5 General Modem - FAQs

B6.1.5.1 Current Modem FAQs

See http://www.microsoft.com/winlogo/hardware/modem/.

B6.1.5.2 DELETED

Modems are not required on any system.
FAQ Date: January 31, 2001

B6.1.5.3 Unimodem required commands [Clarification]

[MOD-0368 »; SDG3:101 »]

Windows Unimodem does not use the following commands directly; therefore, these are not in the sample INF and are not required: +ICF, +MA, +EB, +ESR, +ETBM. These commands are only required if the function is controllable in the modem by way of AT commands; in that case, the standard V.250 commands defined here must be included.
FAQ Date: October 7, 1998

B6.1.5.4 Voice recording and playback capabilities [Logo Program correction]

[MOD-0374 »; SDG3:110 »]

The capability for voice recording and playback (+VTX, +VRX) is not required.
FAQ Date: July 8, 1999

B6.1.5.5 DELETED
B6.1.5.6 WDM support for driver-based modems [Logo Program clarification]

[ MOD-0383 »]

WDM support for driver-based modems is required for Windows Me and Windows XP/Windows 2000. For information about the Ccport.sys QFE for Windows 98, see http://www.microsoft.com/hwdev/devdes/modem_up.htm.
FAQ Date: July 28, 1999; revisions August 26, 1999, March 3, 2000

B6.1.5.7 Total execution time for DPCs queued by a WDM modem [Clarifications]

At any instant in time, the total execution time required for all delayed procedure calls (DPCs) that have been queued by a WDM driver-based modem, but have not dequeued and started executing, should not exceed 500 milliseconds.

A WDM driver-based modem should not continuously disable thread preemption for more than 4.4 milliseconds. This guideline accommodates 400 microseconds of interrupts being disabled together with two back-to-back episodes of 2.0 milliseconds of extended processing at DISPATCH_LEVEL, as up to four 500-microsecond DPCs execute sequentially.
FAQ Date: October 7, 1998

B6.1.5.8 WDM modem latency tolerances [Clarifications]

A driver-based modem should be able to tolerate:

  • A period of 4 milliseconds with interrupts disabled.
  • A continuous period of 8 milliseconds during which a queued DPC is held off from execution, possibly by other DPCs.
  • A 16-millisecond period when thread scheduling is continuously disabled.

See http://www.microsoft.com/hwdev/devdes/modem_up.htm.
FAQ Date: October 7, 1998

B6.1.5.9 Modem supports wake-up events [Clarification]

[MOD-0381, 0382 »; SDG3:102 »]

PCI modems must support power states D0 and D3. PCI devices are required to support the D3 state on a PCI 2.2-enabled system with auxiliary power. On all other power-managed buses (such as USB), support for either D2 or D3 state is acceptable. Modem drivers must accept power management IRPs.
FAQ Date: October 7, 1998; June 14, 2000

B6.1.5.10 Analog modem correctly reports caller ID [Clarification]

For hardware-based modems, see ITU-T V253 section 9.2.3.1 for details about correctly implementing caller ID reporting.

Note: Software-based modems are not required to capture caller ID while the system is either in ACPI S3 sleep state or resuming from S3 state.
FAQ Date: May 08, 2001


B6.1.R General Modem - Future Requirements

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


B7.0 Network Devices

Requirements for network components designed for servers running Windows 2000/Windows Whistler Datacenter Server, including LAN and wide area network (WAN) server network adapters, are not provided in this appendix, which focuses solely on components for desktop and mobile client PCs and servers running Windows 2000/Windows Whistler Server or Advanced Server.

B7.1 General Network

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.

B7.1.1 General Network - Windows Compatibility

B7.1.1.1 NDIS 5.0 miniport driver model: "Network Devices and Protocols" in the Windows DDK

[ NET-0245 », NET–0292 »; SDG3:78 »]

B7.1.1.2 Drivers for connection-oriented media: "Connection-Oriented NDIS" in the Windows DDK

NDIS 5.0 CoNDIS miniports are preferred, but NDIS 4 WAN miniports are acceptable.

B7.1.1.3 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/network/

B7.1.1.4 Windows XP/Windows Whistler Server/Windows 2000/Windows Me: Windows 2000 network INF format

[ NET-0293 »; SDG3:78 »]

"Creating Network INF Files" in the Windows DDK; see also http://www.microsoft.com/hwdev/devdes/netinf.htm.

Note: Windows XP/Windows 2000/Windows Whistler Server and Windows Me share the same INF search path (that is, .nt in the decorated INF file).

B7.1.1.5 Driver works correctly with Microsoft network clients and protocols

[NET-0291 »; SDG3:78.4 »]


B7.1.2 General Network - Industry Standards

B7.1.2.1 Network Device Class Power Management Reference Specification, V. 2.0

[ NET-0289 »; SDG3:81 »]
http://www.microsoft.com/hwdev/specs/PMref/PMnetwork.htm

B7.1.2.2 Home Phoneline Networking Alliance (HomePNA) 1.0 specification or later

[NET-0285 »]
http://www.homepna.org

B7.1.2.3 PCI Bus Power Management Interface Specification, Revision 1.1 or later

[PCI-0130 »; SDG3:37 »]
http://www.pcisig.com/specs.html

B7.1.2.4 USB Communications Class Device 1.1 or later

[USB-0088 »; SDG3:88 »]
http://www.usb.org/developers/devclass.html


B7.1.3 General Network - Quality

WHQL Test Specification References:
Chapter 23: Network Adapter Test Specification
Click to launch Click to launch

B7.1.3.1 Pass WHQL tests

Windows XP: see "Network Devices" in the HCT documentation.

B7.1.3.2

See B7.1.3.1

B7.1.3.3

See B7.1.4.1

B7.1.3.4

See B7.1.3.1

B7.1.3.5

See B7.1.4.1

B7.1.3.6

See B7.1.4.10


B7.1.4 General Network - Windows Experiences

Design Guideline References:
PC 2001 System Design Guide, Chapter 14, "Network Communications" - Click to launch Click to launch
Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server, Chapter 4 - Click to launch Click to launch

B7.1.4.1 Basic device and driver requirements
  • UI and strings are correct, and Help files exist and are correct for network device installed.
  • Adapter automatically senses presence of functional network connection. [ NET-0246 »; SDG3:81 »]
  • Adapter automatically senses transceiver type. [ NET-0247 »;SDG3:82 »]
  • Adapter can transmit packets from buffers aligned on any boundary. [ NET-0248 »; SDG3:83 »]
  • Adapter communicates with driver across any bridge. [ NET-0249 »; SDG3:84 »]
  • Windows Me/Windows XP: Adapter supports filtering for at least 32 multicast addresses. [ NET-0254 »]

Windows Whistler Server: Adapter supports filtering for at least 32 multicast addresses. [ NET-0254 »; SDG3:92 »]

  • Adapter and driver support promiscuous mode. [ NET-0255 »; SDG3:96 »]

Windows Whistler Server: Adapter and driver support multicast promiscuous mode. [ SDG3:97 »]

  • Driver makes only NDIS library calls or WDM system calls. [ NET–0292 »; SDG3:78.5 »]
  • PCI network adapters are bus masters. [ NET-0251 »; SDG3:87 »]

Note: CardBus and Mini-PCI implementations do not need to be bus masters.

B7.1.4.2 Any included diagnostics or utilities work and can be accessed from the NCP Advanced Properties page
B7.1.4.3 ATM network devices

See B7.5.4.4.

B7.1.4.4 Features such as WOL and D0-D3 power states are available and device correctly wakes from D3cold

[ NET-0290 »; SDG3:81 »]

Windows XP: PCI-based network adapters support wake from D3cold.

Note: Wake On LAN (WOL) support is not required in the following cases:

  • Bus-powered USB devices.
  • Multifunction, broadband (such as cable modems), LAN emulation, Wireless LAN, or Server LAN (such as multiport, FDDI, or Gigabit Ethernet) devices.
  • Windows 98/Me: PC Card and CardBus devices; WOL Pattern Match capabilities.
  • Windows XP/Windows 2000: PC Card and CardBus devices.

Mobile PC Note: For mobile PCs, WOL is not required.

B7.1.4.5 Remote boot and remote install options for connection-less LAN devices on PCI bus

[ NET-0256 »; SDG3:94,95 »]

Windows XP Professional: Network adapters with PXE support must be available as an option at point of purchase for systems preinstalled with Windows XP Professional. See A1.1.4.

Windows 2000 Server/Windows Whistler Server: Server systems must provide PXE-based support if a network adapter with remote new system setup capabilities is provided with the system.

This is not a requirement for CardBus adapters or for Mini-PCI adapters that are not sold as a part of or with a PC system.

B7.1.4.6 Windows XP/Windows Me: HomePNA technology, if implemented, complies with HomePNA 1.0 or later, with NDIS 5.0 miniport driver

[ NET-0285 »]

B7.1.4.7 Infrared device supports both fast IR and serial IR, and unattended driver installation requirements

[ NET-0281, 0282 »; SDG3:140-142 »]

B7.1.4.8 Full-duplex adapter automatically detects and switches to full duplex mode

[ NET-0253 »; SDG3:80 »]

B7.1.4.9 Plug and Play capabilities support multiple adapters; all resource settings are reported in the UI

[ NET-0286, 0287 »; SDG3:89 »]

B7.1.4.10 Wireless networking requirements

[ NET-0278,0279 »; SDG3:143-145 »]

  • Media adapter drivers support wireless extensions to NDIS.
  • IEEE 802.11 wireless networking adapters support 11 Mb/s signaling using Direct Sequence Spread Spectrum.
  • Windows XP: Bluetooth Host Controllers (HCI) — Windows uses Bluetooth Wireless technology as a wireless local bus and cable replacement. Therefore, Bluetooth HCI (radios with PC interface) do not need NDIS miniports. Requirements for Bluetooth HCI are listed in B2.3.4.5.
  • Network adapter and driver supports priority for IEEE 802-style networks. [ NET–0257 »; SDG3:98 »]
B7.1.4.11 External networking devices support standard control interfaces as applicable
  • All external USB networking devices support USB Communications Class Device 1.1. [ NET-0288 »; SDG3:88 »]
  • Intermediate NDIS 5.0 miniport driver provided adapters that connects using IEEE 1394 or USB buses. [ NET–0246 »; SDG3:78.3 »]
B7.1.4.12 Windows Whistler Server: Additional adapter and driver support

[SDG3:7x,8x]

  • NDIS 5.0 miniport driver supports high-performance send and receive calls. [ SDG3:79 »]
  • Network adapter supports configuration capabilities and registry settings for performance tuning. [ SDG3:85 »]
  • PCI network adapter properly supports higher-level PCI commands. [ SDG3:86 »]
  • If the network device is for connection-oriented media, it must meet connection-oriented miniport driver and call manager driver requirements. [ SDG3:78.2 »]


B7.1.5 General Network - FAQs

B7.1.5.1 Current Network Device FAQs

See http://www.microsoft.com/winlogo/hardware/network/.

B7.1.5.2 NDIS status codes and indication mechanisms

See NdisMIndicateStatus in the Windows DDK.

B7.1.5.3 PCI network adapters for large-memory systems support the PCI DAC

[Server Design FAQs - SDG3:30-32 »]

Requirements for PCI adapters to support the PCI DAC command are defined in A1.1.6. For network devices, at a minimum this includes adapters implemented in or designed as high-speed network adapters -- Gb Ethernet and Gb+, ATM, and FDDI -- for systems that support more than 4 GB of system memory. The exceptions to this requirement are 10/100 Ethernet adapters and embedded 10/100 Ethernet devices.

See "Large Memory Enabled Device Driver Hardware and Software Requirements" in the Windows DDK; design guidelines are summarized at http://www.microsoft.com/hwdev/newPC/PAEdrv.htm

Requirements for systems that implement support for WinSock Direct (WSD) are now defined at A6.4.8. [For design guidelines, see SDG3:67 »]


B7.1.R General Network - Future Requirements

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

B7.1.R.1 All external IEEE 1394 network adapters must support Remote NDIS over SBP-2

[NET-0288 »; SDG3:88 »]

B7.1.R.2 NDIS 5.0 miniport driver is deserialized

[ NET–0252 »; SDG3:78.7 »]


B7.2 Cable Modem

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general network device requirements in B7.1 are included by reference, except for requirements specific to connection-less or LAN devices.

B7.2.1 Cable Modem - Windows Compatibility

B7.2.1.1 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/network/cable/

B7.2.2 Cable Modem - Industry Standards

B7.2.2.1 Cablelabs DOCSIS Data-Over-Cable Service Interface Specifications

[NET-0262 »; SDG3:90 »]
http://www.cablemodem.com/

B7.2.3 Cable Modem - Quality

B7.2.3.1 Pass WHQL tests

See B1.3.

Windows XP: See "Cable Modem" in HCT documentation.

B7.2.4 Cable Modem - Windows Experiences

B7.2.4.1 Performance meets minimal expectations on high-end broadband network devices

[ NET-0266 »]

B7.2.4.2 Integrated cable modem meets Windows Logo Program network adapter requirements

[ NET-0263 »; SDG3:127 »]

B7.2.4.3 Integrated cable modem exposes an ATM or Ethernet interface

[ NET-0264 »; SDG3:128 »]

B7.2.5 Cable Modem - FAQs

See B7.1.5.

B7.2.R Cable Modem - Future Requirements

See B7.1.R.


B7.3 DSL Device

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general network device requirements in B7.1 are included by reference, except for requirements specific to connection-less or LAN devices.

B7.3.1 DSL Device - Windows Compatibility

B7.3.1.1 Windows compatibility and implementation notes

http://www.microsoft.com/hwdev/network/dsl/

B7.3.1.2 External DSL Modems Design Guidelines

http://www.microsoft.com/hwdev/network/dsl/extdslmodems.htm

B7.3.2 DSL Device - Industry Standards

B7.3.2.1 An Interoperable End-to-End Broadband Service Architecture over ADSL System

http://www.microsoft.com/hwdev/network/dsl/

B7.3.2.2 ATM User-Network Interface Specification, V. 3.1

http://www.atmforum.com/atmforum/specs/approved.html

B7.3.2.3 DSL modem industry standards

[ NET-0273, 0274, 0275 »; SDG3:95 »]

  • ITU-T G.994.1, G.991.1, G.992.2.
  • T1.413 Issue 2 (G.992.1).
  • U.S. T1 Committee Technical Report TR-59.

B7.3.3 DSL Device - Quality

B7.3.3.1 Pass WHQL tests

See B1.3.

Windows XP: See "DSL Devices" in HCT documentation.

B7.3.4 DSL Device - Windows Experiences

B7.3.4.1 All requirements in B7.1.3, except B7.1.3.4 (WOL and power management)

[ NET-0266 »]

Performance meets minimal expectations on high-end broadband network devices.

ATM/DSL simultaneous connections require support for 32 or more connections.

B7.3.4.2 Integrated ADSL modem meets Windows Logo Program network adapter requirements

[ NET-0273-0276 »; SDG3:122 »]

B7.3.5 DSL Device - FAQs

B7.3.5.1

See B7.1.5

B7.3.5.2 ATM/ADSL simultaneous connections

[NET-0266 »; SDG3:112 »]

Updated requirements are defined in B7.3.4.1.

B7.3.R DSL Device - Future Requirements

See B7.1.R.


B7.4 ISDN Net Device

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general network device requirements in B7.1 are included by reference, except for requirements specific to connection-less or LAN devices.

B7.4.1 ISDN Net Device - Windows Compatibility

See B7.1.1.

B7.4.2 ISDN Net Device - Industry Standards

See B7.1.2.

B7.4.3 ISDN Net Device - Quality

See B7.1.3.

Windows XP: See "WAN ISDN Network Devices" in HCT documentation.

B7.4.4 ISDN Net Device - Windows Experiences

B7.4.4.1 Performance meets minimal expectations on high-end broadband network devices
B7.4.4.2 Device meets Windows Logo network adapter requirements

[ NET-0258 »; SDG3:134 »]

B7.4.4.3 Device supports synchronous high-level data link control framing

[ NET-0259 »; SDG3:135 »]

B7.4.4.4 NDIS interface and driver support raw, unframed synchronous B channel I/O

[ NET-0260 »; SDG3:136 »]

B7.4.4.5 Driver supports unattended installation, with limitations

[ NET-0261 »; SDG3:137 »]

B7.4.4.6 Device includes software-selectable terminating resistors

[ NET-0262 »; SDG3:139 »]

B7.4.4.7 ISDN modem supports asynchronous-to-synchronous conversion and RFC 1662

[ MOD-0385 »; SDG3:131 »]

B7.4.4.8 ISDN modem supports required command set

[ MOD-0384 »; SDG3:129 »]

B7.4.5 ISDN Net Device - FAQs

See B7.1.5.

B7.4.R ISDN Net Device - Future Requirements

See B7.1.R.


B7.5 ATM Device

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general network device requirements in B7.1 are included by reference, except for requirements specific to connection-less or LAN devices.

B7.5.1 ATM Device - Windows Compatibility

See B7.1.1.

B7.5.2 ATM Device - Industry Standards

See B7.1.2.

B7.5.3 ATM Device - Quality

B7.5.3.1

See B7.1.3

B7.5.3.2 Pass WHQL tests

Windows XP: See "ATM Devices" in HCT documentation.

B7.5.4 ATM Device - Windows Experiences

B7.5.4.1 DELETED

See B7.5.4.2, B7.5.4.3.

B7.5.4.2 ATM adapter can schedule calls on an unspecified bit rate (UBR) virtual circuit at a peak rate less than the line or link rate

[ NET-0270 »; SDG3:117 »]

Asynchronous Transfer Mode (ATM) Adapter that supports call responds to F4 and F5 calls. [ NET-0272 »; SDG3:119 »]

B7.5.4.3 ATM/DSL simultaneous connections require support for 32 or more connections

[ NET-0266 »; SDG3:112 »]

B7.5.4.4 ATM network devices meet minimal expectations

[ NET-0266-0272 »; SDG3:114-120]

  • UBR service type. [ NET-0267 »; SDG3:114 »]
  • Minimum number of simultaneously active VBR or CBR connections. [ NET-0268 »; SDG3:115 »]
  • Traffic shaping. [ NET-0269 »; SDG3:116 »]
  • Enforces PCR on UBR virtual circuits. [ NET-0270 »; SDG3:117 »]
  • Dynamic link speed configuration. [ NET-0271 »; SDG3:118 »]
  • OAM. [ NET-0272 »; SDG3:119 »]
  • Buffer chaining (Tx + Rx). [ SDG3:120 »]

B7.5.5 ATM Device - FAQs

See B7.1.5.

B7.5.R ATM Device - Future Requirements

See B7.1.R.


B8.0 Printers

B8.1 General Printers

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.

B8.1.1 Printers - Windows Compatibility

B8.1.1.1 Windows XP/Windows 2000: "Printer Drivers and Spooler Components" in the Windows DDK
B8.1.1.2 Windows 98/Me: "Printer INF File Extensions," "Printer-Specific INF File Extensions Reference," and DEVMODE function in the Windows Me DDK
B8.1.1.3 ICM APIs and functionality for Windows 98/Me and Windows XP/Windows 2000

Microsoft Platform SDK and "Color Management for Displays" in the Windows DDK.

B8.1.1.4 Windows compatibility and implementation notes

http://www.microsoft.com/hwdev/print/

B8.1.1.5 Windows XP/Windows 2000: IEEE 1394 printing devices using SBP-2 protocol conform to guidelines in "SBP-2 Support and Windows 2000"

[ 1394-0094 »]
http://www.microsoft.com/hwdev/print/sbp2_w2000.htm
See also "Identifiers for 1394 Devices" in the Windows DDK.

B8.1.2 Printers - Industry Standards

B8.1.2.1 Universal Serial Bus Device Class Definition for Printing Devices, V. 1.0 or later

[PRNT-0294 »; SDG3:73 »]
http://www.usb.org/developers/devclass.html

B8.1.2.2 Legacy Plug and Play Guidelines

[PRNT-0294 »]

For IEEE 1284 or serial port. See Legacy Plug and Play Guidelines. »

B8.1.2.3 ICC Profile Format Specification, Spec ICC.1:1988-09 and Addendum 2, ICC.1A:1999-04

[PRNT-0300 »]
http://www.color.org/profiles.html

B8.1.2.4 Windows Color Quality Specifications for Printer OEMs

[PRNT-0301 »]
http://www.microsoft.com/hwdev/color/

B8.1.3 Printers - Quality

WHQL Test Specification References:
Chapter 25: Printer Test Specification
Click to launch Click to launch

B8.1.3.1 Pass WHQL tests

See B1.3.

Windows XP: See "Printers" in HCT documentation.

B8.1.3.2 - B8.1.3.6

See B8.1.4.10

B8.1.4 Printers - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 15, "Printers"
Click to launch Click to launch

B8.1.4.1 Network Point-and-Print capability accommodates file-number limits and other differences between operating systems that might run on the client and server

[ PRNT-0303 »]

B8.1.4.2 Device associates an ICC profile

[ PRNT-0300 »]

Devices that create sRGB output must associate the "sRGB Color Space Profile.icm" Windows default ICC profile with the device.

Devices using a vendor-supplied ICC profile or profiles must associate this profile or profiles with the device.

B8.1.4.3 Windows XP/Windows 2000: Network printer supports standard port monitor

[ PRNT-0295 »]

B8.1.4.4 Port monitor software meets DDK guidelines

[ PRNT-0302 »]

See "Port Monitors" in the Windows DDK and "Local Port Monitor Design and Implementation Notes" in the Windows Me DDK.

B8.1.4.5 Device is available immediately following installation

[ PRNT-0304 »]

B8.1.4.6 Print device provides non-legacy port connection

[ PRNT-0294 », 0297 »; see FAQ B8.1.5.4]

USB-to-printer port adapters comply with USB specifications. [ SDG3:73 »]

B8.1.4.7 Color printer complies with Windows Color Quality Specifications for Printer OEMs

[ PRNT-0301 »]

B8.1.4.8 USB printer driver takes advantage of built-in operating system support for USB printers

Windows DDK - see "USB Printing" in the DDK

B8.1.4.9 Plug and Play IDs are specific, and INF [Install] sections only key off the most specific IDs

As described in the Windows DDK; see references in B8.1.1.

B8.1.4.10 Printer and driver capabilities requirements
  • Printable regions accuracy. [ PRNT-0305 »]
  • Printer driver runs only in user mode. [PRNT-0307 »; see also FAQ B8.1.5.2]

See "Choosing User Mode or Kernel Mode" in the Windows DDK.

  • DevMode structure support [ PRNT-0299 »]

Windows XP/Windows 2000: "DEVMODEW" in the Windows DDK.
Windows Me/98: "DEVMODE" in the Windows Me DDK.

  • Windows 98/Me: Dynamic load/unload from RAM
  • Printer INF file and installation. [ PRNT-0298 »]

Windows XP/Windows 2000: "Printer INF Files" in the Windows DDK.
Windows Me/98: "Installing and Using USB Printers with Microsoft Windows" and "Printer INF File Extensions" in the Windows Me DDK.

B8.1.5 Printers - FAQs

B8.1.5.1 Current Print Device FAQs

See http://www.microsoft.com/winlogo/hardware/printer/.

B8.1.5.2 Windows XP/Windows 2000: Printer driver runs only in user mode [Clarification]

[PRNT-0307 »]

Testing applies as of March 31, 2000 on new drivers. Resubmissions of existing kernel mode drivers are exempt from this requirement.
FAQ Date: July 8, 1999; revisions July 12, 1999

B8.1.5.3 ECP mode [Logo Program Clarification]

[PRNT-0294 »]

Support for ECP mode is required; support for bi-direction mode is not required.
FAQ Date: May 4, 2000

B8.1.5.4 Printers provide a non-legacy port [Logo Program Clarification

[PRNT-0294, 0297 »]

Printers use non-legacy port connections such as USB, IEEE 1394, or Ethernet. Printers can also include a legacy parallel interface in addition to the required non-legacy port connections. USB-to-printer port adapters are not considered an alternative non-legacy interface.
FAQ Date: January 31, 2001

B8.1.R Printers - Future Requirements

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

B8.1.R.1 USB Printer reports unique serial number

USB printers must report a unique serial number to allow the operating system to differentiate between two identical printers attached to the same system and to support a printer that is moved from one USB port to another.


B9.0 Still Image Devices

B9.1 General Still Image Devices

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.

B9.1.1 Still Image Devices - Windows Compatibility

B9.1.1.1 Still image driver support

Note: Digital still cameras that stream video while tethered must have WDM stream class drivers. [IMAG-0318 »]

  • Windows Me: Vendor provides a WIA driver or supports PIMA 15740 in camera firmware. [IMAG-0317 »]
  • Windows XP: Scanner vendors must provide a WIA driver. Digital camera vendors can implement one of the following solutions:
  • Provide a camera-specific WIA driver.
  • Ensure the camera firmware adheres to the mandatory commands in the PIMA 15740 standard.
  • Implement support compliant with the USB Mass Storage Class Bulk-Only specification and use the Microsoft Usbstor.sys storage driver.

See "Still Image Drivers" in the Windows DDK. See also FAQ B9.1.5.4.

  • Windows 2000/Windows 98: Driver supports STI driver interface - "Still Image Drivers" in Windows DDK.
  • Driver supports TWAIN 1.7, if TWAIN support is implemented. [ IMAG-0319 »]
B9.1.1.2 "Color Management for Still Image Devices" in the Windows DDK

[IMAG-0310 »]

B9.1.1.3 Windows compatibility and implementation notes (general)

http://www.microsoft.com/hwdev/stillimage/

B9.1.1.4 Windows XP/Windows Me: Windows Image Acquisition (WIA) driver support

[IMAG-0312 »]
http://www.microsoft.com/hwdev/wia/

B9.1.1.5 Windows 2000: Still Image Architecture (STI)

http://www.microsoft.com/hwdev/stillimage/w2STI.htm


B9.1.2 Still Image Devices - Industry Standards

B9.1.2.1 Photographic and Imaging Manufacturers Association (PIMA) 15740, "Requirements for communication with digital photography devices"

[IMAG-0311 », 0316 »]
http://www.pima.net/standards/it10a.htm#15740

B9.1.2.2 USB Still Image Capture Device Definition, V.0.9 or later

[IMAG-0311 »]
http://www.usb.org/developers/docs.html

B9.1.2.3 Legacy Plug and Play Guidelines

[Legacy Plug and Play Guidelines »]

B9.1.2.4 ICC Profile Format Specification, Spec ICC.1:1988-09 and Addendum 2, ICC.1A:1999-04

[IMAG-0310 »]
http://www.color.org/profiles.html

B9.1.2.5 Design Rule for Camera File system (DCF) Specification

http://www.jeida.or.jp/document/standard/jeida49-2.html#English

B9.1.2.6 Specification for Exchangeable image file format (EXIF)

EXIF is used in the digital still cameras and related systems.

http://www.jeida.or.jp/document/standard/jeida49.html


B9.1.3 Still Image Devices - Quality

WHQL Test Specification References:
Chapter 13: Still Imaging/WIA Test Specification
Click to launch Click to launch

B9.1.3.1 - B9.1.3.3

See B9.1.1.1

B9.1.3.4 Pass WHQL tests

See B1.3.

Windows XP: See "Scanners" and "Cameras" in HCT documentation.


B9.1.4 Still Image Devices - Windows Experience

Design Guidelines:
WIA at http://www.microsoft.com/hwdev/wia/
PC 2001 System Design Guide, Chapter 16, "Digital Still Image Peripherals" - Click to launch Click to launch

B9.1.4.1 Device uses USB or IEEE 1394 connection

[ IMAG-0309 »; see also FAQ B9.1.5.3]

B9.1.4.2 Device associates an ICC profile

[ IMAG-0310 »]

Devices that create sRGB output must associate the "sRGB Color Space Profile.icm" Windows default ICC profile with the device.

Devices using a vendor-supplied ICC profile or profiles must associate this profile or profiles with the device.

B9.1.4.3- B9.1.4.5 DELETED
B9.1.4.6 Digital camera uses PC-compatible file system for removable storage

[ IMAG-0313 »; see also FAQ B9.1.5.2]

  • Media integrates an ATA controller
  • Device file system installs via the Windows XP/Windows 2000 Installable File System.
  • Device ships with a Windows Media Device Manager (WMDM) pluggable service provider.
B9.1.4.7 Daisy-chained parallel port imaging devices are Plug and Play capable

[INPT-0140 »]

As described in Legacy Plug and Play Guidelines. »

B9.1.4.8 Imaging devices resolve at least 1/4 line per claimed pixel resolution in both directions

[ IMAG-0315 »]

B9.1.4.9 Digital camera stores images in JPEG-compressed file format

[ IMAG-0314 »]

B9.1.4.10 Asynchronous imaging device with an IEEE 1394 interface uses SBP2Port

[ IMAG-0321 »]


B9.1.5 Still Image Devices - FAQs

B9.1.5.1 The current still image FAQs

See http://www.microsoft.com/winlogo/hardware/stillimage/.

B9.1.5.2 ATA Flash Cards [Logo Program clarification]

[ IMAG-0313 »]

A PC Card ATA flash card must support at least one LogConfig with an IRQ resource. Under Windows Me, Configuration Manager (which is responsible for assigning resources) filters the LogConfigs of ATA cards. If an IRQ is not available, then that configuration is ignored. The operating system will not assign resources for a device that has no LogConfig with an IRQ. This requirement is effective July 1, 2000.
FAQ Date: December 22, 1999

B9.1.5.3 Windows Me: USB Mass Storage and Cameras [Clarification]

It is possible to create a camera that appears to the operating system to be a storage device (and not a camera) by supporting the USB Mass Storage Class specification in camera firmware. In this case, the device is a storage device and must adhere to storage specifications. However, Microsoft will not grant a "Designed for Windows" logo to cameras that only appear as hard drives to Windows. The reason for this exclusion is that such a device is specifically not designed for Windows, and it loses functionality when attached to a Windows-based PC. A camera that is designed for Windows retains camera functionality when attached, so the user can take advantage of the imaging feature sets in Windows Me and Windows XP.
FAQ Date: November 24, 1999

B9.1.5.4 Windows Me/Windows XP—Requirement for Still Image Devices [Clarification]

Still image devices are supported under WIA architecture or PIMA 15740. For the Windows Logo Program, the scanner vendor must provide a WIA driver. For digital cameras, however, vendors have theses options:

  • Digital camera vendors can implement one of the following solutions:
  • Provide a camera-specific WIA driver.
  • Ensure the camera firmware adheres to the mandatory commands in the PIMA 15740 standard.
  • Implement support compliant with the USB Mass Storage Class Bulk-Only specification and use the Microsoft Usbstor.sys storage driver.

These choices are available because Windows Me and Windows XP provide a WIA driver for PIMA 15740 and USB Mass Storage Class devices, accomplishing the same functional purpose.

Note: Optimal user experience is seamless integration of the imaging peripheral with the Windows environment. In Windows 2000 and Windows 98, event-driven STI user-mode minidrivers remove unnecessary steps for device interaction with the operating system. In Windows XP and Windows Me, the operating system detects hot-pluggable WIA devices such as digital cameras, providing a seamless interface with the device. For persistent-connection devices, such as scanners, implementation of device events via buttons and sensors will deliver this functionality after initial installation.
FAQ Date: December 22, 1999


B9.1.R Still Image Devices - Future Requirements

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

B9.1.R.1 Digital camera design ensures the PC can both get and set camera properties using WIA driver interface

Future versions of the operating system will provide functionality that allows the user to change stored values on their digital cameras from the PC.


B10.0 Storage Controllers and Devices

B10.1 General Storage

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
BIOS support for boot devices: see A1.1.4.

B10.1.1 General Storage - Windows Compatibility

B10.1.1.1 Windows XP/Windows 2000: "Storage Devices" in the Windows DDK

[SYS-0025.2 »; SDG3:147 »]

B10.1.1.2 Windows 98/Me: "IOS" in the Windows Me DDK

[SYS-0025.6 »; SDG3:147 »]

B10.1.1.3 Int 13h Extensions

[ BIOS-0011 »; SDG3:147 »]

"Int 13 Extension APIs" in the Windows Me DDK.

Option ROM or BIOS supports Int 13 for boot devices.

B10.1.1.4 Windows compatibility and implementation notes

http://www.microsoft.com/hwdev/storage/


B10.1.2 General Storage - Industry Standards

B10.1.2.1 DELETED
B10.1.2.2 ATA/ATAPI-5

[ STOR-0347 »; SDG3:177 »]
ATA standards: Global Engineering Documents at http://global.ihs.com/.

B10.1.2.3 ATAPI Removable Media Device BIOS Specification (ARMD), V. 1.0

http://www.phoenix.com/products/specs.html

B10.1.2.4 MMC-2 - Multi-Media Command Set-2

[STOR-0342 »; SDG3:149 »]
Global Engineering Documents at http://global.ihs.com/ (incorporates information defined in Enhanced Music CD Specification).

B10.1.2.5 SCSI Reduced Block Commands (RBC), NCITS.330:2000)

[STOR-0342 »; SDG3:149 »]

Global Engineering Documents at http://global.ihs.com/.

B10.1.2.6 Small Computer Interface (SCSI-2)

[X3.131:1994] standard; Global Engineering Documents at http://global.ihs.com/.

B10.1.2.7 Compaq-Intel-Phoenix BIOS Boot Specification, V.1.01; El Torito—Bootable CD-ROM Format Specification, V.1.0

[ BIOS-0005.1 »; SDG3:12 »]
http://www.phoenix.com/techs/specs.html

B10.1.2.8 Media Status Notification Support Specification, V. 1.03

[ STOR-0342 »; SDG3:149 »]
http://www.microsoft.com/hwdev/download/devdes/atamed.rtf ; see FAQ B10.1.5.5.

B10.1.2.9 IEEE 1394 storage class devices conform to ANSI standards for SBP-2 with appropriate command set

[ 1394-0094 »; SDG3.160 »]

Appropriate command sets are RBC (Reduced Block Commands) or MMC-2.

B10.1.2.10 Universal Serial Bus Mass Storage Class Specification Overview, Revision 1.0

[ STOR-0343 »; SDG3:158 »; see also FAQ B10.1.5.6]

B10.1.2.11 NCITS Serial Bus Protocol-2 (SBP-2) transport protocols (ANSI NCITS 3.25-1998)

Global Engineering Documents at http://global.ihs.com/.

B10.1.2.12 SCSI Parallel Interface (SPI-3) [ANSI/NCITS T10-1302D] standard

[SCSI-0104 »]

Global Engineering Documents at http://global.ihs.com/.

B10.1.2.13 SCSI-3 Medium Changer Commands (SMC), ANSI NCITS.314:1998

Global Engineering Documents at http://global.ihs.com/.


B10.1.3 General Storage - Quality

WHQL Test Specification References:
Chapter 10: ATA/ATAPI Test Specification
Click to launch Click to launch

B10.1.3.1 Pass all WHQL tests

See B1.3.

Windows XP: See "Storage Controllers and Devices" in the HCT documentation.

B10.1.3.2

See B10.1.3.1 and B10.1.4.7

B10.1.3.3

See B10.1.3.1


B10.1.4 General Storage - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 12, "Storage" - Click to launch Click to launch
Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server, Chapter 5 - Click to launch Click to launch

B10.1.4.1 Configuring or adding a device to a system does not require changing jumpers or switches on either device or system board

[SYS-0029.2 »]

B10.1.4.2 Bootable controller supports El Torito No Emulation mode; option ROM supports Int 13h Extensions

[ ATA-0116, 0117 »; SCSI-0106 »; SDG3:147 »]

B10.1.4.3 Removable media devices support media status notification

[ STOR-0342 »; SDG3:149 »; see also FAQ B10.1.5.5]

B10.1.4.4 Dynamic resource configuration is supported for all devices

[ SYS-0029 »; SDG3:9 »]

B10.1.4.5 Device driver for partitioned media supports all Windows and Windows 2000 partition types

[ STOR-0365 »]

B10.1.4.6 Controller, hard drive, and CD/DVD devices support bus mastering and UDMA/DMA

[ STOR-0341 »; SDG3:146 »; see also FAQ B10.1.5.4]

Programmed I/O (PIO) support is allowed only for Compact Flash format storage and similar flash-RAM devices.

All other storage and optical devices must support DMA bus mastering and cannot use PIO.

(Note that USB controls DMA on the host side).

B10.1.4.7 Devices, controllers, and drivers support upgrading the operating system and converting to any Windows-supported file system
  • Windows NT 4.0 > Windows XP/Windows 2000 Upgrade.
  • Windows 98/Me > Windows XP/Windows 2000 Upgrade.
  • FAT16 > FAT32 upgrade; FAT32 > NTFS conversion.
    Removable media with MTBF similar to hard drives also can be converted to NTFS.


B10.1.5 General Storage - FAQs

B10.1.5.1 Current storage FAQs

See http://www.microsoft.com/winlogo/hardware/storage/.

B10.1.5.2 DAC support and PCI storage adapters for large-memory systems [Clarification]

SDG3:30-32 »]

Requirements for PCI adapters to support the PCI DAC command are defined in A1.1.6. For storage devices, at a minimum this includes adapters implemented in or designed as primary storage components -- RAID, Fibre Channel, high-speed SCSI, and so on -- for systems that support more than 4 GB of system memory.

See "Large Memory Enabled Device Driver Hardware and Software Requirements" in the Windows DDK; design guidelines are summarized at http://www.microsoft.com/hwdev/newPC/PAEdrv.htm

B10.1.5.3 DELETED

FAQ Date: January 31, 2001

B10.1.5.4 Support for ATA Bus Master DMA [Clarification]

[STOR-0341 »; SDG3:146 »]

  • Required for ATA controllers.
  • Required for ATA devices, and ATAPI-based hard drives.
  • Recommended for ATAPI peripherals other than hard drives, including CD and DVD devices.

In particular, non-hard disk ATAPI devices (CD, DVD, ZIP, Orb, and magneto-optical devices, and so on) are not required to support Ultra DMA transfers. However, they often share the bus with other devices. Therefore, non-hard disk ATAPI devices must support ATAPI-5 bus termination schemes such that a device sharing the bus can achieve the bus timing necessary to perform Ultra DMA transfers.

  • Recommended for ATAPI removable media drives.
    FAQ Date: March 5, 1999; June 24, 2000, May 21, 2001
B10.1.5.5 Media status notification [Correction]

[ STOR-0342 »; SDG3:149 »]

The intent of the requirement for media status notification is for devices to support the commands of the implemented bus interface so the operating system can detect when a media event has taken place. The requirements for removable storage devices are defined in the following table; they apply either to single LUN devices or to devices that are part of a Multiple LUN device.

Windows XP: A CD-R/RW drive must support the following Get Event/Status Notification commands:
Operational Change Request/Notification
External Request
Media Request
Device Busy
[see also FAQ B10.5.5.4]
FAQ Date: March 19, 1999; May 24, 2001

Device type | Media status notification implementation
All CD or DVD devices (independent of interconnect) | Required. Comply with ANSI NCITS T10 MMC-2 standard for Media Status Event Notification.
ATAPI floppy/optical direct access drives (PD, MO, removable magnetic floppy or rigid based, and so on) | Required. Comply with either MMC-2 standard or SFF 8070i Version 1.1.
IEEE 1394 storage devices (non-CD / DVD) | Required. Comply with NCITS Reduced Block Commands (RBC; T10/97-260r0) standard.
ATA and non-ATAPI (IDE interconnect) storage devices | Required. Comply with Media Status Notification Support, Version 1.03.
Other ATA/ATAPI devices, including tape drives | Recommended. If implemented, comply with Media Status Notification Support Specification, Version 1.03, or SFF 8070i.
Other types of SCSI removable devices | Recommended. If implemented, support based on SCSI Reduced Block Commands (RBC), NCITS.330:2000 is recommended.
B10.1.5.6 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


B10.1.R General Storage - Future Requirements

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

B10.1.R.1 Devices that write digital content to removable media are capable of both creating and modifying a Desktop.ini file on the media

This future requirement will address the Windows user experience with Autoplay technology.

B10.1.R.2 SCSI Block Commands – 2 (SBC-2), ANSI NCITS T10/1417-D
B10.1.R.3 SCSI Multimedia Commands – 3 (MMC-3), ANSI NCITS T10/1363-D

Previous Next


B10.2 ATA/ATAPI Controllers/Devices

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.

B10.2.1 ATA/ATAPI Controllers/Devices - Windows Compatibility

B10.2.1.1 DELETED

B10.2.2 ATA/ATAPI Controllers/Devices - Industry Standards

B10.2.2.1 ATA/ATAPI-5 Standards

[ATA-0115 »; SDG3:177 »]
Global Engineering Documents at http://global.ihs.com/.

B10.2.3 ATA/ATAPI Controllers/Devices - Quality

B10.2.3.1 Pass WHQL tests

See B1.3, B10.1.3.2, and B10.1.4.7.

Windows XP: See "ATA/ATAPI Controllers" and device-specific topics in HCT documentation.

B10.2.3.2

See B10.1.3.2

B10.2.4 ATA/ATAPI Controllers/Devices - Windows Experience

B10.2.4.1 Windows 98/Me: Driver runs in 32-bit protected mode after installation

[ SYS-0025 »]

B10.2.4.2 Windows XP/Windows 2000 Professional/Windows Me: Large partition support (>8 GB) and ability to boot from loader

[ATA-0116 »]

B10.2.4.3 Windows XP/Windows 2000 Professional/Windows Me: S3 and hibernation support

[SYS-0003.4 »; see A1.4.2]

B10.2.4.4 ATA controllers and devices support Ultra DMA, do not claim 3F7h and 377h

[ ATA-0119 »; STOR-0350 »; SDG3:177 »]

B10.2.4.5 Dual ATA adapters use single FIFO with asynchronous access or dual FIFOs and channels; ATA disk drive supports

ATA-0118, 0117 »; SDG3:176 » Standards

B10.2.4.6 Controller and peripheral connections include Pin 1 cable designation with keyed and shrouded connectors

[ ATA-0120 »; SDG3:178 »]

B10.2.4.7 Peripherals comply with ATA/ATAPI-5

[ STOR-0347 »; SDG3:179 »]

B10.2.4.8 ATAPI devices support DEVICE RESET command

[ STOR-0348 »; SDG3:180 »]

B10.2.4.9 ATA device supports ATA STANDBY command

[ STOR-0349 »; SDG3:181 »]

B10.2.4.10 To tolerate Ultra DMA, ATAPI devices support the termination scheme defined in ATA/ATAPI-5

[ATA-0119 »; see also FAQ B10.1.5.4]

B10.2.5 ATA/ATAPI Controllers/Devices - FAQs

See B10.1.5.

B10.2.R ATA/ATAPI Controllers/Devices - Future Requirements

See B10.1.R.

B10.2.R.1 ATA/ATAPI-6 proposal and its appendices are under consideration for future requirements

This includes proposals for raising the lower limit on UDMA cycle time, 48-bit LBA support, and other advanced features.

The latest draft of ATA/ATAPI-6 is available from the web site for the T13 Technical Committee for the National Committee on Information Technology Standards (NCITS) at http://www.t13.org/.


B10.3 SCSI Controllers/Devices

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.

Note: Most SCSI controllers submitted as reference motherboard implementations can be submitted on a plug-in adapter card. However, if the reference motherboard implementation must be submitted on a motherboard, two different motherboard implementations are required for Windows Logo qualification.

B10.3.1 SCSI Controllers/Devices - Windows Compatibility

B10.3.1.1 SCSI Configured Automatically (SCAM) support is disabled by default

[ SCSI-0113 »; SDG3:171 »]

B10.3.2 SCSI Controllers/Devices - Industry Standards

B10.3.2.1 Small Computer Interface (SCSI-2) [X3.131:1994] standard

Global Engineering Documents at http://global.ihs.com/.

B10.3.2.2 SCSI Parallel Interface (SPI-3) [NCITS.336:2000] standard

[ SCSI-0104 »]

Global Engineering Documents at http://global.ihs.com/

B10.3.3 SCSI Controllers/Devices - Quality

B10.3.3.1 Passes WHQL tests

See B1.3, B10.1.3.2, and B10.1.4.7.

Windows XP: See "SCSI Controllers" and device-specific topics in HCT documentation.

B10.3.4 SCSI Controllers/Devices - Windows Experience

B10.3.4.1 Windows 98/Me: Driver runs in 32-bit protected mode after installation

[ SYS-0025 »]

B10.3.4.2 Windows XP/Windows 2000: S3 and hibernation support

[SYS-0003.4 »]

Windows Me: Hibernate is not supported for SCSI.

B10.3.4.3 Windows XP/Windows 2000/Windows Me: Large partition support (>8 GB) and ability to boot from loader
B10.3.4.4 Adapter is capable of sharing IRQ and works behind a PCI-PCI bridge

[SCSI-0106 »; SDG3:35 »]

B10.3.4.5 Connector and terminator requirements

[SCSI-01xx; SDG3:16x,170]

  • Bus type is clearly indicated using ANSI-approved icons on connectors for all adapters and peripherals. [ SCSI-0108 »; SDG3:163 »]
  • Differential devices support DIFFSENS as defined in SPI -3 standard. [ SCSI-0109 »; SDG3:164 »]
  • Automatic termination circuit and SCSI terminators meet SPI-3 standard. [ SCSI-0110 »; SDG3:165 »]
  • Terminator power is supplied to the SCSI bus with overcurrent protection. [ SCSI-0111 »; SDG3:166 »]
  • External connector meets SCSI-2 or later standard. [ SCSI-0108 »; SDG3:167 »]
  • Controller and peripheral connections include Pin 1 cable designation; shielded device connector meets SCSI-2 or later standard. [ SCSI-0108 »; SDG3:169 »]
  • External devices use automatic termination or an accessible on-board termination switch. [ STOR-0345 »; SDG3:170 »]

Note: Not required for Fault-Tolerant RAID devices where the terminators are considered to be a Field Replaceable Unit (FRU).

  • SCSI devices that support hot-plugging comply with Annex D of SPI-3. [ SCSI-0104 »; SDG3:174 »]
B10.3.4.6 Controller and peripherals implement SCSI bus data protection signal

[ SDG3:168 »]

B10.3.4.7 Hardware supports the SCSI-3 START STOP UNIT command to decrease power consumption as defined in the SCSI Block Commands Specification

[ STOR-0346 »; SDG3:172 »]

B10.3.4.8 Option ROM supports virtual DMA services

[ SCSI-0105 »; SDG3:146 »]

B10.3.4.9 SCSI erasable drive supports SCSI commands

[ SDG3:183 »]

B10.3.4.10 SCSI controller provides multi-initiator support if the controller provides external device connection capability for use as a cluster node

[ SCSI-0114 »; SDG3:162 »]

B10.3.5 SCSI Controllers/Devices - FAQs

See B10.1.5.

B10.3.R SCSI Controllers/Devices - Future Requirements

See B10.1.R.

B10.3.R.1 Architectures are under consideration for future requirements

This includes raising the lower limit on parallel and serial timing, Persistent Reservations, and other advanced features contained at SCSI Parallel Interface 4 (SPI-4), ANSI NCITS T10/1365-D.


B10.4 Hard Disk Drives

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.
All ATA/ATAPI device-specific requirements in B10.2 are included by reference.
All SCSI device-specific requirements in B10.3 are included by reference.

B10.4.1 Hard Disk Drives - Windows Compatibility

See B10.1.1.

B10.4.2 Hard Disk Drives - Industry Standards

B10.4.2.1 SMART IOCTL API Specification, v.1.1

http://www.microsoft.com/hwdev/download/respec/iocltapi.rtf
(if SMART drive support is implemented).

B10.4.2.2 SCSI Primary Commands (SPC), ANSI X3.301:1997

Global Engineering Documents at http://global.ihs.com/.

B10.4.2.3 SCSI-3 Block Commands (SBC), ANSI NCITS.306:1998

Global Engineering Documents at http://global.ihs.com/.

B10.4.3 Hard Disk Drives - Quality

B10.4.3.1 Pass WHQL tests

See B1.3, B10.1.3.2, and B10.1.4.7.

Windows XP: See "Hard Disk Drive" in the HCT documentation.

B10.4.3.2

See B10.4.3.1

B10.4.3.3

See B10.4.3.1

B10.4.3.4

See B10.1.4.7

B10.4.3.5

See B10.4.3.1

B10.4.3.6

See B10.4.4.5

B10.4.4 Hard Disk Drives - Windows Experience

B10.4.4.1 Hard disk supports bus mastering and UDMA/DMA

[ STOR-0341 »; SDG3:146 »; see also FAQ B10.1.5.4]

B10.4.4.2 Windows XP/Windows 2000/Windows Me: Large partition support (>8 GB) and ability to boot from loader
B10.4.4.3 Device driver for block-mode device supports extended BIOS parameter blocks (BPBs)

See "DCB (Device Control Block)" in the Windows Me DDK.

B10.4.4.4 Windows Whistler Server: Hot-swappable drive, if provided, includes a local disk drive replacement indicator

[SDG3:224 »]

B10.4.4.5 Windows Whistler Server: SCSI and Fibre Channel hard drives implement complete identification strings

Strings are defined in SCSI Primary Commands (SCSI-3 PC), Section 7.5.3, Vital Product Data.

This support is used for unique ID of devices with host connection, in multipath, failover, and LUN ID.

B10.4.5 Hard Disk Drives - FAQs

See B10.1.5.

B10.4.R Hard Disk Drives - Future Requirements

See B10.1.R.


B10.5 CD/DVD Drives

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.
All ATA/ATAPI device-specific requirements in B10.2 are included by reference.
All SCSI device-specific requirements in B10.3 are included by reference.

B10.5.1 CD/DVD Drives - Windows Compatibility

B10.5.1.1 DVD Multifunction Devices: Avoiding Multiple Logical Unit Devices

http://www.microsoft.com/hwdev/dvd/multiLUN.htm


B10.5.2 CD/DVD Drives - Industry Standards

B10.5.2.1 CD or DVD drive complies with MMC-2

[ STOR-0354 »; SDG3:188 »]

DVD drives must support SFF 8090 ("Mt. Fuji 5" specification), submitted to the SCSI T10 MMC group at revision 0.9 (ftp://ftp.t10.org/t10/document.00/00-361r0.pdf; available in MMC-3 review draft (ftp://ftp.t10.org/t10/drafts/mmc3/mmc3r09.pdf).

B10.5.2.2 Optical Storage Technology Association (OSTA) MultiRead Specification for CD-ROM, CD-R, CD-R/RW, and DVD-ROM Devices, V.1.11

http://www.osta.org/

Note: MMC-2 and OSTA specifications replace former reference to Multisession Compact Disc Specification Enhanced Music CD Specification.

B10.5.2.3 SFF 8070i (ATAPI Removable Rewritable Media Devices specification) for block rewritable optical ATAPI devices

[ STOR-0363 »; SDG3:148 »]

ftp://fission.dt.wdc.com/pub/standards/SFF/specs/INF-8070.PDF

B10.5.2.4 SFF 8090
B10.5.2.5 Universal Disk Format Specification, V.1.5 and 2.0

http://www.osta.org/

B10.5.2.6 ECMA Standards ECMA-267 (DVD-ROM), ECMA-274 (DVD+RW), and ECMA-273 (DVD-RAM)

http://www.ecma.ch/

B10.5.2.7 DVD Specifications for Rewritable Disc, Part 1: Physical Specifications

Global Engineering Documents at http://global.ihs.com/.

B10.5.2.8 Windows XP: DVD-RAM Specification

Global Engineering Documents at http://global.ihs.com/.


B10.5.3 CD/DVD Drives - Quality

B10.5.3.1 Pass WHQL tests

See B1.3, B10.1.3.2, and B10.1.4.7.

Windows XP: See "CD/DVD Drive" and "Recordable CD/DVD Drive" in the HCT documentation.

B10.5.3.2

See B10.5.4.3


B10.5.4 CD/DVD Drives - Windows Experience

B10.5.4.1 DMA capability on ATA/ATAPI CD-ROM, CD-R/CD-RW, and DVD-ROM drives

[STOR-0341 »; SDG3:146 »; see also FAQ B10.1.5.4]

B10.5.4.2 CD device requirements

[STOR-03xx; SDG3:18x; see also FAQ B10.5.5.4 ]

  • Provides 8x minimum transfer rate or better performance. [ STOR-0362 »; SDG3:185 »; see FAQ B10.5.5.2 ]
  • CD-enhanced compatible. [ STOR-0352 »; SDG3:186 »]
  • Supports specified logical and physical CD formats. [ STOR-0353; 0355 »; SDG3:187 »]
  • Supports the READ CD-DA command as defined in the MMC-2 standard. [ STOR-0354 »; SDG3:188 »; see also FAQ B10.5.5.4 ]
  • Supports digital audio detection and digital audio quality on CD-ROM drive - see http://www.microsoft.com/hwdev/devdes/cddigital.htm. [ STOR-0357 »; see FAQ B10.5.5.3 ]
B10.5.4.3 DVD storage device requirements

[STOR-036x; SDG3:19x]

  • Provides 2 MB per second minimum transfer rate or better performance anywhere on the disc. [ STOR-0360 »; SDG3:191 »; see FAQ B10.5.5.2 ]
  • Supports logical and physical CD formats, MMC-2, and defect management where applicable. [ STOR-0361 »; SDG3:192, 193 »; see FAQ B10.5.5.4 ]
B10.5.4.4 Windows 98/Me: Media Player functionality with .AVI and .MPG files

Previous Next


B10.5.5 CD/DVD Drives - FAQs

B10.5.5.1

See B10.1.5

B10.5.5.2 Minimum speed requirement for CD and DVD devices [Logo Program Clarification]

[STOR-036x; SDG3:165]

The design references for this requirement are now STOR-0362 », STOR-0360 », SDG3:165 ».
FAQ Date: June 16, 2000

B10.5.5.3 CD transfer speed on USB [Logo Program clarification]

Microsoft acknowledges that CD-ROM devices that otherwise meet the Windows Logo Program requirements for 8x or better transfer rate will likely achieve only about 6x transfer speed when the device is connected over USB, because of the transfer speed limitations of USB 1.x. Such configurations will be eligible for the Windows Logo.
FAQ Date: December 22, 1999

B10.5.5.4 CD Capabilities and CD Audio [Correction]

[ STOR-0357 »]

CD and DVD drives must implement "CD Capabilities and Mechanical Status Page" (2Ah), as defined in the MMC-2 standard. The bit "CD-DA Commands Supported" must be set and the functionality must be implemented.

CD and DVD drives must also implement and set the bit "CD-DA Stream is Accurate" of "CD Capabilities and Mechanical Status Page." The READ_CD command and READ_RAW commands must provide sector-accurate reads, as defined in MMC-2. Data alignment accuracy must be equivalent to that of data reads. Because of the lack of error correction code (ECC) bytes used for data tracks, the data itself may contain inaccuracies due to physical defects of the media.

Windows XP: A CD-R/RW drive must support the following commands, as defined in SFF-8090 and MMC-2:

Get Configuration
Get Event/Status Notification
Operational Change Request/Notification
External Request
Media Request
Device Busy
Mode sense10, Mode Select10
Prevent/Allow Medium Removal
ReadTOCPAMAATIP
Read CD, Read CD MSF
Read Disc Information
Read Track Information
Send OPC Information
Set CD Speed
Start/Stop Unit
Blank
Write 10, Read 10, Read 12
Write 12, in the following cases:

DVD+RW Feature (2Ah)
DDCD-R Write Feature (31h)
DDCD-RW Write Feature (32h)
Real-Time Streaming Feature (107h)

A CD-R/RW drive that identifies itself as CD-RW capable must support the following capabilities:

Capability | Description
Profile List | A list of all profiles supported by the device.
Core | Basic functionality.
Morphing | Ability to notify Initiator about operational changes and accept Initiator requests to prevent operational changes.
Removable Medium | The medium may be removed from the device.
Random Readable | Read ability for storage devices with random addressing.
Multi-Read | The Logical Unit complies with OSTA Multi-read.
CD Read | The ability to read CD specific structure.
Incremental Streaming | Write support for sequential recording.
Formattable | Support for formatting the media.
Restricted Overwrite | Write support for media that shall be written in multiples of Logical blocks.
CD Track at once | Ability to write CD with track at once recording.
Defect management | Ability of the drive/media system to provide an apparently defect-free space.
Power management | Initiator and device directed power management.
Timeout | Ability to respond to all commands within a specific time.
Real-Time Streaming | Ability to read and write using Initiator requested performance parameters.

FAQ Date: October 7, 1998; May 24, 2001

B10.5.5.5 Defect management for +RW media [Correction]

Defect management for +RW media is defined in ECMA-274.
FAQ Date: October 7, 1998; corrections March 1, 1999

B10.5.5.6 CSS copyright protection; DVD Regionalization [Logo Program Clarification]

CSS copyright protection is not a Logo Program requirement. Nor is DVD Regionalization. The related technical issue is addressed through proprietary licensing programs and is not a testing requirement for the Windows Logo Program. It is the responsibility of independent hardware and software vendors to ensure for themselves that they have met the necessary requirements in their products.
FAQ Date: January 18, 2000


B10.5.R CD/DVD Drives - Future Requirements

See B10.1.R.

B10.5.R.1 CD-RW drives will be required to support the Mt. Rainier initiative specification for support of Windows-based block addressing of CD-RW media

See http://www.mt-rainier.org.


B10.6 Removable Media Drives

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.
All ATA/ATAPI device-specific requirements in B10.2 are included by reference.
All SCSI device-specific requirements in B10.3 are included by reference.

B10.6.1 Removable Media Drives - Windows Compatibility

B10.6.1.1 Windows XP/Windows 2000: Removable Storage Management and Windows 2000

http://www.microsoft.com/hwdev/storage/RSM.htm

B10.6.2 Removable Media Drives - Industry Standards

See B10.1.2.

B10.6.3 Removable Media Drives - Quality

B10.6.3.1 Pass WHQL tests

See B1.3, B10.1.3.2, and B10.1.4.7.

Windows XP: See "Removable Media Drive" in the HCT documentation.

B10.6.3.2 and B10.6.3.3

See B10.1.4.7

Removable media with MTBF similar to hard drives also can be converted to NTFS.

B10.6.4 Removable Media Drives - Windows Experience

B10.6.4.1 Windows 98/Me: Driver runs in 32-bit protected mode after installation
B10.6.4.2

See B10.2.4

B10.6.5 Removable Media Drives - FAQs

See B10.1.5.

B10.6.R Removable Media Drives - Future Requirements

See B10.1.R.


B10.7 Tape Drives

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.
All ATA/ATAPI device-specific requirements in B10.2 are included by reference.
All SCSI device-specific requirements in B10.3 are included by reference.

B10.7.1 Tape Drives - Windows Compatibility

See B10.1.1.

B10.7.2 Tape Drives - Industry Standards

B10.7.2.1 Tape-related standards

[ SDG3:197 »]

  • Cartridge drives: QIC 157 Revision D, "Common SCSI/ATAPI Command Set For Streaming Tape" at http://www2.qic.org/qic/html/standards/15x.x/qic157d.pdf.
  • ATA tape drive complies with packet passing protocol in ATA/ATAPI-5.
  • SCSI tape drive complies with SCSI tape command set SCSI-3 Stream Commands (SSC), ANSI NCITS.335:2000.
B10.7.2.2

See B10.1.2

B10.7.3 Tape Drives - Quality

B10.7.3.1

See B10.7.3.2

B10.7.3.2 Pass WHQL tests

See B1.3, B10.1.3.2, and B10.1.4.7.

Windows XP: See "Tape Drive" in the HCT documentation.

B10.7.4 Tape Drives - Windows Experience

B10.7.4.1 To tolerate Ultra DMA, ATAPI devices support the termination scheme defined in ATA/ATAPI-5

[ ATA-0119 »; see FAQ B10.1.5.4]

B10.7.4.2 Windows Whistler Server: Driver integrates with Removable Storage Manager

[ SDG3:198 »]

B10.7.4.3 Windows Whistler Server: Single-backup device meets minimum capacity requirements

[ SDG3:196 »]
Basic: Required.
Advanced Server: 20 GB required.

B10.7.5 Tape Drives - FAQs

See B10.1.5.

B10.7.R Tape Drives - Future Requirements

See B10.1.R.

B10.7.R.1 For support of larger storage farms and server installations, the minimum tape size is 40 GB

Due to the needs of even the lowest end systems.


B10.8 Media Changer Devices

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.

B10.8.1 Media Changer Devices - Windows Compatibility

See B10.1.1.

B10.8.2 Media Changer Devices - Industry Standards

See B10.1.2.

B10.8.3 Media Changer Devices - Quality

B10.8.3.1

See B10.8.3.2

B10.8.3.2 Pass Windows Logo Program testing

See B1.3 and B10.1.3.2.

Windows XP: See "Media Changer Device" in the HCT documentation.

B10.8.3.3 DELETED

B10.8.4 Media Changer Devices - Windows Experience

Design Guideline References:
Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server, Chapter 5
Click to launch Click to launch

B10.8.4.1 If CD changer device supports 7 discs or less, comply with MMC-2

[ STOR-0356 »; SDG3:199 »]

B10.8.4.2 SCSI tape changer and drive support auto-configuration

[ SDG3:200 »]

B10.8.4.3 SCSI tape and optical disk changer support auto-configuration

[ SDG3:201 »]

B10.8.5 Media Changer Devices - FAQs

See B10.1.5.

B10.8.R Media Changer Devices - Future Requirements

See B10.1.R.


B10.9 RAID

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.

Note: If this device is implemented on a client system, compatibility testing is required for Windows XP/Windows 2000.

B10.9.1 RAID - Windows Compatibility

B10.9.1.1 SCAM is disabled by default, if SCSI device

[ SCSI-0113 »; SDG3:171 »]

B10.9.2 RAID - Industry Standards

See B10.1.2 and B10.3.2.

B10.9.3 RAID - Quality

B10.9.3.1 Pass WHQL tests

See B1.3, B10.1.3.2, and B10.1.4.7.

Windows XP/Windows Whistler Server: See "RAID Devices" and "RAID Controller" in the HCT documentation.

B10.9.3.2 - B10.9.3.5

See B10.9.3.1

B10.9.4 RAID - Windows Experience

Design Guideline References:
Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server, Chapter 5
Click to launch Click to launch

B10.9.4.1 All external SCSI connectors are labeled with ANSI approved icon for bus type

[SCSI-0108 »; SDG3:163 »]

B10.9.4.2 Requirements in B10.1.4 do not apply for RAID Cluster Devices

This program only verifies basic cluster failover functionality requirements; all features and Windows Experience testing is completed when the product goes through the prerequisite Logo testing for the device type.

B10.9.4.3 RAID support include notification of failed drive

[ SDG3:219 »]

B10.9.4.4 RAID subsystem supports automatic replacement of failed drive

[ SDG3:220 »]

B10.9.4.5 RAID subsystem supports manual replacement of failed drive

[ SDG3:221 »]

B10.9.5 RAID - FAQs

B10.9.5.1 Option ROM requirements [Clarification]

[BIOS-0011 »; SDG3:147 »]

Option ROMs for RAID controllers implemented on systems or as add-in controller cards must fully support Int 13.
FAQ Date: March 19, 1999

B10.9.R RAID - Future Requirements

See B10.1.R.

B10.9.R.1 SCSI controller drivers follow the Microsoft miniport model, in order to enable implementation of advanced features such as multi-path failover, load balancing, or LUN masking

Previous Next


B10.10 Fibre Channel

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.

Note: If this component is implemented on a client system, compatibility testing is required for Windows XP/Windows 2000.

B10.10.1 Fibre Channel - Windows Compatibility

See B10.1.1 and B10.3.1.

B10.10.2 Fibre Channel - Industry Standards

B10.10.2.1 Fibre Channel Physical and Signaling Interface (FC-PH), ANSI X3.230:1994; amendment PC-PH-AM1 (X3.230:1994/AM-1:1996)
2 Fibre Channel 2nd Generation Physical Interface, ANSI X3.297:1997
B10.10.2.3 Fibre Channel 3rd Generation Physical Interface, ANSI X3.303:1998
B10.10.2.4 SCSI-3 Fibre Channel Protocol (FCP), ANSI X3.269:1996

Global Engineering Documents at http://global.ihs.com/.

B10.10.3 Fibre Channel - Quality

B10.10.3.1 FC adapter and hard drives pass Windows Logo Program testing

See B1.3, B10.1.3.2, and B10.1.4.7.

Windows Whistler Server: See "Fibre Channel Controllers" and device-specific topics in the HCT documentation.

Note: The 3-day stress test run specified for "Designed for Windows 2000 Server" testing is not required for client testing.

B10.10.3.2 FC adapter

See B10.10.3.1

B10.10.3.3 FC hard drive

See B10.10.3.1.

B10.10.4 Fibre Channel - Windows Experience

Design Guideline References:
Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server, Chapter 5
Click to launch Click to launch

B10.10.4.1 Option ROMs for FC bootable controllers support extended Int 13 functions

[SDG3:147 »]

El Torito support is not required for FC controllers.

B10.10.4.2 Use X3T11 Private Loop Direct Attach profile as storage base to use native operating system support

[ SDG3:182 »]

B10.10.5 Fibre Channel - FAQs

See B10.1.5.

B10.10.R Fibre Channel - Future Requirements

See B10.1.R.

B10.10.R.1 Fibre Channel controllers comply with the FC-PH Specification, Version (TBD)

In order to take advantage of the Microsoft-defined FibrePort model.

B10.10.R.2 SCSI Fibre Channel Protocol –2 (FCP-2), ANSI NCITS T10/1144-D

Previous Next


B11.0 Streaming Media and Broadcast

B11.1 General Streaming

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.

B11.1.1 General Streaming - Windows Compatibility

B11.1.1.1 Device support is based on DirectX foundation class and WDM stream class

[ VID-0210 »]

  • WDM support: "Streaming Devices (Video and Audio)" in the Windows DDK.
  • All video input sources and capture devices must implement driver support as defined for WDM Stream class in "Devices (Video and Audio)" in the Windows DDK.
  • Minidriver implementation for subpicture decoder: Microsoft DirectX SDK and "DirectShow and DVD Support" in the Windows DDK.
B11.1.1.2 Windows compatibility and implementation notes—streaming

http://www.microsoft.com/hwdev/stream/

B11.1.1.3 Associated control, middleware, and application software use DirectShow

[ VID-0213 »]

It is not required to use the DirectShow filters provided with the operating system, but any substitute filter used must be a superset of the equivalent filter provided with the operating system and must support the same inputs and output.
See FAQ B11.2.5.2.

B11.1.1.4 If present in the system, software MPEG decoders use the DirectX VA API to communicate with the graphics chip’s video acceleration functions

[ VID-0340 »]
See Microsoft Platform SDK and DirectX 8 DDK in the Windows DDK.

B11.1.2 General Streaming - Industry Standards

B11.1.2.1 ANSI/SMPTE standards

http://www.smpte.org/stds/stsubj.html

B11.1.2.2 DVB/DAVIC (Digital Video Broadcasting/Digital Audio-Visual Council)

http://www.davic.org; http://www.dvb.org

B11.1.2.3 IEC 61883 Digital Interface for Consumer Electronic Audio/Video Equipment

http://www.iec.ch/webstore/

B11.1.3 General Streaming - Quality

WHQL Test Specification References:
Chapter 1: Introduction to HCT Test Specifications
Chapter 6: Digital and Broadcast Video Test Specification
Click to launch Click to launch

B11.1.3.1

See B11.1.4.4

B11.1.3.2 Pass WHQL tests

See B1.3.

Windows XP: See "Streaming Media and Broadcast" in the HCT documentation.

B11.1.4 General Streaming - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 9, "Video"
Click to launch Click to launch

B11.1.4.1 Interoperability with operating system and Microsoft DirectShow

[ VID-0221 »]

B11.1.4.2 Support subpicture compositing and closed captioning

[ VID-0219 »]

B11.1.4.3 Device installation requirements
  • Dependent video device is not independently enumerated. [ VID-0212 »]
B11.1.4.4 MPEG and video component requirements

[ VID-0209 », VID-0215 », VID-0216,0217 »]

  • For desktop system, TV-style MPEG-2 video stream playback consumes no more than an additional 45 percent of processor cycles, and no more than 45 percent of the memory, PCI, or AGP bandwidth during any given minute. [ VID-0215.7 »]
  • All MPEG-2 decoders can accept an MPEG-2 elementary stream. [ VID-0216 »]
  • All MPEG transport stream information is available to the central host processor. [ VID-0217 »]
  • De-interlacing of standard-definition video meets requirements. [ VID-0215 »]
  • MPEG sources support bus mastering; MPEG-2 MP@ML playback and video decode implementations meet requirements. [ VID-0215 »]

Mobile PC Note: Requirements are defined in B11.1.4.5.

  • All graphics and video capabilities must be fully supported at 1024 × 768, 32 bpp mode or better. [ VID-0209 »]
  • Synchronized audio and video, no tearing or other artifacts (macroblocking, jaggies, and so on). [ VID-0215 »; AUD-0326 »]
B11.1.4.5 Mobile system meets standard video requirements if video playback is supported

[ MOBL-0231 »]

Mobile PC Note: Support required for up to native display resolution or XGA where native resolution is greater than XGA (1024x768). Mobile system has no CPU utilization limitations or bus bandwidth restrictions for MPEG-2 playback.

B11.1.5 General Streaming - FAQs

See http://www.microsoft.com/winlogo/hardware/video/.

B11.1.R General Streaming - Future Requirements

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


B11.2 DVD Playback

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general requirements in B11.1 are included by reference.

Note: DVD playback is an optional feature, even for systems that include DVD drives.

B11.2.1 DVD Playback - Windows Compatibility

B11.2.1.1 "DirectShow and DVD Support" in the Windows DDK
B11.2.1.2 Windows compatibility and implementation notes—DVD Playback

http://www.microsoft.com/hwdev/dvd/

B11.2.2 DVD Playback - Industry Standards

B11.2.2.1 DVD Specification, V. 1.0

[VID-0219 »; SDG3:194 »]
http://www.mpeg.org/MPEG/DVD/

B11.2.2.2 DVD physical format documents

Global Engineering Documents at http://global.ihs.com/.

B11.2.3 DVD Playback - Quality

B11.2.3.1 Pass WHQL tests

See B1.3, B4.1.4.11.

Windows XP: See "DVD Playback" in the HCT documentation.

B11.2.3.2

See B11.2.4.5

B11.2.4 DVD Playback - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 9, "Video"
Click to launch Click to launch

B11.2.4.1 Experience should be the same or better than with a stand-alone player
B11.2.4.2 Multiple aspect ratio content is displayed correctly, with the default being the information in the MPEG header

[VID-0215.5 »]

B11.2.4.3 DVD decoder requirements

[ VID-0216 », 0218 », 0219 », 0220 », 0223 », 0340 »]

  • Driver correctly handles media types, time discontinuity, and decode-rate adjustment. [ VID-0218 »]
  • All DVD video decoders must support Line21 closed-caption data. [ VID-0223 »; see FAQ B11.2.5.2 ]
  • All MPEG-2 decoders can accept an MPEG-2 elementary Stream. [VID-0216 »]
  • DVD decoder supports subpicture compositing and closed captioning. [VID-0219 »]
  • Subpicture decoder correctly handles subpicture properties and other functions. [VID-0220 »]
  • MPEG decoders with motion compensation or Inverse DCT hardware acceleration use Microsoft DirectX VA API. [VID-0340 »]
  • Windows XP: DVD decoders must use the operating system’s native file system support to read DVD drives; alternatively, for SCSI devices, requests can be passed using IOCTL_SCSI_PASS_THROUGH. The decoder must not use non-Microsoft drivers to read the content of DVD drives.
B11.2.4.4 DVD-Video player navigates chapter breaks seamlessly

[ VID-0222 »]

Even if the underlying elementary streams were created as separate program chain (PGC) objects.

B11.2.4.5 Alpha blending of subpicture content on static menus

[ VID-0219 »]

B11.2.5 DVD Playback - FAQs

B11.2.5.1 Current DVD-Video FAQs

See http://www.microsoft.com/winlogo/hardware/video/.

B11.2.5.2 DVD-Video navigation requirement [Logo Program Clarification]

The motivation for the requirement is that software vendors need a standard interface to DVD-style MPEG playback. This is necessary for such applications as games that include MPEG video, Microsoft PowerPoint® presentations with video, WebDVD applications, and encyclopedias such as Microsoft Encarta® or Compton, and to allow users to exchange MPEG files for display on different PCs.

Windows 98/Me: Windows Logo testing requirements:

  • WHQL testing will ensure that software decoders work with the Microsoft Navigator and the Microsoft DVD Player application runs on OEM systems that support DVD playback.
  • WHQL will not test OEM systems to determine whether a software DVD player is talking with the software decoder by way of the Microsoft Navigator. Any third-party navigator must use DirectShow and support the same interfaces as the Microsoft Navigator.

A DVD player application can talk privately with a software decoder, provided that the decoder also works with the Microsoft Navigator.

Microsoft encourages implementers to provide Microsoft with details about additional required navigator features, so that those features can be added to the future API.
FAQ Date: August 26, 1999; revisions March 10, 2000; revised May 4, 2000; revised June 19, 2000

B11.2.5.3 CSS copyright protection [Logo Program Clarification]

Copy Scramble System (CSS) copyright protection is not a Logo Program requirement. The related technical issue is addressed through proprietary licensing programs and is not a testing requirement for the Windows Logo Program.
FAQ Date: January 18, 2000

B11.2.R DVD Playback - Future Requirements

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


B11.3 TV Tuner

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general requirements in B11.1 are included by reference.

B11.3.1 TV Tuner - Windows Compatibility

B11.3.1.1 Microsoft TV platform

http://www.microsoft.com/tv/

B11.3.1.2 DELETED
B11.3.1.3 Windows XP: Broadcast Driver Architecture

All TV receiver modules for use with Windows XP must conform to the BDA architecture, as defined in the DirectX 8 DDK and in "Broadcast Driver Architecture Drivers" in the Windows DDK. Data streams along with video and audio streams are required to be passed into the Microsoft DirectShow environment. The IP Sink filter provided within the BDA architecture is the mechanism for getting the data to the IP software rather than using an NDIS driver for the TV tuner module.

WebTV for Windows and related DLLs are not part of the Windows XP product. All analog and digital video capture solutions must be based on published DirectShow interfaces, WDM Video Capture and Broadcast Driver Architectures.

B11.3.2 TV Tuner - Industry Standards

B11.3.2.1 ATSC Digital Television Standard, Amendment No. 1

http://www.atsc.org/Standards/stan_rps.html

B11.3.2.2 DVD specifications

[VID-0219 »; SDG3:194 »]
http://www.dvd.org

B11.3.2.3 OpenCable specification

http://www.opencable.com

B11.3.3 TV Tuner – Quality

B11.3.3.1

See B11.3.4.6

B11.3.3.2 - B11.3.3.4 DELETED
B11.3.3.5 Pass WHQL tests

See B1.3, B4.1.4.11.

Windows XP: See "Streaming Media and Broadcast" in the HCT documentation.

B11.3.4 TV Tuner - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 9, "Video"
Click to launch Click to launch

B11.3.4.1 VBI capture samples VBI data exactly 4.7 or 5 times

[ VID-0225 »]

B11.3.4.2 Digital broadcast module can receive

[VID-022x]

  • All streams contained in the particular transport stream [ VID-0226 »]
  • Full bandwidth from each frequency [ VID-0227 »]
  • A minimum of 32 simultaneous elementary streams [ VID-0228 »]
B11.3.4.3 - B11.3.4.5 DELETED
B11.3.4.6 No tearing or other artifacts (macroblocking, jaggies, and so on)

[ VID-0215 »]

B11.3.5 TV Tuner - FAQs

See http://www.microsoft.com/winlogo/hardware/video/.

B11.3.R TV Tuner - Future Requirements

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


B11.4 Video Input/Capture

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general requirements in B11.1 are included by reference.

B11.4.1 Video Input/Capture - Windows Compatibility

B11.4.1.1 Windows compatibility and implementation notes—Video Capture

http://www.microsoft.com/hwdev/vidcap/

B11.4.1.2 Digital Video Camcorder Support

http://www.microsoft.com/hwdev/vidcap/DVCam.htm

B11.4.1.3 WDM Video Capture Overview

http://www.microsoft.com/hwdev/desinit/vidcap.htm

B11.4.2 Video Input/Capture - Industry Standards

B11.4.2.1 ATSC Digital Television Standard, Amendment No. 1

http://www.atsc.org/Standards/stan_rps.html

B11.4.2.2 AV/C Digital Interface Command Set VCR Subunit Specification, V. 2.0.1

http://www.1394TA.org

B11.4.3 Video Input/Capture - Quality

B11.4.3.1

See B11.4.4.8

B11.4.3.2 DELETED
B11.4.3.3

See B11.4.4.9

B11.4.3.4

See B11.4.4.10

B11.4.3.5

See B11.4.4.11

B11.4.3.6 Pass WHQL tests

See B1.3, B4.1.4.11.

Windows XP: See "Streaming Media and Broadcast" in the HCT documentation.

B11.4.4 Video Input/Capture - Windows Experience

Design Guideline References:
PC 2001 System Design Guide, Chapter 9, "Video"
Click to launch Click to launch

B11.4.4.1 Analog video decoder such as NTSC/PAL/SECAM meets quality requirements

[ VID-0215 »]

B11.4.4.2 Video input or capture device provides raw sampled VBI data

[ VID-0224 »]

B11.4.4.3 DELETED
B11.4.4.4 Video input image orientation identification meets requirements

[ PC99a:15.34 »]

B11.4.4.5 Windows Me—Requirement for IEEE 1394 camcorders

IEEE 1394 DV camcorders must implement mandatory VCR subunit commands. DV cameras must comply with the AV/C Digital Interface Command Set VCR Subunit Specification, Version 2.0.1.
[see http://www.1394TA.org ]

At a minimum, the device must support VCR subunit commands labeled "mandatory" in this specification.

B11.4.4.6 Video implementation preserves source quality during playback, storage, or processing of video streams and does not adversely affect overall PC performance

[ VID-0215 »]

B11.4.4.7 VBI data is not affected by any type of video operation the driver is performing on video frames

[ VID-0224 »]

That is, any cropping, scaling, or frame dropping that the hardware or the driver is performing on the related video frames.

B11.4.4.8 No tearing or other artifacts (macroblocking, jaggies, and so on)

[ VID-0215 »]

B11.4.4.9 IEEE 1394 DV camcorder implements mandatory VCR subunit commands

Digital video (DV) cameras must comply with the AV/C Digital Interface Command Set VCR Subunit Specification.

At a minimum, the device must support VCR subunit commands labeled as "mandatory" in this specification.

B11.4.4.10 Analog input supports 720 × 480 decode to 4:2:2

[VID-0215 »]

B11.4.4.11 Frame rate is within 0.2 percent of PAL 25.0fps or NTSC 29.97fps standard

[VID-0215.1 »]

B11.4.5 Video Input/Capture - FAQs

B11.4.5.1 Current video-related FAQs

See http://www.microsoft.com/winlogo/hardware/video/.

B11.4.5.2 Test Clarification

[ VID-0215 »]

The compatibility tests for PC systems determine whether there is excessive cross color, hanging dots, or other artifacts that could degrade the viewer experience. A DVD player with the Joe Kane Video Essentials disk with the Snell and Wilcox Zone plate test pattern is used to assess the video quality.
FAQ Date: November 27, 1998

B11.4.R Video Input/Capture - Future Requirements

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


B12.0 Miscellaneous

B12.1 Multifunction Devices

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All requirements for each specific device class implemented in the multifunction device are included by reference.

B12.1.1 Multifunction Devices - Windows Compatibility

B12.1.1.1 Device drivers comply with Windows DDK requirements for its operating system

Third-party applications implemented as defined in the Microsoft Platform SDK.

Windows XP/Windows 2000/Windows Me: "Driver Requirements for Multifunction Devices," "System-Supplied Setup Classes," "INF DDInstall.HW Section," and "MFCARD_DES" in the Windows DDK.

Windows 98: "Driver Requirements for Multifunction Devices" in the Windows Me DDK.

B12.1.1.2 Windows compatibility and implementation notes—multifunction devices

http://www.microsoft.com/hwdev/mf/

B12.1.1.3 Windows compatibility and implementation notes per bus and device class

See B1.0 and B2.0.

B12.1.1.4 Designing Multifunction Devices for Windows Operating Systems

http://www.microsoft.com/hwdev/mf/download/mfdesign10.zip

B12.1.2 Multifunction Devices - Industry Standards

B12.1.2.1 See related industry standards for each device class implemented on the multi-function device

See B1.0 and B2.0.

B12.1.3 Multifunction Devices - Quality

WHQL Test Specification References:
Chapter 1: Introduction to HCT Test Specifications
Chapter 22: Driver Quality Test Specification
Plus technology-specific test specifications
Click to launch Click to launch

B12.1.3.1 - B12.1.3.4

See B12.1.4.2

B12.1.3.5 Pass WHQL tests

See B1.3.

Windows XP: See "Multifunction" in the HCT documentation.

B12.1.4 Multifunction Devices - Windows Experience

Design Guideline References:
PC 2001 System Design Guide: SYS-0032 »
Hardware Design Guide 3.0 for Windows 2000 Server, Chapter 3 - Click to launch Click to launch

B12.1.4.1 Separate drivers are required for separate functions with no start order dependencies between separate function drivers

[ SYS-0032 »; SDG3:13 »]

The operating system must be able to configure and manage functions in any order, so no function on a multifunction device can depend on another function to be started before the function can be started by the operating system.

B12.1.4.2 MFP devices correctly implement driver and Plug and Play support

[SYS-0032 »]

  • Functional units on a multifunction device do not have start-order dependencies.
  • Resource requirements of one functional unit are not expressed in terms of another functional unit.
  • Operation of one functional unit do not affect or interfere with the operation of another functional unit on the multifunction device or on the system as a whole.
  • Each functional unit is enumerated and its resource requirements communicated to the operating system, so Windows can load the necessary drivers and assign resources to the different units in any order.
B12.1.4.3 Each independent function can be used concurrently, with no hidden dependencies

[SYS-0032 »]

Separate functional units must be able to operate concurrently, without interfering with each other or with other devices on the system.

B12.1.4.4 Each function can be power managed independently

[SYS-0032 »]

Each functional unit in a multifunction device must separately meet the power management device class specifications for its device class and be independently power managed. Each functional unit must be able to successfully complete a system sleep/wake transition (where the unit transitions from D0 to D3 to D0) without losing functionality and without requiring user intervention to restore functionality. All functional units on PCI devices that support wakeup capabilities must correctly support wake from D3cold.

B12.1.5 Multifunction Devices - FAQs

B12.1.5.1 Current general FAQs

See http://www.microsoft.com/winlogo/hardware/MF/.

B12.1.5.2 Resource requirements for MFD [Logo Program Clarification]

The PC 99 exception for multifunction PCI devices that use only a single set of relocatable resources refers solely to multifunction devices of the same device class. If different functions within a multiple-function device require separate class drivers—for example, a combination PCI network adapter and modem—then each function must provide a unique PCI SID and SVID that will allow the proper driver to be loaded for each separate function.

Multifunction devices that contain functions from separate classes will not be properly recognized during an operating system upgrade—and therefore drivers will not be properly upgraded—unless unique IDs are provided for each device.

Note that a "supervisory" driver that loads different drivers for the individual functions does not work well with Windows. In particular, driver support is likely to be lost in cases of operating system re-installation or upgrade, or with distribution of new drivers via Windows Update. Therefore, these supervisory drivers should be avoided. The Logo Program requires separate drivers for separate functions.
FAQ Date: May 28, 1999

B12.1.5.3 Exceptions to individual ID requirement for MF devices [Logo Program Clarification]
  • Multiple devices of the same device class, such as a multiline serial device.
  • Dependent video devices, such as a graphics accelerator on a video card.
  • Devices that are generated by an accelerator or auxiliary processor and that do not have independent hardware I/O. That processor must have an ID; under Windows XP/Windows 2000, Mf.sys must be used to enumerate the dependent devices.
    FAQ Date: May 28, 1999

B12.1.R Multifunction Devices - Future Requirements

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

B12.1.R.1 MFP devices using USB connectivity must appear as part of a composite device

Future requirements for USB connected multifunction print (MFP) device drivers supporting composite implementations are posted at "Multifunction Print Device Design Guidelines" at http://www.microsoft.com/hwdev/mf/mfp.htm.

B12.1.R.2 DELETED
B12.1.R.3 MFP device provides legacy-free interfaces

Future requirement - Legacy interfaces such as parallel (IEEE 1284) or serial are not allowed.


B12.2 UPS

All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.

Note: This document assumes that the device will be run with Windows XP/Windows 2000; however, for devices that are designed to also run with Windows 98/Me, these items specify some requirements that are tested only under Windows 2000.

B12.2.1 UPS - Windows Compatibility

B12.2.1.1 Windows XP/Windows 2000: "Human Input Devices" in the Windows DDK

"UPS Applet for Windows 2000" at http://www.microsoft.com/hwdev/onnow/ups.htm

B12.2.1.2 Windows compatibility and implementation notes

http://www.microsoft.com/hwdev/onnow/ups.htm

B12.2.1.3 Device drivers comply with Windows DDK requirements

See "Overview of System Battery Management" and "BATTERY_INFORMATION" in the Windows DDK.

Third-party applications implemented as defined in the Microsoft Platform SDK.

B12.2.2 UPS - Industry Standards

See B1.2.

B12.2.3 UPS - Quality

B12.2.3.1

See B12.2.4.5

B12.2.3.2 Pass WHQL tests

See B1.3.

Windows Whistler Server/Windows XP: See "UPS" in the HCT documentation.

B12.2.4 UPS - Windows Experience

Design Guideline References:
UPS Applet for Windows 2000 at http://www.microsoft.com/hwdev/onnow/ups.htm

B12.2.4.1 Device can take over and properly notify the user that the device is on battery and/or shut down applications and the system
B12.2.4.2 Device load is measured accurately
B12.2.4.3 Battery modules on larger units are hot swappable
B12.2.4.4 Device can notify the user via email and/or pager that the power is down
B12.2.4.5 Built-in functionality can properly support the device
B12.2.4.5 Device can correctly compensate for voltage irregularities

B12.2.5 UPS - FAQs

See http://www.microsoft.com/winlogo/hardware/unclassified/.

B12.2.R UPS - Future Requirements

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


Appendix C - Designing for Success

This appendix presents a series of guidelines to help you ensure that your new designs are compatible with Microsoft operating systems, and to help you ensure the design meets Windows Logo Program requirements and passes all HCTs and other Windows Logo Program testing.

Microsoft does not guarantee that complying with the Windows Logo Program requirements, or the related design guidelines provided in PC System Design Guide and similar publications, will ensure hardware or chipset compatibility with any versions of the Windows operating systems.

Manufacturers who are designing new system or component hardware, chip sets, or firmware are encouraged to work directly with Microsoft to ensure compatibility of new designs. To do this, manufacturers should work with their Microsoft program manager or technical evangelist to arrange design reviews. If you are not working with Microsoft, please send mail to ihv@microsoft.com with "Program Contact Request" in the Subject line. Note that Microsoft cannot guarantee that it can schedule reviews for all manufacturer requests.

Microsoft support to help manufacturers achieve device and application compatibility fall into these basic categories:

  • Driver Development Kits (DDK)
    Installable File System Development Kit (IFS Kit)
    HAL Development Kit (HAL Kit)
  • Microsoft device class-specific development team outreach.
    This includes "Windows Plugfests" hosted by Microsoft to test for hardware and driver compatibility during the development of the operating system
  • Microsoft service organizations that support system and peripheral manufacturers
  • Windows Hardware Quality Labs (WHQL), for testing through the Hardware Compatibility Tests (HCTs)

Microsoft provides the following guidelines for system and peripheral manufacturers to create hardware and drivers that are compatible with Windows operating systems and that meet Windows Logo Program requirements.

Design Hardware for Windows Compatibility

Design Using Current Information. Manufacturers can get up-to-date information about developing hardware and drivers for Windows:

Know the Current Windows Compatibility Guidelines. Read and understand Guidelines for Bus and Device Specifications, a paper that clarifies what Windows needs from hardware so it can interoperate successfully: http://www.microsoft.com/hwdev/issues/SpecGuide1.htm

  • For industry specifications upon which Microsoft designs support in Windows, plus the Plug and Play, power management, and other platform-related specifications from Microsoft, see: http://www.microsoft.com/hwdev/specs/
  • Ensure that the system’s ACPI BIOS is correctly implemented and passes the Microsoft ACPI HCT. OEMs must increase the OEMRevision field in the ACPI FACP to ensure that the system will run in ACPI mode under Windows. See http://www.microsoft.com/hwdev/onnow/.
  • Properly implement Plug and Play and power management support for all devices—in particular, ensure that all PCI components properly implement unique SIDs and SVIDs:
    http://www.microsoft.com/hwdev/devdes/pciids.htm

Check the web site for Hardware and Driver Developers. This web site provides tools, information, and services for driver developers and hardware designers who create products that work with the Microsoft Windows family of operating systems: http://www.microsoft.com/hwdev/

Submit Hardware Prototypes and New Systems and Devices to Windows Labs. Systems that pass testing in the Windows test labs receive the "compatible" designation on the Hardware Compatibility List. For information, write to: wintrack@microsoft.com.

Participate in Plugfests. Microsoft Plugfests, Meltdown compatibility testing, and industry events such as USB Implementers Forum Plugfests help identify firmware and driver issues.

Request Early Technical Design Reviews. Contact your Microsoft program manager or technical evangelist to request a technical review for new chipset or system designs; Microsoft architects can work with you in early phases to identify issues and ensure optimal design.

Subscribe to Windows Driver Services (WDS). WDS coordinates sign-up and access for Microsoft publications about driver development and testing for Windows (NDA required for some items) and Beta versions of Windows and the HCTs. If you are not currently working with Microsoft, subscribe to WDS services: http://www.microsoft.com/ddk/wds/

Design for the Windows Logo Program

Use the Windows Logo Program Requirements as a Design Guide. Confirm that all hardware and software components comply with the Windows Logo Program guidelines to ensure that all components in the system work together to provide the optimal end-user experience under Windows.

Use the WHQL Test Specification as a Design Guide. The WHQL Test Specification defines the precise test assertions that are validated by the HCTs. Study the WHQL Test Specification to understand exactly what portions of industry specifications and DDK driver guidelines are required in the compatibility tests.

Use the HCTs to Design for Compatibility. Use the HCTs in your product test suites to ensure compatibility as part of your development process. Manufacturers can get current and beta versions of HCTs and WHQL Test Specifications.

Attend Microsoft Review Events for the Industry. Microsoft offers design reviews, the Windows Hardware Engineering Conference (WinHEC), and other events to provide system planners and designers with technical information to help keep their products in sync with Windows system and component architectures. Some events are by invitation only.

Review and Comment on Proposed New Requirements:

  • Review draft versions of the Windows Logo Program requirements
  • If you offer server products, register as a server design guide reviewer at: http://www.hwdev.org/desguide/sdgreq.htm
  • To receive notice of review events related to proposed Logo Program requirements, subscribe to:
    WHQL-LOGO-SUBSCRIBE-REQUEST@list.hwdev.net

Participate in Industry Standards Efforts. Microsoft bases new capabilities in the operating system on industry standards and specifications. Participate in the industry forums, and in committees that develop strategic specifications and interfaces.

Design for Performance and Legacy Reduction:

  • Implement a fast BIOS POST and follow the guidelines to create fast boot/fast resume PC systems: http://www.microsoft.com/hwdev/fastboot/
  • Create and deliver only Windows-compatible, 32-bit software with any PC system or peripheral.
  • OEMs should plan to migrate all bundled devices to non-legacy interfaces, such as USB and IEEE 1394.
  • IHVs should build HID-compliant input devices and implement non-legacy interfaces for other device classes.

Develop, Test, and Distribute Compatible Windows Drivers

Develop Drivers Based on Windows DDK:

  • Use the Windows DDK samples to develop your code.
  • Use the Driver Verifier and other DDK Test tools.

Use the Current DDK. Receive the Windows DDK as part of the beta release, or download from the web: http://www.microsoft.com/ddk/

Test to Ensure a Smooth Upgrade Path. Your test matrix should include upgrading your shipping client PC systems to Windows XP, which will help to identify constraints that might prevent a smooth transition for your customers.

Run Regular, Complete Testing Suites. Use the tools and guidelines from Microsoft to ensure that your testing suites exercise all the operating system features and functions used by your hardware and drivers. Run test tools on a regular basis to ensure drivers are free of errors.

Submit Bugs and Follow Up with Microsoft. Use the reporting mechanism defined in the beta package.

Ensure Users Can Get BIOS and Driver Updates

  • Make updated ACPI BIOSes available on your web site.
  • Submit drivers for inclusion on Windows Update:
    http://www.microsoft.com/hwdev/supportability/
    http://windowsupdate.microsoft.com/


References

1394 Open Host Controller Interface Specification, Release 1.0

ftp://ftp.austin.ibm.com/pub/chrptech/1394ohci/ohcir100.pdf

1394 Open Host Controller Interface Specification, Release 1.1

http://www.microsoft.com/hwdev/1394/
http://developer.intel.com/technology/1394/download/ohci_11.htm

1394 Trade Association Power Specification, Part 1: Cable Power Distribution
1394 Trade Association Power Specification, Part 3: Power State Management

ftp://ftp.p1394pm.org/pub/p1394pm/

1394 Trade Association

E-mail: 1394-sig@1394ta.org
http://www.1394ta.org

1999 Version of National ISDN Basic Rate Interface Terminal Equipment Generic Guidelines, Document Number SR-4620 (replaced by 2000 Version, SR-4995)

http://telecom-info.telcordia.com/site-cgi/ido/index.html

AC ‘97 and AMR Plug and Play Design (for Windows)

http://www.microsoft.com/hwdev/audio/AMR.htm

AC '97 Component Specification and related publications

http://developer.intel.com/ial/scalableplatforms/audio/index.htm

AC '97 System BIOS Codec/Function Detection Algorithm

ftp://download.intel.com/ial/scalableplatforms/audio/ac97bios.pdf

Accelerated Graphics Port Interface Specification, Revision 2.0

http://developer.intel.com

ACPI Changes for Legacy Free

http://www.microsoft.com/hwdev/onnow/download/LFreeACPI.doc

ACPI Docking for Windows 2000

http://www.microsoft.com/hwdev/onnow/ACPIdock.htm

Advanced Configuration and Power Interface Specification, Revision 1.0b and Revision 2.0
(ACPI 1.0b and ACPI 2.0)

http://www.teleport.com/~acpi/

AGP Pro Specification, Revision 1.1a

http://www.agpforum.org/downloads/apro_r10.pdf

An Interoperable End-to-End Broadband Service Architecture over ADSL Systems, Version 3.0

http://www.microsoft.com/hwdev/network/dsl/

ANSI NCITS T10 Multi-Media Command Set-2 (MMC-2)

Global Engineering Documents at http://global.ihs.com/

ANSI/SMPTE standards

http://www.smpte.org/stds/stsubj.html

Application Specification for Microsoft Windows 2000, for desktop applications, Version 1.0

http://msdn.microsoft.com/certification/appspec.asp

AT Attachment with Packet Interface – 5 (ATA/ATAPI-5)

ftp://fission.dt.wdc.com/pub/standards/x3t13/project/d1321r3.pdf

ATA and ATAPI draft standards and other working documents

http://www.t13.org
Global Engineering Documents at http://global.ihs.com/

ATA Packet Interface for CD-ROM, SFF 8020i

Global Engineering Documents at http://global.ihs.com/

ATAPI Removable Media Device BIOS Specification (ARMD), Version 1.0

http://www.phoenix.com/techs/specs.html

ATAPI Removable Rewriteable Media Devices (SFF-8070i)

ftp://fission.dt.wdc.com/pub/standards/SFF/specs/INF-8070.PDF

ATM User Network Interface (UNI) Specification, Version 3.1, 1/e

Prentice Hall; 1995
ISBN 0-13-393828-X
http://www.atmforum.com/

ATSC Digital Television Standard and Amendment No.1 (A/53)

E-mail: mktg@smpte.org
http://www.atsc.org/Standards/stan_rps.html

Audio and Windows web page

http://www.microsoft.com/hwdev/audio/

Audio Codec ’97, Revision 2.1

http://developer.intel.com/ial/scalableplatforms/audio/index.htm

Audio Device Class Power Management Reference Specification, Version 1.0

http://www.microsoft.com/hwdev/specs/PMref/

Audio/Modem Riser Card Specification, Revision 1.01

http://developer.intel.com/ial/scalableplatforms/audio/index.htm

AV/C Digital Interface Command Set VCR Subunit Specification, V. 2.0.1

http://www.1394ta.org/Technology/Specifications/Descriptions/AVC_VCR_201.htm

Bellcore Technical References

http://www.telcordia.com/index.html

BIOS Boot Specification, Version 1.01

http://www.phoenix.com/techs/specs.html

Bluetooth Implementation and Windows web page

http://www.microsoft.com/hwdev/Bluetooth/

Bluetooth Special Interest Group (SIG): See Specification of the Bluetooth System.

Boot Integrity Services Application Programming Interface, Version 1.0

http://developer.intel.com/ial/wfm/wfmspecs.htm

Cable Modems and Windows web page

http://www.microsoft.com/hwdev/network/cable/

CardBus Host Controllers and Windows Compatibility

http://www.microsoft.com/hwdev/busbios/CARDBUS1.HTM

CardBus Technology and Windows web page

http://www.microsoft.com/hwdev/cardbus/
See also "Explanation of CardBus Registry Entries In PCMCIA.INF" at http://support.microsoft.com/support/kb/articles/q201/0/18.asp

Caution for Display Driver Dependencies on GDI

http://www.microsoft.com/hwdev/devdes/gdi.htm

Ccport and Windows 98 Second Edition

http://www.microsoft.com/hwdev/devdes/modem_up.htm

Color Coding for Connectors

http://www.pcdesguide.org/documents/pc99icons.htm

Color Management and Windows Operating Systems web page

http://www.microsoft.com/hwdev/color/

Common Application Environment (CAE) Specification

http://www.opengroup.org/onlinepubs/9629399/toc.htm

Common Information Model (CIM)

http://www.dmtf.org/work/cim.html

Communications Device Class Power Management Reference Specification, Version 1.0

http://www.microsoft.com/hwdev/specs/PMref/

Compaq, Intel, Phoenix BIOS Boot Specification, Version 1.01 (CIP BIOS Boot 1.01)

http://www.phoenix.com/techs/specs.html

Compatibility Testing for Hot-Plugging Support for PCI Devices

http://www.microsoft.com/hwdev/pci/hotplugtest.htm

Compatibility Testing Requirements for Display and Video Miniport Drivers

http://www.microsoft.com/hwdev/video/vidminiport.htm

Computer Display Monitor Timing Specifications, Version 1, Revision 0.8

http://www.vesa.org/standards.html

Configuring PCI-PCI Bridges on Windows 2000 and Windows XP

http://www.microsoft.com/hwdev/pci/

Configuring PCI-to-PCI Bridges with VGA Cards

http://www.microsoft.com/hwdev/pci/vgacard.htm

Data-Over-Cable Service Interface Specifications (DOCSIS)

http://www.cablemodem.com/

Debug Port Specification

http://www.microsoft.com/hwdev/NewPC/debugspec.htm

Default Device Class Power Management Reference Specification, Version 1.0

http://www.microsoft.com/hwdev/specs/PMref/

Design Guidelines for PC Card and CardBus

http://www.pcdesguide.org/library/pccard.htm (or in PC 2001 System Design Guide .CHM file)

Designing HID Game Controllers for DirectInput

http://www.microsoft.com/hwdev/devdes/hidgame.htm

Designing Multifunction Devices for Windows Operating Systems

http://www.microsoft.com/hwdev/mf/download/mfdesign10.zip

Design Rule for Camera File system (DCF) Specification

http://www.jeida.or.jp/document/standard/jeida49-2.html#english

Desktop Management Interface Specification, Version 2.0
DMI Compliance Guidelines, Version 1.0

http://www.dmtf.org/tech/specs.html

Device Bay Specification, Version 1.0

http://www.device-bay.org

Device class power management reference specifications

http://www.microsoft.com/hwdev/specs/PMref/

Digital Audio and Windows white papers

http://www.microsoft.com/hwdev/audio/

Digital Video Camcorder Support in Windows 98 and Windows 2000

http://www.microsoft.com/hwdev/vidcap/DVCam.htm

Digital Visual Interface (DVI), Revision 1.0

http://www.ddwg.org

Display Adapter Drivers and Windows Millennium Hibernation

http://www.microsoft.com/hwdev/video/Mill_D3display.htm

Display Adapters and Windows web page

http://www.microsoft.com/hwdev/display/

Display Device Class Power Management Reference Specification, Version 1.0b

http://www.microsoft.com/hwdev/specs/PMref/

Display Technology web page

http://www.microsoft.com/hwdev/display/

Distributed Management Task Force (DMTF)

http://www.dmtf.org

DLS Specification, V. 1.0

http://www.midi.org/

DOCSIS: See Data-Over-Cable Service Interface Specifications

DSL Devices and Windows web page

http://www.microsoft.com/hwdev/network/dsl/

DVB/DAVIC (Digital Video Broadcasting/Digital Audio Visual Council)

http://www.dvb.org
http://www.davic.org

DVD and Microsoft Operating Systems

http://www.microsoft.com/hwdev/devdes/dvdwp.htm

DVD Multifunction Devices: Avoiding Multiple Logical Unit Devices

http://www.microsoft.com/hwdev/dvd/multiLUN.htm

DVD Physical Format documents

Global Engineering Documents at http://global.ihs.com/

DVD Playback and Windows web page

http://www.microsoft.com/hwdev/dvd/

DVD Specification, Version 1.0

Toshiba Corporation, http://www.toshiba.com
or http://www.mpeg.org/MPEG/DVD/

DVD Specifications for Rewritable Disc, Part 1: Physical Specifications

Toshiba Corporation, http://www.toshiba.com
or http://www.mpeg.org/MPEG/DVD/

Easy PC Initiative and legacy-free design

http://www.microsoft.com/hwdev/newpc/

ECMA Standards: ECMA-267 (DVD-ROM), ECMA-272, 273 (DVD-RAM) and ECMA-274 (+RW)

http://www.ecma.ch/

EIA Standard #ANSI/EIA-516-88:
Other EIA standards

Global Engineering Documents at http://global.ihs.com/

El Torito - Bootable CD-ROM Format Specification, Version 1.0

http://www.phoenix.com/techs/specs.html

Enhanced BIOS Services for Disk Drives [T13-1226DT], Revision 7

Global Engineering Documents at http://global.ihs.com/

Enhanced Host Controller Interface Specification for Universal Serial Bus 2.0

To be published on http://www.usb.org/ when available

Ensuring Digital Audio Quality on CD-ROM Drives

http://www.microsoft.com/hwdev/devdes/cddigital.htm

Enumerating Serial Devices in Windows 2000

http://www.microsoft.com/hwdev/desinit/serddvr.htm

EPS Power Supply: A Server System Infrastructure (SSI) Specification for Entry Chassis Power Supplies

http://www.ssiforum.org/docs/entrylevelpowersupply.pdf

European Telecommunications Standards Institute (ETSI) or Global System for Mobile (GSM) standards

E-mail: secretariat@etsi.fr
http://www.etsi.org/

Extensible Firmware Interface Specification (EFI)

http://developer.intel.com/technology/efi/download.htm

Extensions to VT100 Terminal Definition

http://www.microsoft.com/hwdev/headless/

External DSL Modems Design Guidelines

http://www.microsoft.com/hwdev/network/dsl/extdslmodems.htm

Fibre Channel Second Generation Physical Interface, ANSI X3.297:1997

http://global.ihs.com

Fibre Channel Third Generation Physical Interface, ANSI X3.303:1998

http://global.ihs.com

Fibre Channel Physical and Signaling Interface (FC-PH), ANSI X3.230:1994; Amendment PC-PH-AM1 (X3.230:1994/AM-1:1996)

http://global.ihs.com

GDI+: Next-Generation Graphics Device Interface

http://www.microsoft.com/hwdev/video/gdinext.htm

Global Engineering Documents

http://global.ihs.com

Guidelines for WDM-based Software Modems

http://www.microsoft.com/hwdev/modem/softmodem.htm

Handshake procedures for digital subscriber line (DSL) transceivers

http://www.itu.int/

Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server

http://www.microsoft.com/hwdev/serverdg.htm

HID Usage Tables, Version 1.1
Other HID-related specifications

http://www.usb.org/developers/hidpage.html

Home Phoneline Networking Alliance (Home PNA) Specification, Version 1.0

http://www.homepna.org

Home Radio Frequency (HomeRF) Working Group

http://www.homerf.org

Hot-Plug PCI and Windows 2000 web page

http://www.microsoft.com/hwdev/pci/hotplugpci.htm

I2O (Intelligent I/O) Architecture Specification, Version 1.5

http://www.i2osig.org (special interest group)

IBM Personal System/2 Common Interfaces, Part No. S84F-9809
IBM Personal System/2 Mouse Technical Reference, Part No. S68X-2229

International Business Machines Corporation
IBM Customer Publications Support: (800) 879-2755

ICC Profile Format Specification, Spec ICC.1:1988-09 and Addendum 2, ICC.1A:1999-04

http://www.color.org/profiles.html

Icons for PCs web page

http://www.pcdesguide.org/documents/icons.htm

IEC 61883 Digital Interface for Consumer Electronic Audio/Video Equipment

http://www.iec.ch/webstore/

IEC 61966-2-1 Multimedia systems and equipment – Colour measurement and management – Part 2-1: Colour management – Default RGB colour space – sRGB

http://www.iec.ch

IEEE 802.14 Cable TV Working Group

http://www.walkingdog.com/

IEEE 1212-2000
IEEE 1284-1994
IEEE 1394-1995 Standard for a High Performance Serial Bus
IEEE 1394a-2000 amendment to IEEE 1394-1995
IEEE P1394b
Other IEEE standards

http://standards.ieee.org/reading/ieee/std/busarch/1394-1995.pdf
http://standards.ieee.org/index.html
http://global.ihs.com

IEEE 1394 and Windows web page

http://www.microsoft.com/hwdev/1394/

Implementing Display Control Panel Extensions in Windows 95/98

http://www.microsoft.com/hwdev/devdes/displaycpl.htm

Implementing Legacy Audio Devices on the PCI Bus

http://developer.intel.com/ial/scalableplatforms/audio/doc.htm

InfiniBand Trade Association

http://www.infinibandta.org

Infrared Data Association (IrDA) documents

E-mail: info@irda.org
http://www.irda.org/standards/specifications.asp

Infrared Devices and Windows web page

http://www.microsoft.com/hwdev/infrared/

Infrared Extensions to the NDIS Version 4.0 Functional Specification

http://www.cablemodem.com/

Infrared Transfer Picture Specification (IrTran-P), Version 1.0

http://www.irda.org/standards/specifications.asp

Input Device Class Power Management Reference Specification, Version 1.0

http://www.microsoft.com/HWDEV/specs/PMref/PMinput.htm

Input Device Drivers and Windows 2000

http://www.microsoft.com/hwdev/input/drv.htm

Input Devices and Windows web page

http://www.microsoft.com/hwdev/input/

Instantly Available PC System Power Delivery Requirements and Recommendations

http://developer.intel.com/design/power/supply98.htm

Instantly Available Power Managed Desktop PC Design Guide

http://developer.intel.com/technology/iapc/tech.htm

Intel Itanium Processor Family System Abstraction Layer Specification (SAL 3.0)

http://developer.intel.com

International Color Consortium (ICC)

http://www.color.org

Interoperability Specification for ICCs and Personal Computer Systems Specification, Revision 1.0 (PC/SC Specification)

http://www.pcscworkgroup.com/

Introducing Digital Rights Management

http://www.microsoft.com/hwdev/audio/DRM.htm

IP Multicast over Token-Ring Local Area Networks

RFC 1469
http://www.rfc-editor.org/rfc.html

IrDA Bridge Device Definition, 1.0 at

http://www.usb.org/developers

IrDA Control Specification
IrDA Serial Infrared Data Link Standard Specifications

http://www.irda.org/standards/specifications.asp

Other IrDA specifications
http://www.irda.org

IrDA Plug and Play Issues and Windows 2000

http://www.microsoft.com/hwdev/infrared/IrDAPnP.htm

IrTran-P, IrLPT, and IrDA Networking Support under Windows 2000

http://www.microsoft.com/hwdev/infrared/IrCOMM.htm

ISO 13491-1:1998 Banking—Secure cryptographic devices (retail)—Part 1: Concepts, requirements and evaluation methods

http://www.iso.ch/cate/d19521.html

E-mail: sales@iso.ch
http://www.iso.ch/cate/cat.html

ISO/IEC 7811-1:1995 Identification Cards—Recording technique—Part 1: Embossing

http://www.iso.ch/cate/d14717.html

ISO/IEC 7811-3:1995 Identification Cards—Recording technique—Part 3: Location of embossed characters on ID-1 cards

http://www.iso.ch/cate/d14721.html

ISO/IEC 7813:1995 Identification Cards—Financial transaction cards

http://www.iso.ch/cate/d14731.html

ISO/IEC 7816-1:1998 Identification cards—Integrated circuit(s) cards with contacts—Part 1: Physical characteristics

http://www.iso.ch/cate/d29257.html

ISO/IEC 7816-2:1999 Identification cards—Integrated circuit(s) cards with contacts—Part 2: Dimensions and location of the contacts

http://www.iso.ch/cate/d26536.html

ISO/IEC 7816-3:1997 Identification cards—Integrated circuit(s) cards with contacts—Part 3: Electronic signals and transmission protocols

http://www.iso.ch/cate/d14735.html

ISO/IEC 10373:1993 Identification cards—Test methods

http://www.iso.ch/cate/d18434.html

ITU (International Telecommunication Union) communications standards

E-mail: sales@itu.ch
http://www.itu.int/publications/index.html

Joint EIA/CVCC Recommended Practice for Teletext: North American Basic Teletext Specification (NABTS)

http://www.tiaonline.org/

Key Benefits of the I/O APIC

http://www.microsoft.com/hwdev/newpc/io-apic.htm

Key Support and Keyboard Scan Codes for Windows web page

http://www.microsoft.com/hwdev/desinit/scancode.htm

Legacy-Free Hardware and BIOS Requirements

http://www.microsoft.com/hwdev/NewPC/LF.htm

Legacy PCI Interrupt Routing and CardBus in Windows 2000

http://www.microsoft.com/hwdev/cardbus/Spir.htm

Legacy Plug and Play Guidelines

http://www.pcdesguide.org/pc2001/

Legacy Support for USB Keyboards and Mice and the Host Controller Driver

http://www.microsoft.com/hwdev/busbios/usbhost.htm

Low Pin Count (LPC) Interface Specification

http://developer.intel.com/design/chipsets/industry/lpc.htm

MCNS Documents

http://www.cablemodem.org

Media Status Notification Support Specification, Version 1.03

http://www.microsoft.com/hwdev/respec/storspec.htm

Microsoft Developer Network (MSDN) Professional membership

http://msdn.microsoft.com/subscriptions/

Microsoft DirectInput DDK provided with the Windows 98 DDK

http://www.microsoft.com/ddk/

Microsoft DirectShow

http://msdn.microsoft.com/directx/

Microsoft Extensible Firmware Interface FAT32 File System Specification,
Microsoft Extensible Firmware Interface Long File Name Specification,
Microsoft Portable Executable and Common Object File Format Specification,
plus other EFI-related specifications and guidelines

http://www.microsoft.com/hwdev/efi/

Microsoft information for hardware manufacturers

http://www.microsoft.com/hwdev/
E-mail: ihv@microsoft.com

Microsoft Platform SDK, including Win32® and Win64™ APIs

http://msdn.microsoft.com/downloads/sdks/platform/platform.asp
Also provided through MSDN Professional subscription

Microsoft TV Platform web page

http://www.microsoft.com/tv/

Microsoft Windows Driver Development Kit (DDK)

http://www.microsoft.com/ddk/
Also provided through MSDN Professional subscription

Microsoft Windows Hardware Compatibility List (HCL)

http://www.microsoft.com/hcl/

Microsoft Windows Hardware Compatibility Test Kits (HCT)
Microsoft Windows Hardware Quality Laboratory (WHQL) testing information

http://www.microsoft.com/hwtest/

Microsoft Windows Logo Program System and Device Requirements v.2.0
Microsoft Windows Logo Program for Hardware web page

http://www.microsoft.com/winlogo/hardware/

Mini PCI Specification, Revision 1.0

http://www.pcisig.com/developers/specification/index.php3?t2=1

MMC-2 Multi-Media Command Set-2 standard
including SCSI Multimedia Commands

Global Engineering Documents - http://global.ihs.com/

Modem Technology web page

http://www.microsoft.com/hwdev/modem/

Mount Rainier Drag and Drop Data on CD-RW

http://www.mt-rainier.org

MSDN Professional subscription

E-mail: msdn@microsoft.com
http://msdn.microsoft.com/subscriptions/

Multifunction Device web page

http://www.microsoft.com/hwdev/mf/

Multifunction Print Device Design Guidelines

http://www.microsoft.com/hwdev/mf/mfp.htm

Multimedia Commands – 2 (MMC-2)

Global Engineering Documents - http://global.ihs.com/

MultiProcessor Specification, Version 1.4 (replaced by ACPI 1.0b)

http://developer.intel.com/design/intarch/MANUALS/242016.htm

Multiprocessor Systems and Windows Processor Steppings Support

http://www.microsoft.com/hwdev/desguid/smp.htm

MultiRead Specifications for CD-ROM, CD-R, CD-R/RW, & DVD-ROM Devices, Revision 1.11

http://www.osta.org/html/mrspec.html

Multisession Compact Disc Specification Enhanced Music CD Specification, Version 1.0

Replaced by Multi-Media Command Set-2 (MMC-2) standard

NCITS Serial Bus Protocol-2 (SBP-2) transport protocols [ANSI NCITS 3.25-1998]
SCSI Reduced Block Commands (RBC), NCITS.330:2000

http://www.ncits.org/standards/standards.htm

NDIS 5.0

See Microsoft Windows DDK

Network Devices and Windows web page

http://www.microsoft.com/hwdev/network/

Network Device Class Power Management Reference Specification, Version 1.0a

http://www.microsoft.com/hwdev/specs/PMref/

Network PC System Design Guidelines, Version 1.0b

Preboot Execution Environment (PXE) Specification, Version 2.1

New Key Support for Windows web page

http://www.pcdesguide.org/documents/keycode.htm

OnNow and Power Management web page (OnNow and ACPI implementation guidelines under Windows operating systems)

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

OpenCable specification

http://www.opencable.com

OpenHCI: Open Host Controller Interface Specification for USB, Release 1.0a

http://www.microsoft.com/hwdev/respec/busspecs.htm

PAE Server Design web page

http://www.microsoft.com/hwdev/pae/

Parallel and Serial (COMM) Technology and Windows web page

http://www.microsoft.com/hwdev/comm/

PC 2001 System Design Guide

http://www.pcdesguide.org/pc2001/

PC '99 3.3Vaux FAQ Power Delivery/Consumption Clarifications

http://developer.intel.com/technology/iapc/pc99vqa.htm

PC Card and CardBus Guidelines, Version 1.1

http://www.pcdesguide.org/library/pccard.htm

PC Card Controller Device Class Power Management Reference Specification, V. 1.0

http://www.microsoft.com/HWDev/specs/PMref/PMcard.htm

PC Card Standard, Release 7

http://www.pcmcia.org/bookstore.htm

PC Card Voltage Requirements for Windows Operating Systems

http://www.microsoft.com/hwdev/cardbus/pccardvlt.htm

PC Design Guides web page

http://www.pcdesguide.org

PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges, (in Volume 11 of the PC Card Standard, Release 7)

http://www.pcmcia.org/bookstore.htm

PCI Bus Power Management Interface Specification, Revision 1.1 (PCI-PM)

http://www.pcisig.com/developers/specification/

PCI and Windows web page

http://www.microsoft.com/hwdev/pci/

PCI Device Subsystem IDs and Windows

http://www.microsoft.com/hwdev/devdes/pciids.htm

PCI Hot-Plug Specification, Revision 1.0

http://www.pcisig.com/developers/specification/

PCI IDE Controller Specification, Revision 1.0

http://www.pcisig.com/developers/docs/

PCI IRQ Routing on a Multiprocessor ACPI System

http://www.microsoft.com/hwdev/onnow/acpi-mp.htm

PCI Local Bus Specification, Revision 2.2 (PCI 2.2)

http://www.pcisig.com/developers/specification/

PCI Power Management and Device Drivers

http://www.microsoft.com/hwdev/desinit/pcipm.htm

PCI Subsystem IDs and PCI-to-PCI Bridge Devices

http://www.microsoft.com/hwdev/pci/pcibridge.htm

PCI to PCI Bridge Architecture Specification, Revision 1.1

PCI SIG
http://www.pcisig.com/developers/specification/

PCI-X Specification, Revision 1.0 (PCI-X 1.0)

http://www.pcisig.com/developers/specification/

Personal Computer Audio Quality Measurements

by Dr. Steven Harris and Cliff Sanchez, Crystal Semiconductor
http://www.cirrus.com/products/papers/meas/meas.html

PIAFS - PHS Internal Access Forum Specification

http://mitf.arib.or.jp/e/menu.html

PIMA 15740:2000 Photography – Electronic still picture imaging – Picture Transfer Protocol (PTP) for Digital Still Photography Devices

http://www.pima.net/standards/it10/IT10_POW.htm#15740
See also the implementation guidelines in the Windows DDK.

Plug and Play Design Specification for IEEE 1394, Version 1.0c
Plug and Play External COM Device Specification, Version 1.0
Plug and Play ISA Specification, Version 1.0a and Clarifications to the Plug and Play ISA Specification, Version 1.0a
Plug and Play Parallel Port Devices, Version 1.0b

http://www.microsoft.com/hwdev/respec/pnpspecs.htm

Porting Your Driver to 64-bit Windows

http://www.microsoft.com/hwdev/64bitWindows/

Preboot Execution Environment (PXE) Specification, Version 2.1

http://developer.intel.com/ial/wfm/wfmspecs.htm

Printers and Windows web page

http://www.microsoft.com/hwdev/print/

QIC 157 Revision D, "Common SCSI/ATAPI Command Set For Streaming Tape"

http://www2.qic.org/qic/html/standards/15x.x/qic157d.pdf

Reduced Block Commands (RBC)

ftp://ftp.t10.org/t10/drafts/rbc/rbc-r10a.pdf

Removable Storage Management and Windows 2000

http://www.microsoft.com/hwdev/storage/RSM.htm

RFC 1469: See "IP Multicast over Token-Ring Local Area Networks"
RFC 1179; RFC 1662; RFC 1663

http://www.rfc-editor.org/rfc.html

RS-IA-64 System Abstraction Layer (SAL) Specification, Revision 2.7

http://developer.intel.com/design/ia-64/downloads/245359.htm

SBP-2 Support and Windows 2000

http://www.microsoft.com/hwdev/print/sbp2_w2000.htm

Scan Code Mapper for Windows 2000

http://www.microsoft.com/hwdev/input/W2kscan-map.htm

Scan Codes for Keyboard Power Switches

http://www.microsoft.com/hwdev/desinit/scancode.htm

SCSI-3 Block Commands (SBC), ANSI NCITS.306:1998
SCSI-3 Fibre Channel Protocol (FCP), ANSI X3.269:1996
SCSI-3 Stream Commands (SSC), ANSI NCITS.335:2000
SCSI Primary Commands (SPC)
SCSI Primary Commands (SPC), ANSI X3.301:1997
SCSI-3 Medium Changer Commands (SMC), ANSI NCITS.314:1998
SCSI Parallel Interface (SPI-3) [NCITS.336:2000] standard
Small Computer Interface (SCSI-2) [X3.131:1994] standard
Other SCSI standards and documents

Global Engineering Documents - http://global.ihs.com/

Serial Bus Protocol 2 (SBP-2)

ANSI NCITS 325-1998
http://web.ansi.org/public/std_info.html

Serial Port Console Redirection Table

http://www.microsoft.com/hwdev/headless/

SFF 8070i; SFF 8090
Other SFF publications

Global Engineering Documents - http://global.ihs.com/

Shared Wireless Access Protocol (SWAP) Specification, Version 1.1

http://www.homerf.org/tech/

SII NS-2482-30

http://www.sii.co.jp/js/nshp/product/index-e.html (English)
http://www.sii.co.jp/js/nshp/product/NS2482/ns2482_30.html (Japanese)

Simple Boot Flag Specification, Version 1.0

http://www.microsoft.com/hwdev/desinit/simp_bios.htm

Smart Battery Charger Specification, Revision 1.1
Smart Battery Data Specification, Revision 1.1
Smart Battery System Manager Specification, Revision 1.0

http://www.sbs-forum.org/specs/

Smart Card and Windows web page

http://www.microsoft.com/hwdev/smartcard/

SMART IOCTL API Specification, v.1.1

http://www.microsoft.com/hwdev/download/respec/iocltapi.rtf

Specification for Exchangeable image file format (EXIF)

http://www.jeida.or.jp/document/standard/jeida49.html

Specification ICC.1:1998-09 File Format for Color Profiles

http://www.color.org/ICC-1_1998-09.PDF

Specification for Use of PCI IDs with Windows Operating Systems

http://www.microsoft.com/hwdev/pci/pciidspec.htm

Specification of the Bluetooth System, Volume 1: Core, Version 1.0 B
Specification of the Bluetooth System, Volume 2: Profiles, Version 1.0 B

http://www.bluetooth.com

Standard Modem Command Sets and Standard Modem INFs

http://www.microsoft.com/hwdev/modem/comndset.htm

STD-201: Extensions to NDIS for Wireless WANs

http://www.pcca.org/standards/standards.htm

Still Image Architecture and Windows 2000

http://www.microsoft.com/hwdev/stillimage/w2STI.htm

Still Image Devices and Windows web page

http://www.microsoft.com/hwdev/stillimage/

Storage Device Class Power Management Reference Specification, Version 1.0a

http://www.microsoft.com/hwdev/specs/PMref/

Storage Technology web page

http://www.microsoft.com/hwdev/storage/

Streaming Media Technology

http://www.microsoft.com/hwdev/stream/

Supporting PAE Memory under Windows 2000

http://www.microsoft.com/hwdev/newPC/PAEdrv.htm

Supporting Removable Devices under Windows

http://www.microsoft.com/hwdev/busbios/rem_devs.htm

System Management BIOS Reference Specification, Version 2.3

http://www.phoenix.com/techs/specs.html

System Test Implementers Forum

http://www.systemtest.org

TIA and other standards

http://global.ihs.com/

TWAIN Specification, Version 1.7

http://www.twain.org/docs/

Unimodem Diagnostics Command Reference Specification

http://www.microsoft.com/hwdev/respec/commspec.htm

Universal Disk Format Specification, Version 1.5 and Version 2.0

http://www.osta.org

Universal HCI (UHCI) Specification

http://developer.intel.com/design/usb/

Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1

http://www2.fm.intel.com/pcd_ae/public/general/specs_ind/USB/uhci_1_1.pdf

Universal Serial Bus Specification, Revision 1.1
Universal Serial Bus Specification, Revision 2.0

http://www.usb.org/developers/docs.html

Update on ClearType Font Technology and LCD Displays web page

http://www.microsoft.com/hwdev/video/clrtype.htm

UPS Applet for Windows 2000

http://www.microsoft.com/hwdev/onnow/ups.htm

Usage Tables for HID Power Devices, Version 1.0
Other HID-related specifications

http://www.usb.org/developers/hidpage.html

USB and Windows web page

http://www.microsoft.com/hwdev/usb/

USB Class Definitions for Communication Devices, Version 1.0
USB Common Class Specification, Revision 1.0
USB Communications Class Device 1.1
USB Definitions for Communications Devices, Version 1.0
USB Device Class Definition for Audio Devices, Release 1.0
USB Device Class Definition for Device Bay Controllers
USB Device Class Definition for Human Interface Devices (HID), Version 1.1
USB Device Class Definition for MIDI Devices, V. 0.9
USB Device Class Definition for Printing Devices, Version 1.1
USB Mass Storage Class Specification Overview, Revision 1.0
USB Monitor Control Class Specification, Revision 1.0
USB PC Legacy Compatibility Specification, 0.9 Draft Revision
USB Still Image Capture Device Definition Specification, Revision 1.0
Other USB device class specifications

http://www.usb.org/developers/devclass_docs.html

USB Plug and Play IDs and Selecting Device Drivers to Load

http://www.microsoft.com/hwdev/busbios/usbpnp.htm

U.S. T1 committee Technical Report TR-59, Single-Carrier Rate Adaptive Digital Subscriber Line (RADSL)

http://www.t1.org/html/trs.htm

VCOMM Port Driver Power Management Interface

http://www.microsoft.com/hwdev/devdes/vcomm.htm

VESA BIOS Extension Standard/Core Functions 2.0 (VBE/Core 2.0)
VESA Display Data Channel (DDC) Standard, Version 3
VESA Enhanced Extended Display Data Channel Standard (E-DDC), Version 1
VESA Enhanced Extended Display Identification Data Standard (E-EDID), Release A
VESA Extended Display Identification Data (EDID) Standard, Version 3
VESA Generalized Timing Formula (GTF), Version 1.1

Video Electronics Standards Association (VESA)
http://www.vesa.org/standards.html

Video Capture

http://www.microsoft.com/hwdev/vidcap/

Videophone-ready Modem Handbook, Version 1.0

http://developer.intel.com/ial/vidred/index.htm

WDM Audio Drivers for Windows 2000

http://www.microsoft.com/hwdev/devdes/wdmaudio.htm

WDM Kernel Streaming Architecture

http://www.microsoft.com/hwdev/desinit/csa1.htm

WDM Video Capture Overview

http://www.microsoft.com/hwdev/desinit/vidcap.htm

Web-Based Enterprise Management (WBEM) information

http://www.dmtf.org/

Windows 2000 Support for Mobile System Displays

http://www.microsoft.com/hwdev/video/mobiledisplay.htm

Windows 98 MS-DOS Box Game Compatibility

ftp://download.intel.com/ial/sm/compatibility.pdf

Windows Color Quality Specifications for Printer OEMs

http://www.microsoft.com/hwdev/color/

Windows DDK
including Windows 95 DDK, Windows 98 DDK, Windows Me DDK, Windows XP/Windows 2000 DDK, DirectX DDK, and information about WDM and NDIS)

http://www.microsoft.com/ddk/
http://msdn.microsoft.com/library/default.asp

Windows Driver Model (WDM) Technology web page

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

Windows Hardware Instrumentation Implementation Guidelines (WHIIG), Version 1.0

http://www.pcdesguide.org/whiig.htm

Windows Image Acquisition web page

http://www.microsoft.com/hwdev/wia/

Windows Logo Program for Hardware

http://www.microsoft.com/winlogo/hardware/

Windows Management Instrumentation (WMI) and Win32 Extensions schema

http://msdn.microsoft.com/downloads/sdks/wmi/

Windows Modem Update

http://www.microsoft.com/hwdev/devdes/modem_up.htm

WMI web page

http://www.microsoft.com/hwdev/wmi/

Windows NT Removable Storage Manager Programming Documentation

http://msdn.microsoft.com/library/psdk/zaw/proguide_912q.htm

Windows Support for HID-based Audio Controls

http://www.microsoft.com/hwdev/hid/audctrl.htm

Windows Update web page

http://windowsupdate.microsoft.com


Glossary - Windows Platform Terms

#

2-D

two-dimensional

3-D

three-dimensional

4GT

4 GB RAM Tuning

5GWIAG

5 GHz Wireless Industry Advisory Group

8B10B

IBM 8 bit to 10 bit encoding

8-VSB

ATSC 8-Vestigial Side Band

A

AA

See anti-aliasing

AAC

Advanced Audio Codec

ABP

Address Book Provider

ABR

available bit rate

AC

alternating current

AC-3

An audio standard developed by Dolby Laboratories for delivering 5.1 audio. This system compresses six channels of digital audio into 384 Kbps versus 4 Mbps uncompressed.

AC '97

Audio Codec '97

ACAP

As Close As Possible

ACK

acknowledgment signal

ACL

access control list

ACP

Acronym for the ANSI Code page in use. Windows uses this code page to convert to and from Unicode automatically whenever an application calls one of the 'A' entry points.

ACPI

See Advanced Configuration and Power Interface.

ACPI hardware

Computer hardware with the features necessary to support operating system power management and with the interfaces to those features described using the Description Tables as specified in Advanced Configuration and Power Interface Specification

ACPI Name Space

A hierarchical tree structure in operating system controlled memory that contains named objects. These objects can be data objects, control method objects, bus and device package objects, and so on. All the information in the ACPI Name Space comes from the Differentiated System Description Table.

ACR SIG 6

Advanced Communication Riser Special Interest Group

ACS

Admission Control Service

Active Device

A device that is powered and is not in the Suspend state.

Active Directory

Provides the ability to build applications that give a single point of access to multiple directories in a network environment, whether those directories are LDAP, NDS, or NTDS based directories.

A/D

analog-to-digital

adapter

See device.

ADC

analog-to-digital converter

add-on devices

Devices that are traditionally added to the base PC system to increase functionality, such as audio, networking, graphics, SCSI controller, and so on. Add-on devices fall into two categories: devices built onto the system board and devices on expansion cards added to the system through a system board connector such as PCI.

address

1. A number specifying a location in memory where data is stored. See also absolute address, address space, physical address, virtual address.

2. A name or token specifying a particular computer or site on the Internet or other network.

3. A code used to specify an e-mail destination.

ADF

Automatic Document Feeder

ADO

ActiveX Data Objects

ADPCM

Adaptive Differential Pulse Code Modulation. An encoding format for storing audio information in a digital format.

ADSI

Active Directory Service Interfaces

ADSL

Asymmetric Digital Subscriber Line. A method for moving data over regular phone lines. An ADSL circuit is much faster than a regular phone connection, and the wires coming into the subscriber’s premises are the same (copper) wires used for regular phone service.

ADT

attribute definition table

Advanced Configuration and Power Interface (ACPI)

A specification that defines an interface to the system board that enables the operating system to implement operating system directed–power management and system configuration. Following the ACPI allows system manufacturers to build systems consistent with the OnNow design initiative for instantly available PCs.

Advanced Power Management (APM)

A software interface (defined by Microsoft and Intel) between hardware-specific power management software (such as that located in a system BIOS) and an operating system power management driver.

advertisement

Where files are shown on a client machine as being available, but are not actually installed. They are available to the client machine through the network.

AEC

acoustic echo cancellation

agent

Software that runs on a client computer for use by administrative software running on a server. Agents are typically used to support administrative actions, such as detecting system information or running services.

AGP

Accelerated Graphics Port – A high performance, component level interconnect, targeted at 3D graphical display applications and based on a set of performance extensions or enhancements to PCI.

AGP system memory

See Non-local memory.

algorithm

In compression software, refers to a specific formula used to compress or decompress video or other data.

AGU

Address Generating Unit

alpha blending

Alpha or transparency blending attempts to approximate the way transparent and translucent surfaces distort light rays.

AMA

active member address, also AM_ADDR

AML

ACPI Machine Language. Pseudocode for a virtual machine supported by an ACPI-compatible operating system and in which ACPI control methods are written. The AML encoding definition is provided in section 16 of the Advanced Configuration and Power Interface Specification.

AMR

audio modem riser

analog

A method of signal representation by an infinitely smooth universe of numeric values. Measurements that are characterized as analog include readings of voltage and current. Compare with digital.

analog video

A video signal that represents an infinite number of smooth gradations between given video levels. Compare with digital video.

anamorphic

Unequally scaled in vertical and horizontal dimensions.

ANSI

1. American National Standards Institute. A standards-setting, non-governmental organization that develops and publishes standards for voluntary use in the United States.

2. The Microsoft Windows ANSI character set, essentially ISO 8859/x plus additional characters, which was originally based on an ANSI draft standard. MS-DOS uses the ANSI character set if ANSI.SYS is installed.

anti-aliasing (AA)

A form of interpolation used in graphics display technology when combining images; pixels along the transitions between images are averaged to provide a smooth transition.

AOAC

always on/always connected

AP

access point

A/PC

Auto PC

APC

asynchronous procedure call

API

Application programming interface. A set of routines that an applications program uses to request and carry out lower-level services performed by a computer operating system.

APIC

Advanced Programmable Interrupt Controller

APIPA

automatic programmable IP addressing

APM

See Advanced Power Management.

appliance

Single- or limited-purpose device, with simple consumer appliance-like functionality.

appliance server

A relatively low-cost computing device used for specific tasks, including Internet connectivity and file and print. Does not have the full capabilities or software of a typical server that is sold for general-purpose office use, but has and extremely high ease-of-use associated with it.

APS

analog protection system

AR_ADDR

Access Request Address

arbitrator

1. A software module in Windows that handles the allocation of hardware resources among devices.

2. Under Windows 95, the Plug and Play device driver responsible for allocating a specific resource among all drivers that require the resource. For example, VDMAD is a DMA-channel arbitrator, and VPICD has services for allocating IRQ lines. Windows 95 provides arbitrators for standard I/O, memory, hardware interrupt, and DMA-channel resources.

ARC

Advanced RISC Computing

architecture

A general term referring to the structure of all or part of a computer system. Also refers to the design of system software, such as the operating system, as well as referring to the combination of hardware and basic software that links machines on a computer network.

ARGB

alpha red, green, blue

ARMD

ATAPI Removable Media BIOS Specification

ARP

Address Resolution Protocol

artifact

An unintended, unwanted visual aberration in a video image.

AS

Advanced Server

ASCII

American Standard Code for Information Interchange. The most popular coding method used by small computers for converting letters, numbers, punctuation, and control codes into digital form. The ASCII character set is used by DOS. ASCII, the US national variant of ISO 646, is a 7-bit character set encoding that contains characters for upper and lowercase English, American English punctuation, base 10 numbers, and a few control characters. Although very primitive, it's important to note that ASCII’s set of 128 characters is the one common denominator contained in all the other common character sets.

ASF

Advanced Systems Format

ASIC

application-specific integrated circuit

ASL

ACPI Source Language. The programming-language equivalent for AML. ASL is compiled into AML images. The ASL statements are defined in section 15 of the Advanced Configuration and Power Interface Specification.

ASP

active server pages

aspect ratio

The relationship of width and height. When an image is displayed on different screens, the aspect ratio must be kept the same to avoid either vertical or horizontal stretching.

ASPI

Advanced SCSI Programming Interface

assertion

An assertion is a truth statement declaration of a feature criterion that extracts the precise requirement(s) from a source document’s text. Assertions are derived from all pertinent documents such as design guides, industry specifications, and industry standards documents. Assertions include criteria that are both testable and non-testable. The set of assertions forms an interpretation of the source document. See also Test Assertion.

assigned configuration

Drivers examine this portion of the device node to determine which resources have been allocated for the device. For Plug and Play cards, the assigned resources for a device can change dynamically or from one system start-up to the next.

ASSP

Application-specific Standard Protocol

ASTB

Advanced Set Top Box

ASVD

analog simultaneous voice/data

asymmetrical compression

A system that requires more processing capability to compress than to decompress an image. It is typically used for the mass distribution of programs on media such as CD-ROM, where significant expense can be incurred for the production and compression of the program, but the playback system must be low cost. Compare with symmetrical compression.

asynchronous

An operation that proceeds independent of any timing mechanism, such as a clock. Compare with synchronous.

AT

IBM registered trademark for PC/AT

AT#UD

Unimodem Diagnostics Command

ATA

AT Attachment. More commonly known as IDE. ATA defines the physical, electrical, transport and command protocols for the internal attachment of storage devices. A compatible register set, and a 40-pin connector and its associated signals. An integrated bus usually used between host processors and disk drives.

ATAPI

ATA Packet Interface. A device implementing the Packet Command feature set. A hardware and software specification that documents the interface between a host computer and CD-ROM drives using the ATA bus.

ATM

Asynchronous transfer mode. A transmission protocol that segments user traffic into small, fixed-size units called cells, which are transmitted to their destination, where they are reassembled into the original traffic. During transmission, cells from different users may be intermixed asynchronously to maximize utilization of network resources.

ATSC

Advanced Television Systems Committee

ATU-C

DSL termination at CO, also DSLAM

ATU-R

DSL termination at user side, also DSL modem

ATVEF

Advanced Television Enhancement Forum

audio class

The class of filters that deals with pulse code modulation or similar digitized data or analog signals. A WDM audio minidriver provides support for audio devices under the WDM digital audio architecture.

Audio Compression Manager (ACM)

A device-driver manager that controls which applications are required in order to play or record sounds. ACM manages the following types of drivers: compressor and decompressor (codec) drivers, format converter drivers, and filter drivers. If a source file was created on a computer that was not running Windows, it cannot use an ACM codec and thus cannot be used by Windows Media Technologies.

audio mixing

The method of combining multiple streams of audio data into a single stream through some method such as addition and clipping.

AUI

Attachment Unit Interface. The portion of the Ethernet standard that specifies how a cable is to be connected to an Ethernet card. AUI specifies a cable connected to a transceiver that plugs into a 15-pin socket on the network adapter.

authentication

The process of validating a user.

authorization

The process of granting or denying access to protected resources.

A/V

audio/video

AVD

alternating voice/data

AVGA

Advanced VGA

AVHDD

A/V Hard Disk Drive

AVI

Audio Video Interleaved

B

B2B

Business to business

B2C

business to consumer

B2E

business to employee

bandwidth

The data transfer capacity of a digital communications system, such as the Internet or a local area network (LAN). Bandwidth is usually expressed in the number of bits that a system is capable of transferring in a second: bits per second (bps) or kilobits per second (Kbps).

BAR

base address register

base character

One or more of:

  • A character that has meaning independent of other characters.
  • Any graphical character that is not a diacritic.
  • Any graphical character that is not, itself, a diacritic.

Baseline

1. A common definition of system components or performance upon which new design or testing criteria are defined.

2. In the printing and display of characters on the screen, an imaginary horizontal line with which the base of each character, excluding descenders, is aligned.

BBIC

BaseBand Integrated Circuit

BDA

1. Broadcast Driver Architecture

2. BIOS Data Area

BDC

backup domain controller

BDK

Business Development Kit

BER

Bit Error Rate

BiDi

Bi-Directional text. A mixture of characters that are read from left to right and characters that are read from right to left. Most Arabic, Hebrew, Farsi and Urdu characters, for example, are read from right to left, but numbers and quoted Western terms within these languages' text are read from left to right.

bilinear textures

A texture-mapping technique that averages the colors of surrounding texels to determine the texture color.

BIOS

Basic input/output system. A set of routines that works closely with the hardware to support the transfer of information between elements of the system, such as memory, disks, and the monitor. Although critical to performance, the BIOS is usually invisible to the end user; however, programmers can access it.

BIOS enumerator

Responsible in a non-ACPI Plug and Play system for identifying all hardware devices on the motherboard of the computer. The BIOS supports an API that allows all Plug and Play computers to be queried in a common manner.

BIS

Boot Integrity Services

bit map

Representation of characters or graphics by individual pixels arranged in rows (horizontal) and columns (vertical). Each pixel can be represented by either 1 bit (simple black and white) or up to 32 bits (high-definition color).

bit mapped graphics

Images created with matrices of pixels or dots. Also raster graphics.

bit rate

1. The speed at which digital content in general is streamed on a network. Bit rate is usually measured in kilobits per second (Kbps), for example, 28.8 Kbps.

2. The speed at which binary content can move across a network. It usually is measured in kilobits per second (Kbps).

bit specifications

Number of colors or levels of gray that can be displayed at one time. Controlled by the amount of memory in the computer’s graphics controller card. An 8-bit controller can display 256 colors or levels of gray; a 16-bit controller, 64,000 colors; and a 24-bit controller, 16.8 million colors.

BizTalk

1. Framework based on XML schemas and industry standards for sharing information.

2. Microsoft BizTalk™ Server 2000 technology, which supports Internet application integration via XML.

Blackcomb

Code name for the version of the operating system after Windows "Whistler," based on Windows NT technology.

blackpoint

A device's blackpoint is the input level where the device just begins to show color output.

blt

block transfer

Bluetooth wireless technology

A specification for small-form factor, low-cost, short range radio links between mobile PCs, mobile phones, and other portable devices.

BNC

Bayonet Nut Connector (Also British Naval Connector or Bayonet Neil Consulman)

BOOTP

Boot Protocol

BOSS

Bus Owner/Supervisor/Selector

Bottom up (order)

Arrangement of pixel data in memory with the lowest addressed pixels corresponding to the lower left corner of the image, proceeding to the right with increasing memory address, with the highest addressed pixels corresponding to the upper right corner of the image.

BPB

BIOS Parameter Blocks

BPC

Broadcast PC

bpp

Bits per pixel. The number of bits used to represent the color value of each pixel in a digitized image.

bps

Bits per second. The number of bits transferred per second in a data communications system. A measure of speed.

BPSK

Binary Phast Shift Keying

BRAN

Broadband Radio Access Networks

BRAN-HL/2

BRAN–HyperLAN/2

BRDF

Bi-directional Reflectance Distribution Functions

BRI

Basic Rate Interface

brightness

The value associated with a pixel, representing its gray value from black to white.

broadband

A high-speed transmission. The term generally refers to communication lines or services that operate at T1 rates (1.544 Mbps) or higher.

broadcast architecture

The set of technologies that enable PCs to receive broadcast data.

BSD

Berkeley Software Distribution (UNIX)

BSSID

Basic Service Set Identifier

BTh

See Bluetooth.

BTO

Build to Order

BTS

Microsoft BizTalk Server

buffer

A reserved portion of memory in which data is temporarily held pending an opportunity to complete its transfer to or from a storage device or another location in memory.

bulk transfer

One of the four USB transfer types, where transport of command, data, and status occurs solely by way of Bulk endpoints (not via Interrupt or Control endpoints, where the endpoint is the part of the hardware the communicates with USB). Bulk transfer occurs directly between the host and the device. Bulk transfer uses any available bandwidth and can be delayed until bandwidth is available.

bus compliance

A device is in bus compliance with a bus specification when it implements all functional, protocol, electrical, and mechanical aspects explicitly stated in that specification.

bus enumerator

In a Plug and Play system, a bus device driver that detects devices located on a specific bus and loads information about devices into the hardware tree.

BW

bandwidth

C

C#

Old name for ADE (from C++)

CA

certificate authority

C2

A security class of the Department of Defense Trusted Computer System Evaluation Criteria (DOD 4200.28.STD)

cache

A special memory subsystem in which frequently used data values are duplicated for quick access.

CAD

computer-aided design

CAL

channel abstraction layer

calibration

Calibrating a device means to cause it to behave in a known manner. Characterization is a necessary prelude to calibration.

CAM

Common Access Method

CAN

Controller Area Network

CAP

Carrier less Amplitude/Phase modulation

CAPI

Communications API

CAPP

Controlled Access Protection Profile

Card Services

Under Windows 95, a protected-mode system component that is a VxD linked with the PCMCIA bus driver. Card Services passes the event notification from socket services to the PCMCIA bus driver, provides information from the computer’s cards to the PCMCIA bus driver, and sets up the configuration for cards in the adapter sockets.

CAS

Conditional Access System

CAT5

Category 5. See UPT5

CAV

Constant Angular Velocity

CBQ

class-based queuing

CBR

constant bit rate

CBT

computer-based training

CCITT

Comite Consultatif Internationale de Telegraphie et Telephonie (Consultative Committee for International Telephone and Telegraph). An international standards organization dedicated to creating communications protocols that will enable global compatibility for the transmission of voice, data, and video across all computing and telecommunications equipment.

CCP

Compression Control Protocol

CD

compact disc

CDB

command descriptor blocks. The stream of bytes that completely describe the transmitted SCSI command.

CDC

communications class device

CDDB

Compact Disc Data Base

CDFS

CD-ROM File System

CD-I

compact disk-interactive

CDM

Common Diagnostic Model

CDMA

Code Division Multiple Access

CD-MRW

A rewritable CD drive or media that meets the requirements of the Mt. Rainier specifications.

CDO

Collaboration Data Objects

CDPD

Cellular Digital Packet Data

CD-R

compact disk-recordable

CD-R2

Physical format for CD read-only

CD-ROM

Compact disc read-only memory. A 4.75-inch laser-encoded optical memory storage medium (developed by NV Philips and Sony Corporation) with the same constant linear velocity (CLV) spiral format as compact audio discs and some videodiscs. CD-ROMs can hold about 550 MB of data.

CD-RW, CDR/W

compact disk-readable/writable

CE

consumer electronics

CEBus

Consumer Electronics Bus. A standard for communication over powerline (EIA-600).

CEDR

Windows CE Driver Repository

CF I/II

Compact Flash form factor I (one) and II (two)

CFM

cubic feet per minute

CGA

Color Graphics Adapter, A video adapter capable of 320 x 200 graphics resolution with four colors.

CHAP

Challenge Handshake Authentication Protocol

character

1. The simplest element used to represent written languages. Note that the appearance of a character is not constant: a character's appearance depends on the font used as well as the context of surrounding text. See also Glyph.

2. A code element.

character encoding

A one-to-one mapping from a set of characters into a set of numbers, used to represent text in software

characterization

The measurement of a device's initial state.

chroma, chrominance

1. The color portion of the video signal that includes hue and saturation information. Requires luminance, or light intensity, to make it visible.

2. Hue is defined as tint. Saturation indicates the degree to which the color is diluted by luminance (or by white light). Compare with luminance.

CHS

cylinder head sector

CI

1. Component Instrumentation. A specification for DMI related to the service layer.

2. Calling Indicator – One of four calling signal tones defined by V.8 for exchanging preliminary information. CI is used to indicate the call type (Data, FAX send/receive, Videotex, or H.324).

CID

CompatibleID

CIE

Commission International de l’Eclairage. The international commission on illumination. Developer of color matching systems.

CIFS

Common Internet File System

CIM

Common Information Model. Describes the WBEM data representation schema that is now a DMTF-sponsored industry standard.

CIMOM

CIM Object Manager. A key component of the WBEM architecture. A central message of WBEM is uniform data representation encapsulated in object-oriented fashion in the CIM. Formerly HMOM.

CINF

check (modem) INF tool

CIOB-G

Champion I/O Bridge with Gigabit Ethernet

CIOB-X

Champion I/O Bridge with PCI-X

CIP

common isochronous packet

CIS

card information structure

CISC

complex instruction set computing

ckt

circuit

class

For hardware, the manner in which devices and buses are grouped for purposes of installing and managing device drivers and allocating resources. The hardware tree is organized by device class, and Windows 95 uses class installers to install drivers for all hardware classes.

class driver

A Microsoft-provided class driver is an intermediate driver designed to provide a simple interface between a vendor-written minidriver and the operating system. Under WDM, the minidriver registers its associated hardware adapters with the class driver, and the class driver creates a file object to represent each adapter that registers.

CLB

Component Load Balancing

CLEC

Competitive Local Exchange Carrier

CLI

command line interface

client system

A computer using the specific Windows operating system that the test device is acquiring a logo for. This computer must also have the test device installed.

CLV

constant linear velocity

CMI

1. Control Method Interface

2. computer-managed instruction

CMIC

Champion Memory I/O Controller

CMM

Color Management Model

CMOS

Complementary Metal-Oxide Semiconductor, A low power consumption chip used to store information about your computer's hardware.

CMR

Communication and Network Riser (CNR) interface specification

CMP

1. Cellular MultiProcessing

2. connection management protocol

CMS

1. Communication Management Services

2. Color Management System

CMTS

cable modem termination system

CMYK

Cyan-magenta-yellow-black. A mixing model or method of describing colors used with many printing systems. Uses subtractive primaries, starting with white and subtracting percentages of cyan (blue), magenta (red), and yellow to yield desired colors.

CN

Common Name

Code

Program instructions. Source code consists of human-readable statements written by a programmer in a programming language. Machine code consists of numerical instructions that the computer can recognize and execute and that were converted from source code.

Code Page / Code Set (also code-page, code page)

An ordered set of characters in which a numeric index (codepoint value) is associated with each character. This term is generally used in the context of codepages defined by Windows 3.1 or MS-DOS, and may also be called a "character set" or charset.

A code page can be represented in a table as a mapping of characters to single-byte values or multibyte values. Many code pages share the ASCII character set for characters in the range 0x00 – 0x7F.

codec

1. Coder-decoder. A filter data that manipulates in some form, usually by compressing or decompressing the data stream.

2. compressor/decompressor

color depth

The number of simultaneous colors that are displayable. Color depth can be indicated as the number of colors displayable or the number of bits per pixel (bpp).

color keying

To superimpose one image over another for special effects.

colorspace

A color space is a way to describe a set of colors and their relationships. An example of a colorspace is CIE XYZ. A device’s colorspace describes its color gamut and the characteristics of the color output with that gamut.

COG

Cost of Goods

COM

1. Component Object Model; the core of OLE(object linking and embedding). Defines how OLE objects and their clients interact within processes or across process boundaries.

2. Legacy serial port.

command packet (ATA)

A command packet is a data structure transmitted to the device by a PACKET command that includes the command and command parameters.

compatibility mode

An asynchronous, host-to-peripheral parallel port channel defined in the IEEE 1284–1944 standard. Compatible with existing peripherals that attach to the Centronics-style PC parallel port.

Complex Script

Scripts that require special processing to display, print, and edit.

For more information, see Complex Scripts at http://www.microsoft.com/globaldev/FAQs/Complex.asp

compliance

A platform is in compliance with a specification when it implements all functional aspects explicitly stated in that specification.

Composite character (also composed character)

A text element consisting of a base character AND a diacritic or accent mark. Although most common in the Latin script, other scripts (including Greek, Devanagari and Tamil) have composite characters too.

composite video

A signal that combines the luminance, chrominance, and synchronized video information onto a single line. This has been the most prevalent NTSC video format.

compressed video

A digital video image or segment that has been processed using a variety of computer algorithms and other techniques to reduce the amount of data required to accurately represent the content and thus the space required to store the content.

compression

The translation of data (video, audio, digital, or a combination) to a more compact form for storage or transmission.

concatenate

To join sequentially.

configuration manager

The Windows Plug and Play system component that drives the process of locating devices, setting up their nodes in the hardware tree, and running the resource allocation process. Each of the three phases of configuration management—boot time, real mode, and protected mode—have their own configuration managers.

connection

A negotiated method of communication between devices, whether implemented in hardware or software.

connectionless networking

Networking based on media such as IEEE 802 LAN adapters and Fiber Distributed Data Interface (FDDI) adapters.

contrast

The range of light and dark values in a picture; or a measure of brightness content in an image. The range between the lightest tones and the darkest tones in an image.

controllerless modem

Also host-based controller. A modem that consists of a DSP without the usual microcontroller. The host CPU provides the AT command interpreter, modem-control functions, and v.42bis implementation. Compare with software modem.

control method

A definition of how an ACPI-compatible operating system can perform a simple hardware task. For example, the operating system invokes control methods to read the temperature of a thermal zone. Control methods are written in an encoded language called AML(ACPI Machine Language).

control transfer

One of the four USB transfer types. Control transfers support configuration/command/status type communications between client and function.

convergence

In an RGB monitor, where red, green, and blue signals all converge in one pixel. At full convergence, the RGB pixel would be white.

CPE

Customer Provided Equipment

CPI

1. Cycles Per Instruction

2. Characters per inch, The number of characters per inch that can be printed. Usually used when referring to a dot matrix printer.

CPL

Control panel applet

CPTWG

Copyright Protection Technical Working Group

CPU

Central processing unit. A computational and control unit of a computer; the device that interprets and executes instructions. By definition, the CPU functions as the "brain" of the computer.

CRC

cyclic redundancy check

CRL

Certificate Revocation List

CRM

customer relations management

CRS

Content Replication Service

CRT

Cathode Ray Tube, The picture tube in a monitor. Monitors are often informally referred to as CRTs.

CS

Computer Science (also name for the pcode compiler), also Customer Service

CSA

Connection and Streaming Architecture. Kernel-mode streaming in WDM.

CSC

1. Client-side caching

2. Color Space Conversion

CSEL

Cable Select

CSN

Card Select Number. The handle created by the system BIOS or the operating system through the isolation process and assigned as a unique identifier to each Plug and Play card on the ISA bus.

CSNW

Client Services for Networks

CSP

Cryptographic Service Provider

CSR

control and status register

CSS

copy scramble system

CT

Computer Telephony

CTO

Configure to Order

CTS

Clear To Send

CVS

Continuous Variable Slope Delta Modulation

CW

Control Word

D

D/A

digital to analog

DAA

data access arrangement

DAB

Digital Audio Broadcast

DAC

1. digital-to-analog converter

2. Device Access Code

DAP

Directory Access Protocol

DARPA

Defense Advanced Research Project Agency

DASD

direct access storage device

DAT

1. Digital audio tape. A consumer recording and playback media for high-quality audio.

2. dynamic address translation

data rate

The speed of a data transfer process, normally expressed in bits per second or bytes per second.

dB

decibel

DBC

Device Bay Controller

dBr

decibels above reference noise

DBS

direct broadcast satellite

DC

1. direct current

2. domain controller

3. device context

DCC

Darwin Component Code

DCD

1. Data Carrier Detected

2. digital capture device

DCE

Data Circuit-Terminating Equipment or Data Communications Equipment, typically refers to a modem device.

DCF

Data Call First model.

DCI

Display Control Interface

DCM

1. Device Control Module

2. Digital Content Management

DCOM

Distributed Component Object Model

DCT

Discrete Cosine Transform

DDC

Display data channel. The Plug and Play baseline for monitors. The communications channel between a monitor and the display adapter to which it is connected. This channel provides a method for the monitor to convey its identity to the display adapter.

DDC2B

Display Data Channel Standard Level 2B

DDE

Dynamic Data Exchange

DDF

Data Decryption Field

DDI

1. device driver interface

2. display device driver

DDK

Driver Development Kit

DDL

data definition language

DDM

device driver module

DDML

Display Driver Management Layer

DDN

Defense Data Network

DDR

double data rate

DDRAM

Direct DRAM

DDS

1. Distributed Data Server

2. Digital Data Service

decompression

To reverse the procedure conducted by compression software, and thereby return compressed data to its original size and condition.

default address

An address defined by the USB Specification and used by a USB device when it is first powered or reset. The default address is 00h.

default pipe

The message pipe created by the USB System Software to pass control and status information between the host and a USB device’s endpoint zero.

deinterlace

To combine two interlaced fields into a single frame that is not interlaced. Deinterlacing is done to remove artifacts and improve the quality of encoded video.

density

The degree of darkness of an image. Also, the percent of screen used in an image.

DEP

Discovery and Enumeration Protocol. Standardized by Annex D in IEEE P1394.1

depth-based fog

Color blending objects in a scene with a chosen fog color based on the depth of an object in a scene or its distance from the viewpoint.

DES

Data Encryption Standard

device

Any circuit that performs a specific function, such as a parallel port.

Device Bay

An industry specification that defines a mechanism for both peripheral devices and system bays. Allows adding and upgrading PC peripheral devices without opening the chassis.

device class compliance

A device is in device class compliance when it implements all functional aspects explicitly stated in the device class specific specification.

device ID

A unique identifier for a hardware device that the operating system uses to determine the proper driver to load. A device ID is a vendor-defined numeric value that uniquely identifies a device. The underlying bus driver for a device returns the device ID to the operating system, which uses the device ID to create a subkey for the device in the registry.

device node

The basic data structure for a given device, built by the Configuration Manager. Device nodes are built into memory at system startup for each device and enumerator. Each device node contains information about the device, such as currently assigned resources.

device object

A kernel-mode–only object type used to represent a physical, logical, or virtual device whose driver has been loaded into the system.

DFS

distributed file system

DFT

Discrete Fourier Transform

DHCP

Dynamic Host Configuration Protocol

DIAC

Dedicated Inquiry Access Code

Diacritic

1. Any mark placed over, under, or through a character, usually to indicate a change in phonetic value from the unmarked state.

2. A character that is attached to or overlays a preceding base character . Most diacritics are non-spacing characters that do not increase the width of the base character .

DIB

1. Device-independent bitmap. A file format designed to ensure that bitmap graphics created using one application can be loaded and displayed in another application exactly the way they appeared in the originating application.

2. Directory Information Base

DIFF

Differential

digital

A method of signal representation by a set of discrete numerical values, as opposed to a continuously fluctuating current or voltage. Compare with analog.

digital rights management (DRM)

The technology for packaging Windows Media files and managing the rights for accessing those files.

digital video

A video signal represented by computer-readable binary numbers that describe a finite set of colors and luminance levels. Compare with analog video.

digitization

The process of transforming analog video signal into digital information.

DIP

Dual Inline Package, A small switch used to change hardware settings.

Direct3D

Microsoft Direct3D is a component of the Microsoft DirectX API designed to enable game and 3D graphics on a computer running Microsoft Windows operating system. Direct3D provides device-dependent access to 3D video-display hardware in a device-independent manner.

DirectDraw

Microsoft DirectDraw is a component of the DirectX API that provides direct access to display devices while maintaining compatibility with the Windows graphics device interface (GDI). It is not a high-level graphics API. DirectDraw provides a device-independent way for games and Windows subsystem software, such as 3D graphics packages and digital video codecs, to gain access to the features of specific display devices.

DirectShow

Microsoft DirectShow is an API for client-side playback, transformation, and capture of a wide variety of data formats. DirectShow is the successor to Microsoft Video for Windows and Microsoft ActiveMovie™, and it improves on these older technologies in significant ways. For developers, the component architecture of DirectShow makes it easy to support new and custom data formats or create custom effects and transforms on standard formats. DirectShow provides default support for MPEG-1 (including MP3), MPEG-2 parsing and multiplexing, MPEG-4, AVI, WAV, RIFF, and DVD.

DirectX

Microsoft DirectX is an advanced suite of multimedia APIs built into Microsoft Windows operating systems. DirectX provides a standard development platform for Windows-based PCs by enabling software developers to access specialized hardware features without having to write hardware-specific code.

Dir-sync

See DSS.

disk I/O controller

Also HDC. A special-purpose chip and circuitry that directs and controls reading from and writing to a computer’s disk drive.

DISP

Directory Information Shadowing Protocol

display resolution

The number of pixels (horizontally and vertically) that are displayed on the screen.

DIT

Directory Information Tree

DLC

1. Digital Loop Carrier

2. Data Link Control

DLL

Dynamic link library. DLLs are modules that contain functions and data. A DLL is loaded at run time by its calling modules (.exe or .dll). When a DLL is loaded, it is mapped into the address space of the calling process.

DLS

1. Distributed Link Services

2. Downloadable Samples

3. Downloadable Sound

DMA

Direct memory access. A method of transferring data between device and host (or vice versa) without the intervention of the microprocessor. The system board uses a DMA controller to handle a fixed number of channels, each of which can be used by only one device at a time.

DMI

Desktop Management Interface. A framework created by the DMTF. DMTF specifications define industry-standard interfaces for instrumentation providers and management applications.

DMT

discrete multitone

DMTF

Distributed Management Task Force

DN

Distinguished Name

DNS

Domain Name System

dock

To insert a portable computer into a base unit. Cold docking means the computer must begin from a power-off state and restart before docking. Hot docking means the computer can be docked while running at full power. See also warm docking.

docking station

The base computer unit into which a user can insert a portable computer, expanding it to a desktop equivalent. A typical docking station provides drive bays, expansion slots, all the ports on an equivalent desktop computer, and AC power.

DOCSIS

Data-Over-Cable Service Interface Specification

DOM

Distributed Operations Master

dongle

A physical device, attached to a PC’s I/O port, that adds hardware capabilities.

DOP

Directory Operational Protocol

DOS

Disk Operating System, A computer operation system responsible for file access, storage, organization, and execution.

Dot4

1. IEEE P1284.4, Standard for Data Delivery and Logical Channels for IEEE Std. 1284 Interfaces.

2. In the DDK, the device setup class for a parent device that controls the operation of a multifunction IEEE 1284.4 peripheral device.

Double-byte character set (DBCS)

DBCS is a specific type of Multi-byte character set. It includes some characters that consist of 1 byte and some characters that consist of 2 bytes. Used for languages like Chinese, Japanese and Korean

DPA

Distributed Password Authentication

DPC

Deferred procedure call. Method used in Windows NT and Windows 2000 for event scheduling.

DPD

Differential Pulse Detection

DPI

dots per inch

DPMI

DOS Protected Mode Interface

DPMS

Display Power Management Signaling

DQPSK

Differential Quadrature Phase Shift Keying

DRAM

dynamic RAM

DRF

Data Recovery Field

driver

Kernel-mode code used either to control or emulate a hardware device.

driver stack

Device objects that forward IRPs to other device objects.

DRM

Digital Rights Management

DRMK

DRM Kernel

DRQ

Data Request

DRS

Driver Referral Server

DS

1. Directory Services

2. Digital Services

3. Digital Signal

4. Data Strobe encoding used by 1394a nodes

DSA

Directory Server Agent

DSC

digital still camera

DSDT

Differentiated System Description Table. In an ACPI BIOS, the DSDT contains the Differentiated Definition Block, which supplies the implementation and configuration information about the base system. The operating system always inserts the DSDT information into the ACPI Namespace at system boot time, and never removes it.

DSE

development software engineer

DSL

Digital Subscriber Line

DSLAM

DSL Access Multiplexer

DSP

Digital signal processor. An integrated circuit designed for high-speed data manipulations. Used in audio, communications, image manipulation, and other data-acquisition and data-control applications.

DSS

Digital Satellite System. This system is used in motion video test procedures.

DSSS

Direct Sequence Spread Spectrum, Modulates frequency using a predefined "spreading code" algorithm. Jumps much faster than FHSS

DSVD

Digital Simultaneous Voice/Data

DTE

Data Terminal Equipment – typically refers to a PC.

DTMF

Dual-Tone Modulation Frequency.

DTR

Data Terminal Ready

DTV

Digital television. DTV standards allow standard resolution mode—with about twice the horizontal resolution of conventional analog broadcasts—as well as HDTV mode. Video uses MPEG-2 digital compression, and audio uses AC-3 (Digital Dolby) compression.

DUN

Dial-up networking

DV

1. digital video

2. data voice

DVB

Digital Video Broadcasting

DVB/DAVIC

Digital Video Broadcasting/Digital Audio-Visual Council

DVBT

Digital Video Broadcasting Terrestrial

DVC

Digital Video Compression

DVCR

Digital Video Cassette Recorder

DVD

Digital versitile disk. Optical disk storage that encompasses audio, video, and computer data.

DVD-RAM

DVD- Random Access Memory

DVHS

Digital-VHS

DVI

Digital Visual Interface

DVR

Digital Video Recorder

DX8

DirectX Version 8.0

dynamic detection

The process by which a system can detect that a new device has been added or removed from the PC. This process allows the operating system and applications to immediately begin using the added devices or stop using the removed devices without rebooting the system.

E

EA

extended attributes

EAP

Extensible Authentication Protocol

EAPOL

EAP over LAN

EBD

Emergency Boot Disk

EC

embedded controller

ECA

Enrollment Certification Authority

ECC

error-correction code

ECM

Entitlement Control Message

ECMA

European Computer Manufacturers Association

ECN

Engineering Change Notice

ECP

Extended capabilities port. An asynchronous, 8-bit–wide parallel channel defined by IEEE 1284-1994 specification that provides PC-to-peripheral and peripheral-to-PC data transfers.

ECR

engineering change request (for PCI)

EDID

Extended Display Identification Data

EDK

Extension Development Kit

EDMA

Enhanced Dynamic RAM

EDT

European Deaf Telephone

EE

Eastern European

EEPROM

electrically erasable programmable ROM

EET

enhanced environment technology

EFI

Extensible firmware interface

EFS

Encrypting File System

EGA

Enhanced Graphics Adapter, A video adapter capable of 640 x 350 resolution with 16 colors chosen from a palette of 64 colors.

EIA

Electronic Industries Association

EIB

Embedded Intelligent Building

EIDE

Enhanced IDE (also E-IDE)

EIO

Extended I/O

EISA

Extended Industry Standard Architecture. A 32-bit PC expansion bus designed as a superset of the ISA bus. Designed to expand the speed and data width of the legacy expansion bus while still supporting older ISA cards.

EMB

extended memory block

embedded controller

The general class of microcontrollers used to support OEM-specific implementations, mainly in mobile environments. The embedded controller performs complex low-level functions through a simple interface to the host microprocessor(s).

embedded controller interface

ACPI defines a standard hardware and software communications interface between an operating system driver and an embedded controller—for example, Smart Battery and AML code. This allows any operating system to provide a standard driver that can directly communicate with an embedded controller in the system, thus allowing other drivers to communicate with and use the resources of system embedded controllers.

EMF

1. enhanced metafile

2. electromotive force

EMI

electromagnetic interference

EMS

Emergence Management Services Expanded-Memory Specification, A description of a technique for adding memory to IBM PC and compatible computers; also called LIM EMS because it was developed by Lotus/Intel/Microsoft.

Encoding

A method (algorithm) for presenting characters in digital form by mapping sequences of code values of into sequences of bytes. (e.g. ASCII, Unicode, Windows 1252)

encrypt

To programmatically disguise content to hide its substance. Encrypted content, often called a cipher, cannot be played without first being changed back into clear content through the process of decryption.

endpoint address

The combination of an endpoint number and an endpoint direction on a USB device. Each endpoint address supports data transfer in one direction.

End-User Defined Character (EUDC)

A special character, such as a rare ideograph, that the user creates with an editor and assigns to a code point within a reserved range. Note that such characters are not automatically recognized by the system for functions such as sorting.

enumeration

The process by which logical devices and buses, and their available resources, are identified by Plug and Play during system setup.

enumerator

A Plug and Play device driver that detects devices below its own device node, creates unique device IDs, and reports to Configuration Manager during startup. For example, a SCSI adapter provides a SCSI enumerator that detects devices on the SCSI bus.

EPF

Electronic Picture Frame

EPG

electronic program guide

EPP

Enhanced Parallel Port

EPROM

Electrically Programmable Read Only Memory

ERP

Enterprise Resource Planning

ESCD

Extended System Configuration Data

ESD

1. electrostatic discharge

2. electronic software distribution

ESDI

Enhanced Small Device Interface

ESP

1. EFI System Partition

2. enhanced serial port

ETK

Embedded Toolkit for Windows CE

ETSI

European Telecommunications Standards Institute

event set

A uniquely identified set that represents a group of items about which a client can be notified.

ExCA

Exchangeable Card Architecture

EPROM

Electrically Programmable Read Only Memory

EXIF

Exchangeable Image File format

expansion bus

A group of control lines that provide a buffered interface to devices located either on the system board or on cards that are plugged into expansion connectors. Common expansion buses included on the system board are USB, PC Card, and PCI.

expansion card

A card that connects to an expansion bus and contains one or more devices.

expansion ROM

See option ROM.

F

FACS

Firmware ACPI Control Structure

FADD

Floating-point ADDition

FADT

Fixed ACPI Description Table, contains I/O port locations of fixed feature registers Contains details about ACPI features (e.g. how to enable ACPI mode, which IRQ the SCI is wired to, etc.) Critical for proper ACPI operation

FAQ

frequently asked questions

FAT

File allocation table. A table or list maintained by an operating system to keep track of the status of various segments of disk space used for file storage.

FCA

Fibre Channel Arbitrated Loop

FCB

file control block

FCC

Federal Communications Commission

FCP

function control protocol

FC-PH

Fibre Channel Physical

FDC

Floppy disk controller. A special-purpose chip and associated circuitry that directs and controls reading from and writing to a computer’s disk drive.

FDDI

Fiber Distributed Data Interface

FDO

functional device object

FEC

forward error correction

FEK

File Encryption Key

FET

field-effect transistor

FFT

fast Fourier transform

FH

frequency hopping

FHS

frequency hop synchronization

FHSS

Frequency-Hopping Spread Spectrum, uses a synchronized clocking algorithm and jumps around to different carrier frequencies.

FiDO

filter device object

field

One half of a television picture. One complete vertical scan of the picture, containing 262.5 lines. Two fields make a complete television picture (frame). The lines of field 1 are vertically interlaced with the lines of field 2 for 525 lines of resolution.

FIFO

First in/first out. A method for processing a queue in which items are removed in the same order they were added.

filters

1. Components that provide the basic building blocks for processing data.

2. Under the WDM Stream architecture, also known as a functional device or multimedia processing driver. Each filter’s capability is described in part by a number of connection points called pins. Each pin can consume, produce, or both consume and produce a data stream such as digital audio. Specialized tasks can be solved by connecting filters by way of their pins into a topology—for example, to play filtered and mixed audio.

3. Under WDM, a filter is implemented as a kernel-mode entity that is a device object implemented by a kernel driver.

4. Under DirectShow, a filter is a user-mode entity that is an instance of a COM object, usually implemented by a DLL.

FIPS

Federal Information Processing Standards

FIR

fast IR

flash (disk or drive)

A type of non-volatile memory built into the unit or available as a PC Card that can be plugged into a PCMCIA slot. Flash memory can be written in blocks or over the entire chip, making it easy to erase or update.

flat shading

A method of shading that calculates a single intensity value for the rendered polygon that is used for the entire polygon surface. This is also known as "constant" or "faceted" shading.

FM

frequency modulation

FNO

Foreign Namespace Object

Font

A collection of glyphs for displaying text in a particular typeface.

Font association

Mechanism for substituting missing glyphs with glyphs from an appropriate font listed in the registry. Applies only to ANSI text APIs. The substitute font is identified by an ANSI codepage.

Font association is restricted to scripts and fonts that map codepoints to glyphs one to one. The registry setting is recreated by the system whenever the user changes system locale, updates language support, or changes user interface language.

FOP

Fan-Out-PHY. See also PIL-FOP.

Formatted text

Text displayed with multiple attributes, such as typeface, slant, weight, and color, and special effects such as shading, underlining, and blinking.

FOURCC

Microsoft Direct3D and the Direct3DX utility library use a special set of codes that are four characters in length. These codes, called four-character codes or FOURCCs, are stored in file headers of files that contain multimedia data, such as bitmap images, sound, or video. FOURCCs describe the software technology that was used to produce multimedia data. By implication, they also describe the format of the data itself. Direct3D applications use FOURCCs for image color and format conversion. FOURCCs are registered with Microsoft by the vendors of the respective multimedia software technologies. Some common FOURCCs are listed at http://msdn.microsoft.com/library/psdk/directx/DX8_VB/hh/directx8_vb/_dx_four_character_codes_fourcc__graphicsvb.htm

FP

floating point

fps

frames per second

FPU

Floating-Point Unit

FQDN

fully qualified domain name

FR

frame relay

frame

A single screen-sized image that can be displayed in sequence with other slightly different images to create animated drawings. A video frame consists of two interlaced fields of either 525 lines (NTSC) or 625 lines (PAL/SECAM), running at 30 frames per second (NTSC) or 25 frames per second (PAL/SECAM). Film runs at 24 frames per second.

frame rate

The number of frames displayed per second in video. High frame rates generally produce better quality video because there are more frames, which makes movement in the video appear smoother.

FRS

File Replication Service

FRU

Field Replaceable Units

FS A

Full-scale A-weighted. In measuring the dynamic range performance of digital audio recording and playback, FS A indicate that decibels are measured relative to full scale using "A weighting" filters.

FSB

front-side bus

FSD

file system driver

FSIP

full-scale input

FSK

frequency-shift keying

FSOP

full-scale output

FSRTL

File System Run Time Library

FTL

file translation layer

FTP

file transfer protocol

FTS

fault tolerance system

full duplex

In terms of data flow, indicates bi-directional data flow.

full-motion video

Video reproduction at 30 frames per second (NTSC-original signals) or 25 frames per second (PAL-original signals). See also frame.

functional device

See filters.

functional test

A functional test verifies the functionality, or correctness, of a feature implementation.

G

G.Lite (G.922.2)

1. Universal DSL

2. splitterless DSL

G11N

Abbreviated form of GLOBALIZATION. G + 11 characters + N.

GAL

Global Address List

gamma

Gamma is the exponent in the equation relating output intensity to the input signal.

gamut

The range of colors that a particular color-capable device can produce.

GART (Graphics Address Remapping Table)

For AGP technology, GART is the chipset hardware that is used by the operating system to map locked pages onto physical memory that can be used by AGP devices.

GB

gigabyte

Gbps

Giga bits per second

GC

Global Catalog

GC-HE

Grand Champion High-End

GC-LC

Grand Champion Low-Cost

GC-LE

Grand Champion Low-End

GCM

Champion (for) McKinley

GDI

Graphics Device Interface – Microsoft’s hardware-independent interface for 2D drawing and windowing commands.

GDT

Global Descriptor Table

GENA

General Event Notification Architecture

GFX

global effects

GIDEI

General Input Device Emulation Interface

GHz

gigahertz

GIF

Graphics Interchange Format

GINA

Graphical Identification and Authentication

Globalization

Designing and developing a software product to function in multiple locales. This process involves identifying the locales that must be supported, designing features which support those locales, and writing code that functions equally well in any of the supported locales. In other words, adding support for input, display, and output of a defined set of language scripts relating to specific geographic areas.

Glyph

A graphical representation of either a character (a, ?, ?, ?), a part character (e.g. a diacritic: °, ?) or a sequence of characters (for example, a ligature: fi).

GND

Ground reference voltage

GOF

Glass Optical Fiber

Gouraud shading

A method of shading based on linear interpolation of a polygon from its vertices. The shading value for the vertices is calculated from the normal of the vertex. This is also known as "color interpolation" or "intensity interpolation" shading.

GP

general protection

GPE

General Purpose Event

GPO

group policy object

GPRS

General Packet Radio System

GPT

GUID partition table

GPU

Graphics Processing Unit

graceful recovery

Also called graceful exit. Termination of a process that allows the operating system or parent process to regain normal control. Does not crash the machine or result in a GPF or blue screen. User is not required to close the application, and can continue to use the other functionality.

Graphics

Generally refers to computer graphics, including the software engine and hardware adapter that render images on screen.

gray scale

The spectrum (range) of shades of black that an image has.

group

In networking, an account that contains other accounts, called members Permissions and rights granted to a group are also granted to its members.

group policy

Used to specify settings for groups of users and computers, including software policies, scripts, user documents and settings, application deployment, and security settings.

GSM

Global System for Mobile Communications

GSNW

Gateway Services for Networks

GSS-API

Generic Security Service Application Program Interface

GSTN

General Switched Telephone Network.

GTF

Generalized Timing Formula

GUI

Graphical User Interface, A graphical interface that enables a user to start programs, choose commands, and manage files and other options by pointing to pictorial representations (icons) and lists of menu items on the screen.

GUID

Globally unique identifier. A 16-byte value generated from the unique identifier on an adapter, the current date and time, and a sequence number. This is used to allow any party to create identifiers that will be guaranteed not to overlap with other similarly created identifiers.

H

H.323

ITU standards for multimedia conferencing over IP

H.324

ITU-T Recommendation which specifies procedures for video telephony between computers over a GSTN.

HAL

Hardware Abstraction Layer – A device-specific interface, provided by the device manufacturer, that DirectDraw and Direct3D use to work directly with the display hardware.

hardware branch

The hardware archive root key in the registry that is a superset of the memory-resident hardware tree. Although the hardware tree contains information only about those devices currently detected and running in the system, the registry contains a complete list of all hardware ever installed on the particular computer. The hardware root key is \\Hkey_Local_Machine\Hardware.

hardware tree

A record in RAM of the current system configuration based on the information for all devices in the hardware branch of the registry. The hardware tree is created each time the system is started or whenever a dynamic change occurs to the system configuration.

HAVi

Home Audio Video interoperability

HBA

Host Bus Adapter

HCA

host channel adapter

HCAL

hardware channel abstraction layer

HCI

Host controller interface. For example, a system-level interface supporting USB.

HCL

Hardware Compatibility List. A registry of products that have been tested by WHQL and that have passed Windows compatibility testing.

HCT

Hardware Compatibility Tests. A suite of tests from Windows Hardware Quality Labs that verify hardware and device driver operations under a specific operating environment. These tests exercise the combination of a device, a software driver, and an operating system under controlled conditions to verify that all components operate properly.

HDC

Hard disk controller. A special-purpose chip and circuitry that directs and controls reading from and writing to a computer’s disk drive.

HDCP

High definition Digital Content Protection

HDD

hard disk drive

HDLC

High-Level Data Link Control

HDTV

High-definition TV. A proposed standard that recommends doubling the current 525 lines per picture to 1050 lines, and increasing the screen aspect ratio (that is, width to height) from the current 12:9 to 16:9, which would create a television screen shaped more like a movie screen.

headless

BIOS or server appliances without display or input peripherals, such as a keyboard, pointing device, or video monitor.

HEL

Hardware Emulation Layer – An interface that is provided by DirectDraw that emulates features in software.

HFC

hybrid fiber-coax

HID

Human Interface Device

HID specification

The device class definition developed by the USB standards group for Human Interface Devices. Serves as the basis for WDM input device support, and unifies input devices by providing flexible data reporting, typeless data, and arrayed and variable input and output.

high-contrast support

Part of Accessibility options set by users to indicate that they require a high degree of contrast to improve screen legibility.

high resolution

An adjective describing improvement in display image quality as a result of increasing the number of pixels per square inch.

HL/2

HiperLAN 2

HIPPI

High-Performance Parallel Interface

HMA

High-Memory Area, The first 64K of extended memory, accessible through extended memory manager such as HIMEM.SYS.

HMB

Host Memory Bridge

HMMP

HyperMedia Management Protocol. The encapsulation of CIM objects and operations on those objects.

HMMS

See CIM.

HMOM

See CIMOM.

HomePNA

The Home Phoneline Networking Alliance (HomePNA) has been formed to develop specifications for interoperable, home-networked devices using the phone wiring already in place.

HomeRF

The HomeRF Working Group (HRFWG) was formed to provide the foundation for a broad range of interoperable consumer devices by establishing an open industry specification for wireless digital communication between PCs and consumer electronic devices anywhere in and around the home. The HRFWG is developing a specification for wireless communications in the home called the Shared Wireless Access Protocol (SWAP).

host controller

The host’s USB interface.

HPC

Handheld PC

HPCF

Hard Polymer Clad Fiber

HPFS

High-Performance File System

HPNA

See HomePNA

HRTF

Head Related Transfer Function

HSB

Hue-saturation-brightness. With the HSB model, all colors can be defined by expressing their levels of hue (the pigment), saturation (the amount of pigment), and brightness (the amount of white included), in percentages.

HSC

Help and Support Center

HSCDS

high-speed cable data services

HS-CSD

High Speed Circuit Switched Data

HSM

hierarchical storage management

HSS

Health and Support Services

HSSDC

high-speed serial data connector

HTML

Hypertext Markup Language

HTTP

Hypertext Transfer Protocol

hub

A USB device that provides additional connections to the USB.

hue

The color tint of an image. The color of the analog video signal is determined by three factors: hue, saturation, and luminance.

Human Interface Device specification

The device class definition developed by the USB standards group for HIDs. Serves as the basis for the WDM input device support, and unifies input devices by providing flexible data reporting, typeless data, and arrayed and variable input and output.

HUT

HID Usage Tables

HW RAID

A RAID set where all RAID operations are done in hardware, without knowledge of the operating system.

Hz

Hertz

I

I2O

Intelligent I/O

I18N

Abbreviated form of INTERNATIONALIZATION. I + 18 characters + N.

IA-32, IA-64

Intel Architectures for 32-bit and 64-bit platforms.

IAC

Inquiry Access Code

IAL

Intel Architecture Labs

IANA

Internet Assigned Numbers Authority

IA-PC

Intel Architecture Personal Computer. A general descriptive term for computers built with processors conforming to the architecture defined by the Intel processor family based on the 486 instruction set and having an industry-standard PC architecture.

IAS

Information Access Service

IB

InfiniBand

IBTA

InfiniBand Trade Association

ICC

International Color Consortium, an industry organization that working to create and promote the standardization of an open, vendor-neutral, cross-platform color management system architecture and components.

ICD

Installable Client Driver. An OpenGL driver model in which the driver is responsible for implementing the entire OpenGL pipeline. Intended for high-end graphics cards that implement most of the OpenGL pipeline in hardware.

ICM

Image Color Management

ICMP

Internet Control Message Protocol

ICP

Internet content provider

ICS

Internet Connection Sharing

ID

Identifier. Generally, any text string used as a label, such as the name of a procedure or a variable in a program, or the name attached to a hard drive or floppy disk.

iDCT

Inverse Discrete Cosine Transform

IDE

Integrated Device Electronics. A type of disk-drive interface where the controller electronics reside on the drive itself, eliminating the need for a separate adapter card. See also ATA.

IDSL

Internet Digital Subscriber Line. ISDN basic rate service deployed using low-bandwidth DSL technology.

IDT

1. Internet Development Toolbox

2. Interrupt Dispatch Table

IEAK

Internet Explorer Administration Kit

IEC

International Electrotechnical Commission

IEEE

Institute of Electrical and Electronics Engineers, pronounced "I-triple-E." Founded in 1963, IEEE is an organization composed of engineers, scientists, and students. IEEE is best known for developing standards for the computer and electronics industry.

IETF

Internet Engineering Task Force

IEU

Integer Execution Unit

IF

1. Implementers Forum

2. Interface

IFFT

Inverse Fast Fourier Transform

IFS

Installable File System Manager

IGMP

1. Internet Group Management Protocol

2. Internet Group Membership Protocol

IGN

Internet group names

IHV

independent hardware vendor

IID

Interaural Intensity Difference

IIS

Internet Information Server

ILEC

Independent (Incumbent) Local Exchange Carrier

ILMI

Interim Local Management Interface

IM

instant messaging

IMADPCM

music-oriented codec

image

The computerized representation of a picture or graphic.

image resolution

The fineness or coarseness of an image as it is digitized; measured in dots per inch (DPI), typically ranging from 200 to 400 DPI.

IMAPI

Image Mastering API

IMB

Intra-Module Bus

IMD

Intermodulation Distortion

IME

See Input Method Editor

IMM

See Input Method Manager

IMS

Integrated Management system

INB

In Band

INF file

An INF file is an ASCII or Unicode text file that provides device and driver information, including the driver files, registry entries, device IDs, catalog files, and version information required to install the device or driver.

input class

The class of filters that provide an interface for HID hardware, including USB and legacy devices, plus proprietary and other HID hardware, under the WDM HID architecture.

Input language

A language to be inputted into the system, be it through the keyboard, a speech-to-text converter or an IME.

Input Locale

Pairing of input language (LangID) and method of input determines what language is currently being entered and how. See also Locale, System Locale, User Locale, User Interface (UI) Language.

Input Method Editor (IME)

A software program used to enter text with large character sets, such as Chinese, Japanese, and Korean.

Input Method Manager (IMM)

The module in Windows that handles communication between Input Method Editors (IMEs) and applications.

instantiate

In object-oriented programming, to create an instance of a class.

instrumentation

A mechanism for reporting information about the state of system hardware and software to enable management applications to ascertain and change the state of a system and to be notified of state changes.

integrated device

Any device—such as a parallel port, graphics adapter—that is designed on the system board rather than on an expansion card.

integration test

An integration test verifies the functionality and correctness of a feature implementation when it is fully integrated with other system components (higher level class and mini drivers, etc.).

intelligent streaming

A type of streaming that detects network conditions and adjusts the properties of a video or audio stream to maximize quality. Intelligent streaming is only available for content encoded by using a multiple bit rate profile.

IntelliMirror

Microsoft IntelliMirror® is a set of management technologies that mirror systems, data, and applications on a server.

interactive video

A video program and a computer program running in tandem under the control of the user. In interactive video, the user’s actions, choices, and decisions genuinely affect the way in which the program unfolds.

interconnect

Electrical or mechanical connection the physical connection and communication between two components in a system.

interface

1. The point at which a connection is made between two elements so that they can work with each other.

2. Software that enables a program to work with the user (the user interface, which can be a command-line interface, menu-driven, or a graphical user interface), with another program such as the operating system, or with the computer's hardware.

3. A card, plug, or other device that connects pieces of hardware with the computer so that information can be moved from place to place. For example, standardized interfaces such as RS-232-C standard and SCSI enable communications between computers and printers or disks.

interframe coding

Compression techniques that track the differences between frames of video. This results in more compression over a range of frames than intraframe coding.

interlaced

To display video by using a half-resolution image known as a field. Interlaced video uses two video fields to make a single frame of video. Each field of video contains alternating lines of an image: field 1 displays the odd numbered lines and field 2 displays the even numbered lines. Interlacing saves bandwidth when the video is transmitted as a television broadcast or on cable.

Internationalization

Term used out side of Microsoft to indicate Globalization and Localizability. I18N is a common abbreviation for Internationalization because the I in International is followed by 18 letters and ends with the letter "N".

interpolation

The process of averaging pixel information when scaling an image. When reducing the size of an image, pixels are averaged to create a single new pixel; when an image is scaled up in size, additional pixels are created by averaging pixels of the smaller image.

interrupt transfer

One of the four USB transfer types. Interrupt transfer characteristics are small data, non-periodic, low-frequency and bounded latency. Interrupt transfers are typically used to handle service needs.

I/O

Input/output. Two of the three activities that characterize a computer (input, processing, and output). Refers to the complementary tasks of gathering data for the microprocessor to work with and make the results available to the user through a device such as the display, disk drive, or printer.

IOCTL

Input/output control. A custom class of IRPs available to user mode. Each WDM class driver has a set of IOCTLs that it uses to communicate with applications. The IOCTLs give the class driver information about intended usage by applications. The class driver performs all IOCTL parameter validation.

IOS

I/O supervisor

IP

Internet Protocol

IP multicasting

Sending data to distributed servers on the Multicast Backbone. For large amounts of data, IP multicast is more efficient than normal Internet transmissions because the server can broadcast a message to many recipients simultaneously. Unlike traditional Internet traffic that requires separate connections for each source-destination pair, IP multicasting allows many recipients to share the same source. This means that just one set of packets is transmitted for all the destinations.

IPC

interprocess communication

IPL

Initial program load. A device used by the system during the boot process to load an operating system into memory.

IPOA

IP over ATM

IPP

Internet Printing Protocol

IPSec

IP Security

IPX

Internetwork Packet Exchange

IPX/SPX

Internetwork Packet Exchange/Sequenced Packet Exchange protocol

IR

infrared

IRAM

Intelligent RAM

IRC

Internet relay chat

IrDA

Infrared Data Association

IRDP

Internet Router Discovery Protocol

IrLAP

IR Link Access Protocol

IrLMP

IR Link Management Protocol

IRP

I/O request packet. Data structures that drivers use to communicate with each other. The basic method of communication between kernel-mode device drivers. An IRP is a key data structure for WDM, which features multiple layered drivers. In WDM, every I/O request is represented by an IRP that is passed from one driver layer to another until the request is complete. When a driver receives an IRP, it performs the operation the IRP specifies, and then either passes the IRP back to the I/O Manager for disposal or onto an adjacent driver layer. An IRP packet consists of two parts: a header and the I/O stack locations.

IRP_MJ_XXX

IRP Major. One of a predefined class of IRPs that a device can accept.

IRQ

Interrupt request. A method by which a device can request to be serviced by the device’s software driver. The system board uses a PIC to monitor the priority of the requests from all devices. When a request occurs, a microprocessor suspends the current operation and gives control to the device driver associated with the interrupt number issued. The lower the number—for example, IRQ3—the higher the priority of the interrupt. Many devices only support raising requests of specific numbers..

IRQL

IRQ level

IrTran-P

Infrared Transfer Picture

ISA

Industry Standard Architecture. An 8-bit (and later, a 16-bit) expansion bus that provides a buffered interface from devices on expansion cards to the PC internal bus.

ISAPI

Internet Server API

iSCSI

Generic name for the delivering of SCSI block storage commands and protocol over IP. IETF and the T10 Technical Committee each have working groups associated with this technology. Other names for this technology include EtherSCSI or SCSI over IP (SoIP).

ISD

Interaural Spectrum Density

ISDN

Integrated Service Digital Network. A set of communications standards that enable a single phone line or optical cable to carry voice, digital network services, and video.

ISIS

Image and Scanner Interface Specification

isochronous

Refers to a communication protocol based on time slices rather than handshaking. For example, a process might have 20 percent of total bus bandwidth. During its time slice, the process can stream data.

isochronous data

A stream of data whose timing is implied by its delivery rate.

isolation

The Plug and Play process by which cards on an ISA bus are distinguished from each other after system startup.

ISO

International Organization for Standardization

isochronous

Refers to a communication protocol based on time slices rather than handshaking. For example, a process might have 20 percent of total bus bandwidth. During its time slice, the process can stream data.

Isochronous Data

A stream of data where the timing is implied by the delivery rate.

Isolation

The Plug and Play process by which cards on an ISA bus are distinguished from each other after system startup.

ISO/OSI

ISO Open Systems Interconnection model. A layered architecture that standardizes levels of service and types of interaction for computers exchanging information through a communications network.

ISP

Internet service provider

ISR

Interrupt service routine. A routine whose function is to service a device when it generates an interrupt.

IST

interrupt service thread

ISV

independent software vendor

ITD

Interaural Time Difference

ITP

In-Target Probe

ITU-T

International Telecommunications Union – Telecommunications Standardization Sector

ITV

interactive television

IVR

interactive voice response

IXC

Inter Exchange Carriers

J

JNI

Java Native Interface

JPEG

Joint Photographic Experts Group. A working committee under the guidance of the ISO that is attempting to define a proposed universal standard for the digital compression and decompression of still images for use in computer systems.

K

KB

Kilobyte (1024 bytes) (referred to as K in Microsoft Knowledge Base articles)

KBC

keyboard controller

Kbps

kilobits per second

KCC

Knowledge Consistency Checker

KDC

Key Distribution Center

KDT

keyboard definition table

kernel

The core of the layered architecture that manages the most basic operations of the operating system, such as sharing the processor between different blocks of executing code, handling hardware exceptions, and other hardware-dependent functions.

kernel mode

The processor mode that allows full, unprotected access to the system. A driver or thread running in kernel mode has access to system memory and hardware.

Keyboard layout

A standard arrangement of characters on a keyboard that defines which keys produce particular characters or scan codes.

kHz

kilohertz

KMixer

Kernel Mixer

knowledge worker

User (other than IT professionals) who uses PC technology to access data for analysis and communication.

KS

kernel streaming

Kss

kilo-samples per second

L

L10N

Abbreviated form of LOCALIZATION. L + 10 characters + N.

L2

Level 2

L2TP

Layer 2 Tunneling Protocol

LAN

Local area network. A group of computers and other devices dispersed over a relatively limited area and connected by a communications link that enables any device to interact with any other device on the network. Compare with WAN.

LANE

LAN Emulation

Language Enabling

1. Adding support to software for document content in a particular language. In this sense, to enable an application for Japanese means to modify the software so that the user can enter, display, edit, and print text containing Japanese.

2. Modifying software so that it can be localized to a particular language. In this sense, enabling for Japanese means to modify software so that it can display Japanese text correctly in menus, dialog boxes, and other user interface elements. Note that in either sense, an enabled product may still have the user interface in English, i.e., it may not be localized. Contrast Localization.

Language Group

Term used to describe the supported script families in Windows 20000.

Language ID (LangID)

A 16-bit value that identifies a language. A LangID consists of a primary language, such as Arabic, and a sub-language, such as Arabic for Saudi Arabia.

LAPM

Link Access Protocol, Modem

latency

The amount of time it takes to send a packet from one designated point to another.

layered driver

One of a collection of drivers that responds to the same IRPs. Layered driver describes the highest-level and lowest-level drivers in a chain of layered drivers that process the same IRPs, along with all intermediate drivers in the chain.

LBA

Logical block address. A unit of data supplied or requested by a host computer.

LBA

logical block addressing

LBFO

load balancing and fail-over

LC

linear control

LCC

logical link control

LCD

liquid crystal display

LCLK

Link Clock

LDAP

Lightweight Directory Access Protocol. A network protocol designed to work on TCP/IP stacks to extract information from a hierarchical directory such as X.500. This gives users a single tool to comb through data to find a particular piece of information, such as a user name, e-mail address, security certificate, or other contact information.

LDT

Lightning Data Transport

Lead Byte

The byte value that is the first half of a double-byte character. See also Double-byte character set.

LEC

LAN emulation clients

LED

light-emitting diode

legacy

Any feature in the PC system based on older technology for which compatibility continues to be maintained in other system components. See Legacy Device and Legacy Mode.

legacy device

Non-ISA PnP/PCI/USB/IEEE 1394 legacy device is the term used by this document for devices that require either ACPI configuration mechanisms or Plug-n-Play system device nodes to specify resource configurations.

legacy mode

Non-ACPI legacy mode is the operational mode in which ACPI is disabled. In this mode, the interrupt router routes interrupts to the system management interrupt (SMI) instead of the system control interrupt (SCI). Power management, if supported, is provided through the APM 1.2 feature, and auto-configuration is supported through the ESCD, system device nodes, ISA PnP configuration registers, PCI configuration registers, and USB/IEEE 1394 enumeration and configuration mechanisms.

Legacy PCI Devices/Systems

A class of devices or systems which are compliant with PCI Local Bus Specification, Revision 2.1 or Revision 2.0.

LFN

long file name

Ligature

Two or more characters combined to represent a single typographical character. The modern Latin script uses only a few. Other scripts use many ligatures that depend on font and style. Some languages, such as Arabic, have mandatory ligatures; other languages have characters that were derived from ligatures, such as the German ligature of long and short "s" (ß) and the ampersand (&), which is the contracted form of the Latin word et.

LIM

Lotus-Intel-Microsoft

line of business

1. OEM division specifically focused on a particular business sector

2. Application created specifically to support specific business needs in an enterprise.

LM

Link Manager

LME

Large Memory Enabled

LMP

Link Manager Protocol

load balancing

Scaling the performance of a server-based program by distributing its client requests across multiple servers within the cluster by using Windows Clustering. Each host can specify the load percentage that it will handle, or the load can be equally distributed across all the hosts. If a host fails, Windows Clustering dynamically redistributes the load among the remaining hosts.

load/stress test

A load/stress test verifies the functionality of a feature implementation under stressful system load conditions.

LOB

line of business

local bus

Usually refers to a system bus directly connected to the microprocessor on a system board. Used colloquially to refer to system board buses located closer to the microprocessor than are ordinary expansion buses (that is, with less buffering), which are therefore capable of greater throughput.

Locale

A collection of rules and data specific to a language and a geographic area. Locales include information on sorting rules, date and time formatting, numeric and monetary conventions, and character classification. Microsoft uses this term in combination with others to specify a subclass of these preferences.

Microsoft deals with four different areas pertaining to locales: System Locale, User Locale, Input Locale, User Interface (UI) Language.

Locale ID (LCID)

A 32-bit value that identifies a locale. An LCID consist of a LangID and a sort key ID.

Localizability

Process of developing a program core whose features and code design don't make assumptions based on a single locale or script.

Localization

The process of customizing or translating the separated data and resources needed for a specific region or language. L10N is a common abbreviation for Localization because the L in Localization is followed by 10 letters and ends with the letter "N".

local memory

Random access memory associated directly with the graphics accelerator. Sometimes referred to as the "local frame buffer."

Logical order

The ordering of characters in text corresponding to the order in which they are inputted (such as when writing by hand, or keying in text using a keyboard). Contrast Visual order.

long filename (LFN)

Any filename that exceeds 8.3 characters in length or contains any lowercase characters or any characters that are not valid in the 8.3 namespace. For every long filename, an alias entry is generated that complies with the 8.3 filename rules for backward compatibility.

LON

Also known as LonWORKS or ANSI/EIA 709.1-A; technology developed by Echelon to provide in-home data transport over power line

LORG

large organization

lossless compression

Ensures that the original data is exactly recoverable with no loss in image quality.

lossy compression

The original data is not completely recoverable. Although image quality may suffer, many experts believe that up to 95 percent of the data in a typical image may be discarded without a noticeable loss in apparent resolution.

LRU

Least-recently used. Algorithm for paging.

LPAR

logical partitioning

LPC

low pin count

LPCM

location PCM

LPT

line printer

LRU

least-recently used

LS120

Laser storage 120 MB. An ATAPI (ARMD compliant) high density floppy drive that can read and write standard 1.44 megabyte floppy discs as well as proprietary 120 megabyte media.

LSA

Local Security Authority

LSB

least significant bit

LSI

large-scale integration

LTVS

Local TV Satellite

luminance

Used to describe the black-and-white component of a video signal. The amount of luminance contained in a video signal is directly related to the amount of light intensity. Also, brightness; one of the three image characteristics coded in composite television (represented by the letter Y). See also YUV.

LUN

logical unit number

LVD

Low Voltage Differential

LVE

Live Video Extensions

M

MAC

1. Media Access Control

2. Message Authentication Code

macro pixel

An aggregation of the minimum numbers of pels needed to define a minimum number of pixels such that these pels do not participate in the definition of any other pixels.

MADK

Microsoft ActiveX® Development Kit

MAPI

Messaging Application Programming Interface

master clock

Controls the rate of reference time within a graph and is used by filters within the graph to synchronize presentation times. Provides a standard mechanism to query the reference time, to query the physical clock time and rate (compared to the system clock) of the owner of the master clock, and to establish event notifications based on position changes in the master clock’s reference time.

MB

megabyte

Mbps

Mega bits per second

MB/s

Megabytes per second

MBONE

multicast backbone

MBR

1. Master Boot Record

2. multiple bit rate

Mb/s

megabits per second

MC

Momentary control; megacycle

MCA

Micro Channel Architecture. The design of the bus used in most IBM model PS/2 models. MCA is not compatible with ISA or EISA adapter cards.

MCD

1. Miniclient Driver. An OpenGL driver model in which the driver is responsible only for handling those features that can be accelerated in hardware, leveraging software implementation to handle the rest of the pipeline.

2. Master Copy Distribution

MCI

Media Control Interface

MCIS

Microsoft Commercial Internet System

MCL

Microsoft Compatibility Labs

MCNS

Multimedia Cable Network System

MCSC

Microsoft Certified Support Center

MCT

Modem Compatibility Test

MD5

message-digest hash function. This is the function used in the IP Security protocol defined in RFC 2085, "HMAC-MD5 IP Authentication with Replay Prevention".

MDCT

Modified Discrete Cosine Transform

MDI

multiple-document interface

MDK

Modem Developers Kit

MDL

Memory descriptor list. In Windows NT, an opaque structure, defined by Memory Manager, that uses an array of physical page frame numbers to describe the pages that back a virtual memory range.

MEI

Matsushita Electronics Incorporated

MEMS

MicroElectroMechanical Systems

MESN

Media Event Status Notification

metadata

Information about content, such as the title, author or copyright. The information is contained in a metafile.

method set

Used in Windows NT, Windows 2000, and WDM drivers to perform an action, such as allocating memory, and to provide a way to access related actions. Each method set has a unique identifier used to retrieve that method set and can be fulfilled either synchronously or asynchronously. A resource method set contains resource-specific methods for manipulating a type of resource by a kernel-mode client, and is used in resource allocation by enumerated devices on a bus.

MF

more fragments (bit)

MFC

Microsoft Foundation Class library

MFP

multi-function peripheral

MFT

master file table

MHz

megahertz

MI

1. Management Interface

2. multiple inheritance

MIB

Management Information Base

MIDI

Musical Instrument Digital Interface. An industry-standard connection for computer control of musical instruments and devices. A hardware and data standard for communicating between hardware. Most references involve only the data standard, which is a byte stream used for controlling musical instruments and storing the output of such instruments.

MIMD

multiple instruction multiple data

minidriver

A minidriver is a hardware-specific DLL that uses a Microsoft-provided class driver to accomplish most actions through function calls, and provides only device-specific controls. Under WDM, the minidriver registers its associated hardware adapters with the class driver, and the class driver creates a file object to represent each adapter that registers.

miniport driver

A device-specific kernel-mode driver linked to a Windows NT, Windows 2000, or a WDM port driver, usually implemented as a DLL that provides an interface between the port driver and the system.

MIP

Multimission Interactive Picture

MIP-mapped textures

A texture map that pre-filters and stores texture information at different spatial bandwidths. Each pre-filtered image, or level, in the MIP map is a power of two smaller than the previous level. A high-resolution level is used for objects that are close to the viewer, while lower-resolution levels are used as the object moves farther away.

MIPS

Millions of instructions per second. A common measure of processor speed.

MIS

management information system

mixer class

The class of filters that deal with manipulating controls such as volume, treble, and so on.

MLAN

Music LAN

MLD

In the context of this document, MLD is used to denote a metric of similarity, which we call Mean Level Difference. Given image components I and I’, this is computed on an h*w block as
<b>Equation

MMAC

Multimedia Mobile Access Communication; Japanese initiative similar to HIPERLAN2 and 802.11 aiming to provide wireless data transport either in-home or in the access net.

MMC

Microsoft Management Console

MMC2

Multimedia Command Set 2

MMC3

Multimedia Command Set 3

MMDS

Multichannel Multipoint Distribution System

MME

Microsoft Mobile Explorer

MMF

micron multimode fiber

MMHID

Multimedia Human Input Device

MMI

Man-Machine Interface

MMIO

memory-mapped I/O

MMU

memory management unit

MoComp

Motion Compensation

modem

Short for modulator/demodulator. A communications device that converts between digital data from a computer or terminal and analog audio signals that can pass through a standard telephone line. Although such a device may not actually modulate or demodulate analog signals, it may be described as a modem, because a modem is perceived by many users to be a black box that connects a computer to a communications line (such as a high-speed network or a cable TV system). International standards for modems are specified by the International Telecommunications Union, or ITU.

MOF

Managed Object Format

monolithic driver

A driver that has many different classes of functionality contained in the same driver.

motherboard

See system board.

MP@ML

Main Profile at Main Level

MP3

MPEG 1, Layer 3. A technology for compressing audio while retaining the original level of quality heard during playback.

MPAA

Motion Picture Association of America

MPEG

Moving Picture Expert Group. Used when referring to one of several standard video-compression schemes. A codec for squeezing full-screen, VHS-quality digital video into a small data stream so it can be played from a CD-ROM drive.

MPIO

Multi-path I/O

MPP

1. multimedia peripheral port

2. massively parallel processing

3. massively parallel processor

MPPE

Microsoft Point-to-Point Encryption

MPS

Multiprocessor Specification

MPX

multiplexed

MRL

Memory Read Line

MRM

Memory Read Multiple

MRU

most recently used

ms

millisecond

MSB

most significant bit

MSBPN

Microsoft Business Partner Network

MSC+

Mass Storage Class plus

MSCDEX

Microsoft CD-ROM Extensions

MSCS

Microsoft Cluster Service (MSCS) System is the high-availability clustering feature of Microsoft Windows NT Server 4.0 Enterprise Edition, Microsoft Windows 2000 Advanced Server, and Microsoft Windows 2000 Datacenter Server.

MSDE

Microsoft Data Exchange

MSDL

Microsoft Download Library

MSDN

Microsoft Developer Network.

MSDV

Microsoft Digital Video Infrastructure

MSEN

Media Status Event Notification

MSI

1. message-signaled interrupts

2. medium-scale integration

3. Microsoft Installer

MSMQ

Microsoft Message Queue Server

MSP

1. TAPI media service provider

2. Message Security Protocol

MSPI

SPI for MSPs

MSPMSP

Microsoft portable media service provider

MSR

Microsoft Research

MSTV

Microsoft TV

MSTVT

Microsoft TV Technologies

MSVAD

Microsoft Virtual Audio Device

MSU

memory storage unit

Mt. Rainier

The Mt. Rainier Group (Philips, Microsoft, Compaq, Sony, and Adaptec) proposes an open industry standard for making CD-RW easier to use, increasing compatibility and performance, and enabling operating system support..

MTA

multimedia terminal adapter

MTD

memory technology driver

MTF

Microsoft tape format

MTS

1. Microsoft Transaction Server

2. Multi-channel Television Sound

MTU

Maximum Transmission Unit

MUD

Master User Domain

MUI

Multilingual user interface

MultiByte Character Set (MBCS)

MultiByte Character Set. A mixed-width character set, in which some characters consist of more than 1 byte. A double byte character set (DBCS), which is a specific type of multibyte character set, includes some characters that consist of 1 byte and some characters that consist of 2 bytes.

multicast

A method of distributing content in which multiple clients share a stream from a server.

multicast address dynamic client allocation protocol (MADCAP)

An extension to the DHCP protocol standard used to support dynamic assignment and configuration of IP multicast addresses on TCP/IP-based networks.

multifunction device

A piece of hardware that supports multiple, discrete functions, such as audio, mixer, and music, on a single adapter.

multimedia

Refers to the delivery of information that combines different content formats, such as motion video, audio, still images, graphics, animation, text, and so forth.

multimedia processing driver

See filters.

multiple bit rate (MBR) video

A feature of Windows Media Technologies that supports the creating and streaming of multiple encoded video streams within one Windows Media stream. By using multiple bit rate video in Windows Media Encoder, you can create Windows Media-based content that has a variety of video streams at variable bandwidths ranging from 28.8 Kbps through 300 Kbps, as well as a separate audio stream. After receiving this multiple encoded stream, the server determines which bandwidth to stream based on the network bandwidth available. Multiple bit rate video is not supported on generic HTTP servers.

music class

The class of filters that deal with music data, such as ZIPI or MIDI.

MUX

multiplexer

MV

motion vector

MWI

Memory Write and Invalidate

N

NABTS

North American Basic Teletext

NAK

negative acknowledge

NAS

Network attached storage

NAT

network address translation

National Language Support (NLS)

The set of system functions in 32-bit Windows that contain national language support (information that is based on language and cultural convention).

NBDD

NetBIOS datagram distribution server

NBNS

NetBIOS name server

NC

1. network computer

2. naming context

NCB

network control block

NCITS

National Committee for Information Technology Standards

NCP

NetWare core protocol

NCSC

National Computer Security Center

NDA

Non-Disclosure Agreement

NDD

Norton Disk Doctor

NDIS

Network Driver Interface Specification. The interface for network drivers used in Windows and Windows NT-based operating systems, including Windows 2000. NDIS provides a common mechanism by which any given NDIS-compatible transport driver can communicate with any NDIS-compatible network adapter driver. Moreover, it provides for multiple transports to work over multiple network adapters by supporting multiplexing between transports and drivers.

NDS

Novell Directory Services. A feature introduced in Novell Netware 4.0 that provides access to directories that may be located on one or more servers.

.NET

Microsoft vision and road map for its next generation of software and services.

Net PC

Network PC

NetBEUI

NetBIOS Enhanced User Interface

NetBIOS

network basic input output system

NetBT

NetBIOS over TCP/IP

NetX

NetWare 3.x client shell

NFS

Network File System

NGWS

Next Generation Windows Services

nibble mode

An asynchronous, peripheral-to-host channel defined in the IEEE 1284-1944 standard. Provides a channel for the peripheral to send data to the host, which is commonly used as a means of identifying the peripheral.

NIC

network interface card

NICAM

Near-Instantaneously Companded Audio Multiplex

NIDRR

National Institute for Disability and Rehabilitation Research

NIS

Network Information Service

NIUF

National ISDN User’s Forum

NLB

Network Load Balancing

NLS

natural language support

NMI

Nonmaskable Interrupt. An interrupt that cannot be overruled by another service request. A hardware interrupt is called nonmaskable if it cannot be masked by the processor interrupt flag.

NNTP

Network News Transfer Protocol

non-interlaced

The method of scanning all lines on a display from top to bottom in sequential order at a specific rate per second. Unlike television, which uses an interlaced scanning method, computers typically use non-interlaced monitors.

non-local memory

Main system memory that can be accessed by the core logic chipset for supporting AGP operations.

Non-spacing character

A character, such as a diacritic, that has no meaning by itself, but overlaps a base character to modify it. Sometimes referred to as a "combining character".

NOS

network operating system

NP

network provider

NPI

network provider interface

NPRM

Notice of Proposed Rulemakings

nrt

non-real time

NTDS

Windows NT Directory Services — See Active Directory Services

ns

nanosecond

NSAP

Network Service Access Point

NSP

native signal processing

NT-1

Network Terminator 1

NTDS

Windows NT Directory Service

NTFS

An advanced file system designed for use specifically with the Windows NT and Windows 2000 operating systems. NTFS supports file system recovery and extremely large storage media, in addition to other advantages.

NTKERN

The Windows 98 version of the kernel component in Windows NT.

NTLDR

Windows NT Loader

NTLM

Windows NT LAN Manager

NTSC

National Television System Committee of the Electronics Industries Association (EIA). The standards-setting body for television and video in the United States. Sponsor of the NTSC standard for encoding color, a coding system compatible with black-and-white signals and the first system used for color broadcasting in the United States. The broadcast standard for the United States and Japan. See also PAL format and SECAM.

NTSC format

A color-television format having 525 scan lines, a field frequency of 60 Hz, a broadcast bandwidth of 4 MHz, line frequency of 15.75 KHz, frame frequency of 1/30 of a second, and a color subcarrier frequency of 3.58 MHz. See also PAL format and SECAM.

NTS/E

Windows NT Server, Enterprise Edition

NUMA

Non-Uniform Memory Access architecture

NVRAM

non-volatile RAM

O

OAL

OEM Adaptation Layer

OAM

operation and maintenance

OBEX

Object Exchange protocol

OCR

optical character recognition

OCX

OLE custom control

ODBC

open database connectivity

ODI

Open Datalink Interface

ODSI

Open Directory Services Interface

OEM

Original equipment manufacturer. Used primarily to refer to PC systems manufacturers.

OEMCP

Default OEM codepage of the system. The OEM codepage is the one used for conversions of MS-DOS based text mode applications.

OEX

OLE system control

OFDM

Orthogonal Frequency Division Multiplexing

OFS

Object File System

OHCI

Open Host Controller Interface

OID

Object ID

OLE

Object linking and embedding. A way to transfer and share information among applications. OLE is based on the COM programming model and binary standard.

ONID

Original Network Identifier

OnNow

A design initiative that seeks to create all the components required for a comprehensive, system-wide approach to system and device power control. OnNow is a term for a system that is always on but appears off and that responds immediately to user or other requests.

OO

object oriented

OOB

1. out-of-box

2. out-of-band channel

OOBE

out-of-box experience

OOC

On-off control

OOP

object-oriented programming

opcode

Open Host Controller Interface

OpenGL

Open Graphics Library. An operating system independent, industry-standard API for2-D and 3-D color graphics programming. Typically used for engineering, visualization, simulation, and other graphics-intensive applications.

OpenHCI

Operation Code

OpenType

A font format jointly developed by Microsoft and Adobe Systems, Inc. to allow for the addition of Type 1 (PostScript) font data to a TrueType font.

OpenType Layout

An extension to the OpenType format designed to provide support for international and high-end typography.

OPK

OEM preinstallation kit

option ROM

Optional read-only memory found on an expansion card. Option ROMs usually contain additional firmware required to properly boot the peripheral connected to the expansion card, for example, a hard drive. Also expansion ROM.

OR

A logical operation for combining two bits or two Boolean values; if one or both values are true, it returns the values of true. Compare with XOR.

ORB

operation request broker

OS

operating system

OSC

One-shot control

OSF

Open Software Foundation

OSI

Open System Interface

OSP

Online Service Provider

OSPF

Open Shortest Path First (interior gateway protocol)

OSPM

OS-directed power management

OSR

OEM service release

OSTA

Optical Storage Technology Association

OT

Output terminal

OTC

on-tape catalog

OU

Organizational Unit

out-

In terms of data flow in kernel streaming and DirectShow, indicates production of data. An out pin is compatible with an in pin.

Overlap

Overlap is a protocol that allows devices that require extended command time to perform a bus release so that commands may be executed by the other device on the bus.

P

PAC

Privilege Attribute Certificate

packed (format)

When pels are grouped near the lowest level of pixel aggregation possible, we say the format is packed. For example, 4:2:2 YVU data can be presented at Y0, U0, Y1, V0; or 4:1:1 YVU data can be presented as U0, Y0, V0, Y1, U1, Y2, V1, Y3, Y4, Y5, Y6, Y7. Other packed presentations are possible, differing slightly in the grouping or order, but common in that they are presented by small aggregations of pixels.

packed-pixel frame buffer

A portion of the display memory that holds the contents of a single screen image with screen bits stored in a single plane and with each pixel on the screen having a set of two or more corresponding bits that define the pixel color.

packet (USB)

A bundle of data organized in a group for transmission. Packets typically contain three elements: control information, data to be transferred and error detection and correction bits.

PAD

packet assemblers/disassemblers

PAE

1. Physical Address Extensions

2. Port Access Entity

PAL format

Phase Alternation Line format. The European video standard, except for France. See also NTSC and SECAM.

PAN

Personal Area Network

PAP

Password Authentication Protocol

Parent

A device, bus, function, or process at one level of a hierarchy that controls the behavior of components below it in the hierarchy.

PBX

Private Branch Exchange

PC

1. personal computer

2. packet classifier

PC 2001 / PC 99

The design guidelines for PC systems and peripherals defined in the PC 2001 and PC 99 Hardware Design Guides.

PC Card

A trademark of PCMCIA. A removable device that is designed to be plugged into a PCMCIA slot and used as a memory-related peripheral.

PCB

printed circuit board

PCH

PC Health

PCI

Peripheral Component Interconnect. A high-performance, 32-bit or 64-bit bus designed to be used with devices that have high bandwidth requirements, such as the display subsystem.

PCI PM

PCI Bus Power Management Specification, Revision 1.0 or higher

PCIC

PC Card I/O cards

PCI-X

A proposed extension to PCI.

PCLK

PHY CLocK

PCM

Pulse coded modulation. A method of encoding information in a signal by varying the amplitude of pulses. The most common method of encoding an analog signal into a digital bit stream.

PCMCIA

Personal Computer Memory Card International Association. Sometimes used to refer to a controller for a type of expansion card documented in the PCMCIA standards.

PCP

Printer Control Protocols

PCR

peak cell rate

PCS

Personal Communications System

PCT

1. private communication technology

2. program comprehension tool

PDA

Personal Digital Assistant

PDC

1. Primary Domain Controller

2. Personal Digital Cellular

PDEV

physical display device

PDK

Peripheral Developers Kit

PDL

page description language

PDO

physical device object

PDU

protocol data unit

PE

Portable EXE

pel (Pixel Element)

In a color space with multiple elements per pixel, we use Pel to indicate a datum that is a constituent value of one or more pixels. For example, in a 4:2:2 YVU color space, Y0 is a Pel, U0 is a Pel, and Y1 is a Pel. U0 is a constituent of both the first and second pixels, while the Y values are constituents of one pixel each. In a 5:5:5 RGB color space, each of the five bits R, G, and B values is a Pel.

PER

Packaged Encoding Rules

performance compliance

A device or system is in performance compliance when it meets all performance criteria specified in the PC 99 System Design Guide.

performance test

A performance test measures the throughput or turn-around time of a feature implementation.

perspective correction

A process that correctly alters textured triangles in a scene to lend the impression that the triangles' vertices are at different distances from the viewer (that is, the triangle has perspective).

PHY

physical layer device

PIC

programmable interrupt controller

PID

1. Product ID

2. program ID

PIF

program information file

PIL

Integrated PHY and Link

PIL-FOP

Integrated PHY and link, Fan-out PHY

PIM

Personal Information Manager, (calendar, contacts, inbox, tasks and notes) Pocket PC software.

PIMA

Photographic and Imaging Manufacturers Association

pin

A set of filter-defined properties in kernel streaming and DirectShow that specify a connection endpoint. For example, audio input can be described by a pin on a filter.

PIO

Programmed Input/Output

PIP

picture-in-picture

pipe

A logical abstraction representing the association between an endpoint on a device and software on the host.

PIT

programmable interrupt timer

PITL

priority issue tracking list

pixel

Pixel element. The information needed to specify the appearance of the minimum subset of an image. Portions of this information may apply to more than one pixel.

pixel drops

The unavailability of a pixel. This can be due to the absence of any pel. When pixel drops occur, packed formats typically lose all pels for the affected pixels, while planar formats typically lose individual pels, as is readily apparent when considering their grouping.

pixel format

The color depth of an image, usually measured in RGB or YUV.

PK

Public Key

PKCS

Public-Key Cryptography Standards

PKI

Public Key Infrastructure

PKT

Partition Knowledge Table

PL

Phy/Link. See also PIL, PIL-FOP.

Plain text

A string of text to be displayed with one value for each text attribute, i.e., one typeface, one slant, and one weight. Contrast Formatted text.

planar

See system board.

planar (format)

When pels are grouped by color space basis vector, we say the format is planar. For example, 4:2:2 YVU data can be provided with Y pels grouped together, U pels grouped together, and V pels grouped together.

platform

A platform, as defined and used in this document, is the motherboard and add-in hardware, the BIOS, and the low-level drivers (i.e., WDM class and mini drivers) that comprise a PC product.

Platform Compliance

A system is in platform compliance if it meets all system requirements specified in the PC 99 System Design Guide.

player

A client program or control that receives multimedia content streamed from a server or played from local files. Windows Media Player is an example of a player.

playlist

A list of links to various digital media files on a computer, a network, or the Internet.

PLC

Power Line Carrier / Phase Locked Clock

PLD

programmable logic device

PLDA

Private Loop Direct Attach

PLL

phase lock loop

Plug and Play

A design philosophy and set of specifications that describe hardware and software changes to the PC and its peripherals that automatically identify and arbitrate resource requirements among all devices and buses on the system. Plug and Play specifies a set of device driver interface elements that are used in addition to, not in place of, existing driver architectures.

Plug and Play BIOS

A BIOS with responsibility for configuring Plug and Play cards and system-board devices during system power up. Provides runtime configuration services for system board devices after startup. See also ACPI.

Plug and Play Compliance

A device, operating system, or BIOS is in Plug and Play compliance when it meets all Plug and Play requirements stated in the current Windows Logo Program requirements.

PM Compliance

A device is in power management compliance with a device-specific power management specification when it implements all power management aspects explicitly stated in that specification.

PMD

Physical Media Dependent

PME

power management event (also PME#)

PO

Power management component in kernel

POF

Plastic Optical Fiber

polling

Asking multiple devices, one at a time if they have data to transmit

PON

Passive Optical Network

POP

1. point-of-presence

2. Post Office Protocol

port

A connection or socket used to connect a device—such as a printer, monitor, or modem— to the computer. Information is sent from the computer to the device through a cable.

port driver

A low-level driver that responds to a set of system-defined device control requests and possibly to an additional set of driver-defined (private) device control requests sent down by a corresponding class driver. A port driver insulates class drivers from the specifics of host bus adapters and synchronizes operations for all its class drivers.

port replicator

Low-cost docking-station substitute intended to provide convenient, one-step connection to multiple desktop devices.

POSIX

Portable Operating System Interface for Unix

POST

Power On Self Test. A procedure of the system BIOS that identifies, tests, and configures the PC in preparation for loading the operating system.

POTS

Plain Old (analog) Telephone Service/system

power management

Mechanisms in software and hardware to minimize system power consumption, manage system thermal limits, and maximize system battery life. Power management involves trade-offs among system speed, noise, battery life, processing speed, and power consumption.

power policy

For power management, the decisions that determine how to save energy and when to go to sleep, based on end-user preferences, application needs, and system hardware capabilities.

power resources

Resources such as power planes, clock sources, and so on that a device requires to operate in a given power state.

P/PC

Pocket PC

PPDT

Peer-to-Peer Data Transport

PPF

Personal Preference File

PPP

Point-to-Point Protocol

PPPoE

PPP over Ethernet

PPTP

Point-to-Point Tunneling Protocol

Precomposed character

A single character that represents a sequence of characters, usually a combination of a base character and one or more diacritics.

PRI

Primary Rate Interface

Private Use Area (PUA)

The area in Unicode from U+E000 through U+F8EE that is set aside for vendor-specific or user-designated characters.

program guide

The on-screen user interface that allows users to select, manage, and search television programs and other content-viewing options.

property set

In Windows NT, Windows 2000, and WDM device driver models, a method defined to set and get properties on a driver. Each property set has a unique identifier, which represents types of related information and is used to access the property set.

protocol

A set of rules or standards designed to enable computers to connect with one another and to exchange information with as little error as possible. The word protocol is also used to refer to a large collection of standards that affect different aspects of communications, such as file transfer, handshaking, and network transmissions.

PS

packet scheduler

PS/2

Personal System/2

PSS

Product Support Services

PSTN

Public Switched Telephone Network

PTH

plated-through-hole

PTP

Picture Transfer Protocol

PTT

Post, Telephone, and Telegraph

Pulse Code Modulation (PCM)

A sampling technique for digitizing analog signals, especially audio signals. When you encode audio by using PCM, no compression is applied.

push technology

In client/server applications, to send data to a client without the client requesting it—for example, sending e-mail. In contrast, the World Wide Web is based on pull technology, where the client browser must request a web page before it is sent. Broadcast media are push technologies because they send information out regardless of whether anyone is tuned in.

PVC

permanent virtual circuit

PVR

Personal Video Recorder

PWB

Printed Wiring Board

PWC

Progressive Wavelet Codec

Px64

Also CCITT Recommendation H.261. A draft standard for motion video compression in videophone and teleconferencing applications, designed for 64-Kbps transmission channels.

PXB

PCI bridge

PXE

Preboot Execution Environment

Q

QAM

quadrature amplitude modulation

QFE

quick-fix engineering

QIC

Quarter-Inch Cartridge Drive Standards, Inc. An international trade association dedicated to promoting use of quarter-inch tape technology and products. For more information, visit the web site at http://www.qic.org/.

QoS

Quality of service

R

RADIUS

Remote Authentication Dial-In User Service

RADSL (RA-ADSL)

rate adaptive asymmetric digital subscriber line

RAID

redundant array of independent disks

RAM

Random access memory. Semiconductor-based memory that can be read and written by the microprocessor or other hardware devices.

RAMDAC

RAM digital-to-analog converter. A chip built into some VGA and SVGA display adapters that translates the digital representation of a pixel into the analog information needed by the monitor to display it.

RAPI

remote API

RAS

1. Remote Access Service

2. remote access server

3. Reliability, Availability, Serviceability

raster

A rectangular pattern of lines.

raster graphics

Also bitmapped graphics. Images defined as a set of pixels or dots in a column-and-row format.

rasterization

The conversion of vector graphics (images described mathematically as points connected by straight lines) to equivalent images composed of pixel patterns that can be stored and manipulated as sets of bits.

RASUM

reliability, availability, scalability/serviceability, usability, manageability

RAW

read and write

RBC

reduced block commands

RDMA

remote DMA

RDN

Relative Distinguished Names

RDR

redirector

Reading order

The overall direction of a sequence of text. Whereas words in a given script always flow in the direction associated with that script (for example, LTR for Latin, RTL for Hebrew), the flow sentence itself depends on the reading order. For example, a mixture of Arabic and English text may be regarded as French embedded in an overall Arabic sentence, implying RTL reading order, or as Arabic embedded in French, implying LTR reading order.

real time

In computing, refers to an operating mode under which data is received and processed; the results are returned instantaneously.

real-time processing

Processing that supports real-time functions such as telephony.

Red Book audio

The data format standard for conventional audio CDs used in home stereo systems.

reference

A logo'd device or system used as a control device or system, to test another device that is acquiring a logo.

refresh rate

The frequency at which data on the screen is redrawn. Faster refreshing results in less apparent screen flickering, but increases the frame buffer utilization.

registry

In Windows and Windows NT operating systems, the tree-structured hierarchical database where general system hardware and software settings are stored. The registry supersedes the use of separate INI files for all system components and applications that know how to store values in the registry.

REJ

rapid economic justification

Release delta

The time between the release of the domestic product and the release of the localized edition.

REMC

Reliability Enhanced Memory Controller

resolution

Number of pixels per unit of area. A display with a finer grid contains more pixels and thus has a higher resolution and is capable of reproducing greater detail in an image.

resource

1. Any sort of set from which a subset can be allocated for use by a client, such as memory or bus bandwidth. This is not the same as resources that are allocated by Plug and Play.

2. A general term that refers to IRQ signals, DMA channels, I/O port addresses, and memory addresses for Plug and Play.

resource arbitrator

In Plug and Play device configuration, a set of functions used by the configuration manager to arbitrate and allocate resources on the PC.

resource conflict

In Plug and Play device configuration, the result of more than one device sharing the same, nonshareable resource. Conflicts can cause the device to be partially functional or nonfunctional, or can cause the PC to malfunction completely.

resource data type function

A function that describes the resource requirements of an ISA expansion card as well as the programmability available on the card and its interdependencies.

RF

radio frequency

RFC

Request for Comments

RFC1483

Internet Request for Comments 1483, a standard for multiprotocol encapsulation over ATM networks

RFP

request for proposals

RGB

Red-green-blue. The primary colors in color video. Often used to describe a video color-recording scheme and the equipment that uses it. Also, a computer color-display output signal comprised of separately controllable red, green, and blue signals (as opposed to composite video, in which signals are combined prior to output). RGB monitors typically offer higher resolution than composite monitors. Compare with CMYK.

RID

Relative ID

RIM Blackberry device

Hardware that supports a mobile e-mail solution on a Mobitex network.

RIP

1. Routing Information Protocol

2. raster image processor

RIPL

remote initial program load

RIS

Remote Installation Server

RISC

Reduced Instruction Set Computing

RLE

Run-length encoding. A data-compression technique in which successive bytes of identical data are converted into a 2-byte pair, consisting of the repeated data byte and the repeat count.

RM

resource management

RMS

root-mean-square

RNA

remote network access

RNDIS

remote NDIS

ROM

read-only memory

root hub

A USB hub directly connected to the Host Controller. This hub is attached to the host.

router

A device that connects two or more networks, and carries data forward. A router determines where the destination computer is located, and then finds the best way to transmit the data there.

RP

recommended practice

RPC

remote procedure call

RR

Review Request

RSA

public-key cipher for encryption/decryption

RSDT

Root System Description Table, contains a list of pointers to other tables and Can be used to identify the system

RSM

Removable Storage Manager

RSOP

Resultant Set of Policies (WMI)

RSSI

Received Signal Strength Indication

RSVP

Resource Reservation Setup Protocol

RSX

Intel Realistic Sound eXperience

rt

real time

RTC

real-time clock

RTL

Right-To-Left. The directions characters are displayed in Middle Eastern languages like Arabic, Hebrew, Farsi and Urdu.

RTOS

real-time operating system

RTP

1. real-time transport protocol

2. Real-Time Protocol

RTS

Request to Send

RWS

Remote Winsock

RX

Receiver

S

SAC

1. Secure, Authenticated Channel

2. Secure Admin Console

SAF

Support Automation Framework

SAK

Server Appliance Kit

SAM

Security Accounts Manager

SAMI

Synchronized Accessible Media Interchange

sampling

The first step in the process of converting an analog signal into a digital representation. Accomplished by measuring the value of the analog signal at regular intervals (called samples). These values are then encoded to provide a digital representation of the analog signal.

SAN

Storage area network

SAP

1. Service Advertising Protocol

2. Secure audio path

SAR

segmentation and re-assembly

saturation

The extremes of operating range wherein the output is constant, regardless of changes in input.

SBCS

Single-byte Character Set. A character encoding in which each character is represented by 1 byte. Single byte character sets are mathematically limited to 256 characters.

SBP

1. Serial Bus Protocol

2.Serial Block Protocol

SBS

1. Small Business Server

2. Smart Battery System

SBS-IF

Smart Battery System Implementer's forum

SBSM

SBS Manager

scalability

The ability of a system to take advantage of multiple processors and to vary the information content of a program by changing the amount of data that is stored, transmitted, or displayed. In a video image, this translates to creating larger or smaller windows of video on screen (shrinking effect).

scaling

Process of uniformly changing the size of characters or graphics.

SCAM

SCSI Configured Automatically

SCI

System control interrupt. A system interrupt used by hardware to notify the operating system of ACPI events. The SCI is an active low, shareable, level interrupt.

SCID

service channel ID

SCL

system clock line

SCLK

system clock of a 1394 physical layer

SCO

Synchronous Connection-Oriented

SCP

Simple Control Protocol

SCPD

Service Control Protocol Definition

Script

A collection of characters for displaying written text, all of which have a common characteristic that justifies their consideration as a distinct set. One script may be used for several different languages (for example, Latin script, which covers all of Western Europe), and some written languages require multiple scripts (for example, Japanese, which requires at least three scripts: the hiragana and katakana syllabaries and the Kanji ideographs imported from China). Note that this sense of the word script has nothing to do with programming scripts such as Perl or VB Script.

SCSI

"Small computer system interface, pronounced "scuzzy." An I/O bus designed as a method for connecting several classes of peripherals to a host system without requiring modifications to generic hardware and software.

SCT

Software Compatibility Test

SD

1. Service Discovery

2. Secure Digital

SDDB

Service Discovery Database

SDDV

Standard Definition Digital Video

SDE

software development engineers

SDK

software development kit

SDMI

Secure Digital Music Initiative

SDP

Session Description Protocol

SDRAM

synchronous DRAM

SDU

service data unit

SE

single-ended

sealed case

A PC system design that does not provide end-user–accessible internal expansion slots. This is the equivalent of "no user-serviceable parts inside" for consumer electronics or appliances. A sealed case can provide external expansion capabilities.

SECAM

Sequential Couleur a Memoire (Sequential Color with Memory). The television standard for France, Russia, and most of Eastern Europe. As with PAL, SECAM is based on a 50-Hz power system, but it uses a different encoding process and displays 819 horizontal lines per frame at a scan rate of 25 frames per second (50 fields per second). See also NTSC and PAL format.

Secure Digital Music Initiative (SDMI)

An organization that sets standards for secure digital music. One of the main goals of SDMI is to create a framework for the secure distribution of music from the Internet to personal computers and portable devices.

Separators

Symbols used to separate items in a list, mark the thousands place in numbers, or represent the decimal point. Different locales follow different conventions for separators.

sequencer

Hardware or software functionality that interprets a time-stamped music data stream and sends packets to music hardware as their time comes due.

server system

A computer using the specific Windows operating system that the test device is acquiring a logo for. This computer must also have the reference device installed.

SES

1. storage enclosure services

2. Solution Exchange Standard

SETP

Secure Electronic Transactions Process

SFA

sales force automation

SFF

Small Form Factor

SFM

Services for Macintosh

SFP

System File Protection

SFS

shared file system

SHA

Secure Hash Algorithm

SID

1. Subsystem ID

2. stream identifier

SIG

special interest group

signable

The capability of having a test device driver digitally signed.

SIGNC

Special Internet Group Name Cache

SIMD

single-instruction, multiple-data

Sim-ship

Simultaneous ship. The release of localized editions of a product at the same time or soon after the domestic edition is released, usually within 30 days.

sink

In terms of device stacking in DirectShow, indicates that a pin represents possible connections that are attached to, rather than those that attach. Compare with source.

SIP

sound input peripheral

SIPC

Simply Interactive PC

SIR

Serial Infrared

SIT

Special Information Tone

Slant

The obliqueness or tilt of the glyphs in a font. The most common slants are "regular" and "italic".

SLDRAM

synchronous link DRAM

SLI

Scan Line Interleave

SLIP

Serial Line Internet Protocol

SMART

self-monitoring, analysis, and reporting technology

smart card

A small electronic device about the size of a credit card that contains an embedded integrated circuit. Smart cards are used for a variety of purposes, including storing medical records, storing digital cash, and generating network IDs.

smart phone

Wireless mobile device combining platform software, browser, modem chipset, and telephone handset.

SMB

server message block

SMBIOS

System management BIOS

SMBus

System Management Bus. A two-wire interface based on the I²C protocol. The SMBus is a low-speed bus that provides positive addressing for devices, as well as bus arbitration.

SMBus interface

ACPI defines a standard hardware and software communications interface between an operating system bus driver and an SMBus controller using an embedded controller.

SMI

system management interrupt

SMP

symmetric multiprocessing

SMPTE timecode

An 80-bit standardized edit time code adopted by the Society of Motion Picture and Television Engineers. See also timecode.

SMS

1. Microsoft Systems Management Server
2. short messaging service

SMT

surface-mount technology

SMTP

Simple Mail Transfer Protocol

SNA

Systems Network Architecture

snapshot

An image in time of the current data on a logical volume

SNIA

Storage Network Industry Association

SNMP

Simple Network Management Protocol

SNR

signal-to-noise ratio (also S/N)

SOAP

Simple Object Access Protocol. A remote-procedure call mechanism based on XML that sends commands and receives values over HTTP.

SO/CO

Service Office/Central Office

socket services

In Windows, a protected-mode VxD that manages PC Card hardware. Provides a protected-mode PCMCIA Socket Services 2.x interface for use by Card Services. A socket-services driver must be implemented for each separate PC Card controller that is used.

software device

A filter in kernel streaming and DirectShow (formerly ActiveMovie) that has no underlying hardware associated with it.

software modem

Also host-based signal processing or pumpless modem. Performs signal processing on the host CPU and implements the controller using V.42bis. The modem hardware consists of a telephone-line interface and digital-to-analog and analog-to-digital conversion circuitry. The hardware does not contain a DSP or a microcontroller. Compare with controllerless modem.

SOHO

Small Office/Home Office

SONET

Synchronous Optical NETwork

SORG

Small Organization

Sound Blaster

Hardware produced by Creative Labs, Inc., that represents for MS-DOS–based games one of the major hardware interfaces for both audio and music (specifically MIDI) data.

source

In terms of device stacking in kernel streaming or DirectShow, indicates that a pin represents possible connections that attach, rather than those that are attached to. Compare with sink.

SP

1. service pack (example: Windows NT 4.0 SP4)

2. service provider

S/PDIF

Sony/Phillips Digital Interface Format. The current standard for digital connection to consumer audio devices is the S/PDIF connector. Microsoft is encouraging the use of USB or IEEE 1394 as the digital connection between stereo equipment and PCs rather than adapting S/PDIF to meet PC needs.

Specular highlighting

A highlight or reflection observed on any shiny surface. Highlighting on shiny surfaces is caused by specular reflection (whereas normal reflection is diffused reflection). Specular reflection tends towards the color of the light source, rather than the normal reflected color of the object.

SPI

Service Provider Interface. Component in Microsoft networking, TAPI, and other communications technologies.

SPID

service profile identifier

spin down

A power-management capability in which a hard drive shuts down its spindle motor.

SPX

Sequenced Packet Exchange

SQL

Structured Query Language, Commonly pronounced "sequel," a database query and programming sub-language originally developed for IBM mainframe computers. There is now an ANSI-standard SQL definition for all computer systems.

SQRY

Pins on the Cardbay card used to determine its capabilities

SRAM

static RAM

SRB

stream request blocks

SRC

1. sample rate converter

2. seamless rate change

sRGB:

Standard RGB is a standard colorspace derived by Microsoft and HP, integrating installed base average monitor gammas and whitepoint standard values from broadcast studio recommendation ITU 709.

SSA

Serial Storage Architecture

SSDP

Simple Service Discovery Protocol

SSE

Streaming SIMD Extensions. In the context of this document, SSE is used to denote a metric of similarity, which we call Sum of Squared Errors. Given image components I and I’, this is computed on an h*w block as
<b>Equation

SSI

1. single system image

2. small-scale integration

SSIMD

Symmetrical SIMD

SSL

Secure Sockets Layer

SSO

Single Sign On

SSPI

Security Support Provider Interface

STA ACK

Station Acknowledgements

static resources

Device resources, such as IRQ signals, DMA channels, I/O port addresses, and memory addresses, that cannot be configured or relocated.

static VxD

A VxD that is loaded statically during system startup. A static VxD can be loaded in a number of different ways, including device enumeration by the Plug and Play static device enumerator.

STB

set-top box

stepping

Versions of processors are referred to as steppings. Lower steppings come before higher steppings, each stepping has a set of errata and fixes associated with it.

STI

Microsoft Windows Still Imaging Architecture that is supported in Windows 98 and in Windows 2000.

Still Image Architecture

A WDM architecture for still-image devices. A still-image minidriver provides support for still-image devices such as scanners and cameras under the WDM Still Image architecture.

Still Image plug-in

In the Still Image class architecture, a module that manages the translation of standard DDI calls to device-specific sequences in order to support vendor-specific device features.

STLP

Secure Transport Layer Protocol

STP

Shielded Twisted Pair

stream

An object representing an entity on an adapter capable of receiving, processing, or supplying data. Notice that a stream is identical to a WDM Stream architecture pin. A stream can accept data from or supply data to the processor, such as a stream representing an MPEG input, or can simply route data through hardware, such as a stream representing an NTSC output jack on the back of an adapter. The purpose of representing non-data hardware with a stream is that the properties of the hardware can be controlled by software.

streaming

A method of delivering content in which content located on a server is transmitted across a network in a continuous flow and then used by client software. By streaming data, the player can begin rendering the content immediately instead of waiting for an entire file to be downloaded.

STS/EN

Status and Enable bits (ACPI)

STT

Secure Transaction Technology

SU

Selector unit

SVC

switched virtual circuit

SVD

Simultaneous voice/data. A technology used in TAPI-based modem technology.

SVGA

Super VGA. A video standard established by VESA to provide high-resolution color display on IBM-compatible computers. The most commonly implemented SVGA standard is 1024x768 pixels resolution.

SVID

Subsystem Vendor ID

S-Video

Also Y/C video. A video signal that separates the luminance and color (Y and C) components of the signal for improved quality over composite video. The type of video signal used in the Hi8 and S-VHS videotape formats. It transmits luminance and color portions separately, using multiple wires, thus avoiding the NTSC encoding process and its inevitable loss of picture quality.

SW RAID

This is what is meant when using the Windows NT Server Ftdisk driver or Windows 2000 "dynamic disks" to take several physical disks and make one logical fault-tolerant (FT) volume out of them.

Syllabary

A set of written characters in which each character represents a syllable—for example, a consonant sound followed by a vowel sound. Examples of syllabaries include Japanese Katakana/Hiragana and the Indic scripts.

symmetrical compression

A compression system that requires equal processing capability for compression and decompression of an image. This form of compression is used in applications in which both compression and decompression are used frequently. Examples include still-image databasing, still-image transmission (color fax), video production, video mail, videophones, and video conferencing. Compare with asymmetrical compression.

Synchronization Manager

A centralized location for the user to synchronize all personally-owned offline data. It provides a common UI that a mobile user can use to prepare a computer for use away from a network.

synchronous

Any operation that proceeds under control of a clock or timing mechanism. Compare with asynchronous.

Synchronous Access Mode

Defined by V.80, S.A.M. allows the data protocols in a modem to be bypassed and allow any arbitrary, non-traditional protocol to be implemented in the host (such as H.324 video telephony systems).

system board

Also motherboard or planar. The primary circuit board in a system that contains most of the basic components of the system.

system context

The volatile data in the system that is not saved by a device driver.

system devices

Devices on the system board, such as interrupt controllers, keyboard controller, real-time clock, DMA page registers, DMA controllers, memory controllers, FDC, ATA ports, serial and parallel ports, PCI bridges, and so on. These devices are typically integrated in the supporting chip set.

System Locale

Not really a locale. Determines which script non-Unicode applications will support. It is the locale emulated by the system, as seen by applications.

For example, if the system locale for US Windows 2000 is set to Hebrew, then ANSI applications will see it as Hebrew localized Windows 2000, although the user interface of the system will still be in English.

The system locale is system wide, in that it applies to all users. Changing the system locale requires a reboot.

Systems Management Server

Provides a centralized management service for distributed systems.

T

TAPI

Telephony Application Program Interface. A set of Win32-based calls that applications use to control modems and telephones by routing application function calls to the appropriate service provider DLL for a modem.

TB

terabyte

TBD

To be determined

TC

traffic control

TCO

total cost of ownership

TCP

Transmission Control Protocol

TCP/IP

Transmission control protocol/interface program. A software protocol developed by the Department of Defense for communications between computers.

TDD

Telephone Device for the Deaf

TDI

Stands for Transport Driver Interface. TDI allows you to write new transport drivers that are independent of the network card. You can also write network applications to use TDI rather than relying on a certain protocol, such as NetBIOS or IPX.

TDM

time division multiplexing

TDMA

time division multiplexing access

TE

terminal equipment

Telecine

A name for a process of converting to Television field rates from Cinematography frame rates. The process is sometimes referred to as 3:2 pulldown. In this process, 24 frame per second film frames are post processed to generate two streams of fields, yielding 48 fields per second. The resulting field streams are upsampled by replicating selected fields at a rate of one replication for every four original source fields. To provide a more visually pleasing result, the phase of this replication is different in each stream. The resulting video content, when viewed in a progressive environment, is seen to consist of three ‘good’ frames – frames where both fields came from the same film source frame – and two ‘bad’ frames– where the fields are from different film source frames. Note: It is possible, if this is the only processing the film/video has been subjected to, to reconstruct the original film source field pairs and thus the original film frames. In practice, video post production frequently involves any of several steps that interfere with the ability to do this. Video mode edits, and compositing with material originally produced as video (interlaced scan with a difference in time between the interlaced samples) are two examples of such steps. Telecine is sometimes used to name a machine that implements the process.

telephony

Telephone technology.

telset

local telephone instrument

Test assertion

A statement that clarifies or provides additional detail with respect to a testable requirement. The intent of a test assertion is to remove any ambiguity from a requirement by clearly stating assumptions.

test suite

A test suite is a collection of tests that collectively verify a feature implementation.

texel

For 3-D graphics, refers to the individual color values that make up a texture’s two dimensional array of color values. Each texel has a unique address in the texture. The address can be thought of as a column and row number, which are labeled u and v respectively.

TFTP

Trivial File Transfer Protocol

TGT

Ticket Granting Ticket

THD+N

total harmonic distortion plus noise

thin client

Small client software layer for a centrally managed, network terminal, allowing the user access to server-hosted applications and data.

Thread Locale

The locale of a given thread. Gets inherited upon creation from the current User Locale and can be changed at run time to any valid locale (per thread). Calls to NLS APIs can use this locale to format numbers, date, time ...

TIA

Telecommunications Industry Association

timecode

For MPEG, frame-by-frame address code time reference recorded on the spare track of a videotape or inserted in the vertical blanking interval. It is an eight-digit number, encoding time in hours, minutes, seconds, and video frames (for example, 02:04:48:26).

timeout

The detection of a lack of bus activity for some predetermined interval.

TinyTP

IrDA transport protocol

TLC

Third-level cache

TLS

Transport Layer Security protocol

top down (order)

Arrangement of pixel data in memory with the lowest addressed pixels corresponding to the upper left corner of the image, proceeding to the right with increasing memory address, with the highest addressed pixels corresponding to the lower right corner of the image.

TOS

type of service

TP

1. twisted pair

2. transaction processing

TR

Token Ring

transfer

One or more bus transactions to move information between a software client and its function.

transform

A set in kernel streaming and DirectShow that defines the access to a filter actually provided by a pin. Each pin supports one transform.

TREC

Texture and Rendering Engine Compression

TSD

type-specific driver

TSID

Transport Stream Identifier

TSP

TAPI call control service provider

TSR

Terminate and Stay Resident, A program running under MS-DOS that remains loaded in memory even when it is not running so that it can be quickly invoked for a specific task performed while any other application program is operating.

TTL

transistor-transistor logic

tuple

A data structure defined by the PCMCIA to describe a single, specific characteristic of a PC Card device. Tuples are chained together to form the CIS, which describes to system software the PC Card’s resource requirements and other characteristics. Tuples consist of a tuple code, an offset to the next tuple, and a number of bytes specific to the tuple.

TVCF

Telephone Voice Call First model (also known as V.8 prime or V.8’). Available on data/fax modems that support H.324 video telephony.

TWAIN

API for image acquisition developed by an association of industry leaders. The specification is available from http://www.twain.org.

TXD

transmission data (also XOR)

Tx/Rx

Transmit/Receive

Typeface

Name given to a particular style of text. In contrast, a font is an implementation of a typeface.

U

UADSL

Universal Asymmetrical Digital Subscriber Line

UART

Universal Asynchronous Receiver/Transmitter. A module composed of a circuit that contains both the receiving and transmitting circuits required for asynchronous serial communication.

UAS

user account system

UAWG

Universal ASDL Working Group

UBR

unspecified bit rate

UCT

universal coordinated time

UDF

universal disk format

UDP

User Datagram Protocol

uDSL

universal Digital Subscriber Loop

UFI

USB Floppy Interface

UGA

Universal Graphics Adapter

UHCI

Universal Host Controller Interface

UHF

ultra-high frequency

UI

user interface

ULS

User Location Service

UMA

1. Uniform Memory Access.

2. Upper Memory Area, Usually 384K bytes of memory located between 640K and 1024K. This area of memory is normally reserved for running system hardware such as the monitor.

3. Unified Memory Architecture

UMB

Upper Memory Block. An area of the UMA that is not currently in use. Adapter Cards use upper memory block addresses. Device drivers and TSRs can be loaded into the UMBs with the correct software and hardware.

UMTS

Universal Mobile Telecommunications System

UNC

Uniform Naming Convention

UNI

User Network Interface

unicast

A method of providing content in which each client receives a unique stream from a server; no other client has access to the stream.

UNICODE

Unicode is a large character set that includes most of the world’s languages. It is 16-bits encoding. This allows 65,000 characters. This form is called UCS-2, i.e., Universal Character Set 2-bytes. Unicode is the first level of ISO 10646, and it is also called a BMP (Basic Multilingual plane) or Plane Zero

unidriver

universal printer driver

Unimodem

Universal modem driver. A driver-level component that uses modem description files to control its interaction with the communications driver.

Uniscribe

The Unicode Script Processor built into Windows 2000. Uniscribe supports line measurement, display, caret movement, character selection, justification, and linebreaking, of Unicode plaintext and rich text. Uniscribe covers most characters in Unicode.

universal naming convention (UNC)

The system for indicating names of servers and computers, such as //Servername/Sharename.

UP

Uniprocessor (single CPU)

UPnP

Universal Plug and Play

UPS

Uninterruptible power supply. A device connected between a computer and a power source that ensures that electrical flow to the computer is not interrupted because of a blackout and, in most cases, protects the computer against potentially damaging events such as power surges and brownouts.

upstream

The direction of data flows towards the host. An upstream port is the port on a device electrically closest to the host that generates upstream data traffic from the hub.

URB

USB request block. Clients send URB transfers to the bus by including a pointer in an IRP to a URB structure; a function within the URB identifies the specific request.

URL

Uniform Resource Locator

USB

Universal Serial Bus. A bidirectional, isochronous, dynamically attachable serial interface for adding peripheral devices such as game controllers, serial and parallel ports, and input devices on a single bus.

USB class

The class of filters under WDM that provides a bus interface and bus enumerator for USB.

USBD

1. USB driver

2. USB device

User Interface (UI) Language

Language in which the operating system displays its menus, help files, and dialog boxes. See also Locale, System Locale, User Locale, and Input Locale.

User Locale

The user preferences for formatting of dates, currencies, numbers, etc. The user locale is a per-user setting, and does not require a reboot or logoff/logon. See also Locale, System Locale, Input Locale, and User Interface (UI) Language).

user mode

The nonprivileged processor mode in which application code executes, including protected subsystem code in Windows NT and Windows 2000.

user-mode drivers

Microsoft Win32-based multimedia drivers and VDDs for MS-DOS–based applications with application-dedicated devices. For more information, see the Multimedia Drivers and Virtual MS-DOS Drivers documentation in the Windows NT and Windows 2000 DDKs.

USN

Update Sequence Number

UTC

Coordinated Universal Time (often spelled out as Universal Coordinated Time).It is the standard time common to every place in the world. Formerly and still widely called Greenwich Mean Time (GMT) and also World Time. It is expressed using a 24-hour clock.

UTP

unshielded twisted pair

UTP-5

UTP / Category-5 (same as CAT5)

UWB

Ultra WideBand

UX

User Experience

V

V

volt

V.250

ITU-T Recommendation, which is a superset of the TIA-602 basic AT command set. New components include a standard for extending the AT command set and standard extensions for modem ID, port control, modulation control and reporting, error control, and data compression control and reporting.

V.251

ITU-T Recommendation which specifies a standard set of commands that enables the DTE (PC) to use V.25, V.8, and participate in V.8 bis call control for point-to-point data calls, voice/data/video calls, and voice-to-data transitions.

V.8

ITU-T Recommendation which defines procedures for starting sessions of data transmission over a GSTN.

V.8 bis

ITU-T Recommendation which defines procedures for the identification and selection of common modes of operation between DCE and DTE over the GSTN and on leased point-to-point telephone circuits.

V.8 prime (V.8’)

An extension of V.8 procedures (defined after H.324 was approved, but before V.8 bis), which provides an interim method of transitioning from telephony to H.324 during an existing voice call. Also known as "Voice Call First."

V.80

ITU-T Recommendation which defines in-band DCE control and synchronous data modes for asynchronous DTE.

VA

Video acceleration

VAR

Value added reseller. A company that resells hardware and software packages to developers and/or end users.

VBE

VESA BIOS Extension

VBI

Vertical blanking interval. The time interval between television fields needed for the scanning gun to move from the bottom to the top of the screen for the start of the next field.

VBR

variable bit rate

VC

1. virtual circuit

2. virtual channel

VCACHE

In Windows, a 32-bit protected-mode cache driver.

VCDFSD

virtual CD-ROM file system driver

VCF

Voice Call First model (also known as V.8 prime). Available on voice modems that support H.324 video telephony.

VCI

virtual channel identifier

VCOMM

In Windows, a 32-bit protected-mode communications driver.

VCR

Video cassette recorder. An analog magnetic recording and playback machine. Usually used for recording and viewing full-motion video; also useful as a data backup device.

VDC

Volts Direct Current

VDD

virtual display device driver

VDIF

Video Display Information Format

VDM

1. virtual DOS machine

2. virtual device manager

3. video display metafile

VDMA

virtual DMA

VDMAD

virtual DMA device

VDS

virtual DMA services

vector graphics

Images defined by sets of straight lines, defined in turn by the locations of the end points.

VESA

Video Electronics Standards Association. A governing body that establishes standards for the video and graphics portions of the electronics industry.

VfW

Video for Windows

VGA

Video graphics array. A video adapter that supports 640x480-pixels color resolution. Video display standard for boot devices under Windows operating systems. Provides medium-resolution text and graphics.

VHF

very high frequency

VHN

video home network

video codecs

Full-color video. Requires 3 bytes per pixel, at 640x480 resolution; equals nearly 1 MB of digital data per frame. This means that a developer could easily use 1 GB of hard-disk space by storing less than one minute of uncompressed digital video information.

Visual order

The ordering used to display glyphs on a screen, printed page, or other medium. Usually used with bi-directional text, because reordering is required to go from logical order to visual order. Contrast Logical order.

VLB

VESA local bus

VLIW

very large instruction word

VLM

1. NetWare 4.x client shell

2. Very Large Memory

VM

Virtual machine. Software that mimics the performance of a hardware device.

VMR

Video mixing renderer

VoIP

Voice over Internet Protocol

VPE

Video Port Extensions. Extensions to the DirectDraw API to control the video stream from the video port within the context of VGA memory.

VPI

virtual path identifier

VpicD

virtual programmable interrupt controller device

VPN

virtual private network

Vpp

voltage peak-to-peak

VRAM

video RAM

VRML

Virtual Reality Modeling Language

VRMS

volts root-mean-square

VSD

vendor specific driver

Vsync

vertical synchronization

VTOA

Voice Telephony over ATM

VUDA

VESA Unified Graphics Architecture

VxD

Virtual Device Driver. A device driver that runs at the privileged ring 0 protected mode of the microprocessor. Can extend the services of the Windows kernel, supervise hardware operations, or perform both functions. Such driver files are usually named according to the scheme VxD, where x refers to the device or service supported.

W

W3C

World Wide Web Consortium

WAN

Wide area network. A communications network that connects geographically separated areas. Compare with LAN.

warm docking

A method of removing or installing a mobile system in a docking station with which the computer can be docked or undocked while in a reduced power state, such as suspend.

WARP

Name of an IETF draft submission defines the requirements and some architectural implementation issues for an RDMA system

watchdog (timer or driver)

A hardware device used to monitor continuing system health and functionality through communications with the system software using a dedicated device driver.

WBEM

Web-based Enterprise Management. A DMTF initiative to provide a standards-based mechanism to specify information exchange between management applications and managed components. This work was recently transferred to the DMTF by BMC Software, Inc., Cisco Systems, Inc., Compaq Computer Corporation, Intel Corporation, and Microsoft Corporation.

WC

write combining

WCDMA

Wideband CDMA

WDCTRL

Western Digital–compatible hard disk controller

WDL

Windows Driver Library. See WHQL.

WDM

Windows Driver Model. A 32-bit driver model based on the Windows NT driver model that is designed to provide a common architecture of I/O services for all Windows operating systems for specific classes of drivers. A driver model based on the Windows 2000 driver model that is designed to provide a common architecture of I/O services and binary-compatible device drivers for both Windows 2000 and Windows operating systems for specific classes of drivers. These driver classes include USB and IEEE 1394 buses, audio, still-image capture, video capture, and HID-compliant devices such as USB mice, keyboards, and joysticks. Provides a model for writing kernel-mode drivers and minidrivers, and provides extensions for Plug and Play and power management.

WDM Comm

WDM Communications Class

WDMCSA

WDM Connection and Streaming Architecture

WDM DDK

Provides the supplementary header files used together with the Windows NT DDK to build WDM drivers.

WDM power management

Facilities provided in WDM for drivers to implement power policy and control. DDIs are defined for synchronizing power state changes with other power management activities in the system and for detecting device idleness. IRPs are defined for setting power sate, enabling wakeup, and querying power status.

WDM streaming

A WDM-based kernel-mode extension of DirectShow, providing kernel connection and streaming services as used by the WDM Stream class driver and system software components provided in future versions of all Windows operating systems, such as the cross-process audio mixer and sample rate converter. WDM streaming provides low-level services for the lowest latency streaming; DirectShow provides higher-level features. Operating system support includes a Stream class driver that supports minidrivers for audio, video, and other types of stream input, output, and acceleration.

web blade

Internet server appliance.

web service

Internet-based application, management, or other functionality provided as a commercial service.

WECA

Wireless Ethernet Compatibility Alliance

WEN

Windows for Express Networks

WEP

Wired Equivalent Privacy, both client and access point have encryption keys. Data is encrypted before it is sent through the air. If a station receives a packet that isn’t encrypted it is dropped.

WfM

Wired for Management

WFP

Windows File Protection

WHIIG

Windows Hardware Instrumentation Implementation Guidelines

Whistler

Code name for next version of the Windows 2000 operating system, based on NT technology.

whitepoint

Whitepoint is the color produced by the device as it makes its whitest color in its colorspace. Whitepoint is measured in degrees Kelvin of black body radiation.

WHQL

Windows Hardware Quality Labs. Formerly Microsoft Compatibility Labs. Provides compatibility testing services to test hardware and drivers for all Windows operating systems. Administers testing for the "Designed for Microsoft Windows" logo programs. For more information, see the Web site at: http://www.microsoft.com/hwtest/.

WIA

Windows Image Acquisition

Wi-Fi

Wireless Fidelity

Win32 API

A 32-bit application programming interface for Windows operating systems that includes sophisticated operating system capabilities, security, and API routines for Windows-based applications.

Windows

Refers to the entire family of Microsoft Windows operating systems, including Windows 98, Windows 2000, and any add-on capabilities and any later versions of the operating system.

Windows 2000

The Microsoft Windows 2000 operating system, including any add-on capabilities and later versions of the operating system.

Windows driver model

See WDM.

Windows installer service

Provides end users with a way to install and remove applications, or components of software as needed. System administrators can more easily manage applications and support roaming users.

Windows Management Instrumentation

Extensions to WDM developed for Windows 2000 and Windows to provide an operating system interface through which instrumented components can provide information and notifications.

Windows Media Player

A client/control that receives a stream from a Windows Media server or local content for playback. It either can run as a stand-alone client executable program or be embedded in a Web page, C++ program, or a Microsoft Visual Basic program that uses the client ActiveX control.

Windows Media streaming library

A library providing a set of APIs that are used to convert audio data into a specified digital format for convenient storage and retrieval using computer technology, usually involving compression and encryption technology.

Windows NT

Refers to the Microsoft Windows NT version 5.0 operating system, including any add-on capabilities and any later versions of the operating system, unless specific design issues are defined that relate to version 5.0.

Windows NT driver model

The layered device driver model used under the Windows NT operating system. For information, see Inside Windows NT, by Helen Custer (Microsoft Press, 1993).

WinHEC

Windows Hardware Engineering Conference

WinPE

Windows Preinstall Environment

WINS

Windows Internet Name Service

Winsock

Windows Sockets

WLAN

wireless LAN

WMA

Windows Media Audio

WMC

Windows Media Container

WMDM

Windows Media Device Manager

WME

Windows Media Embedded PAK

WMF

1. Windows Media Format

2. Windows Metafile Format

WMI

Windows Management Instrumentation. Extensions to WDM developed for Windows 2000 and Windows 98 to provide an operating system interface through which instrumented components can provide information and notifications.

WMP

Windows Media Player

WMT

Windows Media Technologies

WMTV

Windows Media TV (Stream)

WMV

Windows Media Video

workstation

In general, a powerful computer with considerable calculating and graphics capabilities.

World-Ready

A product is World-Ready when;

1. It has provisions for the input, display, and output of a defined set of Unicode supported language scripts and data relating to specific geographic areas, and

2. It has been designed and coded to allow the localization of its data and resources to be as close to being just a translation process as possible.

WOSA

Windows Open System Architecture

WOW64

Windows on 64-bit Windows

WPS

1. Windows Printing System

2. Workplace Shell

WQL

WMI Query Language

Write Combining Memory

Processors supporting WC memory combine several partial (line) write transactions into a single line write transaction, using internal CPU (Write Combining) buffers. This allows for great performance improvement of frame buffer accesses.

Writing system

The collection of scripts and orthography required to represent a given human language in visual media.

WSD

Winsock Direct

WSDP

Winsock Direct Path

WSH

Windows Scripting Host

WSP

WinSock Proxy

WSS

Windows Sound System

WWUI

World Wide Unique Identifier

WWW

World Wide Web

WYSIWYG

What You See Is What You Get

X

XBDA

Extended BIOS Data Area

xDSL

general class of DSL technologies

XFN

X/Open Federated Naming

XGA

Extended Graphics Array. A video adapter produced by IBM capable of 1024 x 768 resolution and 256 colors.

XML

Extensible Markup Language

XMS

Extended-Memory Specification, A specification developed by Lotus, Intel, Microsoft, and AST Research that defines a software interface that allows real-mode applications to use extended memory and certain areas of conventional memory not managed by DOS.

XOR

Exclusive OR. A Boolean operation that yields "true" if and only if one of its operands is true and the other is false. Compare with OR.

Y

Y2K

Year 2000

YcrCb

See YUV.

YUV

The method of color encoding for transmitting color video images while maintaining compatibility with black-and-white video. Uses less bandwidth than the three separate video signals in an RGB video transmission. Consists of two major components: luminance (Y), which corresponds to the brightness of an image pixel, and chrominance (UV or CrCb), which corresponds to the color of an image pixel.

Z

Z

Z axis. For graphical displays, the optical axis that is perpendicular to X and Y axes.

ZAK

Zero Administration Kit for Windows NT Workstation

ZAW

Zero Administration Windows

Z-based fog

See Depth-based fog.

Z buffer

A memory buffer that stores the depth of all pixels in a scene. The Z buffer determines which triangle of many overlapping triangles is closest to the viewer.

Zero Administration initiative for Windows

Also Zero Administration initiative. An initiative that focuses on improving Windows and Windows NT for maximum automation of administrative tasks with centralized control and maximum flexibility.

ZIPI

A MIDI-like serial data format for musical instruments. Provides a more hierarchical method of addressing instruments and an extensible command set.

ZV

Zoomed Video

Previous

Microsoft, ActiveX, BizTalk, Direct3D, DirectDraw, DirectShow, DirectX, IntelliMirror, MS-DOS, Win32, Windows, Windows Media, and Windows NT are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.
© 2001 Microsoft Corporation. All rights reserved.


PC 99a - 15.34. Video input image orientation identification meets PC 99 requirements

Required
RGB pixel formats must be described with a BITMAPINFOHEADER that has a negative biHeight value to indicate that the vertical orientation of the image is top-down, but using the sign of biHeight to indicate orientation is only valid for RGB (uncompressed) formats. The exception is that WDM minidrivers for capture devices are required to only advertise positive biHeight for RGB.

For other compression types described with a FOURCC code in the biCompression field, the FOURCC code uniquely identifies the compression and orientation. It is not valid to describe the orientation with the sign of biHeight.

Common YUV formats such as UYVY, YV12, and YUY2 are top-down oriented. It is invalid to store an image with these compression types in bottom-up orientation. The sign of biHeight for such formats must always be set positive by drivers producing such formats, and the sign must be ignored by any driver receiving such formats. For proprietary compression formats with an associated FOURCC, any orientation is acceptable, but must always be the same for all bitmaps of that FOURCC.

© 1998 - 1999 Intel Corporation and Microsoft Corporation. All rights reserved.


PC 2001 Appendix A Resource Mapping

This appendix summarizes assignments for IRQ, DMA, and I/O port addresses used by built-in devices on legacy system boards. This appendix also includes details about required interrupts for legacy-free PC 2001 systems.

ISA Interrupts

Some IRQ assignments are fixed as specified in the table below. Any interrupt assignment that is not considered fixed is available for reassignment by the system.

For legacy-free systems, some unused IRQs are reserved, since there is no way for them to be used by another system function. Unused and reserved IRQs should be enabled and unmasked in the Programmable Interrupt Controller (PIC), and they must not be connected to an active signal source.

ISA Interrupts

Hardware IRQ | Legacy-reduced system | Legacy-free system
IRQ 0 | System timer | System timer
IRQ 1 | Keyboard | Keyboard for mobile or reserved.
IRQ 2 | Second PIC cascade | Second PIC cascade
IRQ 3 | COM 2 | Not considered fixed
IRQ 4 | COM 1 | Not considered fixed
IRQ 5 | Sometimes LPT 2—not considered fixed | Not considered fixed
IRQ 6 | FDC | Not considered fixed
IRQ 7 | LPT 1 | Not considered fixed
IRQ 8 | Real-time clock/CMOS | Real-time clock/CMOS
IRQ 9 | Not considered fixed | Not considered fixed
IRQ 10 | Sometimes COM 4—not considered fixed | Not considered fixed
IRQ 11 | Sometimes COM 3—not considered fixed | Not considered fixed
IRQ 12 | PS/2-style mouse | Not considered fixed or integrated pointing device for mobile
IRQ 13 | Coprocessor | Coprocessor
IRQ 14 | Primary IDE controller | Primary IDE controller
IRQ 15 | Secondary IDE controller | Secondary IDE controller

Legacy ISA DMA Assignments

Legacy-reduced PCs are permitted to use ISA DMA channels 2 and 3 for the functions specified in the table below. Legacy-free PCs are not permitted to use any ISA DMA channels.

Legacy ISA DMA Considered Fixed

Hardware DMA | System function (default)
DMA 0 | ISA expansion devices. Reserved. Do not use.
DMA 1 | ISA expansion devices. Reserved. Do not use.
DMA 2 | FDC
DMA 3 | Extended capabilities port (ECP) parallel port on LPT 1.
DMA 4 | DMA controller cascading. Do not use.
DMA 5 | ISA expansion devices. Reserved. Do not use.
DMA 6 | ISA expansion devices. Reserved. Do not use.
DMA 7 | ISA expansion devices. Reserved. Do not use.

Legacy ISA I/O Address Assignments

The following table lists I/O addresses that are used by legacy ISA devices and are therefore considered fixed.

Legacy ISA System I/O

I/O address | Default system function
0000–000F | Slave DMA
0010–0018 | System
0001F | System
0020–0021 | Master 8259
0040–0043, 0048–004B | PIT #1, PIT #2
0050–0052 | System
0060 | Keyboard/mouse controller
0061 | System control port B
0064 | Keyboard/mouse status
0070–0071 | NMI enable/real-time clock
0081–008B | DMA page registers
0090–0091 | System
0092 | System control port A
0093–009F | System
00A0–00A1 | Slave interrupt controller
00C0–00DE | Master DMA controller
00F0–00F1 | Coprocessor busy clear/reset
0170–0177 | Secondary IDE controller
01F0–01F7 | Primary IDE controller
0201 | Joystick interface1
0220–022F | Sound Blaster1
0278–027A | LPT 2 (XT parallel port 3)1
02E8–02EF | Alternate COM (4)1
02F8–02FF | COM 21
0330–0331 | MPU-4011
0376 | IDE Controller
0378–037A | LPT 1 (XT parallel port 2)1
0388–038B | FM synthesis
03B0–03BB | MDA, EGA/VGA
03BC–03BE | LPT 3 (XT parallel port 1)1
03C0–03DF | EGA/VGA
03E0–03E7 | PCIC PCMCIA controllers
03E8–03EF | Alternate COM (3)1
03F0–03F7 | FDC—excluding 03F61
03F8–03FF | COM 11
0534–0537 | Windows Sound System-compatible
0CF8–0CFB | PCI ports
1 These addresses are restricted and must not be used by PC 2001 legacy-free systems. Processor reads of the byte addresses in the shaded rows of this table must return FFH.

Required Interrupts for PC 2001 Legacy-Free Systems

The following table lists required interrupts for PC 2001 legacy-free systems.

Required Interrupts for PC 2001 Legacy-Free Systems

Interrupt

Description

INT 8 (IRQ 0)

System timer. Used to keep the time-of-day clock updated.

INT 9

INT 9 is invoked only by software and does not use IRQ 1 signaling. However, for proper system operation, this handler must perform the same operations as on legacy systems, which are:

The interrupt handler needs to be in the IVT chain for INT 9.

IRQ 1 is unmasked at the PIC.

The INT 9 handler required in the BIOS is exactly the same as that which is required in systems that contain legacy components. This handler is not intended for use during the boot process, it is available to help support legacy applications running in Microsoft MS-DOS Virtual Machines (MS-DOS-boxes).

For backward compatibility with MS-DOS applications, Windows Me implements a complete "Virtual" keyboard controller and passes all keyboard traffic through it regardless of whether it is from a real keyboard controller or a USB keyboard. This allows both Win16 applications and MS-DOS-based applications to continue to function. In order to support legacy applications in MS-DOS Virtual Machines, the command interpreter must behave the same as on a legacy system, which requires the full INT 9 support provided by legacy systems. This handler handles input from port 60h, passes it off to INT 15h / AH= 4Fh, stores the data in the keyboard buffer of the BIOS Data Area, and updates the flags. The following provides reference code for the required capabilities:

push es

push ds

push a

push f

mov ax, 40h

mov es,ax

mov ax, <segment of translation table>

mov ds,ax

xor bx, bx

in al, 60h

mov ah, 4Fh

int 15h

jnc SkipProcess

mov bl,al

shl ax, 8

mov al, ds:[bx]

mov bx, es:1ah

mov es:[bx]

inc bx

inc bx

mov es:1ah, bx

mov al, 61h

out 20h, al

SkipProcess:

popf

popa

pop ds

pop es

iret

INT 10

Set video mode.

INT 11

Equipment determination.

If there are devices that appear as FDDs (for example, El Torito capable CD-ROM devices), then:

Bit Mask 0x0001 (bit 0) in AL must be set.

Bits 6 and 7 must properly indicate the number of FDD devices and devices that appear as floppy disk devices.

If there are no devices that appear as FDDs, then:

Bit mask 0x0001 (bit 0) must be clear.

Bits 6 and 7 must be set to 0.

INT 13

High-capacity drive support.
All subfunctions, including AH = 40h–48h.

Disk operation notes:

ROM BIOS must set the head settle, motor start, and format gap values in the disk table pointed to by interrupt vector 1Eh.

Implement the INT 13h AH = 17h call, that is, set the DASD type for format.

Support the change line (INT 13h AH = 15h) on INT 13h FDDs.

Support INT 13h AH = 8 (Get device parameters).

Implement the extended INT 13h services (AH functions 41h – 48h).

For INT 13h with AH = 48h for installed FDDs:

If there are no FDDs attached as INT 13h devices, INT 13h AH = 48h must fail for all floppy drive numbers (drive 0, in particular). However, INT 13h AH = 8 on drive number 0 (DL=0) must work even if there are no INT 13h FDDs, and it must return a FDD count of 0 in the DL register to indicate that no FDDs are present.

If a FDD is an industry-standard 1.44-MB, 3.5-inch drive, the INT 13h AH = 8 call on the device should not modify the BL register.

If the device is something other than an industry-standard 1.44-MB, 3.5-inch drive, but is media compatible with the 1.44-MB floppy standard, the INT 13h AH = 8 call on the device should return the parameters for a 1.44-MB industry-standard floppy disk drive but set the BL register to 10h and return the true maximum-supported capacity drive parameters on the INT 13h AH = 48h call.

For floppy devices that are not media compatible with the 1.44-MB floppy standard, the INT 13h AH = 8 call should return the closest reasonable parameters, set the BL register to 10h, and return the true maximum supported capacity parameters on the INT 13h AH = 48h call.

The INT 13h AH = 8 (Get device parameters) call must not turn on the drive motor for FDDs.

INT 15

The following subfunctions are required:

AH
C0 Get configuration
4F Translate keyboard scan code
87 Copy extended memory
88 Get extended memory size

AX
C2xx Mouse functions
E820 Get system memory map
E801 Get memory size

Function 4Fh is expected to pass all keys from the keyboard, and respect the status of the carry flag on return. The HID key codes from USB keyboards must be translated to PS/2 key codes for backward compatibility with other key filters. All keyboards must be supported, including-but not limited to-101/102 key English, 105 key European, 106 and 109 key Japanese. HID to PS/2 translation tables are available at: http://www.pcdesguide.org/documents/keycode.htm

INT 16

The following subfunctions are required:

AH
00h Get keystroke
01h Check for keystroke
02h Get control keys
10h Get enhanced keystroke

11h Check for enhanced keystroke
12h Get control keys for enhanced keyboard

INT 19

Bootstrap loader

INT 1A

The following subfunctions are required:

AH 0x RTC

AX B1xx PCI BIOS

INT 1B

CTRL+Break Handler

INT 23

CTRL+C, CTRL+Break Handler

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Design Guidelines for PC Card and CardBus

A Technical Reference for PC Card and CardBus Controllers and Devices for the Microsoft® Windows® Family of Operating Systems

Addendum to PC 2001 System Design Guide

Version 1.1 – April 12, 2000

© 1998-2000 Intel Corporation and Microsoft Corporation. All rights reserved.

PC Card Basic Requirements

This section summarizes the basic requirements for PC Card.

PCCard-1. All devices comply with the PC Card standards

Required — PC 99:12.1

Designs for PC Card socket controllers and cards must all be based on PC Card Standard Release 7 or later.

All PC Card devices must comply with these standards.

For information about implementing R2 version cards to use only 3.3 volts, see the white paper titled "Card Voltage Requirements and the Windows Operating System" at http://www.microsoft.com/hwdev/cardbus/pccardvlt.htm.

Note: In PC 99 System Design Guide, this requirement referred to earlier versions of the standard. This guide cites the current specification. The implementation requirements remain the same.

PCCard-2. System and ZV-compatible 16-bit PC Cards comply with ZV standard definitions

Required - PC 99:12.2

The PC Card standards define the requirements for Zoomed Video (ZV) cards and system support.

Note: In PC 99 System Design Guide, Zoomed Video support was required. Zoomed Video is not required for PC 2001, but if it is implemented, it must support PC Card standards.

PC Card Socket Controller Requirements

This section summarizes requirements and standards for socket controllers.

PCCard-3. Controller supports industry-standard ExCA register set

Required — PC 99:12.3

The built-in software supporting 16-bit PC Card cards in Windows includes drivers for the industry-standard Exchangeable Card Architecture-compatible (ExCA-compatible) socket controllers. To be compatible with these drivers, socket-controller implementations must support the industry-standard ExCA base register set.

Notice that some controllers do not fully implement the register set and therefore are incompatible. Also, some controllers implement extended registers or enhancements. The built-in Windows drivers do not exploit these features, even though the controller might be compatible.

PCCard-4. System maintains mapping of IRQ Routing Register bits to system interrupt vectors

Required — PC 99:12.4

The system design must maintain the mapping of the PC Card controller’s IRQ Routing Register bits to system interrupt vectors. This means that when an interrupt is programmed in the controller to occur on the IRQx pin, the system’s IRQ routing causes the interrupt controller to generate the interrupt vector for IRQx and no other IRQ.

PCCard-5. IRQ connections can be determined by using the 0805 register

Required — PC 99:12.5

Windows uses the 0805 register on CardBus controllers to determine which ISA IRQs are connected to the controller. This register must engage (drive low when the IRQ is asserted) the corresponding ISA IRQ when programmed with a value. It must deselect the IRQ (float high) when programmed at zero (0). This behavior must be achieved without requiring the operating system to program any non-standard registers.

PCCard-6. CardBus controllers support both ISA and PCI interrupts

Required — PC 99:12.6

PC Card software dynamically configures the bridge to use ISA interrupts for 16-bit PC Card cards and to use Peripheral Component Interface (PCI) interrupts for CardBus cards. As defined in earlier requirements, CardBus controllers must maintain mapping of IRQ routing. Also, notice that systems implementing CardBus controllers must fully support PCI 2.2 as well as additional PCI requirements for IRQ routing as defined in PC 99 System Design Guide and PC 2001 System Design Guide.

To ensure that the Windows operating system can correctly assign ISA IRQs to 16-bit PC Cards, CardBus controllers that have parallel ISA IRQ mode must have all ISA IRQs pins, except IRQ 0 (timer), 1 (keyboard), 6 (floppy), 8 (CMOS), 13 (math coprocessor). It is recommended that system vendors using parallel ISA IRQ mode always connect ISA IRQs 3, 4, 5, 7, 9, 10, 11, 12, 14, 15 and not cross wired them.

Note: Vendors using serialized IRQ mode only need to connect the serial IRQ pin, and the ISA IRQ information will be sent to the PCI chip set serially; the ISA IRQ information can specify any of IRQ 0–15.

PCCard-7. System supports industry-standard definition for CardBus bridges

Required — PC 99:12.7

Systems must support the definition in PC Card Standard Release 7 (or later) PC Card Host System Specification (Volume 11), PCI-to-CardBus Bridge Register Description (Section 4) for CardBus controllers (PCI-to-CardBus bridges). This definition includes a common PCI Configuration Space header assigned the Header Type field value of 82h.

Windows supports this specification. Any controller features that are not part of this specification will not be used in standard drivers. The BIOS is responsible for any hardware initialization or setup required to make the controller comply with this specification or other requirements in this document.

Because CardBus host controllers are PCI bus bridges, they will be supported (enumerated and configured) by the PCI software in Windows in the same manner as other PCI bus bridges.

Note: In PC 99 System Design Guide, this requirement referred to PCI to PCMCIA CardBus Bridge Register Description (Yenta specification). This guide cites the current specification as it was incorporated into the PC Card standard. The implementation requirement remains the same.

PCCard-8. BIOS initializes CardBus controller in 82365-compatible mode and supports backward compatibility

Recommended — PC 99:12.8

Note: In PC 99 System Design Guide, this item was recommended. It is required for PC 2001.

When Intel 82365–compatible modes are implemented, CardBus controllers are enumerated and configured in the same way as other PCI bus bridges. The PCI bus bridge support in Windows 98 is based on requirements for PCI interrupt routing and bridge-window configuration. Therefore, full compliance with the latest PCI specifications is required for CardBus support.

There are steps the BIOS can take to achieve backward compatibility with Windows. Specifically, the BIOS can initialize the CardBus controller in Intel 82365-compatible mode and report it as device "PNP0E03, Intel 82365-compatible CardBus controller." The requirements are as follows for BIOS POST time (CardBus controller ConfigSpace initialization):

  • Command register (offset 0x04) set to 0x07 (IOSpaceEnable, MemSpaceEnable, BusMasterEnable).
  • RegisterBaseAddress (offset 0x10) set to 0. If support for other environments is needed, such as Windows 3.1 or MS-DOS®, some other value can be set.
  • All memory and I/O windows (offset 0x1c–0x38) set to 0.
  • Interrupt Line register (offset 0x3c) set to 0xff (no IRQ assigned). If support for other environments is needed, such as Windows 3.1 or MS-DOS, an assigned IRQ line can be set. Notice, however, that this register must be set to 0xff at the time that the device is disabled by the operating system, and then set into CardBus mode. More information about BIOS enumeration is presented later in this requirement.
  • Other controller-specific initialization as required to put the controller in legacy mode.

This puts the CardBus controller into legacy mode where the Windows Socket Services driver can access it as an Intel PC Card I/O card–compatible (PCIC-compatible) controller at an I/O address, for example, 0x3e0.

Notice that the BIOS must be at least PCI 2.2-compliant and must support the $PIR Interrupt Routing Table. The $PIR table must return the necessary PCI IRQ routing information, including the routing information for the CardBus controller. In general, if the CardBus controller is on the system board, there must be a slot routing entry for it in the table. If the CardBus controller is a PCI add-on card, there must be routing information entries for each PCI slot in the system.

During Plug and Play BIOS enumeration, the BIOS should report the CardBus controller as *pnp0e03 with a compatible ID of *pnp0e00 and the I/O resource of two ports, for example, 0x3e0–0x3e1.

For more information, see the white paper on CardBus host controllers and Windows compatibility at http://www.microsoft.com/hwdev/cardbus/.

PCCard-9. CardBus controllers do not share writable PCI Configuration Space bits

Required — PC 99:12.9

CardBus controllers are multifunction PCI devices, and Windows treats each function as an independent device. As such, there can be no sharing between functions of writable PCI Configuration Space bits, such as the Command register.

Notice that the 16-bit PC Card interface legacy-mode Base Address Register (BAR; offset 44h in the Type 2 PCI header) is the only exception to this requirement. This BAR must be shared between the two functions in order to be compatible with the ExCA programming model.

PCCard-10. Each 16-bit PC Card memory window in CardBus controller has it own page register

Required — PC 99:12.10

For complete flexibility and support of typical configurations, CardBus controllers must support the independent location of R2 memory windows anywhere in the full system address space as recommended in the PC Card Standard Release 7 (or later), PC Card Host System Specification, PCI-to-CardBus Bridge Register specification.

Controllers that share a single page register among all 16-bit PC Card memory windows require that all 16-bit PC Card memory windows must be located within the same 16-MB block. This is often not possible with typical (16 MB) DRAM and bridge (positive-decode) configurations. The result is disabled cards.

Note: In PC 99 System Design Guide, this requirement refers to the Yenta specification. This guide cites the current specification as it was incorporated into the PC Card standard. The implementation requirement remains the same.

Plug and Play Design for 16-bit PC Card Cards

This section summarizes the Plug and Play requirements for 16-bit PC Card cards.

The Windows operating system determines what type of card is plugged into the PC Card socket by examining the tuples on the card. For Plug and Play functionality, 16-bit PC Card I/O cards must support a set of required information and configuration tuples. The PCMCIA bus enumerator uses these tuples to identify the card, load the correct device driver, and indicate all possible configurations to the Plug and Play configuration manager. The operating system then dynamically assigns a valid configuration based on this information.

PCCard-11. Card supports required I/O card tuples

Required — PC 99:12.11

The following items must be implemented for any 16-bit PC Card I/O card that connects to a system:

  • The 16-bit PC Card card must contain:
  • The device information tuple (CISTPL_DEVICE, 01h for cards capable of 5V operation or CISTPL_DEVICE_0C, 1Ch for cards capable of 3.3V operation).
  • The Level 1 (L1) version/product information tuple (CISTPL_VERS_1, 15h).
  • The configuration tuple (CISTPL_CONFIG, 1Ah).
  • The configuration table entry tuple (CISTPL_CFTABLE_ENTRY, 1Bh).
  • A 16-bit PC Card card with more than 64 MB Common Memory must contain the extended device information tuple (CISTPL_EXTDEVICE, 09h).
  • The L1 version/product information tuple must contain the product name and manufacturer name in the product information string (TPLLV1_INFO, byte 4).
  • The product name and manufacturer name in the L1 version/product information tuple must be composed only of ASCII characters greater than ASCII 20h and less than ASCII 7Fh.

Windows uses the information contained in the required and recommended tuples to create a unique device ID for the card and to assimilate configuration information for the device. Windows uses the device configuration tuples to determine the general characteristics of the card.

Required I/O Card Tuples

Tuple ID | Tuple code | Description and comments
01h | CISTPL_DEVICE | Device information (common memory). For non-memory cards, this tuple must be present, but the device type will be NULL.
15h | CISTPL_VERS_1 | L1 version/product information strings: Product information, Product name, Product number, Other manufacturer information
1Ah | CISTPL_CONF | Configuration. Indicates the location of configuration registers and registers present.
1Bh | CISTPL_CE | Configuration table entry. Appropriate configuration requirements for I/O space, interrupts, memory, and so on should be specified.
20h | CISTPL_MANFID | Manufacturer ID. Card manufacturer ID code. Defines manufacturer for this card.
21h | CISTPL_FUNCID | Function ID. Provides function information about the card. Also includes system initialization information.

The device information tuple provides information about the memory devices used in the card’s common memory space. The device type, size, and speed are used to configure the socket for efficient access to the card. This tuple must be present on 16-bit PC Card I/O cards, but the device type must be NULL.

The L1 version/product information tuple contains human-readable information about the product and its manufacturer. This information is intended to be displayed to the user where necessary. Windows uses the information contained in the product information string and product name string to construct the device ID for that card. It also scans through the tuple, starting at the very beginning and continuing to the end of the product name string.

The information gathered from the L1 version/product information tuple is used to construct the unique device ID. Because the optional third and fourth strings in the tuple are not used in the unique ID, devices that require unique numbers on each card can use these strings to store that information.

The configuration tuple tells the software where to locate the configuration registers that program the card’s configuration, as well as which registers are present on the card.

Each configuration table entry tuple completely describes one valid configuration in which the card can operate. Each entry describes power, timing, I/O space, interrupt, and memory space requirements for the given configuration. Configuration software selects one of these configurations for the card based on the resources currently available in the system.

The manufacturer ID tuple (CISTPL_MANFID, 20h) and the function ID tuple (CISTPL_FUNCID, 21h) add extra flexibility to a PC Card that connects to the PC:

  • The manufacturer ID tuple provides unique information about the card manufacturer. This code is registered with PCMCIA. Windows uses the manufacturer ID tuple as one source for creating a 16-bit CRC used in the construction of the device ID.
  • The function ID tuple provides information about the class of device or what function the card provides, for example, memory, modem, disk, and so on. This information helps the software perform necessary installation tasks and locate compatible drivers. Although it is not required to make this determination, Windows uses the function ID tuple internally to determine what type of device is on the PC Card.
PCCard-12. Configuration table entry tuples listed in priority order

Required — PC 99:12.12

Configuration table entry tuples are placed in the preferred order for configuring the device. Windows processes the tuples in the order they are placed in the Card Information Structure (CIS). From these tuples, Windows creates a logical configuration in this order and prioritizes them in the same order. Notice that for multiple voltage cards, the voltage policy is to prioritize 3.3-volt configurations, if they are supported by the system, over 5-volt configurations, regardless of the order of the configuration table entry tuples (CISTPL_CFTABLE_ENTRY).

PCCard-13. Card specifies maximum configuration options

Required — PC 99:12.13

Many older PC Cards specified fixed configurations in order to address compatibility with existing software. However, this is not the intended use for tuples; the configuration software should be responsible for compatibility. The tuples should be used only to describe its maximum configurability, ruling out configurations not supported by the hardware.

If fixed configurations must be provided for an operating system other than Windows, there must be one or more entries that specify the maximum configurability that the hardware can handle. An example of "maximum configurability" is to specify "any IRQ" rather than only IRQ 3 or IRQ 4.

Plug and Play Design for CardBus

This section summarizes the Plug and Play requirements for CardBus cards. CardBus was designed as a combination of the 16-bit PC Card and PCI. The goal is to gain the benefits of PCI in a PC Card format. Consistent with this goal, Windows support for CardBus places specific requirements on CardBus cards.

PCCard-14. Configuration Space meets Common Silicon Guidelines

Required — PC 99:12.14

The Common Silicon Guidelines are defined in Section 2.1 of the PC Card Standard Guidelines, Volume 10.

Note: PC 99 System Design Guide cited Section 2.6. This guide corrects the citation and provides the following additional notes:

  • The standard for CardBus defines a PCI "Type-2" configuration space that is defined in Section 4.5 of Volume 11 (PC Card Host System Specification) of the PC Card Standard Release 7. The Type-2 CardBus-bridge PCI header structure was defined to be as similar to the Type-1 (PCI-to-PCI bridge) header as possible. Type-2 and Type-1 PCI headers differ only in that the Type-2 header allows 4-byte resolution in I/O Base and Limit registers, while the Type-1 header supports a coarser 4K resolution for these registers.
  • CardBus cards include normal Type-0 PCI headers, with certain provisions. The quadword register located at 0x28 is used as a pointer to the CardBus Card Information Structure (CIS). CardBus cards must also implement certain Command and Status Register fields that are optional for PCI devices. CardBus cards must also provide a Memory BAR for every I/O BAR provided (so that I/O windows can be memory-mapped).
  • Section 2.1.3.4 of Volume 10 (Guidelines) of the PC Card Standard Release 7 details the common silicon guidelines to which CardBus cards must adhere.

To maintain compatibility with existing PCI system software and drivers, Windows will support only CardBus cards whose Configuration Space is designed to meet the Common Silicon Guidelines. This is a requirement because CardBus configuration is performed by the PCI software, which can deal with all aspects of PCI topology configuration, including bridging. Without the allocated fields, the cards cannot be fully treated as PCI devices and cannot be supported under Windows.

The required allocated fields are listed in the following table.

Required Allocated Fields

Field | Description and comments
Vendor ID | This read-only field contains a unique ID (in PCI space) for the card manufacturer. The PCI SIG allocates unique IDs.
Device ID Revision ID | These read-only fields are vendor-assigned values that uniquely identify the device (among all vendors of PCI or CardBus products).
Class Code | This read-only field is defined in PCI 2.2. It describes what type of device the card is.
Max_Lat Min_Gnt | These read-only fields specify the desired settings for Latency Timer values according to PCI 2.2. A value of 0 indicates the device has no major requirements for the settings of Latency Timers.
Interrupt Line | This register must be read-write and must not be connected to anything, just as on PCI cards. This register is used to store the current IRQ routing for the device.
PCCard-15. RESERVED fields comply with PCI 2.2

Required — PC 99:12.15

The CardBus specification also lists two RESERVED fields (offset 2C in the Configuration Space), which have since been defined in PCI 2.2. These fields are also required on CardBus cards for Windows compatibility.

Required RESERVED Fields

Field | Description
Subsystem ID | If different from Device ID
Subsystem Vendor ID | If different from Vendor ID
PCCard-16. CardBus card implements required and recommended tuples

Required — PC 99:12.16

For CardBus, Windows also requires the same set of card tuples recommended in the PC Card guidelines, as summarized in the following table.

Required CardBus Tuples

Tuple ID | Tuple code | Comments
04h | CISTPL_CONFIG_CB | —
05h | CISTPL_CFTABLE_ENTRY_CB | —
07h | CISTPL_BAR | —
13h | CISTPL_LINKTARGET | Required as first tuple in PC Card standard.
15h | CISTPL_VERS_1 | —
20h | CISTPL_MANFID | —
FFh | CISTPL_END | Required as end-of-chain tuple in PC Card standard.
21h | CISTPL_FUNCID | Recommended in PC Card standard; required for Windows operating system compatibility.

Power Management for PC Card

This section summarizes the specific power management requirements for PC Card. Power management requirements for specific device classes are defined in the related chapters in PC 99 System Design Guide and PC 2001 System Design Guide.

PCCard-17. Socket controller complies with device class power management reference specification

Required — PC 99:12.17

This applies for both 16-bit PC Card-only controllers and CardBus controllers.

The PC Card Controller Device Class Power Management Reference Specification, Version 1.0 or later, provides class-specific definitions of the OnNow device power states (D0–D3) for these devices. The specification also covers device functionality expected in each power state and the possible wake-up event definitions for the class, for example, whether card insertion should wake the system.

PCCard-18. 16-bit PC Card cards implement power-related events using ReqAttn bit and #STSCHG mechanism

Required — PC 99:12.18

Any 16-bit PC Card card that is capable of signaling a wake-up event to the system, as defined in the device class power management reference specification for its class, must implement the ReqAttn bit and its associated enable bit in the Extended Status register, and must signal on the #STSCHG line.

PCCard-19. CardBus controllers and cards implement PCI and CardBus power management specifications

Required — PC 99:12.19

PCI-to-CardBus bridges and CardBus cards must comply with the requirements defined in Section 3 (PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges) of the PC Card Standard, Release 7. This specification describes the CardBus power-management interface hardware, as well as proper software use of these hardware mechanisms.

The CardBus card must use the CSTSCHG pin to signal wake-up events. This is because there is no PME# pin on the CardBus interface, and the CardBus card must use PME_EN in the card’s Configuration Space to enable wake-up events. Specifically, setting the PME_EN bit in the card’s Configuration Space must provide the same behavior as setting both the GWAK and WKUP bits in the card’s Function Event Mask register.

If wake-from-D3cold is implemented in a platform, the following are required:

  • Associated CardBus controller must support PME# assertion from D3cold.
  • Associated socket must supply sufficient Vaux power to support the card in its D3cold state.

This requirement must be independently met by each enabled D3cold-wake-capable CardBus socket in the system, as defined in the host system chapter of PC Card Standard, version 7.

Power management requirements for 16-bit PC Card cards are defined earlier in requirement 18.

Note: This guide defines these new power management requirements over what was required in PC 99 System Design Guide:

  • Section 3 (PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges) of the PC Card Standard, Release 7 as a new specification for CardBus cards. (PC 99 requirements called only for PCI-PM 1.0.)
  • Wake-from-D3cold support for controller and socket.

Device Drivers and Installation for PC Card

This section summarizes requirements for PC Card device drivers.

PCCard-20. No user intervention required for correctly installing devices

Required — PC 99:12.20

The user must not be required to perform any device-installation action other than to insert disks that contain drivers and other files.

PCCard-21. Device is immediately functional without restarting the system

Required — PC 99:12.21

The user must be able to begin using the device without having to restart the system. Device use begins either after installation is complete or whenever the device is inserted in the system.

PCCard-22. ZV-compatible PC Card driver uses DirectDraw VPE

Required — PC 99:12.22

ZV-compatible PC Card drivers must use software interfaces based on 32-bit Microsoft DirectDraw® Video Port Extensions (VPE) in order to configure the graphics controller to receive video input using the ZV port. This includes programming the graphics controller to configure the format of the video data, its location on screen, and so on. VPE is part of Microsoft DirectX® APIs.

ZV card device drivers must handle dynamic graphics state changes, such as resolution changes, color depth changes, and switching to and from full-screen MS-DOS®–based applications.

Note: Since PC 99 System Design Guide, the extensions to DirectDraw APIs identified as Live Video Extensions (LVE) have been renamed Video Port Extensions (VPE). The implementation requirement remains the same.

PCCard-23. 16-bit PC Card card driver supports sharing of level-mode interrupts

Required — PC 99:12.23

CardBus systems support both 16-bit PC Card cards and CardBus cards. In this environment, interrupt sharing becomes an issue because CardBus controllers can use PCI interrupts, which are level-sensitive and sharable. To help alleviate interrupt limitations in CardBus systems, Windows operating systems can take advantage of PCI interrupt-sharing capabilities.

In cases where no ISA IRQs are available to a 16-bit PC Card card in a CardBus controller, the operating system will assign a PCI interrupt to the card. All 16-bit PC Card card drivers must "hook" the interrupt, whether it is sharable or not, before its hardware generates any interrupts.


Legacy Plug and Play Guidelines

A Technical Reference for Legacy PCs and Peripherals for the Microsoft® Windows ® Family of Operating Systems

Version 1.0 – May 16, 1999

© 1997–1999 Intel Corporation and Microsoft Corporation. All rights reserved.

Chapter 1 Basic Legacy Plug and Play

This chapter defines the basic specifications and implementation guidelines for legacy Plug and Play.

For information about Plug and Play drivers support under Windows 95, see the Windows 95 DDK. Plug and Play for VxD drivers under Windows 98 should also follow the guidelines defined in the Windows 95 DDK.

For information about Plug and Play support under Windows 2000, see the Windows 2000 DDK.

Legacy Plug and Play Specifications

Each bus and device provided in the computer system must meet the current Plug and Play specifications related to its class, including requirements clarifications published for some Plug and Play specifications. For ACPI-based systems, buses and devices must also meet the requirements defined in Section 6 of the Advanced Configuration and Power Interface Specification, Revision 1.0. This specification defines the requirements for automatic device configuration, resource allocation, and dynamic disable capabilities.

The following shows current version numbers for all legacy Plug and Play specifications:

  • Plug and Play BIOS Specification Version 1.0a

Important: This specification applies only for non-ACPI-based systems. ACPI-based systems must follow the requirements defined in ACPI 1.0.

  • Plug and Play External COM Device Specification, Version 1.0
  • Plug and Play Industry Standard Architecture (ISA) Specification, Version 1.0a
  • Clarification to Plug and Play ISA Specification, Version 1.0a
  • Plug and Play Parallel Port Device Specification, Version 1.0b
  • Plug and Play Small Computer System Interface Specification, Version 1.0

Note: Standard system devices are excluded from this requirement. The system can reserve static resources for devices such as programmable interrupt controllers (PICs) 1 and 2, 8254-2 timer, 8042 keyboard controller, real-time clock, DMA page registers, DMA controllers 1 and 2, and math coprocessor. For systems based on Intel Architecture compatible processors, these fixed resources are located at I/O addresses under 100h and can also include a Nonmaskable Interrupt (NMI).

All system-board devices must use ISA-compatible addresses. This includes devices with I/O port addresses within the reserved range 0h–0xFFh. For information about legacy system I/O addresses, see Appendix A, "IRQ, DMA, and I/O Port Addresses."

Unique Plug and Play Device IDs

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 by the BIOS, 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.

In addition, 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 Network PC System Design Guidelines, Version 1.0b or later.

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

  • Legacy devices attached to the ISA bus on the system board do not have unique Plug and Play IDs—for example, serial ports, parallel ports, or Personal System/2 (PS/2) compatible port devices. The method for device identification is defined in the Plug and Play ISA Specification, Version 1.0a, and the ACPI 1.0 specification.
  • 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 the Windows operating system.
  • 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 IDs for each function included on the device.

Option ROM Guidelines

These guidelines apply for devices that use option ROM on systems based on Intel Architecture processors, whether the device is present on the system board or provided through an expansion card.

Option ROMs are usually located on cards used as system boot devices. During the boot process, option ROMs initialize the boot devices, which provide the primary input, primary output, and Initial Program Load (IPL) device to boot the system. However, Plug and Play option ROMs can be used to supply the Plug and Play expansion header to devices other than boot devices, enabling them to initialize both devices when the system boots.

"PNP" Vendor Codes and Compatible IDs

All legacy devices not enumerated by the system-board interface must not use the acronym for Plug and Play, "PNP" in their vendor and device codes. The PNP vendor code is reserved for Microsoft and for vendors whose hardware is specifically assigned a particular ID. Other hardware can use a PNP code only when defining a device’s Compatible ID (CID) and only after first indicating the device’s Hardware ID in the Plug and Play header.

Use of CIDs are recommended for devices that use device drivers provided with the Windows operating system, such as a Standard PC COM Port (PNP0500).

For information about using PNP CIDs, see Appendix B, "Device Identifiers." To obtain a unique PNP vendor ID, complete the form provided at http://www.microsoft.com/hwdev/pnpid.htm.

I/O Decoding

Each device must support a unique I/O port address in the 16-bit address range. This requirement means that, at a minimum, the upper address lines (A10–A15) can be used as the device enable address, so that the device does not respond to addresses outside of the 10-bit address range.

Devices that use less than 16-bit I/O decode create conflicts that cannot be resolved by a Plug and Play operating system. Phantom (alias) addressing is not supported by the Windows operating system and cannot be used to meet this requirement.

Notice that this requirement does not apply for the three ISA auto-configuration registers used during device enumeration and configuration. The ADDRESS, WRITE_DATA, and READ_DATA registers will continue to use 12-bit decoding as described in the ISA Plug and Play Specification, Version 1.0a.

Chapter 2 ISA Plug and Play

This chapter summarizes Plug and Play requirements for any ISA legacy implementations.

In addition to ISA expansion cards, the following are also ISA devices:

  • 8042 and similar controllers, ports, keyboards, and mice
  • Direct memory access (DMA) controllers and slaves
  • Floppy disk controllers (FDCs)
  • Interrupt controllers
  • Legacy parallel and serial ports
  • Math coprocessors
  • Programmable interrupt timers (PITs)
  • VGA controllers

However, any such devices located at I/O addresses below 100h can use fixed resources and are exempt from Plug and Play requirements for unique IDs, flexible resource configuration, and dynamic disable capabilities.

For details about the interrupt request (IRQ) settings, DMA address, and I/O port addresses for specific devices, see Appendix A, "IRQ, DMA, and I/O Port Addresses."

System Requirements for Plug and Play ISA

This section summarizes the basic requirements for a PC system that includes the ISA bus.

If ISA support is included in a system, the manufacturer must implement the standards described in the following Plug and Play specifications:

  • Plug and Play ISA Specification, Version 1.0a
  • Plug and Play BIOS Specification, Version 1.0a
  • Clarifications to the Plug and Play BIOS Specification, Version 1.0a.

The Plug and Play specifications are available from the web site at http://www.microsoft.com/hwdev/respec/pnpspecs.htm.

Additional ISA clarifications and white papers related to ISA Plug and Play under the Microsoft Windows operating system are available from the web site at http://www.microsoft.com/hwdev/legacy/.

Note: Standard system devices are excluded from this requirement. The system can reserve static resources for devices such as interrupt controllers 1 and 2, 8254-2 timer, 8042 keyboard controller, real-time clock, DMA page registers, DMA controllers 1 and 2, and math coprocessor (if present). For a system based on Intel Architecture, these fixed resources are located at I/O addresses below 100H and can also include an NMI mask.

Plug and Play ISA Device Requirements

This section includes additional requirements for ISA cards, including requirements for design implementations that appear only as recommendations in the ISA specification, to ensure that such cards will perform correctly under Windows.

The information in this section is provided for manufacturers of ISA devices who want to ensure that their devices are completely compatible with Plug and Play operating systems.

For more details, see the Plug and Play ISA Specification, version 1.0a.

Plug and Play ISA Standards for Devices

Any card or bus that implements Plug and Play ISA must fully implement the standards defined in the Plug and Play ISA Specification, Version 1.0a. This specification also defines the requirements for a unique ID for each ISA device. The unique ID is used to identify the device for Plug and Play configuration.

Option ROMs for ISA Boot Devices

Option ROMs must be used only on cards that contain boot devices.

Cards with option ROMs must not hook the primary boot interrupts (Int 9h, Int 10h, Int 13h, Int 18h, and Int 19h) until the system calls the boot connection vector in the selected option ROM expansion header.

For cards with option ROMs, the default configuration must be able to be disabled after the card has been isolated.

I/O Decoding for ISA Device

This circuit can be simple enough to limit I/O addresses to the 0h to 3FFh range, or it can be flexible enough to use the upper address regions.

The device must meet the guidelines for 16-bit I/O decoding defined in Chapter 1, "Basic Legacy Plug and Play," in this guide.

ISA IRQ Sharing

Under Windows 95/98 (but not Windows NT® 4.0 or Windows 2000), an ISA device and its driver can support IRQ sharing if resource requirements cannot be met. This capability applies only for devices of the same class, not across device classes.

To share IRQs, the following requirements must be met:

  • The IRQ line must be pulled high by the system board.
  • The IRQ line must never be driven high by the devices.
  • To signal an interrupt, devices must pull the IRQ line low for a minimum of 100 nanoseconds and then release it. The interrupt is signaled by the rising edge that occurs as a result of the pull-up on the IRQ line.
  • The drivers for all devices connected to the IRQ line must correctly support the interrupt-sharing services of the virtual programmable interrupt controller device (VpicD). This means that after dispatching an interrupt from VpicD, the drivers must respond to VpicD and correctly indicate whether they actually processed an interrupt for their devices. VpicD will ensure that all devices with pending interrupts have been serviced before returning from the interrupt.
  • IRQ sharing support implemented in the device driver for servicing interrupts.

Deterministic Values for Unimplemented Registers

Any unimplemented registers in the range 00h–2Fh must return a deterministic value when they are read. Unimplemented configuration registers must return the "disabled" or "unused" value (not necessarily 0) when they are read.

Correct Identifiers for ISA Devices

In the Plug and Play ISA specification, it is required that a Plug and Play card have both:

  • An industry-unique Vendor ID (acquired by completing the form provided at http://www.microsoft.com/hwdev/pnpid.htm)
  • A company-unique Product ID (assigned by the manufacturer)

The specification requires that this Product ID be unique among all Plug and Play ISA cards manufactured by that company.

This means each product (for example, fax card, display adapter, sound adapter, and so on) and every model (for example, 14.4 fax, 28.8 fax, and so on) from the same manufacturer must have different product identifiers.

This is a requirement because it allows the operating system to isolate and identify these different cards. The user must never have a Plug and Play card that cannot be identified because it cannot be distinguished from other models of cards from the same manufacturer. The use of a unique Product ID does not solve the problems that occur when a user installs two of the same cards in a PC system.

In those cases, the user might install a Plug and Play card but will not receive indication that it was installed and the card will not work. For this purpose, the Plug and Play ISA specification defines a unique serial-number field that can be added to the Vendor and Product IDs to make the card completely unique. A board-unique number in the serial-number field is required for ISA devices included on a system.

BIOS Reporting or Serial ID for System Board Devices

A peripheral ISA device implemented on the system board can use a fixed Serial ID (which is not unique) if the device is reported through the BIOS.

If the system board device participates in the Plug and Play ISA isolation scheme (rather than being reported through the BIOS), then it must meet the same requirements for a unique Serial ID as for an add-on card.

Notice that it is possible that an add-on card containing an ISA chip might be added to a PC system that contains the same chip on the system board. In such a case, the add-on device will be found only if it has a different Serial ID.

PNP Suffixes and Compatible Device IDs

Device IDs that use the three-character PNP suffix are allowed only in the Compatible Device ID field and cannot be used as Device ID or Logical Device ID fields. The exception would be the device to which the PNP-based ID was originally assigned.

Resource data describe what resources must be available for each logical device on the card (for example, number of available IRQ numbers, address ranges of memory, and so on). Resource data can be stored in the same nonvolatile storage device (such as a serial ROM) that contains the serial identifier. The resource data in the nonvolatile storage device must be sequentially loaded into the resource data register (04h).

The content of the nonvolatile storage device must be programmed with the information the system needs to interpret which resources the card requires. The structure of the data contained in the storage device is variable, depending on what resources are needed.

The resource data for a Plug and Play ISA card can be read while the card is in the Config state. This card can enter the Config state either after it has been isolated during the isolation sequence or whenever it receives a Wake (Card Select Number [CSN]) software command in which the CSN matches the CSN assigned to the card. Only one card at a time can be in the Config state.

Option ROMs for Boot Devices

Plug and Play ISA expansion cards that contain boot devices require some special considerations to properly boot the system. The system must implement support for Plug and Play ISA boot devices and option ROMs as described in the Plug and Play BIOS specification.

The types of devices required for the boot process include the primary input device (usually a keyboard), the primary output device (usually a display adapter and monitor), and any IPL devices.

Any Plug and Play ISA expansion card that provides a boot function must be active when the system powers up. This gives non-Plug and Play systems the means for using Plug and Play ISA devices during a legacy boot process.

In this case, a non-Plug and Play system BIOS will not perform the isolation sequence but will instead perform a ROM scan to detect the presence of a boot device. After the ROM scan detects the presence of an option ROM on the boot device, the system ROM will jump to the option ROM to initialize the device. The Plug and Play option ROM on the card will detect that the system BIOS is not Plug and Play-compatible and will respond accordingly.

Although an initial set of static resources must be provided during this legacy boot, the Plug and Play ISA card must be capable of changing these resources using the standard Plug and Play ISA isolation and configuration process.

As required in the Plug and Play ISA specification, resource usage of a card is always reflected in the card’s configuration registers. This information allows Windows to easily determine the default settings of a Plug and Play boot device. The default settings can then be overridden by the operating system with full cooperation of the device driver.

Chapter 3 I/O Ports and Devices

This chapter presents guidelines for legacy I/O ports and devices, including serial and parallel ports.

Legacy Serial Port

This section defines requirements for legacy serial ports.

A 16550A buffered Universal Asynchronous Receiver/Transmitter (UART) or equivalent buffered legacy serial port is the standard implementation. For acceptable performance under Windows, the device must be able to support 115.2K baud.

A legacy serial port must provide flexible resource configuration and complete dynamic disable capabilities as defined in the Plug and Play External COM Device Specification, Version 1.0.

These are the recommended resource settings for legacy serial devices:

  • Four I/O locations for each port, where the standard ISA I/O addresses are 3F8h, 2F8h, 3E8h, 2E8h. Using the standard addresses ensures the proper functioning of software that directly addresses these locations.
  • Two IRQ signals, where the standard is programmable interrupt controller-based (PIC-based) IRQ 3 and IRQ 4. Using the standard IRQ signals ensures the proper functioning of software written for systems that use standard IRQ signals.

Two IRQs are required for each port. If two serial ports are implemented in the system, the IRQs can be assigned as follows:

  • For serial port A: PIC-based IRQ 4 and IRQ 11
  • For serial port B: PIC-based IRQ 3 and IRQ 10

An infrared (IR) adapter port might replace a serial port in a system. In such a case, the IR port should use the resource configuration that would otherwise be assigned to the second serial port.

Notice that IRQ sharing can be implemented under Windows if the minimum resource requirement cannot be met.

Important: Conflict resolution for legacy serial port must ensure the availability of at least one serial port. In the event of an irreconcilable conflict with other serial ports on the system, a legacy serial port must be capable of being disabled by Plug and Play software. This allows at least one of the two conflicting serial ports to operate correctly.

Legacy Parallel Port

This section presents guidelines for legacy parallel ports.

A legacy parallel port must provide flexible resource configuration following the Plug and Play Parallel Port Device Specification, Version 1.0b. Resource requirements must be met for each device of this type on the system. The requirements cannot be split between two ports on the system.

For legacy parallel devices, the following are the minimum resource requirements for each parallel port on the system:

  • Required: Support ISA I/O addresses of 378h and 278h, plus 3BC or a vendor-assigned I/O address. Using these standard I/O addresses ensures proper functioning of software written for operating systems that directly address these locations.

Recommended: Map the base I/O address to four additional locations.

  • Required: Support PIC-based IRQ 5 and IRQ 7. Using these standard IRQs ensures proper functioning of software written for operating systems that use standard IRQ signals.

Recommended: Support five additional IRQ signals.

  • Required: Support two unique DMA channel selections if the parallel port design supports block data transfers to memory using DMA controllers. Notice also that the DMA function will not work on a parallel port without an IRQ because the end of a DMA transfer is signaled by an interrupt.

To ensure Plug and Play support for resolution of resource conflicts, a full list of options for all possible configuration combinations must be enumerated, including:

  • Options for both extended capabilities port (ECP) mode, which requires an I/O address, an IRQ, and a DMA selection, and standard LPT mode, which requires only an I/O address.
  • Options that specify only the I/O address, allowing Windows to assign the IRQ and DMA channel.

On Intel Architecture systems, the operating system considers the parallel port base address (/) stored in the first BIOS Data Area (BDA) locations to be LPT1. The address stored in the second location is LPT2, and so on. On RISC-based systems, the information is in the ARC tree. On all ACPI-based systems, the information is obtained through the ACPI tree.

EPP Support and Restricted I/O addresses

Some enhanced parallel port (EPP) implementations require eight contiguous I/O ports. If EPP support is implemented, the hardware cannot use the ISA I/O address 3BCh as a base I/O address because VGA devices require use of port 3C0h.

Compatibility, Nibble Mode, and ECP Protocols

Support for a parallel port must include, at a minimum, the compatibility-mode and nibble-mode protocols required by the IEEE 1284-1994 specification. This allows other IEEE 1284-compliant devices to be connected without problems.

The port must also support the ECP protocol as defined by IEEE 1284 to allow connections with higher-speed parallel peripherals.

Recommended: Enable ECP by default.

IEEE 1284 Port Connector Specifications

IEEE 1284-I–compliant ports use a standard DB25 connector found on existing system parallel port designs. This is called an IEEE 1284-A connector in the specification.

IEEE 1284-II–compliant ports use an IEEE 1284-C connector. This connector is used on both the port and the peripheral device.

The parallel port design must provide enough space between the connectors and the surrounding enclosure to allow for a mating connector, connector shell, and latch assembly. The IEEE 1284 specification recommends an IEEE 1284-C connector for all new ports and devices.

Plug and Play Device IDs for IEEE 1284 Peripherals

The device ID is described fully in the IEEE 1284 specification. All characters in the device identification string must consist only of ASCII values 20h–7Fh. The device identification string consists of a leading zero (0), a hexadecimal value that represents the length of the string, and then a set of fields in ASCII that have a unique identification string.

In addition to the requirements specified in Plug and Play Parallel Port Device Specification, Version 1.0b, the device ID string must contain the following keys, at minimum. The keys are case-sensitive and can be abbreviated in INF files as indicated.

Key | Abbreviated string
MANUFACTURER | MFG
MODEL | MDL
CLASS | CLS
DESCRIPTION | DES

All MANUFACTURER and MODEL key values must remain unique for each manufacturer. All MANUFACTURER, MODEL, CLASS, and DESCRIPTION key values must remain static for a specific unit, where ID values do not change for different hardware configurations. For example, a user simply adding a memory module to a printer should not change the MODEL key value reported as part of the device ID. However, if the user adds memory by installing an upgrade kit that requires a different driver or requires the existing driver to behave differently, then changing the MODEL value is acceptable as part of the upgrade installation process.

The CLASS key describes the type of parallel device. The CLASS key can contain the values PRINTER, MODEM, NET, HDC, PCMCIA, MEDIA, FDC, PORTS, SCANNER, or DIGCAM. HDC refers to hard disk controller. MEDIA refers to any multimedia device. FDC refers to floppy disk controller.

The DESCRIPTION key is an ASCII string of up to 128 characters that contains a description of the device the manufacturer wants to have presented if a device driver is not found for the peripheral.

For information about how the system determines the correct peripheral device driver, see the Windows 95 DDK and Windows 2000 DDK.

Compatible ID Key for Parallel Device ID

The CID key in the device identification string can provide a value that exactly matches a peripheral name supported by a device driver shipped with Windows. The value must match a value listed in the device’s INF file.

Legacy Mouse Port and Devices

The following requirements must be met to ensure that all Plug and Play requirements are met and that built-in Microsoft-supplied drivers support the pointing device. If a PS/2-style port is used, the following requirements must be met:

  • Comply in full with requirements in Personal System/2 Specification, by IBM.
  • Use an 8042 chip (or equivalent) to ensure compatibility with Windows. In most cases, the existing 8042 keyboard port is sufficient; the chip initiates a PIC-based IRQ 12 interrupt when the pointing device is connected.
  • Support PCI-based IRQ 12 to ensure the proper functioning of software written for legacy systems that use this IRQ signal.
  • Return expected codes, including send ID (0F2h) and response acknowledgement (ACK) (0FAh), plus 1-byte ID.

Legacy Keyboard Port and Devices

If a PS/2-style keyboard port is used, it must meet the following requirements, which ensure that all Plug and Play requirements are met and that built-in Microsoft-supplied drivers support this device.

  • Support IRQ 1 on Intel Architecture to ensure the proper functioning of software written for legacy systems, which expect to use this IRQ signal.
  • Map the I/O address ports to 60h and 64h.
  • Return expected scan codes, including send ID (0F2h) and response ACK (0FAh), plus 2-byte ID.

Legacy FDC

The following resource requirements must be met for each legacy FDC device on the system:

  • Use static I/O addresses 3F2h, 3F4h, and 3F5h. Additional addresses can be provided in the event of conflict
  • Use IRQ 6
  • Use DMA Channel 2 if FDC supports block data transfers to memory using DMA controllers

These resources cannot be shared among devices of the same type.

The FDC must be capable of being configured, relocated, and disabled. For example, if the legacy FDC is located on the system board and an adapter that includes an FDC is added to the system, the system-board FDC must be capable of being disabled to prevent conflicts with the new adapter.

If the legacy FDC is located on an expansion card, the expansion card must allow independent dynamic disabling of the FDC and the hard disk controller. In this case, the adapter will continue to function if the FDC is disabled because of conflicts.

Appendix A IRQ, DMA, and I/O Port Addresses

This appendix lists resource assignments for IRQ, DMA, and I/O port addresses used by built-in devices on legacy system boards.

Fixed Interrupts

See "ISA Interrupts" in Appendix A of PC 2001 System Design Guide.

Legacy DMA Assignments

See "Legacy ISA DMA Assignments" in Appendix A of PC 2001 System Design Guide.

Legacy I/O Address Assignments

See "Legacy ISA I/O Address Assignments" in Appendix A of PC 2001 System Design Guide.


PC 2001 General System Requirements

This section presents a summary of the general system requirements, including system board, memory, and power management requirements. For performance requirements and exceptions for workstation and mobile PCs, see Chapter 4, "Workstations," and Chapter 5, "Mobile."

Note: Mobile PC exceptions are found throughout this guide.

SYS–0001. System performance meets PC 2001 minimum requirements

The performance requirements for PC 2001 systems are based on the minimum computational capabilities and performance necessary to support the demands of Windows-based applications together with the estimated processing demand and processing capability of the lowest-end processor in mid-2001.

The minimum performance requirement consists of the following.

  • SYS–0001.1. System includes CPU and cache that meets PC 2001 minimum requirements. The minimum microprocessor capability is specified to support the demands of rich media, Internet access, and conferencing. The performance requirement for these media enhancements is specified so that the system meets performance targets at minimum platform power.

The processor requirements for PC 2001 desktop systems are:

  • Minimum 667 MHz processor
  • Minimum 128 KB of cache present and enabled
  • SYS–0001.2. System memory meets PC 2001 minimum requirements. A PC 2001 system must meet the following memory requirements:
  • 64 MB RAM minimum
  • 128 MB RAM minimum for computers that have Windows 2000 preinstalled
  • SYS–0054. If implemented, system memory includes ECC memory protection. If error correction code (ECC) is implemented, system memory and external processor cache must be protected with ECC memory protection. All ECC RAM visible to the operating system must be cacheable. The ECC memory subsystem hardware must be able to detect at least a double-bit error in one word and to correct a single-bit error in one word, where word means the width in bits of the memory subsystem. A detected error that cannot be corrected must result in a system fault.
  • SYS–0001.3. APIC implemented and properly connected. All desktop systems must be Advanced Programmable Interrupt Controller (APIC) enabled. This means:
  • The local APIC in the processor must be hardware enabled.
  • All hardware interrupts are connected to an input/output Advanced Programmable Interrupt Controller (IOAPIC).
  • The IOAPIC is connected to the local APIC in the processor. If an 8259 is present in the system, the system must be configured such that the 8259 interrupt controller functions correctly with an operating system that is not aware of the APIC.

The BIOS must program and enable the system 8259 Programmable Interrupt Controller (PIC) for PC-AT compatible mode operation. The BIOS must program the APICs for Virtual Wire Mode operation. There are two Virtual Wire modes available: Virtual Wire Mode via the Local APIC and Virtual Wire Mode via the IOAPIC. Virtual Wire Mode via the IOAPIC is the preferred method of operation to be programmed by the BIOS.

Mobile PC Note

Mobile systems that do not have an APIC present are excluded from this requirement.

SYS–0002. System design meets ACPI 1.0b specification and PC 2001 requirements

The system board and BIOS must support Advanced Configuration and Power Interface Specification, Revision 1.0b. This requirement permits the system to correctly support Plug and Play and power management.

ACPI support must include the following.

  • SYS–0002.1. 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. Support for S1, S2, and S4BIOS is optional. Every system must support wake from all implemented sleep states, except S4 and S5, for all wake-capable devices and buses.

Multiprocessor systems are required to support S1, S4, and S5. Multiprocessor support for S3 is optional.

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.

  • SYS–0002.3. System provides no user-accessible method for disabling ACPI in the BIOS. If the system includes a BIOS setting that the manufacturer can use to switch between ACPI and Advanced Power Management (APM) modes, this setting must not be exposed to the end user in a CMOS setting or other means once a Microsoft ACPI-enabled operating system has been installed. Disabling ACPI will cause boot failures, because Windows 2000 relies on it for identification and initialization of system devices. Not having a user-accessible option to disable ACPI support does not impact the ability to properly load an operating system that is not ACPI compatible.
  • SYS–0002.4. 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.
  • SYS–0002.5. 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.
SYS–0003. Hardware design supports OnNow and Instantly Available PC initiatives

The OnNow and Instantly Available PC initiatives are based on these goals for the user experience:

  • The user experiences the PC as off when it is in a sleep state.
  • The user can easily see whether the PC is working or sleeping.
  • The user can easily control power through switches and software.

These initiatives are described in the Instantly Available Power Managed Desktop PC Design Guide. OnNow initiative information is available on the OnNow and Power Management Web site. Both are listed in "PC System References."

The following items are required to support these initiatives.

  • SYS–0003.1. System and devices appear as off in the sleep state. At a minimum, all media drives, display, sound, input devices, and fans must be perceived as off when the system has completed the transition to a sleep state, for example, no noise or lights other than the status indicator. It is acceptable for system fans to run for some period of time, provided these automatically turn off once sufficient cooling is achieved.
  • SYS–0003.2. System provides one or more indicators to show whether the system is in the working or sleep state. System provides a unique indication for the working state (S0), the sleep states (S1, S2, and S3) and off (S5) system state.

S4 must appear to the user as the off state (S5); therefore, S4 and S5 must have the same indication.

Each indication must visible and unique.

  • SYS–0003.3. System provides software-controlled, ACPI-based power switch. The system must provide an easily accessible power switch that can be controlled by software. This requirement for an easily-accessible power switch does not preclude power-control capabilities, such as closing the lid on a mobile PC.

The following are requirements for power/sleep buttons:

  • The function of these buttons is determined by the operating system.
  • In case of a hardware or software failure that prevents normal operation of the software-controlled buttons, the switch capabilities must include an override mechanism for turning off the PC.

A four-second override mechanism is recommended in Section 4.7.2.2.1 of the ACPI 1.0b specification. The override must be associated with the user’s primary switch interface, in order to establish an industry-standard implementation.

Notice that the override mechanism is not an alternative way for the user to turn off the PC in normal operation; it is only a fail-safe function for fault conditions.

  • If the power/sleep button is provided on the keyboard, the key must be clearly labeled and must consist of a single keystroke for turning on the PC, to provide accessibility for persons with disabilities. (Two keystrokes can be used to turn off the PC.) For information about scan codes for keyboard power switches, see the information listed in "PC System References."

The following are implementation requirements for the power/sleep button:

  • A single-button design is preferred. This button must be the user’s primary switch interface, and must be a power button as defined by the ACPI 1.0b specification.
  • 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. The preferred implementation in a two-button design is to hide the power button behind a door or on the rear of the system.
  • SYS–0003.4. Each device and bus supports the power management specifications for its class. All devices and drivers must support the D0 and D3 power states consistent with the definitions in the relevant device class power management reference specification and the Default Device Class Power Management Reference Specification, Version 1.0 or later. Support of D1 and D2 states is optional, unless required in the relevant device class specification. Requirements referring to D3 assume that power is removed unless otherwise noted.

Each device can successfully survive a system sleep/wake transition (where the device transitions from D0 to D3 to D0) without losing functionality and without requiring user intervention to restore functionality.

This requirement includes no requirement to retain any device context because it will be preserved or restored by the driver when returning to the D0 power state.

PCI, USB, IEEE 1394, and PC Card buses must support power management requirements as defined in their related bus standards. For information on PCI, USB and IEEE 1394, see Chapter 6, "Buses and Interfaces." For information on PC Card, see PC Card and CardBus Guidelines, Version 1.1.

  • SYS–0003.5. System power supply provides standby power for system wakeup events. The system supplies adequate standby power to support 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.

For more information, see the Instantly Available PC System Power Delivery Requirements and Recommendations, listed in "PC System References."

Mobile PC Note

This requirement for the system power supply does not apply to mobile PCs.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


PC 2001 BIOS Requirements

This section states requirements for the BIOS. Remote boot is separate from general BIOS requirements to distinguish between other desktop or mobile computers.

For BIOS requirements related to legacy-free designs, see "PC 2001 Legacy Free Requirements."

BIOS–0004. BIOS meets PC 2001 requirements for OnNow and Instantly Available PC support

The intention of this requirement is to avoid presenting the end user with confusing information and unnecessary visual display, and to permit access to error information by using a hot key.

ACPI BIOS entries, as defined in Section 1.6 of the ACPI 1.0b specification, must be the same for supporting either Windows Me or Windows 2000.

The following BIOS capabilities are required for OnNow support.

  • BIOS–0004.1. BIOS supports Fast POST (S4, S5, or mechanical off). Power on to the bootstrap loader handoff must occur in 12 seconds or less for systems not using SCSI as the primary storage connection. This time limit includes, if present, initialization of keyboard, graphics adapter, and a parallel ATA storage bus. For systems containing additional option ROMs, system integrity and security services, or user PXE boot option, an additional 4 seconds are allowed per instance. This time limit does not include hard disk spin-up time, time used for loading CPU firmware, multiprocessor systems, and time required for ECC scrubbing, if supported and enabled.
  • BIOS–0004.2. Resume from sleep state (S1–S3) to operating system handoff occurs within 1 second. This requirement does not apply for the S4 state. 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.
BIOS–0005. BIOS includes local boot support

The BIOS boot support requirements include the following. Additional BIOS requirements to support legacy reduction are defined in "PC 2001 Legacy Reduction Requirements." For information about BIOS and ATA, see ATA–0119, "Controller supports Ultra DMA (ATA/33)," in Chapter 6.

  • BIOS–0005.1. 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, Limited, for installing Windows from optical media, such as bootable CD media.

The primary optical device must be bootable. This requirement applies to the primary optical storage provided and on the primary bus that the device is attached, in its shipping configuration.

  • BIOS–0005.2. 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.

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).

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.

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.

  • BIOS–0005.3. 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.

  • BIOS–0005.4. Operating system recognizes the boot drive in a multiple-drive system. The BIOS must comply with the implementation of boot-drive determination in multiple-drive systems as defined in Section 5.0 of the BIOS Boot Specification, Version 1.01. Both Windows Me and Windows 2000 operating systems use this format for determining the boot drive when new bootable devices are introduced to a PC.
  • BIOS–0005.5. System timer is supported at system boot. The ROM BIOS must make sure that the timer is on at system boot and that timer interrupts are occurring as part of power-on self-test (POST) or reset.
BIOS–0006. BIOS supports SMBIOS 2.3

Windows 2000 can present system management BIOS (SMBIOS) 2.2 or later static table data in Windows Management Instrumentation (WMI). System designers must provide platform-specific static information at boot time using this mechanism. For more information, see System Management BIOS Reference Specification, Version 2.3.

BIOS–0007. BIOS and CMOS properly accommodate dates

BIOS and CMOS firmware support calendar dates from January 1, 1999 through December 31, 2099.

BIOS–0008. BIOS supports security

All PC systems must provide some mechanism for security, such as a preboot password, to protect enable/disable capabilities for hardware components before the operating system boots.

BIOS–0009. BIOS supports BIOS updates and revisions

Capability for BIOS updates must be provided. The following methods can be used to meet this requirement:

  • Through a remote new system setup mechanism downloaded and executed at boot time as described in NET–0256, "Adapter can be used as a boot device" in Chapter 14.
  • Through normal file access and execution methods when the system is fully booted into the normal operating system environment.

If option ROMs are provided, they must also be capable of being upgraded.

BIOS–0010. System BIOS supports debug port

BIOS provides support for system debug port. The debug port can be used during system startup for debugging, troubleshooting, and software development.

If a legacy serial port is implemented, the BIOS must provide an option to configure at least one legacy serial port to use either 2F8h or 3F8h. This capability allows the port to be treated as a boot device by the BIOS and is required to be usable by components as a diagnostic port in the event that system debugging is required by either the BIOS or the operating system.

For a legacy-free system, the implementation must meet the requirements defined in requirement BIOS–0015, "BIOS supports ACPI legacy-free reporting mechanism," and SYS–0046, "System supports legacy-free debug capabilities."

The Debug Port Specification is available at on the Microsoft Web site listed in "PC System References."

BIOS–0011. System BIOS and option ROMs support Int 13h Extensions

BIOS and option ROMs support Int 13h Extensions as defined in the "Layered Block Device Drivers" section of the Windows 98 DDK. This requirement also applies for redundant array of inexpensive disks (RAID) controllers when implemented, to support booting from Int 13h Extension devices. For additional information about Int 13h Extension devices, see ATA–0117, "ATA controller supports Int 13h Extensions and Logical Block Addressing," and SCSI–0106, "Bootable SCSI controller supports El Torito No Emulation mode and Int 13h Extensions," in Chapter 6.

BIOS–0012. ROM BIOS interrupt handlers preserve values in all registers

ROM BIOS hardware interrupt handlers and system management interrupt (SMI) handlers must preserve the values in all registers, including the high 16-bits of 32-bit registers. ROM BIOS application programming interface (API) handlers must preserve the values in all registers, including the high 16-bits of 32-bit registers that the API is not documented to modify.

Any ROM BIOS API that is documented to modify only the low 16-bits of a 32-bit register must preserve the high 16-bits of that 32-bit register; when the bits are preserved there are less likely to be compatibility problems for applications that use that API.

If a ROM BIOS API is documented to modify the flags—for example, it is documented to return with the CARRY flag set or cleared—this restriction does not apply to individual arithmetic bits in the flags register. Any ROM BIOS API that is documented to modify the flags is assumed to modify all of the arithmetic flag bits: AUX-CARRY, CARRY, OVERFLOW, PARITY, and ZEROSIGN.

The values of the other bits in the flags register must be preserved unless the API is documented to modify them.

BIOS–0014. BIOS supports remote boot

Systems designed for use with Windows 2000 must meet these requirements.

Mobile PC Note

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

  • BIOS–0014.1. BIOS supports PXE. The system must support remote boot as defined in Preboot Execution Environment (PXE) Specification, Version 2.1.
  • BIOS–0014.2. BIOS supports booting the system from the network and using F12 to force a system boot. The system BIOS must comply with the requirements that apply to Plug and Play devices as defined in Sections 3 and 4 of the BIOS Boot Specification, Version 1.01. This specification describes the requirements for initial program load (IPL) devices.

Systems that do not have an F12 key or already use the F12 key for another OEM-defined BIOS function can use an alternate key for network boot.

  • BIOS–0014.2.1. BIOS allows boot devices to be configured in order of precedence for boot. This feature must be implemented in accordance with Appendix C of the BIOS Boot Specification, Version 1.01. This feature is a PC 2001 requirement, even though it is optional in the BIOS boot specification.
  • BIOS–0014.2.2. Interface clearly shows boot order when users make configuration choices. For example, in a system that permits booting from floppy disk drive, hard disk drive (HDD), CD drive, DVD drive, or network adapter, it must be clear to the end user how to set a boot order that favors a specific device, such as the network adapter.
  • BIOS–0014.2.3. F12 key forces a system boot initiated from the network adapter. This key function must be enabled by default. Configuration of this feature can be provided through a BIOS configuration setting. When this feature is enabled, the boot display must indicate that F12 will invoke a network boot. This display must appear for a duration sufficient to be read by users, but must not lengthen the overall time needed to boot the machine.
  • BIOS–0014.3. System UUID is provided in print. The system universal unique ID (UUID), in accordance with the Open Group’s Common Application Environment (CAE) Specification, must be provided to the user in printed form for assistance in environments where it might be used as part of prestaging systems. This printed form is left up to the system manufacturer, but suggested means include posting the UUID on the system chassis or case, or printing the ID on the shipping carton.
  • BIOS–0014.4. BIOS supports BIS. For systems that include integrity or authentication services for downloaded remote boot images, the BIOS must provide these capabilities as defined in Boot Integrity Services Application Programming Interface, Version 1.0.

Boot Integrity Services (BIS) requires inclusion of structure type 31 (the BIS Entry Point) in the table of exported SMBIOS structures, in addition to the management data required by SMBIOS 2.3. See BIOS–0006, "BIOS supports SMBIOS 2.3." The BIS Entry Point requires that both 16-bit real-mode and 32-bit flat protected-mode entry points are nonzero. The overall structure checksum evaluates to zero.

  • BIOS–0014.5. System BIOS provides remote lockout capability. During remote management of a PXE client, remote lockout is required to prevent an end user from interrupting sensitive operations like a BIOS update. The remote lockout interface (RLI) allows programmatic lockout of events that could interrupt such an operation. Software running on the client system uses the interface.

The RLI hides the details of the underlying hardware implementation. Thus, manufacturers can provide different lockout hardware implementations while providing a consistent control interface to system software.

For a full explanation of the RLI, see Appendix B, "Remote Lockout."

BIOS–0015. BIOS supports ACPI legacy-free reporting mechanism

Fixed ACPI Description Table (FADT) settings must be supported and correctly implemented, including support for reporting legacy-free and hard reset/boot capabilities. For more details, see the OnNow and Power Management Web page listed in "PC System References."

BIOS–0016. BIOS does not configure I/O systems to share PCI interrupts when APIC is activated

This applies to boot devices configured by the BIOS. The operating system should configure all other devices. For systems that will run the Windows family of operating systems and where the platform hardware can be configured to avoid sharing, OEMs must design the BIOS so that it does not configure the I/O systems in the PC to share PCI interrupts for boot devices.

Mobile PC Note

In mobile systems, the BIOS can configure the I/O system to share PCI interrupts.

BIOS–0017. BIOS configures boot device IRQ and writes to the interrupt line register

This requirement applies to boot devices configured by the BIOS. Windows must configure all other devices because, after an interrupt request (IRQ) is assigned by the system BIOS, Windows cannot change the IRQ. If the BIOS assigns the IRQ and Windows needs it for another device, a sharing problem occurs.

The BIOS must configure the boot device IRQ to a PCI-based IRQ and must write the IRQ into the interrupt line register 3Ch, even if the BIOS does not enable the device. This way, the operating system can still enable the device with the known IRQ at configuration time, if possible.

BIOS–0018. System BIOS supports ATA

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.

BIOS–0019. BIOS enumeration of all ATAPI devices complies with ATA/ATAPI-5

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

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


PC 2001 Physical Design Requirements

This section summarizes physical design requirements for PC 2001 systems. These requirements are in addition to those related to the OnNow and Instantly Available PC initiatives for power-state indicators and easily accessible power switches.

For requirements related to audible noise, see SYS–0003, "Hardware design supports OnNow and Instantly Available PC initiatives," and its supporting requirements.

SYS–0020. System and component design practices follow accessibility requirements

At a minimum, the OEM must do the following:

  • Make sure that the keyboard and other input devices work correctly with the Microsoft Accessibility features in Windows. For example, StickyKeys must work with all keys in any keyboard design.
  • Make all modifier keys, such as the Ctrl and Shift keys, capable of being read and operated by software. This requirement includes the F1–F12 function keys and OEM-specific keys, such as Internet or Help keys. 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.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


PC 2001 System Expansion Bus Requirements

This section provides requirements for all expansion buses included on PC 2001 systems.

SYS–0021. PC 2001 system includes USB with two user-accessible USB ports, minimum

System includes two user-accessible USB ports in addition to any used by the keyboard and pointing devices. USB must meet the requirements defined in Chapter 6, "Buses and Interfaces."

Mobile PC Note

For requirements to any implementation of USB on mobile PCs, see Chapter 5, "Mobile."

SYS–0022. If IEEE 1394 is implemented, all components meet PC 2001 requirements

If implemented, IEEE 1394 must meet the requirements defined in Chapter 6, "Buses and Interfaces" Notably, at least two externally accessible IEEE 1394 sockets are required when external access is provided. Internal-only IEEE 1394 implementations are also allowed.

Mobile PC Note

If implemented externally, mobile PCs require at least one externally accessible IEEE 1394 socket.

SYS–0023. System buses meet PC 2001 requirements

System buses must meet the requirements in Chapter 6, "Buses and Interfaces." This includes SCSI, ATA/ATAPI, and PCI, if implemented.

SYS–0024. If CardBus is implemented, all components meet PC 2001 requirements

If CardBus is implemented in a system, it must meet the requirements defined in PC Card and CardBus Guidelines, Version 1.1.

CardBus cards must comply with Section 3 "PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges," in Volume 11 of the PC Card Standard, Release 7.

If wake-from-D3cold is implemented in a platform, the following are required:

  • Associated CardBus controller must support power management event (PME# assertion) from D3cold.
  • Associated socket must supply sufficient Vaux power to support the card in its D3cold state.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


PC 2001 General Device Requirements

This section contains requirements that apply for every device, whether present on the system board or as an expansion device provided by the OEM in a default system configuration. Most general device requirements are related to Plug and Play capabilities.

SYS–0025. Each device, device driver, and installation of either device or driver, meet PC 2001 requirements

Each device 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.

In addition to the device requirements in this section, see also the specific requirements for each device class in this guide.

  • SYS–0025.1. Driver installation does not interfere with other devices. The installation and loading of a driver must not reduce or eliminate functionality of other devices installed on the system.
  • SYS–0025.2. Devices with WDM support in Windows include WDM-based drivers. Devices with WDM support in Windows include WDM-based drivers. If WDM support is provided in the operating system for a device type, the driver supplied by the manufacturer must be a WDM minidriver. This requirement applies whether the system is designed for use with Windows Me or Windows 2000.
  • SYS–0025.3. Driver supports Plug and Play and power management IRPs. Every driver (or minidriver) must support Plug and Play and power management I/O request packets (IRPs). This requirement applies whether the system is designed for use with Windows Me or Windows 2000.

For virtual device drivers (VxD) for Windows Me, the following requirements apply:

  • Every VxD must support Plug and Play and power management messages.
  • The driver must provide power management support as required by any related device class power management reference specification.

For information about Plug and Play support under Windows 2000, see the Windows 2000 DDK.

  • SYS–0025.4. All configuration settings are stored in the registry. The driver must not use INI files for configuration settings.

The driver must also include correct provider, version, and copyright entries. This information is displayed in Device Manager in Windows.

  • SYS–0025.5. All INF and other file information is correct. The correct minidriver, VxDs, or any other manufacturer-supplied files specified in the device’s information file (INF) must be installed in the correct location.

For manufacturer-provided files, the vendor must not be identified as Microsoft and all other copyright and version information must be correct for the manufacturer.

Files provided by the vendor must not use the same file names as used by files included in Microsoft operating systems and provided as either retail or OEM products, unless specifically agreed upon with Microsoft.

For information about creating correct INF files under Windows 2000, see "Creating Windows 2000 INF Files" in the Windows 2000 DDK.

  • SYS–0025.6. Installation uses methods defined in the DDK. Driver installation and removal must use Windows-based methods, as defined in the Windows 98 DDK and Windows 2000 DDK.

The device driver must be able to be removed using Windows-based software, which can be managed using either the Windows Control Panel option for removing devices or its own remove utility. For information, see the driver installation information in the \SRC\General directory in the Windows 2000 DDK; see also "Windows 95 Class Installers and Network Driver Installers" in the Windows 95 DDK.

Also, any software components and registry entries installed during driver installation must be removed when the driver is removed.

SYS–0026. Each bus and device meets Plug and Play specifications

Each bus and device provided in a PC 2001 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.

Any legacy components remaining in a legacy-reduced system must meet the requirements defined in Legacy Plug and Play Guidelines, which contains all the requirements for legacy Plug and Play as published in PC 99 System Design Guide.

The following list shows current version numbers for all Plug and Play specifications:

  • PCI Local Bus Specification, Revision 2.2.
  • Plug and Play External COM Device Specification, Version 1.0.
  • Plug and Play ISA Specification, Version 1.0a and Clarifications to Plug and Play ISA Specification, Version 1.0a.
  • Plug and Play Parallel Port Device Specification, Version 1.0b.
  • Universal Serial Bus Specification, Revision 1.1.

Plug and Play specifications for IEEE 1394 are defined in this guide. For information, see "Plug and Play for IEEE 1394" in Chapter 6, "Buses and Interfaces."

SYS–0027. Unique Plug and Play device ID provided for each system device and add-on device

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.

In addition, for systems designed for use with Windows 2000, 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).

Legacy devices attached to the ISA bus on the system board are not required to have unique Plug and Play IDs—for example, serial ports, parallel ports, or PS/2 compatible port devices. For information, see Legacy Plug and Play Guidelines.

SYS–0029. Minimal user interaction needed to install and configure devices

After physically installing the device, the user need not perform any action other than inserting the disks that contain drivers and other files. The user should only be required to restart the system for devices that do not support hot plugging.

The following requirements must be met.

  • SYS–0029.1. The device is immediately functional without restarting the system. It is acceptable to require rebooting for the primary graphics adapter and 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.
  • SYS–0029.2. Software settings are available for configuring all resources. All buses and devices on both the system board and all expansion cards must be capable of being configured by the operating system and by software such as the Device Manager in Windows, so that the user does not need to open the PC case to change the configuration. Dual in-line package (DIP) switches on boot devices are allowed for an initial power-on default state or for non-Plug and Play system compatibility, but such settings must be capable of being overridden by software configuration after power on occurs under Plug and Play operating systems.

Note: This requirement does not apply for jumper settings used by the OEM to set CPU speed, select a keyboard, or make other basic system-related settings in the factory. This requirement applies only for settings that the end user must make to configure the hardware.

  • SYS–0029.3. Dynamic disable capabilities are 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 devices are exempt from this requirement: all legacy devices using the I/O range under 100h, 8042 keyboard controller, legacy FDC, HDC, video graphics array (VGA) memory and I/O addresses, and any BIOS memory ranges required for legacy boot support.

SYS–0030. Hot-plugging capabilities for buses and devices meet PC 2001 requirements

To provide reliable support for hot-plugging capabilities, the following requirements must be met.

  • SYS–0030.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.
  • SYS–0030.2. System supports hot-plugging for any PCI devices that use ACPI-based methods. Hot-plugging is not required for PCI devices. Windows Me and Windows 2000 support 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.

More information about Windows 2000 and PCI Hot-Plug can be found on the Web page listed in "PC System References."

  • SYS–0030.3. All removable media support media status notification. For details and for design requirements, see Chapter 12, "Storage."
  • SYS–0030.4. If implemented, system supports smart card specifications. If smart card is implemented, system must support ISO/IEC specifications. See SMRT–0153, "Smart card reader complies with ISO/IEC 7816," in Chapter 7.

For implementation details and additional design requirements, see "Supporting Removable Devices under Windows," the section about hot-plugging, listed in "PC System References."

SYS–0031. If implemented, Device Bay components comply with
Device Bay 1.0

If implemented in a PC 2001 system, Device Bay capabilities must meet the following requirements:

  • The system includes a Device Bay Controller (DBC) compliant with Device Bay Specification, Version 1.0 or later. If the DBC is implemented as a USB device, it must be compliant with Universal Serial Bus Device Class Definition for Device Bay Controllers, Version 1.0.
  • The system includes one USB port and one IEEE 1394 port for each Device Bay-capable bay in the system.

Any Device Bay peripheral that is provided with a PC 2001 system must meet the following requirements:

  • Device complies with Device Bay Specification, Version 1.0.
  • Device uses either the USB bus, the IEEE 1394 bus, or both.
  • If the device uses the USB bus, it must also comply with the relevant USB device class specifications.
SYS–0032. Multifunction device meets PC 2001 device requirements for each device

Multifunction devices can contain more than one device. They must comply with requirement SYS–0025, "Each device, device driver, and installation of either device or driver, meet PC 2001 requirements," including the requirements for automated software-only settings for device configuration, device drivers, and Windows-based installation. In addition, multifunction devices must meet the following requirements.

  • SYS–0032.1. Each enumerated device has a unique device ID. Each function or device on the multifunction add-on device that is individually enumerated must provide a device ID for the bus it uses.
  • SYS–0032.2. Windows can separately access and configure each logical device. Windows must be able to separately access each logical device that is individually enumerated, configure the device resources independently, and disable individual devices in the event of a conflict.
  • SYS–0032.3. Each enumerated device meets its own resource requirements. For each individually enumerated device, resource configuration requirements are the same as for an equivalent device on a separate expansion card. This requirement means that registers cannot be shared among individually enumerated devices on a multifunction add-on device, but it does not supersede device requirements among different bus classes.
  • SYS–0032.4. For PC 2001, separate drivers are required for separate functions. Note that a supervisory driver that loads different drivers for the individual functions does not work well with Windows. In particular, driver support is likely to be lost in cases of operating system re-installation or upgrade, or with distribution of new drivers via Windows Update. Therefore, these supervisory drivers must be avoided.
  • SYS–0032.5. There are no start order dependencies between drivers for separate functions. The operating system must be able to configure and manage functions and devices in any order, so drivers for a multifunction device may not depend on another driver to be started before the function or device can be used.
  • SYS–0032.6. Independent functions and devices can be used concurrently, with no hidden dependencies. Separate functional units in a multifunction device must be able to operate concurrently, without interfering with each other or with other devices in the system.
  • SYS–0032.7. Each function and device can be power managed independently. Each function and device in a multifunction device must separately meet the power management device class specifications for its device class and be independently power managed. Each function and device must be able to successfully complete a system sleep/wake transition (where the unit transitions from D0 to D3 with power removed to D0) without losing functionality and without requiring user intervention to restore functionality. All functions and devices that support wakeup capabilities must correctly support wake from D3 with power removed.
SYS–0033. Each bus meets written specifications and PC 2001 requirements

Each bus and connector used in the system must meet all the requirements for that bus as defined in Chapter 6, "Buses and Interfaces." For CardBus, see PC Card and CardBus Guidelines, Version 1.1. See also SYS–0026, "Each bus and device meets Plug and Play specifications."

SYS–0034. If implemented as an industry-standard riser card, the riser device subsystem complies with applicable standard Plug and Play requirements

All industry standard riser cards must provide means for the device to uniquely identifyeach function, so that the system (including the BIOS) can generate unique PCI Subsystem Vendor ID (SVID) and Subsystem Device IDs (SDIDs) as required in SYS–0027, "Unique Plug and Play device ID provided for each system device and add-on device."

Riser devices, including audio, modems, and network adapters, must supply a unique device ID for each version of the riser that needs a different driver. The device must also expose a different set of Plug and Play device IDs for each function as required in SYS–0032, "Multifunction device meets PC 2001 device requirements for each device."

Examples of these risers include:

  • An audio modem riser (AMR) card that complies with the Audio/Modem Riser Card Specification, listed in "PC System References."
  • Communications and networking riser. For more information, see the Communications and Networking Riser Web site, listed in "PC System References."
  • Advanced communications riser.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Legacy Removal Requirements

This section defines the hardware and BIOS requirements for legacy-reduced and legacy-free systems. For background information about the goals of legacy removal for PC 2001, see "Legacy Removal and Easy PC Goals" in Chapter 2, "Easy PC Initiative."

All PC 2001 computers accomplish some level of legacy removal, as indicated in the following subsection, "PC 2001 Legacy Reduction Requirements." For system designers who want the operating system to identify the computer as a legacy-free system, the "PC 2001 Legacy Free Requirements" section that appears later in this chapter contains additional requirements.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Workstation System Design Requirements

This section summarizes the additional design requirements and exceptions for workstation PC 2001 systems.

WORK–0051. Workstation system components meet minimum performance requirements

Minimum Workstation PC 2001 system component requirements include the following.

  • WORK–0051.1. System CPU speed is 700 MHz, minimum.
  • WORK–0051.2. System has 256 KB of cache per processor, minimum, present and enabled.
  • WORK–0051.3. System memory is 128 MB RAM, minimum.
  • WORK–0051.4. RAM must be capable of expansion to 2 GB, minimum.
WORK–0052. If implemented as a multiple processor system, the system must meet PC 2001 requirements

Workstations implementing multiple processors must meet the following requirements.

  • WORK–0052.1. The system must employ those processors symmetrically.
  • WORK–0052.2. Each processor must have a separate cache.
  • WORK–0052.3. The system memory and external processor cache are protected with ECC memory protection. See SYS–0054, "If implemented, system memory includes ECC memory protection" in Chapter 3.
  • WORK–0052.4. The system must comply with the ACPI 1.0b specification. Windows NT 4.0 was the last Windows operating system to use the MultiProcessor Specification, Version 1.4 (MPS 1.4). MPS 1.4 is a requirement for multiprocessor platforms running Windows NT 4.0.
WORK–0055. If implemented as a 64-bit system, PCI bus, bridges, and adapters support DAC command

On 64-bit workstation platforms that provide support for more than 4 GB of system memory, all PCI adapters, including 32-bit PCI adapters, must function properly in the system. In addition, certain classes of adapters, such as those on the primary data path where the majority of network and storage I/O occurs, must also address the full physical address space of the platform. For 32-bit PCI adapters on the primary data path, this means that the adapter must be able to support the PCI Dual Address Cycle (DAC) command. Note that 10/100 Ethernet adapters and embedded devices do not need to support DAC; however, 10/100 Ethernet adapters and embedded devices must still function properly in those systems even if they do not implement DAC support.

Additionally, all 32-bit PCI buses, host bridges, and PCI-to-PCI bridges must also support DAC.

On 64-bit platforms, all PCI bridges on the system board must support DAC for inbound access, and DAC-capable devices must not be connected below non-DAC capable bridges, on adapter cards, for example. New 64-bit adapters should be DAC capable. This DAC requirement does not apply to outbound accesses to PCI devices; however, for systems where DAC is not supported on outbound accesses to PCI devices, the system BIOS must not claim that the bus aperture can be placed above the 4 GB boundary.

System designers must address special considerations when using legacy devices, adapters, and bridges in systems that provide support for more than 4 GB of memory. For information on Windows 2000 behavior when a non-DAC capable bus is detected on a system that supports more than 4 GB of memory, see the PAE Server Design Web page, listed in "Workstation References."

WORK–0056. Workstation supports 64-bit I/O bus architecture if system includes 64-bit processors

A 64-bit PCI adapter must address any location in the address space supported by the platform.

The workstation must support a 64-bit PCI bus if the workstation has 64-bit processors or has the capability to support greater than 4 GB of physical memory.

SYS–0058. For 64-bit platforms, each device and driver meets PC 2001 device requirements

For workstations implementing a 64-bit platform, each device included within the workstation must have 64-bit Windows 2000 compatible drivers.

WORK–0059. Graphics subsystem supports workstation performance demands

The graphics-intensive application requirements for hardware often exceed the hardware capabilities of the graphics subsystem.

  • WORK–0059.1. Workstation screen resolution meets minimum requirements. For workstations, minimum graphics resolution is 1280 × 1024 × 32 bpp, double buffered in 2-D mode with a 32-bit Z-buffer (defined as 24-bit Z with 8-bit stencil) in 3-D mode.
  • WORK–0059.4. If implemented, an AGP Pro Bus follows the AGP Pro 1.1 Specification, Revision 1.1a.
WORK–0060. If implemented, multiple hard-drive system meets workstation PC 2001 performance requirements

When implementing a workstation storage subsystem capable of supporting multiple hard drives, the hard drives must either be allocated independent ATA Ultra/66 I/O channels (one channel per physical storage device) or may be grouped and interconnected using SCSI interfaces. This requirement ensures workstation data throughput while allowing less costly ATA interfaces on systems that require only a few drives.

If implementing a RAID drive storage subsystem, these arrays can be configured as:

  • RAID 0: Improve performance (multiple spindle access and striping).
  • RAID 1: Data mirroring on parallel drives.
  • RAID 5: For data integrity using distributed data and cyclic redundancy checks (CRCs).

For all related requirements for storage, see Chapter 12, "Storage."

PCIX–0129. If the workstation implements PCI-X, system and components comply with PCI-X 1.0

All cards, bridges, and devices that use PCI-X (a proposed extension to PCI) must meet the requirements defined in PCI-X Specification, Revision 1.0, listed in "Workstation References."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Mobile PC System Design Requirements

This section summarizes the additional design requirements and exceptions for mobile PCs.

MOBL–0061. Mobile PC performance meets Mobile PC 2001 minimum requirements

Minimum mobile PC 2001 performance requirements are:

  • MOBL–0061.1. Minimum 400 MHz processor
  • MOBL–0061.2. Minimum 128 KB of cache, present and enabled
  • MOBL–0061.3. 64 MB of RAM, minimum

Note: The processor requirement does not specify a particular processor form factor or package type.

MOBL–0062. Mobile PC supports Smart Battery or ACPI Control Method battery

A mobile PC must use a Smart Battery or an ACPI control method battery as follows.

  • MOBL–0062.1. If implemented, Smart Battery meets PC 2001 requirements. If Smart Battery is implemented, the following requirements apply:
  • An ACPI embedded controller-based (EC) System Management Bus (SMBus) interface is required, as described in Section 13 of ACPI 1.0b.
  • The Smart Battery must support the complete command set and meet the accuracy requirements defined in Smart Battery Data Specification, Revision 1.1.
  • A Smart Battery Charger, if used, must comply with the command requirements defined in Smart Battery Charger Specification, Revision 1.1.
  • Single battery system must comply with the intent of the Smart Battery System Manager Specification, Revision 1.0, and expose emulated Smart Battery System Manager registers to the operating system.
  • A multiple-battery system may use either a Smart Battery System Manager that complies with the Smart Battery System Manager Specification, Revision 1.0, or it may emulate the functionality of the Smart Battery System Manager. The battery selection or alternate control scheme must comply with the intent of the Smart Battery System Manager Specification. In either case, the multiple battery system must expose actual or emulated Smart Battery System Manager registers to the operating system.
  • Battery systems that support battery calibration must use the Smart Battery System Manager optional calibrate support bits in the BatterySystemStateCont register.

The intent is that battery systems returning Smart Battery system data by way of the EC SMBus interface as defined in the ACPI 1.0b specification do so in a manner consistent with the Smart Battery system specifications. They must return all battery data, the charger status, and all selector or system manager registers in a manner transparent to the operating system, allowing the standard Smart Battery system drivers provided with the operating system to work properly.

  • MOBL–0062.2. If implemented, ACPI Control Method Battery meets PC 2001 requirements. If an ACPI Control Method Battery is implemented, it must meet the requirements defined in Section 11 of ACPI 1.0b and never over-report its capacity.
MOBL–0063. Mobile PC includes at least one USB port

At least one USB port must be built into a mobile PC and not be provided solely by a docked mobile PC. Docked mobile PCs, however, provide extra USB connectors. This USB port can be either a high-power or low-power port, or it can be dynamically configurable at the discretion of the OEM, as provided for by Section 7 of the Universal Serial Bus Specification, Revision 1.1.

For additional information about USB ports and devices, see "USB," in Chapter 6.

MOBL–0064. If implemented, Mobile PC includes compliant IEEE 1394

The IEEE 1394 implementation must meet the IEEE 1394 device requirements found in Chapter 6, "Buses and Interfaces." If externally accessible sockets are provided, at least one IEEE 1394 supported socket must be provided.

MOBL–0065. Mobile PC includes CardBus

At least one 32-bit Type-2 CardBus slot (not 16-bit) is required. All CardBus implementations must comply with the requirements defined in Chapter 6, "Buses and Interfaces," including information about the default initialization of the CardBus controller under both Windows Me and Windows 2000 operating systems.

Information on PC Card and CardBus requirements is listed in "Mobile References."

MOBL–0066. Mobile PC keyboard and pointing device meet PC 2001 Mobile requirements

A mobile PC 2001 system must have an integrated pointing device and integrated input devices (keyboard or speech I/O).

The internal keyboard and any built-in pointing devices, such a mouse, stylus, pen, touch pad, touch screen, trackball, stick, and so on, required for a mobile PC must use standard system-board devices. The USB port can be used to support the requirement for external pointing device and keyboard connections.

For more information, see Chapter 7, "Input Devices," which also provides information about implementing the Windows and Application logo keys on mobile PCs.

MOBL–0069. Mobile PC meets PC 2001 Mobile graphics and video requirements

A mobile PC must meet the guidelines in Chapter 8, "Graphics Adapters," in addition to the guidelines listed below:

  • MOBL–0069.1. Mobile PC has integrated display.
  • MOBL–0069.2. Mobile PC provides PC 2001 Mobile graphics capabilities. Mobile PC meets all graphics requirements.
  • MOBL–0069.3. If implemented, external video connector meets mobile PC requirements. Mobile PCs are not required to include an external video connector. If an analog video connector is implemented, it can be either a VGA connector or DVI connector. If a digital monitor interface is implemented, a DVI connector is required.
  • MOBL–0069.4. If implemented, TV output meets mobile PC requirements. Mobile PCs are not required to include an external TV output.
MOBL–0070. Mobile PC includes PC 2001 hard disk as primary boot device

Mobile PC must include a PC 2001 hard disk as its primary boot device. The drive must meet the requirements in Chapter 12, "Storage."

MOBL–0071. Communications capabilities meet Mobile PC 2001 requirements

The presence of a CardBus slot on the mobile PC meets the PC 2001 requirement for providing access to the LAN and WAN, with the following exceptions:

  • If modem capabilities are integrated in the base platform, the requirements for modems must be met as defined in Chapter 13, "Modems."
  • For a network adapter, support is optional, rather than required, for remote new system setup capabilities. All other requirements for network communications must be met as defined in Chapter 14, "Network Communications."
  • Support for remote wakeup is not required to be built into mobile PCs.
MOBL–0072. If implemented, CD or DVD drive meets PC 2001 requirements

If a mobile PC includes a CD or DVD drive, it must meet the requirements in Chapter 12, "Storage." The mobile PC must also support booting from the drive, whether it is integrated into the platform, contained in a user exchangeable bay device, or attached to the system by a dongle or other cable.

A mobile PC system, as purchased, might not include all peripherals required for operating system installation. This basic PC 2001 requirement is met as long as it is possible for the user to obtain the required device support for operating system installation, even if it requires a separate purchase.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Port Replicator and Docking Station Requirements

Docking stations and port replicators are expansion devices that physically mate to the mobile PC and provide cable management. Docking stations include feature enhancements such as PCI slots, network adapters, PC Card slots, and storage devices.

Expansion devices that connect to the mobile PC by a cable and use buses such as serialized PCI, USB, IEEE 1394 or a wireless connection, must meet their respective industry standards and requirements as specified in the appropriate bus and device chapters in this guide.

The requirements in this section apply for mobile PC that supports a docking system or port replicator. A mobile PC is not required to have a docking system.

For all port replicator implementations, the appropriate requirements in the bus chapter apply unless specific exceptions or additional requirements are listed in this section.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


USB

This section presents the requirements for Universal Serial Bus (USB).

Required on all PC 2001 systems, USB provides an expandable, hot-pluggable Plug and Play serial interface that ensures a standard, low-cost socket for adding external peripheral devices ranging from interactive HID devices such as joysticks and pointing devices to isochronous devices such as telephony, audio, and imaging devices. USB allows integration of cascading hubs into desktop devices such as monitors and keyboards.

Any device that plugs into or is connected to a USB port is considered a USB device and must comply with the requirements defined in these requirements. If the device provides the capabilities of one or more functions or it provides a hub to the host, it must comply with the requirements in this chapter.

Unless this chapter defines a specific requirement or exception, all requirements for buses and interfaces apply as presented in Chapter 3, "PC System," Chapter 4, "Workstation," and Chapter 5, "Mobile."

For information about USB BIOS requirements, see "PC 2001 BIOS Requirements" in Chapter 3, "PC System."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


IEEE 1394

The following requirements expressly require interconnectivity for IEEE 1394-1995 and IEEE 1394a-2000 devices. However, these requirements do not preclude implementations of IEEE P1394b, which has advantages for power management, performance, and integration into low-power systems.

Basic Requirements for IEEE 1394

This section defines the basic PC 2001 requirements for implementing IEEE 1394.

Note: An implementation of IEEE P1394b can meet these requirements.

1394–0090. System implementing IEEE 1394 supports mandatory features in IEEE 1394 standards

Systems that support IEEE 1394 features and interconnectivity that interface to the IEEE 1394 bus must support the industry standards and its amendments as they apply to internal and external devices. Minimum requirements consist of the following.

  • 1394–0090.1. System provides IEEE 1394-1995/1394a interconnectivity

All systems must support the following industry standards and their amendments:

  • IEEE 1394a-2000 amendment to IEEE 1394-1995
  • IEEE 1394-1995 Standard for a High Performance Serial Bus
  • IEEE 1212-2000
  • Serial Bus Protocol 2 (SBP-2)
  • 1394 Trade Association Power Specification (all components)
  • Plug and Play Design Specification for IEEE 1394, Version 1.0c
  • 1394–0090.2. Systems implementing IEEE 1394 internal devices support mandatory features in the IEEE 1394a-2000 or IEEE P1394b amendments to IEEE 1394-1995

A system designer may incorporate one or more internal IEEE 1394 devices, one or more externally accessible IEEE 1394 sockets, or any combination thereof. For example, a system could provide an internal IEEE 1394 DVD device without providing any external interconnect to IEEE 1394. If, however, that same system provides externally accessible IEEE 1394 sockets, support must be provided for connecting an IEEE 1394-1995/1394a device to that socket.

1394–0091. Host controller supports mandatory components of 1394 OHCI 1.1

Host controllers must implement the mandatory features of 1394 Open Host Controller Interface Specification, Revision 1.1, including host notification of a PHY LinkOn event, Dual Buffer Mode enhancements, ack_tardy processing, SCLK failure detection, Skip Processing enhancements, and Block Read Request handling.

PCI Bus Power Management Interface Specification, Revision 1.1, is an implementation option for OHCI 1.1, however, IEEE 1394 host controllers used on PC 2001 systems must provide support for PCI 1.1 Power Management, including power states D0, D1, D2, and D3cold.

1394–0092. Host controller supports minimum peak data rates specified in IEEE 1394 standards

Host controllers must support the highest data rate of the PHY to which they connect.

The host controller’s PHY must support data rates of S100 megabits per second (Mbps), S200 Mbps, and S400 Mbps as specified in IEEE 1394-1995 and IEEE 1394a-2000.

1394–0093. If the IEEE 1394 implementation provides external connectivity, system must use only sockets specified by IEEE 1394-1995 and its amendments

A system that implements externally accessible sockets must provide a method for connecting to devices that only support IEEE 1394-1995 or its amendment, IEEE 1394a-2000.

The connector described in the Device Bay Specification, Version 1.0, is for use inside the PC 2001 system and is not an externally available socket.

Any externally accessible socket must meet all interface specifications of IEEE 1394-1995, 1394a-2000 or IEEE P1394b, as appropriate. This requirement includes, but is not limited to: a) input impedance from the perspective of the pins on the socket looking back into the system, as specified by the IEEE standards, b) signal amplitude, c) sensitivity, and d) jitter.

Minimum acceptable performance of IEEE 1394-1995 and 1394a-2000 sockets can be validated by following the recommendations, test sequences, and test procedures of ANSI/EIA 364-B-90, as specified in the IEEE standards, and comparing results against the electrical and performance requirements contained within the IEEE 1394-1995 and 1394a-2000 standards.

Minimum acceptable performance implementations of non-optical IEEE P1394b sockets can be validated by following the recommendations, test sequences, and test procedures of ANSI/EIA 364-C-94, as specified in the IEEE P1394b standard, and comparing results against the electrical and performance requirements contained within the IEEE P1394b standard.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


SCSI

This section presents requirements for the small computer system interface (SCSI), a flexible I/O bus that is used in the design of a wide variety of peripherals, including disk drives, CD drives, tape drives, scanners, and magneto-optical drives. The SCSI host adapter provides circuitry that serves as an interface between the system and one or more SCSI peripherals. A host adapter can be a card that plugs into the system’s expansion bus, such as a PCI card, or it can be designed directly into the system board.

See also "SCSI Storage" in Chapter 12, "Storage."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


ATA and ATAPI

This section presents the requirements for Windows-compatible ATA and ATAPI controllers and peripherals.

The use of ATA in a PC 2001 system is optional. If a system uses ATA, however, all components must comply with the requirements defined in this section.

ATA–0115. ATA/ATAPI controllers comply with ATA/ATAPI-5 standards

All ATA/ATAPI controllers must meet the hardware and software design requirements listed in the AT Attachment with Packet Interface – 5 (ATA/ATAPI-5) standard.

ATA–0116. Bootable ATA controller supports El Torito No Emulation mode

Details are defined in requirement BIOS–0005, "BIOS includes local boot support," in Chapter 3.

ATA–0117. ATA controller supports Int 13h Extensions and Logical Block Addressing

Int 13h Extensions are detailed in SCSI–0106, "Bootable SCSI controller supports El Torito No Emulation mode and Int 13h Extensions."

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. 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.

ATA–0118. If implemented, dual ATA adapters use single FIFO with asynchronous access or dual FIFOs and channels

Although the use of an ATA adapter with more than one channel is optional, if included, dual ATA adapters must be designed so that either channel might be used at any time; the operating system does not have to serialize access between the primary and secondary channel. This requirement means either that the two channels are totally independent or that anything shared. For example, a programmed I/O (PIO) read prefetch buffer is protected by a hardware arbitrator.

Section 5.0 of the BIOS Boot Specification, Version 1.01 defines an implementation for dual asynchronous channels.

A design implementing a single first in/first out (FIFO) that uses a hardware solution to synchronize access to both channels meets this requirement. A request on one channel need not be completed before another request to the other channel can start. A software-based solution is not acceptable.

ATA–0119. Controller supports Ultra DMA (ATA/33)

The programming register set for PCI Integrated Device Electronics (IDE) bus master DMA is defined in ATA/ATAPI-5. ATA drives must comply with ATA-5 to ensure fully featured hardware and Windows-compatible device driver support.

All controllers and ATA hard drive peripherals must support Ultra DMA at transfer rates of 33 MB per second or higher as defined in ATA/ATAPI-5. In addition to improved transfer rates, Ultra DMA also provides error checking for improved robustness over previous ATA implementations. PCI chip sets must implement DMA as defined in ATA-5.

Definitions for the ACPI control methods can be found in Section 10.8 of ACPI 1.0b.

ATA–0120. ATA controller and peripheral connections include Pin 1 cable designation with keyed and shrouded connectors

One edge of the keyed ribbon cable and the keyed connector of the ATA or ATAPI controller and peripheral device must indicate the Pin 1 cable orientation. Designation of the keyed connector must be clearly indicated on or near the connector.

ATA–0121. ATA bus complies with device class power management reference specification

The ATA bus must comply with the Storage Device Class Power Management Reference Specification, Version 1.0a.

ATA–0122. Discrete PCI ATA controllers in mobile docking stations implement in PCI Native-Mode ATA

Discrete ATA and ATAPI controllers that are implemented in mobile docking stations must comply with the PCI IDE Controller Specification, Revision 1.0, for native mode support. This requirement does not apply to controllers that are a part of the mobile PC’s chip set architecture.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


PCI

This section presents the PC 2001 requirements for Peripheral Component Interconnect (PCI) host controllers and peripherals.

The PCI architecture has become the most common method used to extend PCs for add-on adapters. Windows Me and Windows 2000 use the basic PCI infrastructure to gain information about devices attached to the PCI bus. The ability of PCI to supply such information makes it an integral part of the Plug and Play architecture in Windows.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Bluetooth

Bluetooth technology is designed to be used as a wireless local bus to connect mobile devices over a personal and private connection (in essence, to replace the cables carried by many mobile travelers). Three types of Bluetooth devices are:

  • Host controllers, used to enable PC communication with other devices using Bluetooth wireless technology
  • PC peripherals using Bluetooth wireless technology for communication to the PC
  • Independent devices, such as personal data assistants, which are not within the scope of this design guide

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


General Input Device Requirements

This section summarizes requirements for legacy ports.

INPT–0133. All non-integrated USB human input devices meet USB HID specifications

All USB keyboards, pointing devices, game pads, and their connections included with a PC 2001 system must comply with the Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.1, and USB HID Usage Tables, Version 1.1. This is required whether the devices are implemented as wired or wireless.

For HID implementation requirements under the Windows family of operating systems, see the Windows 2000 DDK.

INPT–0134. All PC 2001 input devices support Microsoft DirectInput and work simultaneously

All input devices implemented in a PC 2001 system must have drivers that support Microsoft DirectInput® if they do not use drivers that are built into the operating system. Also, all input devices must be able to correctly provide simultaneous input. Thus, no input device is disabled automatically when another input device is in use.

Note: The built-in drivers provided with Windows Me and Windows 2000 meet this requirement.

For information about implementing drivers that support simultaneous use of devices, see the Microsoft DirectInput® DDK provided with the Windows 98 DDK, listed in "Input Devices References."

INPT–0135. Devices use USB or external bus connections rather than legacy serial or parallel ports

Although legacy ports can be provided on a PC 2001 legacy-reduced system, no devices that use these ports can be provided with a system. Legacy ports include the serial and parallel ports on the PC. A legacy serial port cannot serve as a mouse, modem, PIN data-entry keyboard, or smart card reader connection. The FDC bus cannot be used for removable media other than standard floppy media. It is allowable to externally expose the FDC bus through the parallel port connector. For a complete list of legacy-related requirements, see "Legacy Removal Requirements" in Chapter 3.

INPT–0136. Serial port adapter meets device class specifications for its bus

As required for all PC 2001 devices, a serial port implementation must meet the specific device class requirements for that bus. An example of a serial port adapter is a USB-to-serial adapter. Such an implementation must comply with all related USB specifications, including:

  • Universal Serial Bus Specification, Revision 1.1 (also known as the USB core specification).
  • Universal Serial Bus Class Definitions for Communication Devices, Version 1.0.

The "Standard Serial Interface Circuit Emulation" appendix in the Universal Serial Bus Class Definitions for Communication Devices specifically addresses serial-port compatibility.

INPT–0137. If implemented, legacy serial port is implemented as 16550A UART or equivalent and supports 115.2K baud

Legacy ports are discouraged for PC 2001 systems, but if implemented, a legacy serial port must comply with legacy the implementation requirements in Legacy Plug and Play Guidelines, listed in "Input Devices References."

INPT–0138. Parallel port meets device class specifications for its bus

As required for all PC 2001 devices, a parallel port implementation that uses a nonlegacy bus must meet the specific device class requirements for that bus.

An example of a parallel port adapter is a USB-to-parallel adapter. Such an implementation must comply with all related USB specifications, including:

  • Universal Serial Bus Specification, Revision 1.1 (also known as the USB core specification).
  • Universal Serial Bus Device Class Definition for Printing Devices, Version 1.0.
INPT–0139. If a legacy parallel port is implemented, flexible resource configuration is supported for each parallel port

Legacy ports are discouraged for PC 2001 systems, but if implemented, a legacy parallel port must comply with legacy implementation requirements in Legacy Plug and Play Guidelines, listed in "Input Devices References."

INPT–0140. Daisy-chained legacy parallel port device is Plug and Play capable

Daisy-chained legacy parallel port devices must be Plug and Play capable. The daisy-chained parallel port device must be capable of answering Plug and Play requests from the host.

All pass-through devices must comply with IEEE 1284.3 because of end-of-chain issues with IEEE 1284 and IEEE 1284.3. Support for parallel ports and daisy-chained devices is provided in the "High-Level Operation of Parclass and Parport" section of the Windows 2000 DDK, listed in "Input Devices References."

INPT–0141. Pointing-device connection meets requirements for its bus class

For implementation requirements for legacy devices such as PS/2-compatible mouse devices, see Legacy Plug and Play Guidelines, listed in "Input Devices References."

If a USB connection is used, it must meet the following USB port requirements:

  • Universal Serial Bus Specification, Revision 1.1
  • Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.1
  • Minidriver support based on HID class support in the operating system

For information about implementing minidriver support based on HID class support in the operating system, see HID Support Routines for MiniDrivers, in the Windows 2000 DDK, which defines the implementation for both Windows Me and Windows 2000, listed in "Input Devices References."

INPT–0142. Keyboard connection meets requirements for its bus class

Mobile PC Note

For implementation requirements for legacy devices such as PS/2-compatible keyboard devices, see Legacy Plug and Play Guidelines.

If a USB connection is used, it must meet the following requirements:

  • Universal Serial Bus Specification, Revision 1.1
  • Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID), Version 1.1
  • Minidriver support based on WDM HID class support in the operating system

USB keyboards must support the USB boot device specification. The system BIOS must provide boot support as specified in requirement BIOS–0005.2, "BIOS provides boot support for USB keyboards and hubs," in Chapter 3.

INPT–0143. No interference occurs between multiple keyboards

Mobile PC Note

If the system includes more than one keyboard, there must be no conflicts. For example, a docked mobile PC can have more than one keyboard attached to the system. The keyboard ports on a mobile PC and a docking station must be able to resolve conflicts between the two ports when the mobile PC is docked. Windows supports multiple configurations through the registry and will determine which keyboard to enable.

For more information about managing resources and devices for a docked mobile PC, see Chapter 5, "Mobile."

INPT–0144. If implemented, Windows and Application logo keys meet Microsoft requirements

The following are requirements for a keyboard design that includes any Windows logo keys:

  • The keyboard must be developed according to technical requirements in New Key Support for Windows Web page, listed in "Input Devices References."
  • The keyboard must be compatible at the Windows virtual key-code level.
  • The Windows logo key must function as a modifier (Ctrl, Shift, or Alt).
  • The Windows Flag trademark must be clearly distinguished on the key top according to the requirements in Key Support and Keyboard Scan Codes for Windows Web page, listed in "Input Devices References."
INPT–0145. If implemented, Internet browser and multimedia keys use Microsoft APIs

If a keyboard or peripheral implements multimedia or Internet browser keys, they must use the registry keys associated with the WM_APPCOMMAND API to access those functions as described in the Windows 2000 DDK. Registry keys can be programmed using INF files to install special entries as defaults or through a customized interface provided to the user.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Wireless Component Requirements

This section defines requirements for wireless components when they are included in a PC 2001 system, provided either as IR or radio frequency (RF) devices.

For information about requirements for wireless networking devices, see "IrDA Requirements for Network Communications" in Chapter 14, "Network Communications."

INPT–0146. IR device uses NDIS 5.0 miniport driver

An NDIS 5.0 miniport driver is required for all IrDA data devices and wireless network devices. For documentation and sample source code for building a miniport driver, see Chapter 13, "IrDA Miniport NIC Drivers," in the Windows 2000 DDK, listed in "Input Devices References."

INPT–0147. IR device meets IrDA specifications

An IR device must be designed to comply with approved IrDA specifications. If the system is intended to run data transfer applications with other IrDA data devices, it must comply with the IrDA Serial Infrared Data Link Standard Specifications.

If an IrDA Control application is used in a PC 2001 system, it must comply with the IrDA Control Specification.

INPT–0148. System supports standard input speeds of 4 Mbps

Device support is required for FIR input speeds of 4 Mbps for all IrDA Data devices.

INPT–0149. System provides a separate, physically isolated transceiver for each IR protocol supported

This requirement provides for correct implementation for a system that includes IR support for any combination of devices that use the IrDA Data protocol, the IrDA Control protocol, or the universal consumer–IR approach to legacy remote control, each of which use different device signals. The system must also expose each separate transceiver to the operating system.

If multiple IR protocols are supported, controllers must provide separate data connections into the PC using USB. For more information, see Appendix F, "IrDA Control on a USB System," of the IrDA Control Specification, listed in "Input Devices References."

INPT–0150. If a legacy IR port is implemented, flexible resource configuration is supported for each port

A legacy IrDA port must be assigned hardware IDs PNP0510 or PNP0511 (generic IrDA–compatible device) by the BIOS and be enumerated in the ACPI Differentiated Description Table. It must also have a Plug and Play compatible register space as specified in the Plug and Play ISA Specification, Version 1.0a, listed in "Input Devices References."

IMAG–0151. Digital still image device with an IR interface uses the Windows Sockets interface

Windows 2000 does not provide support for IrCOMM-based devices. For imaging devices that include an IR interface, the device manufacturer provides the driver that uses the Windows Sockets interface.

Cameras that comply with Infrared Transfer Picture Specification (IrTran-P), Version 1.0 or later need not provide a Windows Sockets interface-based driver.

Mobile PC Wireless Design

This section defines requirements for wireless devices used with a mobile PC.

MOBL–0152. If implemented in a mobile PC, IR devices support power management

IR capabilities are not required for mobile PCs. IrDA devices must support D0 and D3 states, controlled by methods defined in Section 3.4 of the ACPI 1.0b specification or by the relevant bus-specific methods.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Smart Card Requirements

Smart cards are not required, but if implemented, must comply with the requirements defined in this section. The general device requirements are defined in "General Input Device Requirements."

SMRT–0153. Smart card reader complies with ISO/IEC 7816

A smart card reader must comply with the following specifications:

  • ISO/IEC 7816-1:1998 Identification cards—Integrated circuit(s) cards with contacts—Part 1: Physical characteristics
  • ISO/IEC 7816-2:1999 Identification cards—Integrated circuit(s) cards with contacts—Part 2: Dimensions and location of the contacts
  • ISO/IEC 7816-3:1997 Information technology—Identification cards—Integrated circuit(s) cards with contacts—Part 3: Electronic signals and transmission protocols
  • ISO/IEC 7811-1:1995 Identification Cards—Recording technique—Part 1: Embossing
  • ISO/IEC 7811-3:1995 Identification Cards—Recording technique—Part 3: Location of embossed characters on ID-1 cards
  • ISO/IEC 7813:1995 Identification Cards—Financial transaction cards
  • ISO/IEC 10373:1993 Identification cards—Test methods
  • Interoperability Specification for ICCs and Personal Computer Systems, Version 1.0 (PC/SC Specifications)
SMRT–0154. Smart card reader supports ISO/IEC 7816-3 T=0 and T=1 protocols

A smart card reader must support the asynchronous protocols T=0 and T=1 as described in ISO/IEC 7816-3, either in hardware or in the driver. Both protocols must be supported fully. The smart card reader and the driver must support cards that can handle both protocols.

The following protocol rules apply for the T=1 protocol:

  • A transmission is defined as sending a command to a smart card using one or more T=1 blocks and receiving the corresponding answer using one or more T=1 blocks as defined in ISO/IEC 7816-3.
  • For cards that support Information Field Size integrated circuit Card (IFSC) requests, the first transmission—after a reset of the smart card—must start with an Information Field Size Device (IFSD) request, as defined in ISO/IEC 7816-3, Amendment 1, Section 9.5.1.2.

For cards that do not support an IFSD request (that is, the card replies with an R-Block indicating "Other error"), the transmission must continue with an I-Block.

After a successful RESYNCH request, the transmission must restart from the beginning with the first block with which the transmission originally started.

Support for protocols other than T=0 and T=1 is not required.

SMRT–0156. Smart card reader supports 258-byte packets in T=0 and 259-byte packets in T=1

A smart card reader must support the exchange of the following in a single transmission:

  • 258 byte packets in T=0—that is, 256 data bytes plus the two status words SW1 and SW2.
  • 259 byte packets in T=1—that is, 254 information bytes plus node address, packet control bytes, length, and two Error Detection Code bytes.
SMRT–0155. Smart card reader supports inverse-convention smart cards

A smart card reader must support both inverse and direct convention smart cards either in hardware or in the driver for the operating system.

SMRT–0157. Smart card reader supports a smart card insertion/removal monitor

A smart card reader must be able to detect and report smart card insertions and removals without any user intervention other than removing or inserting the smart card itself. The reader must use an interrupt mechanism to report the smart card insertion or removal to the system. A driver polling method to detect smart card insertion and removals is not an acceptable method for meeting this requirement.

SMRT–0158. Smart card reader supports negotiable and specific modes

To support multiprotocol smart cards and smart cards using higher data rates and higher clock frequencies, the reader must support negotiable and specific modes according to ISO/IEC 7816-3 (1997-12-15), Sections 6 and 7, listed in "Input Devices References."

SMRT–0159. Smart card reader supports 3.5795 MHz minimum clock frequency

A smart card reader must support a minimum clock frequency of 3.5795 MHz.

SMRT–0161. Smart card reader supports the Power Down command

A smart card reader must support the Power Down command to turn off power of a smart card, as defined in ISO/IEC 7816-3 (1997-12-15), Section 5.4, listed in "Input Devices References."

SMRT–0162. If input device implements a PIN data-entry keyboard, it must comply with ISO 13491-1

An input device that uses a keyboard for personal identification number (PIN) entry must comply with ISO 13491-1:1998 Banking—Secure cryptographic devices (retail)—Part 1: Concepts, requirements and evaluation methods, listed in "Input Devices References."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Baseline Graphics Features

This section defines the baseline requirements for graphics adapters and the graphics subsystem.

GRPH–0163. Primary graphics adapter uses AGP or another high-speed connection

Accelerated Graphics Port (AGP) requirements are defined in Accelerated Graphics Port Interface Specification, Revision 2.0. PC 2001 requirements are defined in "Requirements for AGP and PCI Graphics Adapters." Specific AGP requirements are as follows:

  • Discrete graphics solutions require the equivalent of AGP 2.X.
  • Integrated graphics solutions require the equivalent of AGP 1.X.

Other buses, such as PCI, may be used for secondary graphics adapters.

GRPH–0164. System provides hardware-accelerated 3-D graphics

Many of the level-of-quality features and enhanced user interface features planned for future versions of Windows rely on Microsoft DirectDraw® and Microsoft Direct3D® being fully implemented in the graphics subsystem. Accordingly, all systems must include DirectX acceleration for 2-D and 3-D as listed in the sections "Hardware Acceleration for 2-D Graphics" and "Hardware Acceleration for 3-D Graphics."

For all systems, 3-D acceleration is based on Direct3D capabilities provided in the operating system.

A system designed as a Windows graphics workstation must include a 3-D accelerator that supports Direct3D and may optionally support OpenGL as well. All hardware-accelerated features of the OpenGL accelerator must be accelerated under Direct3D except for those features not supported by the current released version of Direct3D. OpenGL support can be implemented under Windows as a Mini Client Driver (MCD) or Installable Client Driver (ICD). OpenGL driver support for Windows Me can only be implemented as an ICD.

Implementation details for OpenGL and DirectX are contained in the Windows 98 DDK and Windows 2000 DDK.

GRPH–0165. If Digital Video Interface is implemented, it conforms to DVI specification

DVI is the required interface for connecting monitors with a digital interface. For analog video output, the DVI connector analog feature is the preferred connector for monitors with analog interfaces.

GRPH–0166. Primary graphics adapter works normally with default VGA mode driver

The default VGA driver is required for installing the operating system. The primary adapter must support 4-bit planar VGA mode as described in the Windows 98 DDK and the Windows 2000 DDK.

GRPH–0167. Adapter and driver support multiple adapters and multiple monitors

System expansion buses that allow graphics adapters such as PCI and AGP can support the simultaneous use of more than one graphics adapter in the system. Multiple-monitor support can be implemented using add-on PCI graphics adapters. The device drivers for each graphics adapter must provide the required support to allow the presence of multiple adapters and multiple monitors.

For more information, see "Multiple-Adapter and Multiple-Monitor Support."

GRPH–0168. Screen resolution and graphics memory capacity meet PC 2001 minimum requirements

All PC 2001 systems must support a minimum resolution of 1024 × 768 × 32 bpp, double buffered in 2-D mode with a 32-bit Z-buffer (defined as 24-bit Z with 8-bit stencil) in 3-D mode.

GRPH–0169. Adapter meets industry specifications for external display interface

Display adapters often implement more than one display interface (for example, VGA and DVI, VGA and National Television System Committee (NTSC), Dual VGA, DVI and NTSC, and so on). Each interface that is implemented must comply with the appropriate industry specifications for that interface as outlined in the following list:

  • Analog VGA. Among other resolutions and refresh rates, the graphics adapter must support the 85 hertz (Hz) ergonomic timings for all required resolutions supported by the monitor up to 1024 × 768. These timings must conform to the Computer Display Monitor Timing Specifications, Version 1, Rev. 0.8, or the VESA Generalized Timing Formula (GTF), Version 1.1. Any higher timings and resolutions must conform to established industry standards. Additionally, in order to provide optimal support for video playback of NTSC broadcasts, the display adapter must support the NTSC (59.94 Hz) refresh rate to assure smooth frame delivery in TV-based video content applications. Phase Alternation Line (PAL) is important in many regions, but there are no specific PC 2001 requirements.
  • Digital Visual Interface (both digital and analog implementations). Devices using DVI must implement the timings as specified in the Digital Visual Interface (DVI), Revision 1.0 specification, provided by the Digital Display Working Group. Support for 85 Hz refresh at specified resolutions is also required to support analog monitors with digital interfaces. VGA Mode 3 typically requires a 70 Hz refresh rate, which is not compatible with liquid crystal displays (LCDs). DVI graphics adapters must support the ability to convert VGA Mode 3 70 Hz outputs to the VESA-equivalent 60 Hz timing standards for these displays. Additionally, in order to provide optimal support for video playback of NTSC broadcasts, the display adapter must support the NTSC refresh rate. PAL is important in many regions, but there are no specific PC 2001 requirements.

Single-chip, multihead devices that support independent displays with different images on each display must be able to meet this requirement on both displays simultaneously and independently unless one of the images is a DVD or MPEG-2 video stream—for example, 85 Hz on the PC monitor while displaying NTSC TV out or DVI at a minimum of 1024 × 768 at 32 bpp. This requirement does not imply that TV out support requires simultaneous VGA or DVI support (see GRPH–0207, "If support for TV or DVD-Video playback is implemented, hardware supports video overlay surface with scaling"), but if such simultaneous support exists, this independence requirement must be met.

Support for interlaced display modes is not required. However, if interlaced modes are implemented and the user selects 1024 × 768 resolution, the graphics adapter must default to a noninterlaced refresh rate with the following exceptions:

  • The attached monitor is not compatible with Display Data Channel (DDC) and the user has not selected a monitor type in the display control panel.
  • The monitor does not support 1024 × 768 noninterlaced mode, as determined from the Extended Display Identification Data (EDID) or monitor registry settings.
GRPH–0170. All supported color depths are enumerated

The driver must enumerate all modes supported so that applications can choose their preferred color depth. The driver must comply with the following guidelines for enumeration:

  • For 16 bpp, the 5:5:5 mode, the 5:6:5 mode, or both must be supported.
  • If only the 5:5:5 mode is supported, the driver must also enumerate this as 16-bpp mode. This is required because some applications only look for 16-bpp support and will run in 8-bit mode if they fail to find a 16-bit mode.
  • If both 5:5:5 and 5:6:5 modes are supported, both modes must be enumerated.

For each color depth supported, color ordering must be implemented as shown in the following list. Color ordering is shown in the following list from the most significant bit (MSB) to the least significant bit (LSB).

Mode | Color ordering
15 bpp | 1 undefined, 5 red, 5 green, 5 blue (URRR RRGG GGGB BBBB)
16 bpp | 5 red, 6 green, 5 blue (RRRR RGGG GGGB BBBB)
24 bpp | 8 red, 8 green, 8 blue (RRRR RRRR GGGG GGGG BBBB BBBB)
32 bpp | 8 alpha, 8 red, 8 green, 8 blue (AAAA AAAA RRRR RRRR GGGG GGGG BBBB BBBB)

GRPH–0171. Graphics operations use relocatable registers only

VGA registers must not be used to perform graphics operations such as bit block transferring (blting), palette setting, and pointer movement. The registers used for these graphics operations can be either I/O locations or memory-mapped locations, but must be relocatable. Normal system operation never requires the use of base VGA registers, except for system start-up and mode setting.

GRPH–0178. Adapter supports adjustable gamma correction

ICM uses this capability to perform gamma correction for the attached monitor and to allow game applications to switch palettes. This capability also supports transition effects in applications. To provide support for ICM, the graphics adapter gamma must be programmatically adjustable. It is required that downloadable RAM digital-to-analog converter entries be included to perform gamma correction in hardware at 24 bpp or 32 bpp.

This capability must be supported without requiring the use of any VGA resources as defined in GRPH–0171, "Graphics operations use relocatable registers only."

GRPH–0179. Adapter for external display supports Plug and Play monitor detection

The adapter must support the DDC2B host requirements identified in the VESA Enhanced Extended Display Data Channel Standard (E-DDC), Version 1, which defines the communication channel between the display and host system. The software can use this information to properly manage output to the various displays and to prevent the disabling of television output if no monitor is attached. Devices capable of multihead display must support this feature for all attached monitors.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Multiple-Adapter and Multiple-Monitor Support

This section defines the requirements for multiple-adapter and multiple-monitor support. If a user then adds a second adapter, resources will automatically be available and the operating system can automatically manage multiple display adapters.

Examples of multiple display adapters include:

  • Multiple adapters added to the PC system.
  • A single adapter with a single graphics chip supporting two monitors (single-chip multihead).
  • A single adapter with multiple graphics chips supporting multiple monitors (multihead).
  • Any combination of these scenarios.

Multimonitor support requires multiple-adapter and multiple-monitor compatibility in the BIOS, the graphics adapter, and its driver. This support also allows the system to enable any secondary graphics adapters in VGA mode, thus temporarily disabling that VGA for the previous adapter. For systems with the graphics chip on the system board, see GRPH–0199, "Onboard graphics device can be used as a system boot device." For systems with integrated graphics devices that support AGP slot upgrade capability, see GRPH–0202, "System-board graphics device is not hidden from Plug and play enumeration."

With this support, a single adapter that supports multiple monitors can display independent screen images. The operating system support therefore also assumes that the different displays might have differing X, Y coordinates, resolutions, color depths, refresh rates, and display capabilities.

For technical details about implementing driver support for multiple adapters and multiple monitors, see the Windows 98 DDK and the Windows 2000 DDK.

For additional information about relocatable registers, see GRPH–0171, "Graphics operations use relocatable registers only."

GRPH–0180. Extended resources can be dynamically relocated after system boot

To support Plug and Play for multiple-adapter and multiple-monitor capabilities, all non-VGA standard display resources must be capable of being dynamically relocated after system boot (after POST). Register sets are examples of non-VGA standard display resources, which are also known as extended resources.

GRPH–0181. VGA resources can be disabled by software

A means must be provided to allow a driver to disable its adapter from decoding standard VGA addresses so that the adapter is independent of all other graphics adapters in the system. The adapter must remain fully functional without the VGA addresses.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Hardware Acceleration for 2-D Graphics

This section summarizes requirements related to 2-D graphics features, which can be implemented as hardware acceleration features.

All PC 2001 systems require hardware acceleration for 2-D graphics. Robust DirectDraw support is also required to allow 3-D hardware accelerators to take full advantage of the DirectX architecture.

GRPH–0182. Frame buffer can be accessed asynchronously by the CPU and graphics accelerator

It must be possible for applications to perform direct frame buffer accesses at any time, even while asynchronous accelerator operations are being executed.

GRPH–0183. Hardware supports transparent blter

There is no restriction on source size. A transparent blter can perform a block transfer (blt) with a source key transparent color. This requirement assumes that the blter is asynchronous with the host processor.

GRPH–0184. Hardware provides support to prevent tearing

The hardware must support a mechanism for preventing visible artifacts such as tearing. The mechanism for doing this is at the discretion of the hardware designer, but it must support tear-free capabilities for both full-screen and nonoccluded windowed applications. Only one of two simultaneous displays of the same image on two displays (for example, internal mobile panel and external VGA monitor attached) must meet this requirement. The mechanism to prevent tearing must be performed in synchronization with the vertical blanking interval (VBI).

Except when explicitly requested to do otherwise by an application (via Microsoft DirectDraw), blts must synchronize with the vertical scan line to avoid tearing. The ability to read the current scan line supports blting or writing to the screen without tearing. In some contexts, such as video playback, this support eliminates the need for the secondary overlay buffer. Other exceptions to this requirement may be allowed and are documented in the Windows 2000 DDK.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Hardware Acceleration for 3-D Graphics

This section summarizes requirements related to Microsoft Direct3D technologies that can be implemented as hardware acceleration features. Supporting the items in this section results in improved performance and improved memory use.

GRPH–0185. Hardware supports RGB rasterization

In red-green-blue (RGB) mode under Microsoft Direct3D, shading across a surface is accomplished by independently interpolating all color components. The following capabilities are required for RGB rasterization:

  • GRPH–0185.1. Textures. These include the following:
  • MIP–mapped textures
  • Bilinear, or better filtered textures, rather than point-sampled, with perspective correction
  • GRPH–0185.2. Alpha blending for 3-D graphics. Support for source alpha blending (that is, the blend operation does not require an alpha channel in the render target) and destination alpha blending (that is, the blend operation requires an alpha channel in the render target) is required for all devices. The following table shows the blend modes that must be supported as source and destination factors for alpha blending. All modes must be available in any combination and without dependency on other modes.

Alpha Blending Modes

Blend Mode | Source Factor | Destination Factor
D3DBLEND_BOTHINVSRCALPHA | Required |
D3DBLEND_BOTHSRCALPHA | Required |
D3DBLEND_DESTALPHA | Required | Required
D3DBLEND_DESTCOLOR | Required |
D3DBLEND_INVDESTALPHA | Required | Required
D3DBLEND_INVDESTCOLOR | Required |
D3DBLEND_INVSRCALPHA | Required | Required
D3DBLEND_INVSRCCOLOR |  | Required
D3DBLEND_ONE | Required | Required
D3DBLEND_SRCALPHA | Required | Required
D3DBLEND_SRCALPHASAT | Required |
D3DBLEND_SRCCOLOR |  | Required
D3DBLEND_ZERO | Required | Required

  • GRPH–0185.3. Lighting and fogging. These requirements include the following:
  • Flat and Gouraud shading (that is, constant and linear interpolation of per-vertex diffuse and specular color attributes). The linear interpolation need not be perspective-correct.
  • Specular highlighting through the addition of an RGB specular color, interpolated from per-vertex specular color attributes. The linear interpolation need not be perspective-correct.
  • Fog effects through blending with an arbitrary RGB fog color. The fog blending term is computed on a per-pixel rather than per-vertex basis, and is range-based (range-based fog) or depth-based (pixel fog). See Windows 98 DDK and Windows 2000 DDK for definition and discussion of range-based fog and pixel fog.
  • Driver support for triangle strips and fans.

The Direct3D reference rasterizer provided in DirectX supports all of these capabilities.

GRPH–0186. Hardware supports multitexturing

Multitexturing hardware can apply multiple textures to a polygon. The most common application of multitexturing is with map-based techniques for diffuse lighting and specular reflections.

Implementing this capability requires supporting two or more sets of independent texture coordinates.

The following texture combination operations are required:

  • MODULATERGB: Component-wise multiplication of both texture colors.
  • MODULATELPHA: Multiply colors of one texture by the alpha of the other.
  • ADD: Component-wise addition of both textures.
  • BLEND: Linear combination of textures weighted by a scalar specified in a register or in a polygon alpha.

Multitexturing is used to compute the texture value that participates in the pixel pipeline implemented in Direct3D.

This technique must work in combination with fogging and alpha blending, but is not required to operate at the same time as other advanced filtering. Multipass multitexturing is acceptable; single-pass multitexturing is preferred.

For more information on Windows display and video support, see the Display Technology Web page, listed in "Graphics Adapters References."

GRPH–0187. Hardware supports texture formats

Hardware that implements 3D acceleration must support the following 2D, color texture formats:

  • 16 bpp nonpalletized 1:5:5:5 ARGB
  • 16 bpp nonpalletized 4:4:4:4 ARGB
  • 32 bpp nonpalletized 8:8:8:8 ARGB
GRPH–0188. Hardware complies with texture size limitations

MIP mapping requires that textures of size 1 × 1 be supported. To meet PC 2001 requirements, a 3-D accelerator must support this lower limit on texture size. The texture units must support square and nonsquare power-of-two textures (2n × 2m) up to 1024 × 1024 for all texture operations.

GRPH–0189. Hardware supports Z comparison modes and Direct3D-compatible formats

The 3-D hardware must support 32-bit (24-bit Z and 8-bit stencil), unsigned, lockable Z buffer format and all Z comparison modes.

Hardware that supports Z buffering must support clearing of the Z buffer through the DirectDraw depth-fill blt mechanism. In addition, hardware must support clearing of color, Z buffers, and destination surfaces using this method as well.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Television Output Requirements

This section summarizes requirements for television output capabilities. The requirements in this section apply only if the television output capability is present on a PC 2001 system or on a graphics adapter that supports television output capabilities.

The required support allows an NTSC or PAL television to be used as a primary display surface for the Microsoft Windows family of operating systems and for Windows-based applications. If television output capabilities are provided in a PC 2001 system, support is required for either NTSC or PAL standards.

GRPH–0190. If TV out is implemented, adapter supports overscan/underscan scaling

The television output adapter must be able to correct horizontal and vertical overscan/underscan using hardware scaling. Software must be able to disable and enable this feature.

Mobile PC Note

This requirement does not apply to mobile PC platforms.

GRPH–0191. If TV out is implemented, software supports positioning

Software must be able to program the television output hardware to position the television image in increments of 4 pixels horizontally and 4 scan lines vertically (or finer). The supported range must be at least +/– 40 pixels horizontal and
+/– 20 scan lines vertical.

Mobile PC Note

This requirement does not apply to mobile PC platforms.

GRPH–0192. If TV out is implemented, adapter supports flicker filter

The television output adapter must use multiline (three-tap minimum) hardware filtering techniques for flicker reduction. Enable, disable, and adjust capabilities for the flicker filter must be software controllable.

The TV out capability must be able to accept up to a 1024 × 768 progressive desktop and convert it to an interlaced TV resolution output signal.

GRPH–0193. If TV out is implemented, adapter supports composite video or S-video connectors

Support for composite video or S-video is required.

A dongle with a composite video connector meets this requirement if the dongle ships as part of the TV out implementation.

GRPH–0194. If TV out is implemented, adapter also supports DVI or VGA and television output

A graphics adapter that supports TV out must also support either DVI or VGA or both. This requirement does not apply to systems with integrated displays. The usefulness of a system is greatly enhanced when any combination of outputs can be active concurrently, but concurrent output support is not required.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Plug and Play Requirements for Graphics Adapters

This section summarizes requirements for Plug and Play and other resource- and bus-related capabilities.

GRPH–0195. Display devices do not use VGA BIOS POST to populate PCI SID

System-board and add-on display devices cannot use the VGA BIOS POST routine to populate the SID because the device’s POST code might not be executed until later in the process, after device enumeration occurs. For system-board devices, the system BIOS must populate the SID at power on. Add-on display adapters must provide a method for populating the SID at the point when power is applied and the device is initialized to the state that is ready for POST.

GRPH–0196. System supports conflict resolution, VGA compatibility, and extended registers

When the end user changes or adds a graphics adapter to the system, setting resource assignments must not require changing jumpers or switches on either the card or the system board. The system must be able to automatically relocate the resources used by a graphics adapter on the system board when a graphics adapter expansion card is added to the system. In the event of an irreconcilable conflict with other devices on the system, the system must be able to disable one of the adapters in order to prevent the system from stalling.

The system must support the VGA graphics standard for application compatibility and Windows setup and error-recovery process. If a VGA BIOS exists on the graphics adapter, it must be able to configure its base address to C0000h and one alternate address, at a minimum, to prevent conflicts.

Extended resources are additional I/O ports, direct-access frame buffers, or data transfer areas on a graphics adapter that use more resources than does standard VGA. The Windows configuration manager must be able to map the resources to avoid conflicts with other system devices. At least one alternate configuration must be provided for each non-VGA display resource in the event of conflict during the IPL boot.

The software drivers and VGA BIOS (if used) must be able to use alternate configuration register addresses. The system must be able to dynamically disable or relocate VGA resources from C0000h. It must also be possible to re-enable these resources upon system reboot or reset.

For additional related requirements for multiple-monitor support, see "Multiple-Adapter and Multiple-Monitor Support."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


BIOS and Option ROM Requirements for Graphics Adapters

This section provides requirements related to BIOS support for graphics adapters.

GRPH–0197. Chips support linear packed-pixel frame buffer, relocatable above 16 MB

Note: For DirectDraw, the graphics adapter’s chip set must support linear access to the frame buffer by the host.

For optimized support with Windows, a linear packed-pixel frame buffer is required over a bank-switched frame buffer. Use 32-bit addresses to allow the linear frame buffer to be placed above the 16-MB ISA boundary, which enables a system to be populated with large amounts of RAM.

If memory or other resources conflict with the frame buffer being mapped into a linear address space, the page frame address can be used with minimal degradation of performance.

GRPH–0198. Option ROM supports DDC2B

The option ROM for the graphics adapter must meet current DDC2B host requirements documented in VESA Display Data Channel (DDC) Standard, Version 3, Level 2B protocol (DDC2B). This standard defines the functions that support the data channel between the graphics adapter and a DDC monitor.

GRPH–0199. Onboard graphics device can be used as a system boot device

Systems that have the graphics chip on the system board, and mobile PCs that are capable of docking in a docking station with PCI slots, must provide a means in the BIOS setup utility to force the system to boot using the onboard graphics device, even when an add-in graphics adapter is installed. This capability is required so the onboard graphics device can be used in a multiple-monitor configuration and for hot undock of a docked mobile system.

For systems with integrated graphics devices that support AGP slot upgrade capability, it is acceptable for the integrated graphics to be disabled automatically. When an add-on card is installed in the AGP slot, integrated devices must support multimonitor.

GRPH–0200. System BIOS supports large frame buffers for graphics adapters

The system BIOS must support large frame-buffer graphics adapters that have up to 256 MB of frame buffers.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Requirements for AGP and PCI Graphics Adapters

This section provides requirements for graphics adapters that use the PCI bus.

GRPH–0201. Graphics device supports IRQ and correctly populates PCI BARs

Proper IRQ support is needed for optimal support of video playback. The display driver queries the actual device to find its register locations and so on. The PCI BARs must be populated correctly for this information to be correct in the registry.

On adapters that do not support an IRQ, the Interrupt Pin Register (3Dh) must be zero (0).

GRPH–0202. System-board graphics device is not hidden from Plug and Play enumeration

The system-board device must disable the PCI device rather than hiding it. Hiding the system-board graphics adapter from the PCI bus when another graphics adapter is detected in the system causes problems for supporting multiple-monitor capabilities.

For systems with integrated graphics devices that support AGP slot upgrade capability, it is acceptable for the integrated graphics to be disabled automatically. When an add-on card is installed in the AGP slot, integrated devices must support multimonitor.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Power Management for Graphics Adapters

This section summarizes the specific power management requirements for graphics adapters.

GRPH–0203. Graphics adapter complies with device class power management reference specification

The Default Device Class Power Management Reference Specification, Version 1.0, provides definitions of the OnNow device power states
(D0–D3) for display and graphics devices. The specification also covers device functionality expected in each power state and the possible wakeup event definitions for the class, if any.

GRPH–0204. Graphics adapter complies with VBE/Core 2.0 extensions for power management

The VESA BIOS Extension Standard/Core Functions 2.0 (VBE/Core 2.0) specification defines extensions to VGA ROM BIOS services for power management.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Device Drivers and Installation for Graphics Adapters and Video Devices

This section summarizes the requirements for graphics adapters. The requirements in this section are required for all PC 2001 devices.

For additional driver-related requirements for multiple-monitor support, see "Multiple-Adapter and Multiple-Monitor Support."

GRPH–0205. Driver does not bypass any Microsoft-provided system components

The driver must not bypass or patch any Microsoft-provided system components. For Windows, this includes Gdi.exe, Kernel.exe, User.exe, Dibeng.dll, Mmsystem.dll, Ddraw.dll, D3d*.dll, and so on.

For Windows 2000, this requirement applies for all files normally installed in the System32 directory. These files include, but are not limited to, Win32k.sys, Ntoskrnl.exe, Gdi32.dll, User32.dll, and Mcdsrv32.dll.

GRPH–0206. Driver supports dynamic color depth and resolution change

The graphics adapter must operate properly and must not fail when asked by the operating system to change the color depth or resolution. A restart must not be required to accomplish this.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Graphics Subsystem Support for Video

This section presents requirements for the graphics subsystem to support TV or DVD-Video playback.

GRPH-0207. If support for TV or DVD-Video playback is implemented, hardware supports video overlay surface with scaling

It is envisioned that the overlay surface will be implemented using one of the required YUV formats. The graphics adapter must be able to support a minimum of one off-screen video overlay surface that has following characteristics:

  • GRPH–0207.1. Size. Discrete graphics solutions support 1280 × 720 or larger. Mobile platforms and integrated graphics solutions support 720 × 576 or larger.
  • GRPH–0207.2. Screen Resolutions. The video overlay must be fully operative at 640 × 480 and 1024 × 768 and color depths of 16 bpp and 32 bpp.

Mobile PC Note

Mobile platforms must support video overlay up to their native resolution and color depth.

  • GRPH–0207.3. Color formats. The required formats must include the following:
  • YUV 4:2:2 (YUY2): A packed-pixel byte stream for every pixel in the order of Y1, U, Y2, V is required in all overlay surface buffers. No intra-image padding is allowed.

YUV 4:2:0 (YV12): A system-board byte stream for the entire plane in the order of Y plane, V plane, U plane is required in the final overlay surface buffer when double buffering is supported.

  • If double buffering is not supported, YV12 support must be provided in the overlay surface.

Support for the YUV 4:2:0 format is not a requirement if the graphics chip supports on-chip MPEG decoding.

  • GRPH–0207.4. Scaling. When upscaling and downscaling to any size window, the high quality video scaling can occur anywhere between the video input to the chip, on the AGP, PCI, or side port and the video appearing on the screen.

Video scaling must be implemented using the DirectDraw and Microsoft DirectShow® APIs.

For PCs to effectively compete with dedicated consumer electronics video devices, it is necessary to raise the quality of video scaling on the PC. Specifying scaling quality is hard because of the difficulty of quantifying viewer-perceived video quality. These requirements for the quality of the video filter used in the resizing operations are specified:

  • Use bilinear scaling or better; a filter with a minimum of two vertical taps and a minimum of two horizontal taps is required.
  • Video display must be able to shrink or zoom by a variable factor of up to 8:1 in one-pixel increments.
  • The image quality must not be perceptibly degraded when shrinking by factors up to 2:1. Some image degradation is acceptable for the larger shrink ratios.
  • The scaling engine on a PC that is not enabled for digital television (DTV) must be able to accept a standard definition video input (480i or 576i), such as input that might come from a DVD or NTSC source.

For a DTV-enabled PC, the scaling engine must be able to accept an input with a rate of 720p60 (1280 horizontal pixels) and 540p60 (bobbed from 1080i) (1280 horizontal pixels).

For video sources that horizontally exceed 720 pixels, the hardware can upscale vertically using replication and downscale vertically using decimation. For such video sources, playback quality reductions may result as defined in Chapter 9, "Video."

Note: The exception for video sources that horizontally exceed 720 pixels will be removed in a later version of this design guide.

  • Upscaling and downscaling can be done in hardware and software; however, if a part-software solution is implemented, performance must not be degraded. All video requirements in Chapter 9, "Video," that pertain to video quality and CPU utilization apply independent of scaling ratios.

Scaling 4:2:2 or 4:2:0 YUV video must achieve two-pixel granularity.

GRPH–0208. If support for TV or DVD-Video playback is implemented, colorspace conversion can be configured for different color primary standards

Support is required for the ITU-R [BT.601-5] standard, formerly CCIR 601.

GRPH–0395. Hardware supports color keying for video

This is a requirement for video overlays. The hardware must be capable of independently controlling the pixels for compositing the video plane under the graphics plane. This destination color keying must function in all video modes using either or both of the following:

  • A specific color/color range, for example, on 4-bit, 8-bit, 15-bit modes.
  • Additional alpha blending bits in the color plane bits on 16-bit and 32-bit modes.

Color keying allows certain graphics pixels to replace underlying video pixels on a pixel-by-pixel basis. This feature enables video overlays, controls, Windows pop-up menus, dialog boxes, and so on, and it allows for irregular-shaped graphics compositing. Color keying must work simultaneously with any vertical/horizontal scaling active for the underlying video.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Mobile PC Graphics Design

This section defines the specific graphics capabilities for mobile PC 2001 systems.

GRPH–0393. Mobile system meets mobile PC 2001 basic graphics requirements

The basic graphics requirements for mobile PC systems provide support for operating system startup and for running mainstream applications reliably. Additional features must meet additional requirements only on an "if implemented" basis, as defined in the following list.

  • GRPH–0393.1. Mobile system supports display resolution of at least 640 × 480 with 256 colors. Windows requires a display resolution of at least 640 × 480 with 256 colors (8 bpp using a color look-up table) to run properly. Mobile systems that optionally have 3-D support must implement at least 16 bpp color.
  • GRPH–0393.2. Mobile PC system uses PCI or better interconnect. Mobile systems that support 3-D require the performance equivalent of AGP. AGP implementations must support Graphics Address Remapping Table (GART) at a minimum. AGP equivalent implementations must support GART equivalent functionality. PCI implementations are not required to support GART.
  • GRPH–0393.3. Optional 3-D capabilities meet minimum requirements. For mobile systems, 3-D hardware is optional. If 3-D is supported, the mobile PC must meet all 3-D requirements at all supported resolutions up to and including the native display panel resolution of at least 640 × 480, and it must support a color depth of 16 bpp, with the following exceptions:
  • Support of per-pixel fog is not required; however, support of per-vertex fog is required.
  • Support of range-based or table-based fog is not required.
  • Support of 32-bit textures is not required; however, support of 16-bit textures is required.
  • Support of 32-bit Z buffers is not required; however, support of 16-bit Z buffers is required.
  • Support of Stencil buffers is not required.
  • Support of 32 bpp (ARGB 8:8:8:8) is not required.
  • Support of nonsquare power-of-two textures up to 1024(1024 for all textures operations is not required.
  • Support for square, power-of-two textures of sizes up to and including 256(256 is required.
  • GRPH–0393.4. Mobile PC resolution requirements. Resolution and color depth requirements are limited to the capabilities of the integrated display panel when using an integrated panel or a simultaneous external display. Mobile systems that implement a single-chip, multihead configuration must meet the resolution and color depth requirements on the external display only up to the native resolution and color depth of the integrated display panel. Mobile PC systems that provide 3-D hardware acceleration must support a color depth of 16 bpp.
  • GRPH–0393.5. Mobile PC refresh frequency requirements. Mobile systems must support refresh frequencies only up to the native capabilities of the integrated display panel. A mobile system that implements a single-chip, multihead, multimonitor configuration must meet the refresh frequency requirements on the external display only up to the native capabilities of the integrated display panel.
  • GRPH–0393.6. Mobile PC requirements for Plug and Play support for external displays. Mobile PC systems that support external displays must support DDC detection for external displays, as defined in GRPH–0179, "Adapter for external display supports Plug and Play monitor detection," with the following exceptions:
  • Mobile systems do not have to supply +5V to the VGA connector at any time.
  • The DVI connector must supply +5V only during operating system boot, when the user first enables external video, and when the system is actually outputting analog or digital video through the DVI connector.
  • Mobile systems that implement a single-chip, multihead, multimonitor configuration are not required to display the system boot screen on the external display. In this configuration, the expectation is that the external display will be active when the display driver is enabled and the system is configured for multimonitor operation. If the system is configured for operation with only the external display active, the boot screen must be displayed.
  • GRPH–0393.7. Mobile PC multiple-monitor requirements. For mobile PCs, multiple adapter support as described in GRPH–0167, "Adapter and driver support multiple adapters and multiple monitors," is not required unless the system supports single-chip, multihead, multiple-monitor capabilities, or the mobile PC supports a docking station with PCI expansion slots. If the docked mobile PC supports only Mini-PCI, the system is not required to support multiple-monitor requirements.
  • GRPH–0393.8. Mobile BIOS setup utility can force use of system-board graphics. If the mobile system supports docking stations that allow for an additional display adapter (typically via a PCI slot), the manufacturer must provide an option in the system BIOS setup utility to force the system-board graphics device to be used as the boot device. This option always allows a docked mobile system to undock because the VGA device will be in the mobile unit.

See also MON–0235, "Monitor supports sRGB output or an ICC profile is provided," in Chapter 10, which applies for mobile PC flat-panel displays.

GRPH–0394. All mobile systems meet basic interoperability requirements

All mobile systems must meet basic graphics requirements to reliably run Windows and applications. Specifically, the following requirements must be met.

  • GRPH–0166. Primary graphics adapter works normally with default VGA mode driver
  • GRPH–0169. Adapter meets industry specifications for external display interfaces
  • GRPH–0170. All supported color depths are enumerated
  • GRPH–0171. Graphics operations use relocatable registers only
  • GRPH–0178. Adapter supports adjustable gamma correction
  • GRPH–0179. Adapter for external display supports Plug and Play monitor detection
  • GRPH–0180. Extended resources can be dynamically relocated after boot
  • GRPH–0181. VGA resources can be disabled by software. This requirement needs to be met by mobile systems only if multiheaded, multidisplay support exists.
  • GRPH–0182. Frame buffer can be accessed directly by applications
  • GRPH–0183. Hardware supports transparent blter
  • GRPH–0195. Display devices do not use VGA BIOS POST to populate PCI Subsystem ID
  • GRPH–0196. System supports conflict resolution, VGA compatibility, and extended registers
  • GRPH–0197. Chips support linear packed-pixel frame buffer, relocatable above 16 MB
  • GRPH–0198. Option ROM supports DDC2B. For external displays only
  • GRPH–0200. BIOS supports large frame buffers for graphics adapters. For adapters added through docking-station or as PC-card only.
  • GRPH–0203. Graphics adapter complies with device class power management reference specification
  • GRPH–0204. Graphics adapter complies with VBE/Core 2.0 extensions for power management
  • GRPH–0205. Driver does not bypass any Microsoft-provided system components
  • GRPH–0206. Driver supports dynamic color depth and resolution changes

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Baseline Video Features

This section describes basic video features required for all desktop systems.

Mobile PC Note

Mobile PCs must meet these requirements, with the exceptions noted in the mobile section.

Baseline Video Driver Support

This section describes video driver support.

VID–0209. System supports basic video capabilities

For all PC 2001 systems, all graphics and video capabilities must be fully supported at 1024 × 768, 32 bpp mode or better.

VID–0210. Video input, capture, and broadcast device support is based on DirectX foundation class and WDM Stream class or AV Stream class

The driver for any video or tuner/decoder device must use the Microsoft DirectX foundation class to control all video data. In a PC 2001 system, video input devices must use WDM device drivers. For implementation requirements, see the Windows 2000 DDK, listed in "Video References."

If implemented, the MPEG-2 decoder must support the current DirectShow APIs (including DirectX VA) and must support the WDM Stream class driver architecture. The WDM Stream Class or AV Stream Class must be used to support any data streaming. For information, see the DirectX DDK, the Windows Driver Model (WDM) Technology Web page, and the Windows 2000 DDK, listed in "Video References."

VID–0211. All video implementations use DirectShow for video routing and processing

Use the DirectShow environment for all TV or DVD-Video implementations. Typical applications include Transport Stream demultiplexing as well as general MPEG stream routing. Implement drivers using WDM.

While it is not a requirement to use the DirectShow filters provided with the operating system, alternatives must be fully pin compatible (that is, media-type compatible) with the filter APIs provided with the operating system. This will help ensure third-party software application compatibility. For information, see Microsoft DirectShow, listed in "Video References."

VID–0212. Dependent video device is not independently enumerated

If a video device is implemented as a dependent device on a multifunction adapter, it must not be independently enumerated. Instead, its parent must be responsible for installing and loading its driver and for updating the registry on its behalf. See also SYS–0032, "Multifunction device meets PC 2001 device requirements for each device," in Chapter 3.

VID–0213. If non-Microsoft provided DirectShow filters replace any filters included with the operating system, replacements provide a functional and qualitative superset of the replaced modules

Any replacement DirectShow filter must be able to accept the exact same input and output formats provided by the operating system version of the DirectShow filter.

VID–0215. All video implementations meet basic video quality requirements

This requirement defines how to treat, as a whole or by components, all consumer electronics (CE) high quality TV-style video streams. Video implementation must preserve source quality during playback, storage, or processing of the video streams and not adversely affect overall PC performance.

Note: The following solutions are exceptions to this requirement: solutions serviced by nonisochronous video sources (Internet) and solutions that have inherent quality tradeoffs (conferencing cameras, dongles that convert TV-style video into conferencing-style video or still video). Video functions for monitoring purposes only and not for recreational viewing, such as monitor video windows (outputs) of video editing solutions, are also exempt.

Examples of CE quality video sources are NTSC at 720 × 480 × 29.97 frames per second (fps) and PAL at 720 × 576 × 25 fps, both at MPEG 4:2:2. These resolution and frame rates are the standard definition. Other resolution and frame rate combinations may be subject to the same requirements, depending on the source, but only if the source resolution does not exceed the overall pixel rate of the above example (approximately 10.5 megapixels per second).

Video sources with higher pixel rates may cause system performance to degrade. Either dropped frames or reduced image quality, or a combination of both, become acceptable in that case. In the case of time-shifted playback, a slight relaxation is also acceptable. Combined reduction in image quality and frame rate should be commensurate with the excess in input data rate. For example, if the input data rate exceeds the standard definition pixel rate by a factor of four, acceptable performance could allow dropping half of all frames and image quality that is equivalent to having been high-quality scaled by a factor of two horizontally.

Notice that deinterlacing results in twice the display data rate when compared to the source data rate. However, de-interlacing by itself must never be the cause for frame rate or image quality reduction. Only increases in source resolution beyond this standard definition produce a relaxing of the video quality requirements. The requirements include the following.

  • VID–0215.1. TV-style video source frame and field rates must be preserved to memory and to the display. While in steady-state mode, dropped frames may not exceed one per minute.
  • VID–0215.2. TV-style video source resolution must be preserved to memory and to the display.
  • VID–0215.3. TV-style video source quality must be preserved to memory and display. Image entropy consistent with approximately 400 TV lines of vertical resolution must be preserved.
  • VID–0215.4. TV-style video source color information must be preserved to memory and to the display.
  • VID–0215.5. TV-style video source video aspect ratios are preserved and displayed correctly.
  • VID–0215.6. TV-style MPEG-2 video stream playback consumes no more than an additional 45 percent of CPU measured during any given minute.
  • VID–0215.7. TV-style MPEG-2 video stream playback consumes no more than an additional 45 percent of memory, PCI, or AGP bandwidth during any given minute.

Mobile PC Note

Mobile PCs are not required to meet this subrequirement.

  • VID–0215.8. TV-style video stream playback is audio-video synchronized to within 75 ms. Audio-video synchronization drift is corrected without violating the specifics of the frame rate and field rate requirements.
  • VID–0215.9. Video is made available through input or transform filters in the YUY2 color format while maintaining all other baseline video requirements.
  • VID–0215.10. Displayed video that enters the system interlaced but carrying a tag that identifies how the video fields were derived from a progressive source will be deinterlaced using the weave method. Typically, deinterlacing is performed by the graphics subsystem.

This requirement applies only to properly encoded content.

  • VID–0215.11. Displayed video that enters the system interlaced but carries a tag identifying the video source as 24 fps film will be (in combination with weave deinterlacing) played back using a suitable frame rate increasing process such as 3:2 pulldown or better. Typically, deinterlacing is performed by the graphics subsystem.
  • VID–0215.12. Displayed video that enters the system interlaced and carries either no identifying tag or is tagged as interlaced material should be deinterlaced by the graphics subsystem using the bob method or a method superior to the bob method. Deinterlacing also may take place outside of the graphics subsystem.
  • VID–0215.13. When video is displayed on a monitor that is refreshed at a different rate than the field rates and frame rates of the video stream, a consistent frame repeat pattern must be implemented that in itself causes no frames to be dropped.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


MPEG-2 Video Playback Requirements

This section presents MPEG-2 playback requirements.

VID–0216. If implemented, all MPEG-2 decoders can accept an MPEG-2 elementary stream

DirectShow provides the selection and demultiplexing of MPEG transport streams and program streams. Stream filtering in hardware can be used to aid this process. DirectShow feeds the appropriate video stream, such as Elementary Stream, to the MPEG decoder. The decoder must be able to take MPEG in that form. Packetized Elementary Stream (PES) format support is also required without reliance on any packet sequence numbering. Decoders must not rely on packet sequence numbering to support applications where packet sequence numbers cannot be created. For example, audio and video might come from separate sources, such as video from disc being synchronized to audio from the Internet.

VID–0217. If implemented, all MPEG transport stream information is available to the central host processor

Video-quality standards must be maintained when streams are being routed via the host processor. MPEG streams can come from a number of sources. DirectShow provides support for selecting the required MPEG streams, demultiplexing them, and feeding them to the appropriate decoder or subsystem. Stream filtering in hardware can be used to aid this process.

When conditional access systems allow it, the transport stream demultiplexing must be performed by the central host processor. In situations where this is not possible, all streams from the original broadcast must be sent to the processor if the processor requests them.

It is not acceptable to implement an "around-the-side" hardware path from the receiver to the MPEG decoder. All digital compressed video streams must be routed using the central host software; this will also make it easier to migrate to video-capable home network environment, where the receiver functions and display functions will typically be in completely separate boxes. It is also necessary for features such as intelligent TV timeshifting.

VID–0340. If implemented, MPEG decoders with motion compensation or Inverse DCT hardware acceleration use the Microsoft-provided DirectX VA API

The required DirectX VA API is documented in the DirectX 8.0 DDK or SDK, listed in "Video References."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


DVD-Video Playback Requirements

The following requirements apply for systems that provide DVD-Video playback software and hardware. However, shipping of a DVD drive with the system does not imply that a system needs to pass DVD Video Playback requirements, since a system with a DVD drive is not required to include an MPEG decoder. The goal for DVD and other audio/video (A/V) playback is to ensure that the end-user experience is the same as or better than with a stand-alone DVD player.

VID–0218. If DVD-Video playback is implemented, DVD decoder driver correctly handles media types, time discontinuity, and decode-rate adjustment

Vendor-supplied minidrivers for DVD, MPEG-2, and AC-3 decoders must:

  • Use the correct media types, including validation of all format block fields on connection and on every IPin::QueryAccept message.
  • Query for IMediaSample2 on every received media sample to test for a time discontinuity bit.

It is also acceptable to query on every A/V frame to reduce CPU overhead.

  • Adjust the decode rate in response to IPin::NewSegment () calls for video and subpicture.

For details about APIs, see the DirectShow documentation in the Microsoft Platform SDK, listed in "Video References."

VID–0219. If DVD-Video playback is implemented, DVD decoder supports subpicture compositing and closed captioning

The system must be capable of displaying subpicture data as well as providing closed-captioning support for all such data stored on the disc. This requires YUV offscreen overlay surface support.

Subpicture streams must be supported as defined in DVD Specification, Version 1.0, from Toshiba Corporation.

Note: Alpha blending, or a driver-implemented emulation, is required for static menus.

VID–0220. If DVD-Video playback is implemented, subpicture decoder correctly handles subpicture properties and other functions

The minidriver for the subpicture decoder must be able to:

  • Set the subpicture properties.
  • Turn the subpicture compositing on and off.
  • Set the highlight rect parameters.

For more information, see the Microsoft DirectX SDK and the DirectX information in the Windows 2000 DDK, listed in "Video References."

VID–0221. If DVD-Video playback is implemented, system supports seamless DVD-Video 1.0 navigation

This requirement includes menu navigation, video selection, and language and subpicture track selection in support of the user’s ability to navigate DVD-Video discs.

For any system capable of playing back a DVD-Video title, DVD playback must work with the latest released version of the Microsoft DirectShow Navigator/Splitter filter and other DirectShow test filters to ensure that it conforms to the input and output standards established by the Navigator/Splitter. In particular, it must work with the most recent versions of the following:

  • IdvdGraphBuilder
  • DirectShow DVD Navigator
  • DirectShow Overlay Mixer

The requirement to work with the DirectShow Navigator/Splitter filter is not intended to preclude the use of differentiating product features and enhancements.

VID–0222. If DVD-Video playback is implemented, DVD-Video player provides seamless DVD navigation

All DVD-Video players must navigate chapter breaks seamlessly. This requirement applies even if the underlying elementary streams were created as separate program chain objects. If the navigation calls for a seamless transition, the player must deliver for any legal group of pictures structure, bit rate, or both.

For PC 2001, this player requirement allows independent placement of the layer break position, without regard to chapter navigation. Classically, the layer break is acceptable only during nonseamless transitions.

Although not explicitly allowed in the formal DVD-Video specification, seamless chapter-break transitions span the layer break on some popular DVD features. Therefore, the DVD PC must be able to flawlessly reproducing seamless chapter breaks that are collocated with layer transitions, just as if the layer break weren’t there.

VID–0223. If DVD-Video playback is implemented, All DVD-Video decoders must support Line21 closed-caption data

All DVD-Video decoders must support Line21 closed-captioned data output compatible for use with the DirectShow Line21 decoder filter. In addition to ensuring closed-captioned output for the hearing impaired, it enables applications that use the Line21 channel on DVD as a data channel for non-Line21 data.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


VBI Data Delivery Requirements

VID–0224. If implemented, video input or capture device provides raw sampled VBI data to the host

The VBI data must be made available to the host processor to provide enhancement data, Web pages, and information about elements such as video formats and timecode. VBI data must not be affected by any type of video operation, such as cropping, scaling, or frame dropping, that the hardware or the driver is performing on the related video frames.

VID–0225. If implemented, VBI capture oversamples VBI data exactly 4.7 or 5 times

To ensure accurate data reception, data transmitted on all lines of the VBI must be oversampled exactly 4.7 or 5 times the North American Basic Teletext (NABTS) data bit rate (or locale-specific data bit rate). For example, if there are 288 bits of NABTS data on a scan line, approximately 1,354 one-byte samples, plus the necessary margin, must be captured per scan line if 4.7x oversampling is used. This represents the number required for timing tolerances in the NABTS specification and also for timing uncertainties within the capture hardware.

If the hardware cannot provide 4.7 or 5 times oversampled VBI data, the device-specific driver must compensate by resampling, so that 4.7 or 5 times oversampled data are presented to the operating system.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Digital TV Receiver Module Requirements

The requirements in this section apply for any system that implements a digital broadcast subsystem, whether receiving satellite, cable, or terrestrial broadcasts.

Implement receiver modules in the following form factors: Device Bay modules, PCI modules, external modules, or set-top boxes using IEEE 1394. For a receiver module limited to low bit-rate transmissions (less than 5 Mbps), using standard USB is acceptable. Device Bay is a good solution for receivers requiring conditional access systems, but conditional access systems are acceptable with any of the other receiver types.

Digital broadcast and satellite support as defined under these requirements includes all the requirements for hardware decoder capabilities and driver support as defined in this chapter, plus support for the DirectX foundation class, as defined in the Windows 2000 DDK.

VID–0226. If implemented, digital broadcast module can receive all streams contained in the particular transport stream

This receiver module can be a receiver for cable, satellite, or terrestrial, and other digital TV broadcasts. The receiver module must provide data tuning, demodulation, conditional access, and other network-specific functions.

The receiver module must be able to receive both normal broadcast network-related information, such as MPEG video, audio, and program guide information, as well as data-stream information.

The receiver card must provide a way to allow the host to obtain peak cell rate (PCR) and other transport stream fields, such as the discontinuity indicator bit, when the card is performing PES packet building. In this mode, the driver must make the relevant information available to the host. In addition, the receiver card must provide a mode in which the host can obtain full MPEG-2 transport or program stream headers, and data for selected elementary streams.

VID–0227. If implemented, digital broadcast module can receive full bandwidth from each frequency

The receiver module must be able to receive all information transmitted on any tuner or transponder frequency. If demultiplexing is performed on the receiver module, the stream selection and routing must be controlled by software running on the host processor.

VID–0228. If implemented, digital broadcast module can receive a minimum of 32 simultaneous elementary streams

The receiver module must be able to simultaneously receive on the same carrier frequency and send to the host either a transport stream or the complete set of elementary streams and accompanying data. Any receiver doing transport stream splitting, for example, a receiver that provides a proprietary conditional access scheme, must support a minimum of 32 elementary streams being sent to the host. The streams can be of any type, such as 32 simultaneous data streams. These streams, identified by unique service channel IDs or program IDs, are subdivisions of bandwidth on a single tuner frequency.

The receiver module must provide a means for the host processor to control the demultiplexing of the transport stream (containing the multiple data streams) or pass the complete transport stream to the host processor for software demultiplexing. The fundamental requirement is that the resulting MPEG elementary streams are routed by the software running on the host processor.

VID–0229. If implemented, ATSC DTV tuner/demodulator complies with A/53

If an Advanced Television Systems Committee (ATSC) DTV tuner/demodulator is implemented, it must meet the requirements for packetized data transport structure, and modulation and transmission systems as specified in ATSC Digital Television Standard and Amendment No.1 (A/53).

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Mobile PC Video Design

This section defines the specific video capabilities for mobile PC 2001 systems. These requirements apply only when the mobile system is running on alternating current (AC) power and is not thermally throttled in any way. No video playback performance requirements apply when the system is running on battery power or in a CPU or bus throttled mode. It is expected that performance—but not functionality—will be compromised when the mobile unit is operating under battery power or in a throttled mode.

MOBL–0231. Mobile system meets mobile PC 2001 basic video requirements

A mobile system is not required to support any motion video capabilities, such as playback. The basic video requirements for such mobile PC systems are defined in the following list:

  • Comply with GRPH–0205, "Driver does not bypass any Microsoft-provided system components," in Chapter 8.
  • Support all related desktop video requirements if the mobile system implements support for optional video capabilities, with the following basic mobile video requirements:

There are no CPU utilization limitations or bus bandwidth restrictions for MPEG-2 playback.

Systems must preserve source frame rates and video quality during video playback to at least 50 percent of desktop requirements.

Mobile PCs are required to support these capabilities only up to their native resolution.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Basic Monitor Requirements

This section summarizes the basic design requirements common to all monitor types. As with any device, monitors must meet all PC 2001 general device and driver requirements.

Note: Dot-pitch requirements are not specified in these requirements because dot pitch depends on resolution and size. Also, design features other than dot pitch contribute to usability for PC applications, such as focus and phosphor. Monitors must provide a sharp and clear image across the full range of resolutions they are intended to support.

MON–0232. Color monitor is E-DDC–compliant with unique EDID identifier

A monitor designed for or included with a PC 2001 system must be compliant with VESA Enhanced Extended Display Data Channel Standard (E-DDC), Version 1, Level 2B protocols (DDC2B), which defines the communications channel between the display and host system. A monitor must assume multiple I2C-compliant devices exist on the communications bus, and as such, a monitor must not impede the use of the I2C bus in any way. A monitor designed for, or included with, a PC 2001 system must not issue DDC1 transactions.

The monitor also must transmit an EDID structure containing unique ID Manufacturer Name and ID Product Code identifiers, plus all required fields, as defined in Section 3 of VESA Enhanced Extended Display Identification Data Standard (E-EDID), Release A.

Mobile PC Note

Mobile and other all-in-one systems are not required to support DDC monitor detection. Displays that are attached and connected using an internal interface are not required to provide EDID data identification. This exception applies to all DDC- and EDID-related requirements in this chapter.

MON–0233. Monitor supports EDID 1.3 data structure

All monitors must support E-EDID by implementing an EDID data structure, which includes the following:

  • Set preferred mode bit for all monitor types.
  • Include timing data for the preferred display mode in Timing #1.

For an LCD or other fixed-format display, this would be the native mode of the panel. For other display types, this is the optimal display mode, which is based on the size and capabilities of the device, and must meet the requirements for refresh rates defined in this chapter.

  • Implement monitor descriptors:
  • Monitor range limits
  • Monitor name
MON–0234. If implemented, LCD monitor or built-in LCD display contains display characterization data

LCD monitors and built-in displays must be optimized for Microsoft ClearType™ and other advanced operating system graphics features being implemented through DirectDraw, Direct3D, DirectShow, and GDI+. This optimization will require additional data regarding the characteristics of the attached display. These characteristics include, but are not limited to:

  • Digital interface (external or internal).
  • Vertical pixel striping orientation in normal orientation (subpixels of the same color aligned in vertical columns).
  • Subpixel format is RGB (ordered left to right). Other formats might be acceptable but must be characterized in EDID.
  • High contrast ratio (minimum of 50:1).
  • No scaling or image filtering applied when display is at native resolution.
  • Detailed gamma data.
  • Additional color information.
  • Monitor rotation capability.

Not all of these characteristics are currently supported in industry standards. These items are noted here for informational purposes and will be documented in appropriate industry specifications and other technical documents as the technologies mature.

The Update on ClearType Font Technology and LCD Displays Web page has additional information about ClearType technologies and is listed in "Monitors References."

MON–0235. Monitors support sRGB output or an ICC profile is provided

The monitor must default either to creating sRGB output or using a vendor-supplied ICC profile.

Windows Me and Windows 2000 support using color profiles that comply with the Specification ICC.1:1998-09 File Format for Color Profiles. The ICM APIs and functionality for Windows 98, Windows Me, and Windows 2000 are defined in the Microsoft Platform SDK, the Windows 98 DDK, Windows Me DDK, and the Windows 2000 DDK. The Color Management and Windows Operating Systems Web page has information about implementing color-matching capabilities for Windows operating systems.

Mobile PC Note

Color-capable devices such as desktop cathode ray tube (CRT) monitors, LCDs on mobile systems, color plasma, and other flat-panel devices that do not default to sRGB output must install and associate with one or more ICC profiles for ICC color management. A monitor color-calibration utility can generate, edit, and install ICC profiles. The sRGB profile is distributed in Windows Me and Windows 2000. Mobile PCs with Double Supertwisted Nematic (DSTN) panels do not require ICC profiles.

The requirements for sRGB are defined in IEC 61966-2-1 Multimedia systems and equipment – Colour measurement and management – Part 2-1: Colour management – Default RGB colour space – sRGB, listed in "Monitors References."

MON–0236. USB functionality does not interfere with monitor INF

If a monitor includes USB functionality from either a HID or USB hub, this functionality must be installed separately from the monitor INF file.

A USB hub included on a monitor must be self-powered or externally powered. It cannot be a bus-powered hub. For more information on USB, see the Universal Serial Bus Specification, Revision 1.1 or later.

Monitor support for Windows is installed using a monitor INF file, such as the INF file defined in the Windows 98 DDK and Windows 2000 DDK.

MON–0237. Monitor meets minimum graphics resolution, based on monitor size

These specific monitor sizes are not required; they show the required pixel format for a given size monitor:

  • 14-inch to 15-inch external monitor or built-in mobile PC display = 800 × 600, noninterlaced
  • 17-inch external monitor or 13-inch to 15-inch external LCD = 1024 × 768, noninterlaced
  • 19-inch and 21-inch external monitor or external LCDs larger than 16 inches = 1280 × 1024, noninterlaced
  • 25-inch large-format monitors = 800 × 600

Note: Sizes for LCDs are the actual viewable image size, rounded to nearest inch. Sizes for CRTs are based on actual CRT size (not visible area) rounded to nearest inch.

MON–0238. CRT-based monitor synchronizes to a new format in less than three seconds

This capability is important because sometimes a change from a high refresh-rate graphics mode to a 60 Hz (or 59.94 Hz variant) mode is necessary to optimize video playback.

When the scanning rate is changed from one of its valid rates to another valid rate, the monitor must resynchronize to the new format and produce a stable picture within three seconds from the graphics adapter becoming stable.

MON–0239. External monitor meets E-DDC and E-EDID standards

E-DDC defines the communications channel between the display and host system, and VESA Enhanced Extended Display Identification Data Standard (E-EDID), Release A defines data formats for configuration information. This requirement includes the identification string and other EDID data that the monitor sends to the system.

Use the established standard or (if necessary) detailed timings to indicate the maximum resolution that the monitor supports. Using either the established or the standard timings results in greater flexibility than using detailed timing descriptor blocks.

The following items are particularly critical:

  • EDID content must indicate as much information on the range of the monitor's capabilities as possible. The VESA E-EDID standard clarifies the use of the established and standard timing sections of the EDID to indicate the factory preset modes. If an established or standard timing mode is implemented as a factory preset, then it must be indicated in the appropriate EDID section.

Note: Not all factory preset modes will have a corresponding established or standard timing in the EDID.

  • At least one piece of information must indicate the maximum resolution plus maximum timing at that resolution supported by the monitor. If this indication is not implemented using the established or standards timings, a detailed timing can be used.

To enhance the Plug and Play functionality of monitors, the following monitor descriptor definitions are required, as defined in the E-EDID Release A standard:

  • FD (monitor range). This information is essential for enabling the operating system to calculate the optimal refresh rate for any selected resolution.
  • FC (monitor name). Up to three detailed timing blocks can be used to incorporate the company and model name. These descriptors must be concatenated into a single string, and the blocks must be used in the order in which they are to be concatenated.
  • FF (monitor serial number). If provided, this information is placed in the registry for easy access by asset-management software.
MON–0240. CRT-based monitor supports ergonomic timing standards

The monitor must, at a minimum, support the timings documented in either the VESA Generalized Timing Formula (GTF), Version 1.1 or the Computer Display Monitor Timing Specifications, Version 1, Rev. 0.8. This timing support is required for the resolution specified for each monitor size in MON–0237, "Monitor meets minimum graphics resolution, based on monitor size." Other resolutions and refresh rates may be supported, but for any resolution less than the required resolution, there must be a timing for 75 Hz or better. The standards help ensure a clear, flicker-free display for traditional PC computing.

To support optimal playback of video content, monitors must be able to operate with the 59.94 variant of the 60 Hz VESA timing. All references to 60 Hz timing in this chapter also include the 59.94 variant.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Basic Audio Requirements

This section defines the basic hardware requirements for audio on PC 2001 systems. These are system-based requirements, targeted for the entire PC solution, regardless of whether the audio components are separate add-on devices or are built into the system, for example, on the system board, on the audio card or riser, or on the display monitor. These requirements, with the exception of AUD–0323, apply to the design of system audio devices, and not accessory audio peripherals, such as a TV tuner, camera with audio, voice modem, telephone handset, and so on.

AUD–0322. Audio device does not use legacy hardware interfaces for MS-DOS–based applications

If the audio device supports MS-DOS–based applications, it must use operating system–provided or operating system–compatible software emulation of legacy interfaces. Legacy hardware does not meet PC 2001 requirements if the legacy technique allows MS-DOS–based applications to communicate directly with ISA IRQ, DMA, or I/O hardware resources, such as PC/PCI or distributed direct memory access (DDMA).

Appendix A, "Resource Mapping," provides a comprehensive list of legacy and legacy-free assignments.

This requirement also applies to PCI-based audio devices. Whether Windows-based or MS-DOS–based applications are running, the PCI device must not allocate or use ISA IRQs, DMAs, or hard-coded I/O locations. The BIOS and Windows driver must not contain any options to select the use of ISA resources for the audio device.

If a device supports real-mode operation, the only acceptable manner for acquiring ISA resources is to use a real-mode configuration utility.

When running MS-DOS–based applications in a virtual MS-DOS box, the level of legacy compatibility provided by Windows 98 software emulation is comparable to hardware. A comprehensive report on "Windows 98 MS-DOS Box Game Compatibility" is available on the Web site listed in "Audio References."

AUD–0323. PC 2001 audio subsystem is digital ready

PC 2001 audio sources must be available as digital audio streams accessible to the system-wide kernel, that is, they must not rely exclusively on any analog mixing stage between the digital-to-analog converter and the speaker jack as the only means for output. Sources that continue to offer an analog mixing output configuration must also provide the user a configurable digital option.

One model for providing the user such an option is Windows support for CD Music.

The audio sources covered by this requirement, which must be available digitally to USB speakers if attached, are:

  • CD-ROM or DVD
  • TV tuner
  • FM radio
  • Voice modem

Analog Mic and Line In with available analog-to-digital converters (ADCs) are digital ready by definition. Devices for which the operating system supports emulation equivalents, such as hardware accelerated 3-D and MIDI synthesis (Microsoft DirectSound® 3D emulation and the Windows GS Wavetable SW Synth) are excepted.

This requirement assures that all audio content can be made available at both the analog jack and USB port. Elimination of the dependency on analog mixing for output is key to making PC audio easier to configure and use, and it removes a major obstacle for USB audio rendering devices.

AUD–0324. Audio subsystem supports basic data formats

Windows provides software mixing and sample rate conversion, which eliminates the need for hardware to support all possible rates. Therefore, either the audio controller or the audio codec hardware, or both, are only required to support two key rates: 44.1 kilohertz (kHz) and 48 kHz (and, at these two rates, must not depend on sample rate conversion in the driver or operating system).

  • 44.1 kHz is required for efficiency reasons. Most game content uses a sampling rate that is an integer divisor of 44.1 kHz, and CD audio is 44.1 kHz. When the highest input stream is 44.1 kHz and below, the optimal way to operate the audio output is to convert everything to 44.1 kHz and run the audio device at this rate. This conversion provides the best quality and least CPU overhead.
  • 48 kHz is required because it is the prevalent sampling rate for entertainment content, such as DVD movies. When 48 kHz content is present, the operating system switches the audio output to 48 kHz.
  • Support for other rates (8 kHz, 11.025 kHz, 16 kHz, 22.05 kHz, or 32 kHz) in hardware is optional.
AUD–0325. Audio subsystem supports full duplex operation

Full duplex audio is essential to support emerging communications applications such as Internet Protocol (IP) telephony, conferencing, and network gaming. These applications require the audio system to play back and record simultaneously. The following requirements ensure that full duplex operation is available and performance is consistent across implementations.

  • AUD–0325.1. Full duplex operation is supported for all sampling rates supported by the hardware. If the built-in or external audio device includes both input and output capabilities, full duplex operation must be supported for basic formats (16-bit, and 44.1 kHz and 48 kHz), and for all other formats supported by the hardware, for example, at 8 kHz, 11.025 kHz, 16 kHz, 22.05 kHz, or 32 kHz.
  • AUD–0325.2. Independent selection of input and output sample rates. If the built-in or external audio device includes both input and output capabilities, the audio device must support independent selection of input and output sample rates.
  • AUD–0325.3. Sample rates are time-synchronized. If the built-in or external audio device includes both input and output capabilities, the timing relationship between input and output sample rates must remain constant (i.e., no drift). For example, if 8 kHz is selected for both input and output sampling rate, audio hardware must ensure that the sampling rate for input and output is precisely matched.

Further, when input and output sample rates are set to integer ratios, the actual sample rate ratios must match (i.e., no drift). For example, if 8 kHz input sampling rate and 32 kHz output sampling rate are selected, the ratio of actual sampling rates must be precisely 8:32. This requirement can be accomplished by ensuring that both input and output sampling rates are derived from the same clock, and that sample rate divisors are set correctly.

This requirement helps ensure that Acoustic Echo Cancellation (AEC) and Noise Reduction algorithms maintain performance and convergence.

AUD–0326. Audio driver reports sample position for stream synchronization

The driver must be capable of reporting within 1 ms the current position of the buffer being rendered, in relation to the samples given to the codec. This requirement applies for both compressed and uncompressed data.

AUD–0337. Audio meets PC 2001 requirements for WDM driver support

All audio devices must have drivers that use the WDM architecture exclusively. Audio devices must not use VxDs. The manufacturer can either supply a WDM driver with the audio device or rely on a WDM driver provided with Windows Me and Windows 2000.

For information about WDM device driver support for streaming capabilities, see "WDM Kernel Streaming Architecture" and "Kernel Streaming Overview," available on the Web pages indicated in "Audio References."

AUD–0327. If implemented, audio system provides 2-D and 3-D hardware acceleration according to PC 2001 requirements

If the audio hardware provides acceleration for Microsoft DirectSound or DirectSound3D, it must declare its capabilities as follows:

  • The device must accurately report the maximum number of 2-D and 3-D buffers it can play simultaneously on the minimum PC 2001 system. For example, if the device declares that it can support 20 2-D buffers and 30 3-D buffers, it must be able to play 20 2-D buffers or 30 3-D buffers simultaneously.
  • The device must accurately report the number of available 2-D and 3-D buffers. The device must be able to open and play another 2-D or 3-D buffer when the reported number of available voices is greater than 0.
AUD–0328. If implemented, audio system provides DLS acceleration according to PC 2001 requirements

If the audio system provides hardware acceleration of DLS using Microsoft DirectMusic®, the audio system must be able to fulfill all of the capabilities it declares. For example, if the DirectMusic device indicates that it can play 64 voices and provide reverb, then it is required to support both capabilities, simultaneously on the minimum PC 2001 system.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Audio Performance Requirements

This section summarizes the performance requirements for audio on PC 2001 systems.

Several companies joined together to develop Personal Computer Audio Quality Measurements (PCAQM), a standard testing procedure for defining and measuring audio performance. Contributors to PCAQM include Audio Precision, Compaq Computer Corporation, Crystal Semiconductor, Intel Corporation, and Microsoft Corporation. PCAQM definitions and test methods are available from the Personal Computer Audio Quality Measurements Web site listed in "Audio References."

AUD–0329. Audio meets PC 2001 minimum performance requirements

The following table summarizes audio performance requirements for all audio-enabled PC 2001 systems, with the exceptions noted in "Requirements for Mobile PC Audio." These requirements establish a minimum performance level for PCs.

For precise definitions of the terminology used in the following table, please refer to the PCAQM test methodology paper cited earlier in this section.

PC 2001 Audio Minimum Performance Requirements

Feature | Requirement | Value
Full-scale input voltage | FSIV (A-D-PC) line input FSIV (A-D-PC) microphone input | ≥1.0 Vrms ≥100 mVrms
Full-scale output voltage | FSOV (PC-D-A) line output | ≥1.0 Vrms1
Digital playback (PC-D-A) for line output | Frequency response (–3 dB) 44.1 kHz source material 48.0 kHz source material Passband ripple5 Dynamic range THD+N (–3 dB FS) | 20 Hz to 17.6 kHz3 20 Hz to 19.2 kHz3 <+/–0.5 dB ≥80 dB FS A2, 3 ≤–65 dB FS3
Digital playback (PC-D-A) for speaker output | Speaker output with 8-ohm load4 Frequency response (–3 dB) 44.1 kHz source material 48.0 kHz source material Dynamic range THD+N (–3 dB FS) | 100 Hz to 17.6 kHz4 100 Hz to 19.2 kHz4 ≥80 dB FS A2, 3 ≤–65 dB FS3
Digital recording (A-D-PC) for line input | Frequency response 44.1 kHz destination 48.0 kHz destination Passband ripple Dynamic range THD+N (–3 dB FS) | 20 Hz to 17.6 kHz3 20 Hz to 19.2 kHz3 <+/–0.5 dB ≥70 dB FS A2, 3 ≤–60 dB FS3 (input-referenced)
Digital recording (A-D-PC) for microphone input | Frequency response (–3 dB) 22.05 kHz destination Passband ripple Dynamic range THD+N (–3 dB FS) | 100 Hz to 8.8 kHz <+/–0.5 dB ≥70 dB FS A2, 3 ≤–60 dB FS3 (input-referenced)
Line output cross-talk | Channel separation between left and right line out channels (measured at 10 kHz) | ≥60 dB3
Sampling frequency accuracy | Playback Record | 0.1% 0.1%
1 For 3.3V audio codec the required full-scale output voltage (FSOV) for line output is ≥0.7 Vrms. 2 Decibels relative to full scale (FS), measured using "A weighting" filters. 3 For mobile PC, the dynamic range requirements are relaxed by 10 decibel (dB) FS. The total harmonic distortion plus noise (THD+N) requirements are relaxed by 10 dB FS. The required frequency response is 30 Hz to 15 kHz, measured using 3 dB corners. The cross-talk requirements are relaxed by 10 dB FS. 4 Where separate line and speaker outputs are provided. 5 Bandpass for ripple measurements is from 40 Hz to (0.4xFs)/2 Hz.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Requirements for Voice Input

This section discusses incremental requirements for audio subsystem and peripheral devices to support applications requiring voice input on the PC.

These requirements address issues related to microphone input compatibility for voice-input enabled applications such as acoustic echo cancellation, speech recognition, speakerphone telephony, and conferencing.

AUD–0330. Audio subsystem supports AEC reference inputs

Built-in or external audio devices that support full-duplex, stereo playback and record for speakers and microphone must support simultaneous capture of microphone and one or more AEC reference inputs.

At minimum, the audio device must support capture of microphone input in the left channel and a monaural output mix in the right channel, where the monaural output mix is the left and right channels of the main output merged into a single channel. This 1+1 channel interleaved format (similar to stereo) will be referred to as "mic+ref", and can be easily achieved using existing stereo ADCs.

For more information, see Section 6.2 of Audio Codec ’97, Revision 2.1, from Intel Corporation, which describes one possible implementation. This specification is listed in "Audio References."

AUD–0331. If implemented, analog microphone input meets PC 2001 jack and circuit requirements

This requirement enables users with electret or dynamic microphones to connect the device to their PC and achieve consistent results. This requirement also maintains compatibility with the installed base of microphones. For information about headset microphones, see AUD–0332, "If implemented, close-speaking headset microphone meets PC 2001 performance requirements."

If the PC has an analog microphone input, it must meet the following specifications:

  • Three-conductor 1/8-inch (3.5 millimeters) tip/ring/sleeve microphone jack where the microphone signal is on the tip, bias is on the ring, and the sleeve is grounded.

This design is optimized for electret microphones with three-conductor plugs, but will also support dynamic microphones with two-conductor plugs, where the ring and sleeve are shorted together.

  • Minimum AC input impedance between tip and ground: minimum, 4 kilohms.
  • Input voltages of 10–100 millivolts (mV) must deliver full-scale digital input, using software-programmable gain.
  • Maximum 5.5 V with no load, minimum 2.0 V with 0.8 milliampere (mA) load, direct current bias for electret microphones.
  • Minimum bias impedance between bias voltage source and ring: 2 kilohms.
  • AC coupled tip.
AUD–0332. If implemented, close-speaking headset microphone meets PC 2001 performance requirements

The following requirements are for close-speaking headset microphones intended for use in speech-recognition applications.

These requirements are compatible with most of the installed base of sound cards and audio-enabled system boards.

The requirements for a PC 2001 speech-recognition microphone are:

  • Close-speaking headset design positions microphone within 1.5 inches of the corner of the speaker’s mouth.
  • FSOV: 100 mV (0 dB FS).
  • Microphone connector meets requirements stated in the requirement
    AUD–0331, "If implemented, analog microphone input meets PC 2001 jack and circuit requirements."
  • Operating bias voltage from 2.0–5.0 volts direct current (VDC) with a maximum current drain of 0.8 mA.
  • Capable of sustaining a maximum voltage of 10 VDC on tip or ring without damage.
  • Frequency response:
  • ±3 dB from 100 Hz to 10kHz
  • 0 dB at 1 kHz
  • Minimum sensitivity of –44 dB relative to 1 volt per pascal.
  • Maximum 2 percent THD+N 100 Hz to 10 kHz at 94 decibel sound pressure level (dBSPL).
  • Noise cancellation null sensitivity at 90 degrees and 270 degrees, ±10 degrees, with the following minimums:

20 dB at 100 Hz
20 dB at 400 Hz
20 dB at 1000 Hz

20 dB at 4000 Hz
10 dB at 10 kHz

  • Maximum wind noise sensitivity of –65 dB with 0 dB = 1 V (measured with wind speed of 1 meter per second at the 0 degree axis of microphone).
  • Maximum output impedance of 1 kilohm (using a 1-kHz full-scale test tone with 2.0 VDC bias).

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Requirements for PCI, USB, and IEEE 1394 Audio

This section discusses additional requirements and exceptions for audio devices implemented for PCI, USB, and IEEE 1394.

Audio devices must meet the applicable requirements in Chapter 6, "Buses and Interfaces," unless specified in this chapter.

AUD–0333. PCI device supports initiator, target, and block transfer

For complete implementation details, see PCI 2.2. Full-duplex audio sample transport must be supported using separate PCI bus mastering hardware for playback and capture sample streams.

AUD–0334. PCI device supports efficient audio buffer management

The audio device must be able to fully function when the system can only provide single pages of contiguous memory. In other words, the audio device can require many pages of memory, but must not require the largest block of contiguous memory to exceed one page.

This requirement ensures audio support in docking and dynamic loading scenarios where memory may be fragmented with respect to pages.

The audio device and associated device-specific driver must not introduce unnecessary latency. If the audio driver adds more than 2 milliseconds of computational latency between buffer transfer and queuing for rendering, the driver must provide a programmatic method for a latency sensitive application to temporarily disable the computation.

This requirement helps to ensure that telephony applications closely resemble the performance of a conventional phone and minimizes the possibility that audio and video streams will appear out of synch.

AUD–0335. USB audio meets USB specifications

If USB audio is implemented, the device must comply with Universal Serial Bus Specification, Revision 1.1 and with Universal Serial Bus Device Class Definition for Audio Devices, Release 1.0. This requirement ensures that all Plug and Play requirements are met and that drivers provided with the operating system support this device.

USB audio devices must use an HID to control basic functions. If a USB audio device plans to implement volume adjustment controls, it must employ the HID usages provided on the consumer controls page in the USB HID Usage Tables, Version 1.1 specification and in "Windows Support for HID-based Audio Controls," listed in "Audio References."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Power Management for Audio

This section summarizes the power management requirements for audio components.

AUD–0336. Audio device complies with device class power management reference specification

Audio devices must comply with Audio Device Class Power Management Reference Specification, Version 1.0, which provides definitions of the OnNow device power states (D0–D3) for these devices. The specification also covers the device functionality expected in each power state and the possible wakeup event definitions for the class. The device and driver are required to implement support for power states D0, D2, and D3. Other power states are optional.

Audio devices implemented on the system board must comply fully with ACPI 1.0b.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Requirements for Mobile PC Audio

Mobile audio must meet the requirements for PC 2001 audio as defined earlier in this chapter, with exceptions as defined in this section. These exceptions acknowledge mobile-specific design challenges, such as dual power supplies (battery and AC), low power operation, and smaller form factors.

For mobile PCs, USB plays an especially important role in providing access to higher quality audio output. For more information, see AUD–0323, "PC 2001 audio subsystem is digital ready."

AUD–0338. Audio-enabled mobile PC meets mobile PC 2001 audio performance requirements

For Mobile PCs, the following exceptions and differences are allowed:

  • All dynamic range requirements are relaxed by 10 dB FS A.
  • All THD+N requirements are relaxed by 10 dB FS.
  • The required frequency response (measured at line out) is 30 Hz to 15 kHz, measured using 3 dB corners.
  • All cross-talk requirements are relaxed by 10 dB FS.
AUD–0339. Docked mobile meets PC 2001 speaker selection requirements

The PC 2001 design requirements allow for the audio controller to be implemented on the mobile PC with output capabilities implemented on a docking station. The docking station is not required to implement full desktop audio capabilities, but it can supplement the audio capabilities of the mobile PC. If audio is implemented, the docked mobile PC must meet the requirements for PC 2001 audio as defined in this chapter, with additional requirements as follows:

  • Whether the mobile PC system is docked or not, users must be able to access the highest quality audio output in any given configuration. System vendors can choose to automate the process either in the docking station or the mobile PC to meet this requirement. If speakers are not automatically selected, then the user must be able to select speakers in the mobile PC or docked mobile PC upon docking. However, this requirement must not necessitate users changing the speaker configuration each time they dock and undock.
  • Speakers must be switched off if the headphone jack is used.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Storage Basic Requirements

This section presents the requirements for storage and related peripherals, including DVD devices.

For specific information about implementation details related to storage devices under the Windows Me and Windows 2000 operating systems, see the Storage Technology Web page, listed in "Storage References."

STOR–0341. Storage components and optical devices support bus master capabilities

Hard disk and optical devices (such as CD and DVD devices) must support bus mastering, and bus mastering must be enabled on the host by default. When correctly implemented, bus master support improves performance and Windows-compatible device driver support.

Bus master capabilities must meet the related specification for the particular controller. For example, the programming register set for PCI IDE bus master DMA is defined in the AT Attachment with Packet Interface – 5 (ATA/ATAPI-5), standard. Bus master support is required of optical devices in order to adequately support video playing for DVD and CD-ROM devices.

A DVD drive and controller must support word-aligned, multisegment, bus master DMA transfers. DMA must be enabled by default.

If attached by way of an ATA interface, ATAPI DVD drives and ATA systemboard implementations must support DMA as specified in the ATA/ATAPI-5 standard or ATAPI Removable Rewritable Media Devices (INF-8070i).

STOR–0342. Removable media devices support media status notification

The following list shows the required specifications for implementing media status notification, depending on device type.

Media Status Notification Requirements

Device type | Media status notification implementation
CD and DVD devices | Comply with SCSI Multimedia Commands–2 (MMC-2) standard for Media Status Event Notification.
ATAPI floppy/optical direct access drives | Comply with either MMC-2 standard or INF-8070i version 1.2.
IEEE 1394 storage devices | Comply with Reduced Block Commands (RBC) standard (T10/97-260r0).
ATA and non-ATAPI storage devices | Comply with Media Status Notification Support Specification, Version 1.03.
Other ATA/ATAPI-5 or later devices, including tape drives | If implemented, comply with Media Status Notification Support Specification, Version 1.03, or INF-8070i.
Other types of SCSI removable devices | If implemented, support based on the RBC standard.

STOR–0343. USB storage devices comply with the USB mass storage class specification

All USB storage devices must meet the requirements of the Universal Serial Bus Mass Storage Class Specification Overview, V1.0 Revision. This includes all USB Mass Storage class documents, including Bulk Only, Control/Bulk/Interrupt, Bootability, and UFI Command specifications.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


CD and DVD Devices

This section summarizes the requirements for CD peripherals. The device must also meet the general requirements defined in "PC 2001 Design for Storage Components," including STOR–0341, "Storage components and optical devices support bus master capabilities."

STOR–0352. CD or DVD drive is CD-Enhanced compatible

The CD or DVD drive must be able to mount multisession CD-ROM discs, even if track 1 is Red Book audio. CD-Enhanced support must be Blue Book compliant, as defined in CD EXTRA (Enhanced Music CD) Specification, Version 1.0.

STOR–0353. CD or DVD drive supports specified logical and physical CD formats

At a minimum, the CD or DVD drive must be compatible with the following formats for cross-media compatibility, based on compliance with the MultiRead Specifications for CD-ROM, CD-R, CD-R/RW, & DVD-ROM Devices, Revision 1.11:

  • Logical formats: CD Red Book (CD-Audio), Yellow Book (CD-ROM), Orange Book parts II and III (packet writing if recordable), White Book, Blue Book, and Universal Disk Format (UDF) versions 1.5 and 2.0
  • Physical formats: ROM (stamped), and Orange Book part II (CD-R) and part III (CD-RW)

Note: Any ATAPI CD or DVD drive designed to play back CD-I content must return a minimum of two track entries for the READ_TOC (0x43) command. These two track entries must be a track 01 entry and a track 0xAA entry for the lead-out address. Drives that do not comply with this minimum requirement cannot play back CD-I movies.

STOR–0354. CD or DVD drive complies with MMC-2

CD drives must support the hardware and protocols documented in the NCITS specification.

Note: Support for the READ CD-DA command as defined in the MMC-2 standard is required.

STOR–0355. CD drive supports multisession and compatibility forms of the READ_TOC command

Both multisession forms (01b and 10b) and the compatibility form (00b) of the READ_TOC command must be implemented. This provides complete support for CD-ROM multisession capabilities.

For information about ATAPI peripheral support for CD-I content, see requirement STOR–0353, "CD or DVD drive supports specified logical and physical CD formats."

STOR–0356. CD or DVD changer complies with MMC-2

If a CD or DVD changer with a capacity for seven or fewer discs is present, the changer must comply with the MMC-2 standard.

STOR–0357. CD or DVD device supports digital audio extraction with sector accurate reads

The READ_CD command and READ_RAW commands must provide sector-accurate reads, as defined in the MMC-2 standard. Data alignment accuracy must be equivalent to that of data reads. Because of the lack of ECC bytes used for data tracks, the data itself may contain inaccuracies due to physical defects of the media. Furthermore, CD and DVD drives must implement "CD Capabilities and Mechanical Status Page" (2Ah), as defined in the MMC-2 standard. The "CD-DA Commands Supported" and "CD-DA Stream is Accurate" bits must be set and their functionality must be implemented.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


DVD Devices

This section summarizes specific requirements for DVD devices. For information about the requirements for DVD-Video and MPEG-2 playback performance, see "DVD-Video Playback Requirements" and "MPEG-2 Video Playback Requirements" in Chapter 9, "Video." For more information about DVD support under Windows Me and Windows 2000 operating systems, see "DVD and Microsoft Operating Systems," listed in "Storage References."

STOR–0360. DVD device provides 2 MB per second minimum transfer rate or better performance anywhere on the disc

The minimum sustained DVD device media transfer rate must be at least 2 MB per second for read operations from the DVD disc.

This requirement sets the minimum speed needed for DVD-Video playback during MPEG-2 decoding on Windows platforms. This requirement applies to the minimum read speed (2 MB per second) on any production level DVD-Video media, at any location on the disc. This minimum rate requirement does not apply to DVD data discs that the user records, or discs being read in error-correcting, defect management mode. OEMs must continue to ship DVD drives that produce an acceptable user experience and conform to the specifications cited in
STOR–0341, "Storage components and optical devices support bus master capabilities," and STOR–0353, "CD or DVD drive supports specified logical and physical CD formats."

STOR–0361. DVD drive supports defect management

DVD drives must support defect management that is transparent to the operating system, according to industry standards. Defect management for DVD-RAM media is defined in DVD Specifications for Rewritable Disc, Part 1: Physical Specifications, published by Toshiba Corporation. Defect management for DVD+RW is defined in ECMA-274. Information on ECMA-274 is listed in "Storage References."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


CD Devices

This section describes the requirements for CD devices.

STOR–0362. CD device provides 8x minimum transfer rate or better performance

This requirement sets the minimum speed (1200 KB per second when running in the fully on power state) needed for production-level CD reading on Windows platforms. This requirement applies to the minimum read speed (8x) on any production-level CD media, such as application or game software, at any location on the disc. This minimum speed requirement does not apply to end-user recorded CD data discs or discs being read in error-correcting, defect management mode, or to CD devices attached on buses such as USB 1.0 or later that cannot sustain this data rate.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Rewritable Optical ATAPI Devices

This section summarizes specific requirements for rewriteable optical storage devices. The device must also meet the general requirements defined in "PC 2001 Design for Storage Components."

STOR–0363. Block rewriteable optical ATAPI device complies with INF-8070i, version 1.2

INF-8070i defines the requirements for block rewriteable ATAPI devices, including specifications for logical unit number (LUN) implementation, media status notification, and device write protection. This document also includes required support for the Read Format Capacities command.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


PC 2001 Design for Storage Components

This section summarizes requirements related to Plug and Play and other resource-related design issues for storage devices.

STOR–0364. Device and controller comply with Storage Device Class Power Management Reference Specification

The Storage Device Class Power Management Reference Specification, Version 1.0 provides definitions of the OnNow device power states (D0–D3) for these devices. The specification also covers device functionality expected in each power state and possible wakeup event definitions for the class. Support is required for power states D0, D1, and D3 for hard disks, CD and DVD drives, and other mass storage devices. Hard disks, CD, and DVD drives, and other mass storage devices are required to resume properly from the D3 power state after power to the device is removed. Support for the D1 state is not required for floppy disk devices.

If implemented, the ability to cause a wakeup event must meet the requirements as defined in the Storage Device Class Power Management Reference Specification, Version 1.0.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Device Drivers and Installation for Storage

This section summarizes the basic requirements for device drivers and installation procedures for storage devices.

STOR–0365. Device driver for partitioned media supports all Windows Me and Windows 2000 partition types

Device drivers that support partitioned media must support all Windows Me and Windows 2000 partition types, which include but are not limited to FAT 16, FAT 32, and Windows NT file system (NTFS).

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Voiceband Modems

This section describes the basic features required for all voiceband modems.

MOD–0366. Modem driver supports Unimodem

The device driver must include universal modem driver (Unimodem) support. Typically, this requires a modem INF file, developed and verified using the Modem Developers Kit (MDK) and pretested by the modem manufacturer.

MOD–0367. Modem meets PC 2001 controller requirements

The modem controller must support the following:

  • AT command buffer of at least 60 characters
  • Semicolon (;) character dial string modifier, except when the modem is configured for operation in those countries that prohibit this dial modifier
  • Unimodem Diagnostics command, AT#UD

The modem controller must also be capable of software-based feature upgrades, such as providing upgradeable ROM or a driver-based modem that meets the requirements in "Driver-based Modems" later in this chapter.

MOD–0368. Modem supports V.250 AT command set

International Telecommunication Union (ITU) Recommendation V.250 is a superset of the TIA-602 basic AT command set with significant and useful improvements. The following V.250 commands must be supported:

  • All basic mode commands from TIA-602 (no + prefix)
  • Identification: +GMI, +GMM, +GMR, +GCI
  • Port control: +IPR, +ICF, +IFC, +ILRR, +ITF (defined in V.80)
  • Modulation: +MS, +MR, +MA
  • Error control: +ES, +ER, +EB, +ESR, +ETBM
  • Compression: +DS, +DR

If the AT command for a particular function is implemented, the corresponding V.250 AT command must be supported.

The modem must also be able to generate appropriate V.250 responses enabled by the +ILRR, +MR, +ER, and +DR commands.

MOD–0369. Data modem meets PC 2001 protocol requirements

A PC 2001 modem must support the following protocols:

  • V.90 modulation
  • V.42 Link Access Protocol Modem error control
  • V.42 bis data compression
  • V.80 synchronous data access protocol
MOD–0370. Modem supports call control signaling, controlled using V.251 modem commands

Modems must support the ITU V.251 standard for PC-controlled call control, including:

  • DCE-controlled V.8 operation with DTE notification.
  • DTE-controlled V.8 operation (<a8a> values of 2, 3, and 4).
  • DTE-controlled V.8 bis operation.
  • Backward compatibility for media detection with terminals using V.25 signaling, for example, data calling tone and fax calling tone.
  • Backward compatibility for media detection with older modems, for example, V.32 and V.32 bis.
  • Modems must provide a means for turning on the V.8 Calling Indicator signal for originating calls. Modems must also meet requirements stated in the Videophone-ready Modem Handbook, Version 1.0, which describes the specific implementation details essential to support H.324 voice-band video conferencing.
MOD–0371. FAX modem supports 14.4 Kbps (V.17) with Class 1 command set

If fax modem capabilities are implemented, the fax modem must support 14.4 kilobits per second (Kbps) (V.17) with the Class 1 (ITU T.31) command set.

If fax modems include dax/data media detection (for example, T.32 +FAA command), the INF file must include the necessary registry keys, as defined in the MDK, which is provided in the Windows DDK.

MOD–0372. If delayed and blacklisted number tables are implemented, modem generates appropriate error messages

During certain international Post, Telephone, and Telegraph certification processes, modems must support the delayed and blacklisted numbers feature. For details, see European Telecommunications Standards Institute (ETSI) ETS 300 001.

For Windows compatibility, modems that support delayed and blacklisted number tables must:

  • Generate end-user legible error messages to report these conditions.
  • Provide modem INF file drivers that translate these error messages for Unimodem and Telephony Application Program Interface (TAPI).
MOD–0373. If TDD support is implemented, modem complies with TDD, meeting V.18-1996 with V.250 AT commands

People who are deaf or hard-of-hearing, and people who are unable to speak or who use synthetic speech, can communicate over phone lines using a TDD, also known as a Text Telephone.

ITU Recommendation V.18 codifies how all these devices work and how to adaptively connect to all of them. ITU Recommendation V.250 contains these AT commands for control of V.18 features in a modem: +MV18S, +MV18R, +MV18AM, +MV18P. Modems that support text telephony must support those parts of V.18 applicable to their target countries, and the V.18 commands listed earlier.

MOD–0374. If voice modem is implemented, it supports ITU V.253 (AT+V)

Voice modem features that are implemented must use the corresponding commands and responses defined in V.253.

MOD–0375. If implemented, V.253 modem supports duplex audio (+VTR)

The required formats for duplex audio are for 8-bit 8 kHz: unsigned linear and G.711.

MOD–0376. If Caller ID detection is implemented, modem supports Caller ID Reporting using +VCID and +VRID commands

If Caller ID detection is implemented, reporting must be controlled with the AT+VCID command from V.253. If Caller ID message reporting is implemented, it must be controlled with the AT+VRID command from V.253.

MOD–0377. Modem can connect, stay connected, and successfully transfer data simultaneously

This requirement states a basic criterion for modem functionality. While operating in the default modem configuration on TIA-3800 line I01d-loop 3, the modems must be able to transfer a typical file in 40 minutes or less, simultaneously in both directions, without hanging up or otherwise aborting the transfer. Data transmission is required to be run directly on the modems without the use of an additional protocol such as Zmodem.

The analog V.90 modem subject to this requirement must meet it when connected to digital V.90 modems commonly deployed by Internet service providers (ISPs). For modems certified for operation only in countries outside of North America, the requirement is for operation on impairment combination 2C4, as specified in International Telecommunication Union – Telecommunication Standardization Sector (ITU-T) Recommendation V.56 bis. V.56 bis. specifies that the modem must be connected to an identical analog modem, rather than a digital V.90 modem.

TIA TSB-38 provides detailed test procedures and criteria.

MOD–0378. Modem reliably connects numerous times on good telephone channels

This requirement cites basic modem functionality. While operating in the default configuration, the modem must be able to repeatedly connect, with an overall call completion success ratio of 97 percent and without the modem stalling in an unresponsive, inoperable state. This requirement must be met while operating on channels I01d from TIA-3800.

The analog V.90 modem must meet this requirement when connected to digital V.90 modems commonly deployed by ISPs.

TIA TSB-38 provides detailed test procedures and criteria for modems certified for operation in North America. ITU-T Recommendation V.56 ter provides detailed test procedures for modems only certified for operation outside of North America.

MOD–0379. Modem pair functions concurrently with other applications

For this requirement, the modem must be able to sustain a connection for at least 30 minutes, at no less than 90 percent of the initial connection rate and with no more than 2 retrains, while typical communications applications are running over the modem link on the PC, including:

  • E-mail: Outlook Express over Hotmail.
  • Web browsing: Internet Explorer.
  • Video teleconferencing: Netmeeting.

To meet this requirement, the analog V.90 modem must sustain connectivity when connected to digital V.90 modems commonly deployed by ISPs, using the same channel as described in MOD–0378, "Modem reliably connects numerous times on good telephone channels."

MOD–0380. All external USB modems support USB specifications

An external modem must comply with all related USB specifications, including:

  • Universal Serial Bus Specification, Revision 1.1.
  • Universal Serial Bus Class Definitions for Communication Devices, Version 1.0

External modems may also support V.24 (RS-232) serial interfaces for legacy connectivity.

For compatibility with Unimodem and Windows USB serial drivers, a USB modem that incorporates the modem controller function must support the mandatory and optional requests and notifications for Abstract Control Model Serial Emulation defined in section 3.5.1.2.1 of the Universal Serial Bus Class Definitions for Communication Devices, Version 1.0 specification.

Alternatively, external modems may support IEEE 1394 or Bluetooth instead of USB. If implemented as external Bluetooth modems, they must support one of the applicable profiles defined by the Bluetooth SIG specifications, such as Dial Up Networking (K:7), FAX profile (K:8), or LAN Access (K:9). For more information on Bluetooth specifications, see Specification of the Bluetooth System, Volume 1: Core, v1.0 B, and Volume 2: Profiles, v1.0 B, listed in "Modems References."

MOD–0381. Modem complies with device class power management reference specification

The Communications Device Class Power Management Reference Specification, Version 1.0, provides definitions for the OnNow device power states (D0–D3) for modems. The specification also covers the device functionality expected in each power state and the possible wakeup event definitions for the class.

Power states D0 and D3 are required for modems on power-managed buses, including PCI, CardBus, and USB. Modem adapters that use the PCI bus must be capable of generating a power management event (PME# assertion) from the D3cold device state.

MOD–0382. Modem supports wakeup events

A modem must be able to cause a wakeup event on an incoming ring as defined in the Communications Device Class Power Management Reference Specification. This requirement applies for modems on all power-managed buses, including PCI, CardBus, and USB.

The D2 power state is defined specifically for this purpose in the power management reference specification. The ability for a modem to cause a wakeup event from the D3 power state is also possible (D3 realizes better system power savings). To comply with this requirement, a modem must be able to cause a wakeup event from the D2 state, the D3 state, or both states.

PCI modem devices are required to support wake from D3cold on a system with auxiliary power. On all other power-managed buses (such as USB), support for either D2 or D3 is acceptable.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Driver-based Modems

This section covers requirements for controllerless or "soft" modems, whereby the modem controller function, or both the modem controller and the modem datapump functions, are implemented on the Windows host.

MOD–0383. Driver-based modem uses a WDM-based driver solution

Windows Me and Windows 2000 use the same WDM kernel calls. Driver-based modems must use the WDM kernel so that both operating systems can use a common driver binary. For Windows 2000, these drivers must also support symmetric multiprocessors.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


ISDN Modems

This section covers requirements for serial-port connected ISDN terminal adapters, commonly referred to as "ISDN modems." See also "ISDN Requirements" in Chapter 14.

MOD–0384. ISDN modem supports required command set

An ISDN modem must support the following:

  • Basic AT commands such as TIA-602, which is a subset of ITU V.250
  • Commands to select the end-to-end protocol used over the ISDN, for example, synchronous point-to-point protocol (PPP), V.110, V.120, and so on
  • Commands to set the switch type, subscriber numbers, or directory numbers
  • Service profile ID (SPID) or EndgerateAushlZiffer (EAZ) (where applicable) for user selection or if auto-detection fails, implemented in the device or in the communications driver
MOD–0385. ISDN modem supports asynchronous-to-synchronous conversion and RFC 1662

Because ISDN is a synchronous service and an ISDN modem connects
to a logic asynchronous USB port on the PC, the device must provide
some means of converting asynchronous data to synchronous data. The asynchronous-to-synchronous conversion must support the requirements identified in RFC 1662.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Mobile Modems

This section covers the particular requirements of modems used in mobile systems. These are in addition to the requirements in the "Voiceband Modems" section earlier in this chapter.

MOD–0386. If wireless support is implemented, Mobile PC modem supports +WS46 command

Wireless modems and look-alike modems include the common types, such as North American analog cellular, cellular digital packet data (CDPD), GSM, and other digital cellular systems, as well as several other types.

All wireless and cellular modems must use the +WS46 command, which selects the WAN.

The TIA-678 +WS46 command has codes to indicate the system in which the modem can operate. For example, the following values, quoted from Table 4 of the standard, are useful.

Value | System
1 | Public telephone network (that is, a normal wireline modem)
4 | CDPD
7 | TIA-553 analog cellular system
10 | Metricom Ricochet network
12 | GSM digital cellular system
13 | TIA IS-95 CDMA digital cellular
14 | TIA IS-136 TDMA digital cellular (Personal Communications System)

Windows has registry keys that support analog cellular modems. Windows also supports data access in GSM and other wireless modem types.

MOD–0387. If digital cellular control is implemented, Mobile PC modem supports appropriate +C digital cellular standards

If digital cellular support is implemented, the following appropriate digital cellular control standards must be supported.

Standard | System and services
GSM 7.07 | GSM system: data, fax, voice
GSM 7.05 | GSM SMS
TIA IS-707 | North American CDMA: data and fax
TIA IS-135 | North American TDMA: data and fax

The following commands are required:

  • +CBC battery power monitoring command
  • +CPAS phone activity status
  • +CSQ signal quality-monitoring command
  • +CBST protocol selection command for GSM modems
  • Class 2.0 facsimile services, per appropriate standard

Digital cellular communications equipment must default to using error correction on the radio link. For example, for GSM 7.07, the modem must initialize to +CBST=,,1 (which selects a "nontransparent" air interface).

To allow data cards to use GSM/ISDN V.110 "fast access" where available in the network, +CBST=71,, ( 9600 bits per second (bps) V.110) must be a valid setting.

MOD–0388. If SMS support is implemented, the modem supports appropriate +C SMS control commands

To allow software applications to specify settings and manipulate short messaging services (SMS) through a GSM modem card, the card must support the following GSM 07.05 commands:

+CMGF: Message Format

+CMGL: List Messages

+CMGR: Read Messages

+CMGS: Send Messages

+CMGW: Write Messages

+CNMI: New Message Indications
to terminal equipment (TE)

+CPMS: Preferred Message Storage

+CRES: Restore Settings

+CSAS: Save Settings

+CSCA: Service Center Address

+CSCS: TE character set selection

+CSMS: Select Messaging Service

Unlike wireline data modems, these devices are not required to support V.34 signaling because none is available. Only 9600 bps capability is required.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Telephony

The increasing confluence of voice and data networks is driving the increased use of the PC as a communications device. PC systems that are compatible with acoustic requirements of the telephony network support easy and efficient two-way interactive voice communications, such as telephony, allowing users to use their existing PC audio devices for communication.

MOD–0389. System with telephony applications uses a common set of audio I/O devices for system audio and telephony applications

If the system enables telephony applications such as speakerphone, IP telephone, and so on, then for each type of audio I/O device, the same device must be usable for both system audio and telephony. For example, the same set of speakers must be usable for both system audio and speakerphone functions. When using a headset, users must not need to change plug locations when switching from, for example, listening to CD-audio to speaking on the phone.

This requirement ensures that one convenient, unambiguous I/O connector is provided for each type of audio I/O device. It does not mandate that all audio I/O is delivered to a single I/O device at all times. For example, providing system audio sounds to the speakers while simultaneously using a headset for IP telephony would not be prohibited.

MOD–0390. Telephony applications provided with a PC 2001 system meet industry telephony performance requirements

If the system enables telephony applications that support devices, such as speakerphone or handset telephony, using various types of connections, such as plain old telephone service (for example, through a voice modem) or IP (through a network connection), the applications provided with the system must comply with telecommunications industry requirements for such parameters as send and receive loudness, echo, and so forth.

Speakerphone applications must meet the requirements in ITU-T Recommendation P.340, Transmission characteristics of hands-free telephones. Other applications must meet the requirements in ITU-T Recommendation P.310, Transmission characteristics for telephone band (300-3400 Hz) digital telephones. For additional information for IP telephony functions, see U.S. Committee T1 Technical Report No. 56, Performance guidelines for voiceband services over hybrid internet/PSTN connections, which provides useful guidance for IP telephony functions.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Connectionless Requirements

This section lists the requirements related to connectionless media, such as IEEE 802 LAN adapters (with the exception of wireless) and Fiber Distributed Data Interface (FDDI) adapters.

NET–0252. NDIS 5.0 miniport driver is deserialized

NDIS 5.0 introduces support for deserialized miniports. This feature enables performance improvements and scalability on Windows 2000 multiprocessor systems.

NET–0253. Full-duplex adapter automatically detects and switches to full duplex mode

If both the network adapter and switch port in a link pair support full duplex and there exists a standard way for each to detect and negotiate the duplex mode, the network adapter must negotiate full-duplex mode operation by default. Half-duplex mode can be used if that is the only mode supported by one or both link partners, or it can be manually configured if warranted by special conditions. The goal is to configure this setting automatically without end-user intervention.

NET–0254. Adapter supports filtering for at least 16 multicast addresses

This requirement applies to networking technologies, such as Ethernet, that support multicast. This requirement does not apply to technologies such as Token Ring, which distributes IP multicast traffic using the functional address as specified in RFC 1469, listed in "Network Communications References."

NET–0255. Adapter and driver support promiscuous mode

Promiscuous mode ensures that the adapter can be used with Microsoft Network Monitor Agent. This requirement applies only to LAN (nonswitched) media.

Notice that, by default, promiscuous mode is not on. Enabling promiscuous mode must be possible only by using the Microsoft Network Monitor Agent or another similar administrative application.

NET–0256. Adapter can be used as a boot device

A PC system designed for use with Windows 2000 must include remote boot support as defined in the Preboot Execution Environment (PXE) Specification, Version 2.1. This support may either be included on the adapter, in the system BIOS, or the support may be split between the adapter and the BIOS. See
BIOS–0014.1, "BIOS supports PXE," in Chapter 3.

Note: This is not a requirement for Cardbus adapters or for mini-PCI adapters that are not sold as a part of or with a PC system.

NET–0257. Network adapter and driver supports priority for IEEE 802-style networks

Windows Quality of Service (QOS) components provide link layer priority information to NDIS 5.0 miniport drivers in each transmitted packet’s NDIS_PER_PACKET_INFO structure.

Priority values are derived by mapping Internet Engineering Task Force (IETF) Integrated Services (IntServ, RFC 1663) service typed to IEEE 802.1p priority values, referred to as the user priority object. Current IETF references include:

  • The Subnet Bandwidth Manager.
  • Framework for integrated services over 802 networks.
  • Mapping integrated services to 802.1p.

The IntServ service type used for the mapping is determined by QOS-aware applications or, on behalf of the application, by QOS-aware operating system components. Driver support for link layer priority information must adhere to IEEE 802.lp priority values.

IEEE 802.1p/q-capable Ethernet drivers must use the priority level indicated in the NDIS_PER_PACKET_INFO structure to generate the corresponding field in the IEEE 802.1p/q MAC headers of transmitted packets. Similarly, these drivers must extract the appropriate information from the MAC headers of received packets and copy the priority to the NDIS_PER_PACKET_INFO structure before indicating the packet to higher protocol layers.

Notice that any link layer driver has the ability to interpret the priority information in the NDIS_PER_PACKET_INFO structure and use it as appropriate for the particular media.

For more information, see the Windows 2000 DDK and "QOS: Assigning Priority in IEEE 802-style Networks."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


ADSL Requirements

This section summarizes requirements for ADSL hardware.

Note: All ATM requirements also apply to ADSL devices.

Windows Me and Windows 2000 provides support for ADSL adapters and external ADSL modems, such as those using USB, which provide a faster method for moving data over regular phone lines.

Thirty leading ADSL vendors jointly developed the white paper, An Interoperable End-to-end Broadband Service Architecture over ADSL Systems (Version 3.0), which discusses end-to-end service interoperability over ATM over ADSL. The core idea of this white paper (PPP over ATM over ADSL) has been adopted by the ADSL Forum. This paper is available at the Web site listed in "Network Communications References."

NET–0273. Integrated ADSL modem meets PC 2001 network adapter requirements

ADSL modems must meet all requirements stated in "Network Adapter Requirements." In addition, integrated ADSL modems exposing an Ethernet interface must meet NET–0254, "Adapter supports filtering for at least 16 multicast addresses."

NET–0274. DSL modem supports G.994.1

ITU-T G.994.1, Handshake procedures for digital subscriber line (DSL) transceivers, is the international standard that defines mechanisms to allow DSL transceivers to exchange capabilities and to select a common mode of operation. G.994.1 supports modulation standards G.991.1 High bit-rate Digital Subscriber Line (HDSL), G.992.1 (full-rate discrete multitone [DMT] ADSL), G.992.2 ("G.lite" DMT ADSL), T1.413 Issue 2 (ANSI full-rate ADSL), and T1 TR-59 (CAP/QAM).

Use of G.994.1 allows the customer premises and central office DSL modems to negotiate a common mode of operation, and more importantly, identifies the cause of failure when the link is not established due to the incompatible modes of operation of the two modems.

NET–0275. CAP/QAM ADSL modem supports T1 TR-59

U.S. T1 committee Technical Report TR-59, "Single-Carrier Rate Adaptive Digital Subscriber Line (RADSL)," is the industry consensus specification for CAP/QAM ADSL modems. ADSL modems that support CAP/QAM modulation must implement TR-59. CAP/QAM ADSL modems may also support other modulation methods such as DMT.

Note: TR-59 is not a U.S. ANSI standard for ADSL modems, but is supported by some network access providers.

CAP/QAM ADSL modems must support G.994.1.

NET–0276. DMT ADSL modem supports G.992.2

ITU-T G.992.2, also known as G.lite, is the international standard for DMT modems, which includes features to facilitate easy, end-user installation. ADSL modems that support DMT modulation must implement G.992.2. DMT ADSL modems also may support other modulation standards, such as G.992.1, ANSI T1.413 Issue 2, or other modulation methods such as CAP/QAM, and so forth.

DMT ADSL modems must:

  • Support the L0 (Full On) and L3 (Idle) link states.
  • Support the T0e, T0f, T3a, and T3b link transitions.
  • Support G.994.1.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Wireless Networking

Wireless networking media types enable WAN, LAN, and personal area network (PAN) connectivity. This section lists additional requirements for wireless media. For wireless modem requirements, see Chapter 13, "Modems." For more information about Bluetooth devices, see "Bluetooth" in Chapter 6. In addition, wireless adapters must support filtering for at least 16 multicast addresses. See NET–0254, "Adapter supports filtering for at least 16 multicast addresses."

NET–0278. Wireless networking media adapters support wireless extensions to NDIS

Wireless extensions to NDIS are documented in "Network-Dependent Wireless Objects" in Network Drivers in the Windows 2000 DDK. These extensions are based on the work of the Portable Computer and Communications Association, published in STD-201: Extensions to NDIS for Wireless WANs, listed in "Network Communications References."

NET–0279. IEEE 802.11 wireless networking adapters support industry specifications

IEEE 802.11 wireless networking adapters must support 11Mbps signaling using Direct Sequence Spread Spectrum.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


IrDA Requirements for Network Communications

The interface between IrDA hardware (framers) and the Windows IrDA stack is through NDIS 5.0 miniport drivers that adhere to the conventions defined in Infrared Extensions to the NDIS Version 4.0 Functional Specification. The Windows IrDA stack expects that hardware and NDIS drivers deal with framing, transparency, and error detection, as well as supporting media-sense and speed-change commands. Miniport drivers are responsible for discarding incoming frames with bad cyclic redundancy checks. Never forward these frames to the protocol.

Although the IrDA protocol stack in Windows 2000 is different from the one on Windows Me, use the Windows 2000 DDK for driver development for both platforms. The Windows 2000 IrDA protocol stack imposes stricter requirements on drivers than the protocol stack on Windows Me.

NET–0280. Infrared device meets PC 2001 network adapter requirements

IrDA devices must meet all requirements stated in "Network Adapter Requirements."

NET–0281. Infrared device supports both FIR and SIR

All infrared devices must comply with approved IrDA specifications, including support for SIR, FIR, and optional Very Fast IR (VFIR) data devices.

NET–0282. IrDA hardware supports unattended driver installation

FIR Plug and Play hardware must report a unique Plug and Play ID that matches the combination of the chip set, transceiver, and any other system-specific parameters for the operating system to find and install the correct INF file and the associated driver for the IrDA hardware.

In the best case, the IrDA hardware has only one Plug and Play ID associated INF file and a miniport driver that can autodetect the transceiver type and other system-specific parameters. This combination enables the installation and configuration of the hardware and the driver without user intervention.

In other cases, for example, where the miniport driver cannot autodetect the transceiver type or any other system-specific parameters, a unique Plug and Play ID for each combination of the chip set and the transceiver type must be reported. Also, the vendor must provide for each combination an associated driver and INF file describing the configuration parameters.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Home Networking Media

New networking media types are being invented to make it easy for PC users in homes and small businesses to implement simple LANs without needing to install new wires. This section lists additional requirements for these media. The media types listed in this section cover wireless and re-use of existing telephone wiring.

NET–0283. If implemented, home networking adapter meets PC 2001 network adapter requirements

Home network adapters must meet all requirements stated in "Network Adapter Requirements." In addition, they must meet following requirements:

  • NET–0254, "Adapter supports filtering for at least 16 multicast addresses"
  • NET–0255, "Adapter and driver support promiscuous mode" for network media that confine network traffic signals within a single home
NET–0284. Network adapter that supports Home RF complies with SWAP specification

A PC 2001 network adapter that implements HomeRF, must comply with Shared Wireless Access Protocol (SWAP) Specification, Version 1.1. The HomeRF Working Group (HRFWG) publishes this specification, which is listed in "Network Communications References." The Web site has a technical summary and document ordering information.

NET–0285. If implemented, network adapter that supports HomePNA complies with 1.0 specification.

A PC 2001 network adapter that implements HomePNA technology must comply with the Home Phoneline Networking Alliance Spec, Version 1.0.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Plug and Play and Bus Design for Network Communications

The items in this section are requirements for Plug and Play capabilities.

NET–0286. Plug and Play capabilities support multiple adapters

For network communications devices, the Plug and Play IDs and resource support must be sufficient to allow the automatic addition of multiple network communications devices to the system.

NET–0287. All resource settings are reported in the user interface

All resource settings must be viewable in the Device Manager and in the adapter properties dialog boxes. All resource settings that can be changed by the user must be changed using the standard Windows user interface, not through the use of INI files or other setting files.

This requirement implies that all device resources must be set and read through the standard interfaces provided by the bus on which the device resides. For PCI devices, this interface is the PCI configuration space. Also, device parameter settings must be stored in the registry.

NET–0288. External networking devices support standard control interfaces

External networking devices attached using a serial bus (USB, USB 2.0, IEEE 1394, or Bluetooth) must support standard control interface specifications where applicable.

All external USB networking devices must support Universal Serial Bus Class Definitions for Communication Devices, Version 1.1 (CDC 1.1), listed in "Network Communications References."

If implemented, external USB networking adapters must support one of the following:

  • Ethernet connection model (CDC 1.1)
  • Remote NDIS over CDC 1.1
  • COMMON ISDN-API (CAPI) over CDC 1.1 (ISDN adapters)

If implemented, external IEEE 1394 networking adapters must support remote NDIS over SBP-2.

If implemented, external Bluetooth network devices must support at least one of the applicable profiles defined by the Bluetooth SIG, such as Specification of the Bluetooth System, Volume 2: Profiles, v1.0B.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Power Management for Network Communications

This section summarizes the specific power management requirements for network communications devices.

NET–0289. Adapter complies with network power management specification

The Network Device Class Power Management Reference Specification, Version 1.0a, provides definitions of the OnNow device power states (D0–D3) for network adapters. The specification also covers the device functionality expected in each power state and the possible wakeup event definitions for the class.

Network communications devices that directly attach to the PC over USB, PCI, and IEEE 1394 must comply with this specification.

NET–0290. Network device supports wakeup events

This requirement applies specifically to the following network communications devices and their associated NDIS 5.0 miniport drivers:

  • Ethernet and Token Ring network adapters
  • Integrated DOCSIS cable modems
  • Other devices that transfer IEEE 802.3/DIX Ethernet framed packets

Note: Network Device Class Power Management Reference Specification, Version 1.0a, does not yet define wakeup mechanisms for ISDN adapters or any network communications adapter that uses ATM signaling, including ADSL.

The system must be capable of wakeup from a lower power state based on network events that are specified by the local networking software. As a result of this capability, any standard Windows network access—such as connections to shared drives and WinSock connections, plus service and management applications—can wake a system from lower power states transparently.

External networking devices using USB or IEEE 1394 are not required to support Wake on LAN while operating on bus power. No wireless network connection is required to support Wake on LAN.

Mobile PC Note

For mobile PCs, network device wakeup is not required.

As defined in Network Device Class Power Management Reference Specification, a network adapter and its driver must support wakeup on receipt of a network wakeup frame. Support for wakeup on detection of a change in the network link state or on receipt of a magic packet event is optional. Implementation details are described in the "Network Wakeup Frames" and "Network Wakeup Frame Details" sections of Network Device Class Power Management Reference Specification, Version 1.0a, and in the Windows 2000 DDK.

The packet patterns that define the wakeup frames are provided to the NDIS 5.0 miniport driver by the operating system. To enable Wake on LAN capability for basic networking scenarios, the network adapter must be capable of storing information describing a minimum of three wakeup packet patterns and of generating a wakeup indication on recognition of any wakeup packet. A wakeup packet is a packet that includes a wakeup pattern anywhere within the first 120 bytes of the packet. The minimum set of wake-up packets that must be recognized are the following:

  • A packet directed to at least one IP address
  • An IP address resolution protocol (ARP) packet
  • A packet containing NetBIOS name queries, or any arbitrary string

PCI-based network adapters must support the generation of a power management event (PME# assertion) from the D3cold device state if the physical layer technology is generally capable of operating under the voltage and current constraints of the D3cold device state.

Note: 1000baseSX or 1000baseLX (gigabit Ethernet using optical fiber media) cannot meet this requirement because of the power required to operate the optical physical layer. The same applies for FDDI adapters.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Device Drivers and Installation for Network Communications

This section summarizes requirements for network communications device drivers, in addition to the requirements for using an NDIS 5.0 miniport driver.

NET–0291. Driver works correctly with Microsoft network clients and protocols

This requirement includes the 32-bit Microsoft client and NetWare-compatible clients provided with Windows, whether connected to a Windows 2000 server, a Novell NetWare 3.x or 4.x server, or a Windows-based peer server. In all cases, this requirement applies to connections using Microsoft TCP/IP, IPX/SPX-compatible protocol, and NetBEUI in LANs and Transmission Control Protocol/Internet Protocol (TCP/IP) in WANs.

NET–0292. NDIS miniport driver makes only NDIS library calls or WDM system calls

A miniport driver must make calls only to the NDIS library or the WDM system to provide binary compatibility of the driver between Windows Me and Windows 2000.

NET–0293. NDIS 5.0 driver uses Windows 2000 INF file format

All network components must use the INF file format defined in the Windows 2000 DDK.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Basic Printer Requirements

This section summarizes the basic PC 2001 hardware requirements for printers.

PRNT–0294. Device uses USB, IEEE 1394, or network interface port connection

PC 2001 requires the use of a USB, IEEE 1394, or network interface port connection for printers. No proprietary solutions are acceptable; however, other legacy port connections may be present on the device.

USB printers must conform to Universal Serial Bus Device Class Definition for Printing Devices, Version 1.1.

Network printers must meet the requirements in Chapter 14, "Network Communications."

If an IEEE 1284, serial, or IR port connection is included on the printer, that connection must meet the requirements defined in Legacy Plug and Play Guidelines, which contains the requirements for these connections as defined in earlier versions of the system design guide.

PRNT–0295. Network printer supports standard port monitor

Network-connected printers must support TCP/IP standards for Line Printer Remote (LPR) and Line Printer Daemon (LPD) (RFC 1179), Port 9100 printing (raw mode printing), or both types.

PRNT–0296. Device with IEEE 1284.4 capabilities complies with specification

If any device provides IEEE 1284.4 capabilities, the device must comply with the IEEE 1284.4 specification.

PRNT–0297. MFP devices correctly implement multifunction support

If a device—commonly referred to as a multifunction printer (MFP)—contains more than print-only capabilities, then driver support, INF file requirements, device ID, resource allocation, and other Plug and Play capabilities for all functions in the device comply with the requirements defined in Multifunction Print Device Design Guidelines for compatibility with Windows operating systems. This paper is listed in "Printers References."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Device Drivers and Installation for Printers

This section summarizes device driver requirements for printers. The items in this section are requirements for all PC 2001 systems.

PRNT–0298. Printer INF file and installation meet PC 2001 requirements

The manufacturer must provide a printer INF file that installs all printer device components. The manufacturer does not need to supply a printer INF file if a standard printer INF file provided with the operating system can be used.

INF file requirements for MFPs are defined in requirement PRNT–0297, "MFP devices correctly implement multifunction support."

If the manufacturer provides an INF file, it must be complete and free of errors. This INF file must comply with the printer-specific extensions listed in the Windows 98 DDK and Windows 2000 DDK and requirement SYS–0025, "Each device, device driver, and installation of either device or driver meet PC 2001 requirements," in Chapter 3.

Plug and Play IDs must be specific, and INF file [Install] sections must only key off the most specific IDs, as described in the following list.

Plug and Play ID Strings

Protocol | ID string in the printer INF file
USB | Contains &VID and &PID in the ID string
IEEE 1394 | Always specific, with 1394 in the ID string
Parallel port printer | Contains LPTENUM\ in the ID string
USB printer | Contains USBPRINT\ in the ID string
Dot4 printer | Contains DOT4\ in the ID string

For Windows 2000, DEVMODEW structure is defined in "Graphics Driver Structures" of "Common Graphics Driver Interface" in the "Graphics Drivers Reference" of the Windows 2000 DDK.

For Windows Me, DEVMODE structure is defined in "New Function and Structure Reference" of "Printer Driver Overview" in the "Windows 95 Documentation" of the Windows 98 DDK.

PRNT–0299. Driver correctly reports device capabilities

The driver must correctly support the DEVMODE structure as defined in Windows 98 DDK and Windows 2000 DDK.

Required Windows Me support is defined in "Printer INF File Extension" and "Printer-Specific INF File Extensions Reference" in the "Windows 95 Documentation" of the Windows 98 DDK.

Required Windows 2000 support is defined in "Printer Drivers and Spooler Components" of "Graphics Drivers Design Guide" in the Windows 2000 DDK.

PRNT–0300. Driver supports sRGB output or an ICC profile is provided

The device must default either to creating sRGB output or using a vendor-supplied ICC profile.

Windows Me and Windows 2000 support using color profiles that comply with the Specification ICC.1:1998-09 File Format for Color Profiles, listed in "Printers References." The ICM APIs and functionality for Windows Me, Windows 98, and Windows 2000 are defined in the Microsoft Platform SDK, the Windows 98 DDK, Windows Me DDK, and the Windows 2000 DDK. For further information, see the Color Management and Windows Operating Systems Web page, listed in "Printers References."

For color-capable devices that do not default to sRGB output, the vendor must install and associate one or more ICC profiles for ICM. Devices that are sRGB-compliant do not need to provide an ICC profile. The sRGB profile is distributed in Windows Me and Windows 2000 and subsequent releases to these operating systems.

The requirements for sRGB are defined in IEC 61966-2-1 Multimedia systems and equipment – Colour measurement and management – Part 2-1: Colour management – Default RGB colour space – sRGB, listed in "Printers References."

PRNT–0301. Color printer complies with Windows Color Quality Specifications

Color matching capabilities supported in a color printer must comply with the requirements defined in Section 8 of "Windows color quality specifications for printer OEMs," listed in "Printers References." In particular, the following Delta E tolerances must be met for image, graphics, and Pantone patches with default rendering intent:

  • Average Delta E less than or equal to 12 for center colors
  • Average Delta E less than or equal to 20 for device colors
PRNT–0302. Port monitor software meets DDK requirements

Any port monitor or language monitor software provided with a print device must accurately report errors and support bidirectional communication as defined in the Windows 98 DDK and Windows 2000 DDK. The relevant DDK sections are cited in requirement PRNT–306, "Driver supports required DDIs."

PRNT–0303. Driver supports point-and-print network installation

The user must be able to install a driver from a server by double-clicking on the printer share icon.

This capability must accommodate file-number limits and other differences between operating systems that might run on the client and server.

PRNT–0304. Device is available immediately following installation

The user must not have to restart the system after device installation in order to print.

PRNT–0305. Device supports accurate printable regions

The printable regions that can be selected in the user interface must be accurately supported in the actual print output.

PRNT–0306. Driver supports required DDIs

Printer drivers must make sure that print commands from Win32-based applications are executed correctly on the specified printer or plotter. Because these APIs are not hardware specific, each printer driver must interpret the commands for its specific hardware.

For Windows 2000 drivers, the required device driver interfaces (DDIs) are defined in the Windows 2000 DDK. See "Printer Drivers and Spooler Components" in the Windows 2000 DDK.

For Windows Me drivers, this requirement includes correct support of all features advertised for the device, plus required support for Windows features. The required DDIs for Windows Me drivers are listed in the "Printer Driver Overview" in the "Windows 95 Documentation" of the Windows 98 DDK.

PRNT–0307. Printer driver does not run in kernel mode

Printer drivers for Windows 2000 must run only in user mode. Drivers that run in kernel mode can incur stability problems. For driver implementation requirements, see "Choosing User Mode or Kernel Mode" in the DDK, listed in "Printer References."

PRNT–0308. Printer device and driver support Default Device-class Power Management Specification

All printer devices, printer drivers, and supporting components must support the D0 and D3 power states consistent with the Default Device Class Power Management Reference Specification, Version 1.0. Each device must be able to complete successfully a system sleep/wake transition, where the device transitions from D0 to D3 to D0, without losing functionality and without requiring user intervention to restore functionality. System power must be removed in the D3 state.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Digital Still Image Devices Basic Requirements

This section summarizes the basic PC 2001 hardware requirements for scanners and digital cameras.

IMAG–0309. Digital still camera uses PC 2001 compatible port connection with USB or IEEE 1394 connection

PC 2001 must use either USB or IEEE 1394 port connections for digital still cameras. Other port connections may be present on the device, if these port connections meet PC 2001 requirements.

IMAG–0310. Driver supports sRGB output or an ICC profile is provided

The device must default either to creating sRGB output or using a vendor-supplied ICC profile.

Windows Me and Windows 2000 support using color profiles that comply with the Specification ICC.1:1998-09 File Format for Color Profiles. The ICM APIs and functionality for Windows Me and Windows 2000 are defined in the Microsoft Platform SDK, the Windows Me DDK, and the Windows 2000 DDK. For more information, see the Color Management and Windows Operating Systems Web page, listed in "Digital Still Image Peripherals References."

For color-capable devices that do not default to sRGB output, the vendor must install and associate one or more ICC profiles for ICM. Devices that are sRGB compliant do not need to provide an ICC profile. The sRGB profile is distributed in Windows Me and Windows 2000 and will be in subsequent releases of these operating systems.

The requirements for sRGB are defined in IEC 61966-2-1 Multimedia systems and equipment – Colour measurement and management – Part 2-1: Colour management – Default RGB colour space – sRGB.

IMAG–0311. USB device meets USB imaging device class specifications

All USB hardware must comply with the requirements defined in Chapter 6, "Buses and Interfaces," which includes the USB specifications for specific device types.

Compliance with the following two specifications from the USB Imaging Class Device Working Group requires explanation, as follows:

  • The USB Still Image Capture Device Definition Specification applies to both digital still cameras and scanners. Compliance becomes a requirement for PC 2001 within 90 days of when the revision number of the specification reaches version 1.0.
  • The USB Imaging Class Specification will contain requirements for still images produced by scanners. The USB digital still camera specification is based on the draft for PIMA 15740:2000 Photography – Electronic still picture imaging – Picture Transfer Protocol (PTP) for Digital Still Photography Devices.
IMAG–0312. Still image devices meet minimum throughput requirements

Still image devices must download images to the PC and make them available through WIA to applications at no less than the following rates:

  • Fast IR at 80 Kpixels/s
  • USB at 120 Kpixels/s
  • IEEE 1394 at 200 Kpixels/s

For more information on WIA, see the Windows Image Acquisition Web page, listed in "Digital Still Image Peripherals References."

IMAG–0313. Digital camera uses PC-compatible file system for removable storage

For devices that include removable flash memory, the memory must use one of the following PC-compatible file systems:

  • Media integrates an ATA controller.
  • Device file system installs via the Windows 2000 Professional Installable File System.
  • Device ships with a Windows Media Device Manager (WMDM) pluggable service provider.
IMAG–0314. Digital camera stores images in JPEG-compressed file format

A digital still camera must provide the user with the option to store images in a JPEG-compressed format.

IMAG–0315. Still image devices deliver accurate image information

Imaging devices must resolve at least 1/4 line per claimed pixel resolution in both the horizontal and the vertical direction to ensure greater image capture accuracy. This requirement applies to the device’s best quality setting.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Plug and Play for Digital Still Image Devices

The items in this section are requirements for Plug and Play capabilities. For Plug and Play requirements related to parallel ports, see the Legacy Plug and Play Guidelines.

IMAG–0316. USB camera firmware supports PIMA 15740 protocol

PIMA 15740 defines a common protocol for all digital still cameras, ensuring PC connectivity using a generic driver provided with the Windows operating system. This protocol is supported by imaging industry leaders. PIMA 15740 provides interoperability of digital still cameras, including PC and peer-to-peer connectivity.

For information, see the draft for PIMA 15740.

Note: A USB camera does not need to supply a WIA driver if the camera firmware supports PIMA 15740.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Device Drivers and Installation for Digital Still Image Devices

This section summarizes the device driver requirements for scanners and digital still image devices.

IMAG–0317. Driver support implements the WIA driver architecture

Still image devices must provide drivers based on WIA that expose camera properties and enable camera functionality. The services provided by WIA provide hardware abstraction, installation wizards, and event polling.

WIA is both an API and a DDI for Windows operating systems. WIA provides a mechanism to enumerate available image acquisition devices, both local and remote.

WIA architecture is defined in the "Still Image Drivers" section of the Windows 2000 DDK. For related information, see the Windows Image Acquisition Web page, listed in "Digital Still Image Peripherals References."

Note: The IR bus interface is exempt from this requirement.

IMAG–0318. Digital still cameras that stream video require WDM Stream class drivers

Cameras capable of streaming video while tethered to the PC must provide a WDM minidriver based on WDM stream class support.

WDM stream class support is defined in the "Kernel-mode Drivers for Still Image Devices" section of the Windows 2000 DDK.

IMAG–0319. If TWAIN datasources are provided, device driver supports TWAIN 1.7

For devices with a TWAIN datasource, the device driver must support the TWAIN Specification, Version 1.7, ensuring that the device can run without a hardware-specific user interface and download n number of images at a single time.

IMAG–0321. Scanners with an IEEE 1394 interface uses SBP2Port

SBP2Port.sys is the IEEE 1394 transport driver in the Windows Me and Windows 2000 operating systems. It provides transport services for SCSI-like commands over IEEE 1394. Scanners must use SBP2Port to communicate over IEEE 1394 if converting the device from a SCSI or SCSI-like interface.

Implementation details for bus-specific transfer protocols are defined in the "Storage Driver Architecture" section of the Windows 2000 DDK.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


PC 2001 Graphics and Video Requirements

The following requirements describe video requirements in a PC 2001 system.

SYS–0035. If DVD-Video playback is implemented, PC 2001 system provides video playback capabilities

Video playback capability is required in PC 2001 systems. PCs must be capable of decoding MPEG streams, however this is not a requirement to ship an MPEG decoder with the system. Systems must meet the requirements under "MPEG-2 Video Playback Requirements" and "DVD-Video Playback Requirements" in Chapter 9.

Mobile PC Note

Mobile PC 2001 systems require support of 640 × 480, 16 bpp mode only.

SYS–0036. If video capture is implemented, analog video input and capture capabilities comply with PC 2001 requirements

If video-capture capability is implemented in a PC 2001 system, it must meet the requirements VID–0210, "Video input, capture, and broadcast device support is based on DirectX foundation class and WDM Stream class or AV Stream class"; VID–0224, "If implemented, video input or capture device provides raw sampled VBI data to the host"; and VID–0225, "If implemented, VBI capture oversamples VBI data exactly 4.7 or 5 times," in Chapter 9.

SYS–0037. If Digital Video Interface is implemented, components comply with PC 2001 requirements

Digital interfaces for monitors comply with Digital Visual Interface (DVI), Revision 1.0. See MON–0241, "Digital display interface is DVI compliant," in Chapter 10.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


PC 2001 Storage Requirements

The following storage requirements apply to all PC 2001 systems.

SYS–0038. PC 2001 system includes hard disk and controller

The host controller for hard disk devices must support bus mastering. Bus master capabilities must meet the related specification for the particular controller.

Storage bus devices must not use the ISA bus.

Hard disk and optical devices must meet the requirements defined in Chapter 12, "Storage."

Note: This requirement does not apply for closed-case platforms that do not include an HDD and are designed to boot from the network.

SYS–0039. PC 2001 system includes either CD or DVD drive and controller

The CD or DVD drive and controller must meet the requirements defined in Chapter 12, "Storage."

Note: This requirement does not apply for closed-case platforms that do not include an HDD and are designed to boot from the network.

Mobile PC Note

For requirements for mobile PC systems, see MOBL–0072, "If implemented, CD or DVD drive meets PC 2001 requirements," in Chapter 5.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


PC 2001 Legacy-Reduced System Requirements

This section defines requirements for migration away from legacy architectures for all PC 2001 systems.

SYS–0041. System does not include ISA expansion devices or slots

PC 2001 systems do not include any ISA expansion devices or user-accessible ISA slots.

Systems that are not designed to meet PC 2001 legacy-free requirements can use ISA or ISA-like protocols and signaling for implementations of legacy devices such as the controllers for serial, parallel, 8042, floppy disk drive, and so on. For information, see Legacy Plug and Play Guidelines

SYS–0042. Preinstalled components and upgrades do not require MS-DOS or legacy interfaces

Peripherals included with the system must offer a non-legacy interface such as PCI, USB, USB 2.0, SCSI, IEEE 1394, or CardBus. Peripherals can include both a legacy interface and a non-legacy interface. Proprietary interfaces are not acceptable.

The keyboard and pointing devices can use a PS/2 compatible interface.

SYS–0067. Secondary boot and upgrade capability is independent of FDC-based floppy disk drive

The system must be capable of recovery and upgrade of the hard drive image and BIOS independent of an FDC-based floppy disk drive. Options include a CD or DVD drive attached to USB, ATA, IEEE 1394, or SCSI.

Note: This requirement does not apply to Windows NT 4.0 recovery media that ships or is offered with the system.

Recovery storage devices do not have to be CD- or DVD-based, but must include recovery media from the OEM that does not limit upgrades from production optical media.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


PC 2001 Legacy-Free System Requirements

This section defines the hardware requirements for legacy-free systems that will be implemented under PC 2001 requirements.

The basic goal for the legacy-free system requirements is that the operating system and devices do not use any of the following:

  • ISA slots or devices
  • Legacy FDC
  • PS/2, serial, parallel, and game ports

Revisions to the ACPI specification provide a mechanism that allows the BIOS to report whether a system provides the services of these components and interfaces. If the BIOS reports that the system is legacy free, the system must meet the requirements provided in this section.

Note: The requirements for legacy-free systems are additional to those defined in "PC 2001 Legacy Reduction Requirements."

BIOS–0043. BIOS supports required interrupts

The list in Appendix A, "Resource Mapping," shows the known BIOS dependencies for which support is required. All subfunctions must be present on a legacy-free PC 2001 system as described in Appendix A.

BIOS–0013. BIOS supports legacy removal

The BIOS does not include boot dependencies on ISA, and no ISA-related components appear on BIOS setup screen.

BIOS–0045. No legacy ports detected

The following ports are considered legacy ports and must be replaced by USB or other non-legacy equivalents:

  • FDC
  • Serial
  • Parallel
  • PS/2-compatible ports
  • ISA-based game ports and MPU 401 (Musical Instrument Digital Interface [MIDI]) ports

These ports must not be available for external connection and must not be detected by the operating system as enabled.

In addition, the 8042 controller can be present and reported through ACPI, although PS/2-compatible ports cannot be provided for connecting external devices.

Systems can provide Super I/O-based IrDA support.

Mobile PC Note

New docking stations designed specifically for legacy-free mobile PCs must follow these requirements. This does not preclude existing docked mobile PC designs from being used with legacy-free mobile PCs.

The following table shows the I/O addresses and interrupts related to the restricted legacy devices. Do not use these resources except as noted in the table. If hardware is present and disabled, ACPI declaration must claim the resources so they cannot be freed.

Restricted Port Addresses

Device | I/O Address | Interrupts
COM 1 | 2E8–2EF 2F8–2FF2 3E8–3EF 3F8–3FF | IRQ32, IRQ4
LPT | 278–27A 378–37A 3BC–3BE | IRQ 7
Joystick/game port | 0200–020F |
Sound Blaster | 0220–022F |
MPU-401 (MIDI) | 0330–0331 |
FDC | 3F0–3F7 | IRQ 6

1 An internal COM port header can be used as a debug port solution if the COM port is not exposed to the end user. In this case, the COM port must not use the I/O addresses listed in this table; the relocated COM I/O address must be reported in the ACPI Debug Port table.

2 An IrDA controller is permitted to use these resources.

SYS–0040. If implemented, floppy disk capabilities do not use legacy FDC

To support migration away from legacy devices, floppy disk drives on PC 2001 systems must be based on a solution other than an FDC. Solutions include: ATAPI floppy disk drive compliant with SFF-8070i, USB, IEEE 1394, PC Card, or SCSI-based floppy disk drives.

The device and its controller must meet the general requirements defined in Chapter 12, "Storage."

SYS–0047. A20M# is always de-asserted (pulled high) at the processor

If A20M# generation logic is still present in the system, this logic must be terminated such that software writes to I/O port 92, bit 1, do not result in A20M# being asserted to the processor.

SYS–0046. System supports legacy-free debug capabilities
  • Legacy-free systems must implement a debug solution that complies with the Debug Port Specification, listed in "PC System References."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Port Replicator Definition

For the purposes of these requirements, a port replicator is an acceptable method for adding the following functionality to a mobile PC.

  • Cable management by passing through the following connectors and buses. All the following pass-through connections must be compliant with their respective requirements, specifications, and standards:

Any bus used exclusively for manageability

Audio, including line-in, line-out, microphone, and headphone

Floppy drive

Game port

IEEE 1394 PHY (see note)

LAN

MIDI port

Modem

Parallel or LPT port

PS/2 port

Serial port

USB connector: pass-through connector is allowed to be low power

Video

Note: The IEEE 1394 socket available in the port replicator must meet the requirements for externally accessible IEEE 1394 sockets according to
1394–0093, "If the IEEE 1394 implementation provides external connectivity, system must use only sockets specified by IEEE 1394-1995 and its amendments" in Chapter 6.

  • USB hub

USB hub is compliant with requirements listed in Chapter 6, "Buses and Interfaces."

  • Power supply (if needed)

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Docking Station Requirements

This section describes the requirements for docking stations or docked mobile PCs.

For the purposes of these requirements, a docking station includes the functionality of a port replicator along with additional expansion in the form of enumerable devices or slots and connects to the mobile PC’s PCI bus.

MOBL–0073. Docked mobile PC has the ability to identify the specific model of the dock and to uniquely identify the dock itself

Upon attachment to a docking station, the mobile PC must provide the operating system with the dock’s model number and a unique ID for the dock using the _UID or _BDN ACPI methods. The system vendor may choose the format of the model number and unique dock ID as well as the mechanism for storing and retrieving the data.

For more information on the _UID and _BDN methods, refer to section 6.1.6 of ACPI 1.0b.

MOBL–0074. Docked mobile PC combination meets PC 2001 Mobile requirements

If a mobile PC is shipped with a PC 2001 docking station, the docked mobile PC must meet PC 2001 Mobile requirements.

MOBL–0075. Docking station includes driver support

Drivers for devices in a dock must fully support dynamic loading and unloading, power management, and Plug and Play event messages.

MOBL–0076. Docked mobile PC meets PC 2001 BIOS requirements

The docked mobile PC must meet the PC 2001 BIOS requirement for multiple adapters and multiple monitors. This provides fully operational graphics capabilities in the mobile PC (either the LCD panel or external connector) in the event that a user adds another graphics adapter to the docking station. For more information, see GRPH–0199, "Onboard graphics devices can be used as a system boot device," in Chapter 8.

MOBL–0077. Pre–PC 2001 docking station requirements

PC 2001 mobile PCs with docking station support do not require new docking station designs. A PC 2001 mobile PC combined with a pre–PC 2001 docking station must meet the following requirements:

  • The user cannot experience resource conflicts.
  • All drivers for earlier docking stations must be made available as necessary to support the preinstalled operating system. OEMs can determine how to distribute these drivers, including methods such as an OEM Web site or the Windows update Web site.

This requirement applies only to drivers for devices that were offered as part of the OEM-supplied configuration; it does not apply to devices added to the docking station by systems integrators or end users.

For example, in order for pre–PC 2001 docking stations to work properly with a PC 2001 mobile PC running Windows 2000, all drivers must be updated to support dynamic loading, Plug and Play, and power management messages. This requirement does not imply that new features must be added, but rather that the docked mobile PC and operating system must have full control over the features in the docking station.

MOBL–0078. Mobile/docking station interface uses ACPI-defined mechanisms

The docked mobile PC must enumerate, configure, and disable non-Plug and Play devices using ACPI-based methods, and implement all notification events and docking control as follows.

The mobile PC’s ACPI BIOS must contain at least the following docking-related functions:

  • DCK_CAP must be set to 1 in the FADT table.
  • _Lxx methods must handle the dock insertion event and the Fail Safe Ejection notification. The _Lxx method must include a Notify to the dock object.
  • ACPI descriptions for ports located on the mobile PC and passed through the docking connector must include an _EJD method.
  • The _WAK method must perform a Notify to the dock object.

A dock object must be specified and must have a device named to represent the docking station, including:

  • _UID method for presenting the dock’s model number and unique ID to the operating system.
  • Optional _BDN method for using the Plug and Play BIOS for dock model number and _UID.
  • _DCK method connecting and disconnecting the docking bus.
  • _STA method for checking the status of the dock.
  • _EJx methods to identify which sleep states docking can occur. If hot docking is implemented, the _EJ0 control method must not return until the ejection is complete, as stated in ACPI 1.0b section 6.3.2.

For additional information on ACPI docking implementation, refer to ACPI 1.0b and "ACPI Docking for Windows 2000," listed in "Mobile References."

Removable ATA devices in the docking station and in the mobile PC are required to report changes using ACPI-based methods.

Note: Under Windows 2000, drive letter assignments do not change when drives are added or removed by way of a docking event. That is, all drives in the mobile PC retain their originally assigned drive letters. Note this difference from Windows Me.

MOBL–0079. Docking station supports warm docking

Attaching or ejecting a mobile PC from a docking station must not require powering off the system and must not require a system reboot.

The mobile PC’s ACPI BIOS must contain one or more _EJx methods to inform the operating system of which sleep states are supported for docking operations.

For more information on the _EJx methods for Windows 2000, refer to Section 6.3.2 I of ACPI 1.0b and to "ACPI Docking for Windows 2000," listed in "Mobile References."

MOBL–0080. Docking system supports fail-safe docking

The system must provide a mechanism for notifying the operating system before undocking a mobile PC. The mechanism, in combination with operating system capabilities and methods defined in Sections 5 and 6 of ACPI 1.0b, must perform the following:

  • The user can initiate undocking through Windows-based software choices and through an eject notification button on the docking station or the mobile PC.
  • The eject notification button or software choice sends a signal to the operating system so that the user is warned if the system is in danger of losing resources or data.
  • A safe-to-undock indicator is provided so the user knows when it is safe to remove the mobile PC. This indicator can be an LED or any other mechanism chosen by the vendor. If a physical mechanism automatically undocks the mobile PC, the safe-to-undock indicator is not required.

There is no requirement for mechanical lockout to block the user from removing the mobile unit without operating-system notification.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


USB Core Requirements

This section covers requirements for the USB 1.1 and 2.0 specifications on PC 2001 systems.

USB–0081. USB system hardware and devices comply with USB specifications

USB system hardware and devices, including hubs, must comply with the Universal Serial Bus Specification, Revision 1.1. If a USB hub or device supports USB 2.0, it must comply with the Universal Serial Bus Specification, Revision 2.0.

When a system has more than one host controller, each host controller must provide full bandwidth and isochronous support. Host controllers must be located on the PCI bus (or equivalent) to meet this requirement. The host controller providing USB 1.1 functionality must comply with the specifications for either OpenHCI: Open Host Controller Interface Specification for USB, published by Compaq, Microsoft, and National Semiconductor, or Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1, published by Intel. Information on OHCI and UHCI is listed in "Buses and Interfaces References." Host controllers providing USB 2.0 functionality must comply with the Enhanced Host Controller Interface Specification for Universal Serial Bus 2.0.

USB–0084. USB devices and drivers support maximum flexibility of hardware interface options

Device and driver designs must provide maximum flexibility for interface options so that the operating system or other vendor-supplied resource management tool can coordinate user preferences, allowing multiple devices and applications simultaneously. Minimum requirements consist of the following.

  • USB–0084.1. Devices and drivers provide multiple alternate settings. Devices and drivers must provide multiple alternate settings for each interface where any alternate setting consumes isochronous bandwidth.
  • USB–0084.2. Devices and drivers must not use isochronous bandwidth for alternate setting 0. Devices must consume bandwidth only when they are in use.
USB–0085. USB host controller and devices can wake the system

The USB host controller must support wakeup capabilities from S1, S2, and S3 states. If the system contains multiple USB host controllers, all host controllers integrated on the system board (that is, not add-on cards) are required to support wakeup from S1, S2, and S3.

USB devices and USB client software and drivers must support multiple system suspend and resume cycles into and out of S3.

USB–0086. USB hubs are self-powered

This requirement does not apply for hubs integrated into USB keyboards or into mobile systems. To minimize USB power consumption requirements, bus-powered hubs must provide ports that can be individually power switched.

USB–0087. USB bus, controllers, and devices comply with USB power management requirements

Devices must comply with the power management requirements in the Universal Serial Bus Specification, Revision 1.1. In addition, devices must comply with the Interface Power Management feature in the Universal Serial Bus Common Class Specification, Revision 1.0.

Mobile PC Note

An internal device that connects to a mobile PC using USB must not continually maintain the system when all component parts are on. Such a device will override system power-management settings that control power-saving modes to protect battery life. When any USB device is connected but not active, the driver must allow system power management to suspend the mobile PC.

USB–0088. USB devices and drivers meet requirements in related USB device class specification

A USB device or driver that fits into one of the USB device class definitions must comply with the related USB device class specification.

If a device vendor builds a device in a device class that does not have generic operating system driver support, or if the vendor must exploit additional, unique hardware features in their device, they can create additional WDM minidrivers.

WDM minidrivers are defined in the "Windows 2000 and WDM Drivers" section of the Windows 2000 DDK.

USB–0089. USB devices install without preloading software

A user must not be required to install software before hot-plugging a USB device. Instead, the user must be able to hot-plug the USB device and then load any software in response to operating system detection of the newly attached device.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Requirements for IEEE 1394 Devices

This section summarizes additional requirements for IEEE 1394 peripherals.

1394–0094. Device command protocols conform to standard device class interfaces

Drivers for devices using the SBP-2 protocol must conform to the requirements set in "SBP-2 Support and Windows 2000," listed in "Buses and Interfaces References."

1394–0095. Peak data rates for internal and external devices meet IEEE 1394 requirements

System designers may incorporate IEEE 1394 devices as external, internal, or both. Minimum requirements consist of the following.

  • 1394–0095.1. Internal devices support the standard IEEE 1394a-2000 Amendment data rates. Internal devices support S400-Mbps minimum. A CD-ROM or DVD drive mounted in an externally accessible bay is an example of an internal device.
  • 1394–0095.2. External devices support IEEE 1394a-2000 data transfer rates. External devices that interoperate with a PC and have more than one socket must support S100 Mbps, S200 Mbps, and S400 Mbps data transfer rates. Devices with a single socket may support only S100- or S200-Mbps data transfer rate. An externally mounted CD-ROM or DVD drive is an example of an external device.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Plug and Play for IEEE 1394

This section summarizes the Plug and Play requirements for IEEE 1394 peripheral devices and PC host controllers.

1394–0096. IEEE 1394 Plug and Play devices demonstrate interoperability with other devices

All devices must support Plug and Play for intended use in both a minimal and an extended bus configuration. A minimal configuration is the minimum number of devices necessary to demonstrate the primary use of the device. An extended configuration has at least two devices added to the minimal configuration. The added devices can be extraneous to the use.

1394–0097. IEEE 1394 devices that initiate peer-to-peer communications provide a remote control interface

All devices capable of initiating peer-to-peer communications that have been designed for use with a PC must provide a remote interface enabling remote control for PC applications that allows a third device, such as a PC or some other device controller, to initiate data transmission between two devices.

For example, two devices communicating on IEEE 1394 use a basic protocol to carry command/status information and the actual data, such as a device driver to handle this communication, with SBP-2 and International Electrotechnical Commission (IEC-61883) as example protocols.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Plug and Play for CSR Space

This section defines the Plug and Play requirements related to Configuration Status Register space.

1394–0098. IEEE 1394 CSR provides unique device identification

The device control and status register (CSR) space must provide configuration information as specified in the IEEE 1212r-2000 standard and applicable IEEE 1394 standards, thus providing Plug and Play device control.

1394–0099. IEEE 1394 device CSR space implements IEEE 1212-2000 format

The CSR space format is specified in the applicable IEEE 1394 standards and the IEEE 1212-2000 standard. The general CSR format is an extensible tree structure enabling a managed environment by providing node-specific and unit-specific information as required for Plug and Play, power management, and isochronous data transfers. The general CSR format also provides for definition of multifunction device units. The bus information block and root directory of the general CSR format are required as specified in CSR table of IEEE 1212-2000.

1394–0100. IEEE 1394 CSR includes a unit directory for each independent device function

A unit directory is required for independent function and control of each device unit. A valid pointer to a unit directory must be provided in the root directory.

1394–0101. Vendor and model leafs support textual descriptor leaf format

Textual descriptors are required for Vendor_ID and Model_ID entries in the CSR space in order to display this information to the user. Each textual descriptor points to a leaf that contains a single character string.

Examples of valid textual descriptors are found in the IEEE 1394 Plug and Play specification.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Power Management for IEEE 1394 Devices

All devices on the IEEE 1394 bus must comply with the power management requirements outlined in this section.

1394–0102. Power Manager notified of device power state changes

The host controller and all devices that provide or consume cable power must conform to all components of the 1394 Trade Association Power Specification.

1394–0103. Devices and controllers comply with all components of the 1394 Trade Association Power Specification

The 1394 Trade Association Power Specification provides requirements for implementation of devices that propagate, source, or sink cable power. In addition, mechanisms are defined by which devices consuming cable power may be enabled as well as placed into a variety of power-consuming states.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


SCSI Host Adapter Requirements

This section summarizes class specifications and standards for SCSI host adapters.

SCSI–0104. SCSI controller complies with SPI-3

All SCSI controllers must meet the hardware and software design requirements in the SCSI Parallel Interface-3 (SPI-3) standard, listed in "Buses and Interfaces References."

SCSI–0105. PCI-based SCSI host controller supports bus mastering and virtual DMA services

The host controller must support PCI bus mastering. PCI bus mastering must be enabled by default and virtual direct access memory (DMA) services must be supported in the host-adapter option ROM.

SCSI–0106. Bootable SCSI controller supports El Torito No Emulation mode and Int 13h Extensions

SCSI host adapters with boot ROMs must support the current No Emulation mode of the "El Torito"–Bootable CD-ROM Format Specification, Version 1.0 and the BIOS Boot Specification, Version 1.01.

The Int 13h Extensions ensure correct support for high-capacity drives, and consistent drive-letter mapping between real mode and protected mode. Support for the fixed-disk access subset of Int 13h Extensions must be provided in the system BIOS and in any option ROMs for storage devices that include BIOS support.

The Int 13h Extensions are defined in the "Layered Block Device Drivers" section of the Windows 98 DDK.

SCSI–0108. Bus type is clearly indicated on connectors for all adapters, peripherals, cables, and terminators

Connectors must comply with the requirements defined in the SCSI-2 standard. The SCSI bus cable must be plugged into shrouded and keyed connectors on the host adapter and devices. For internal configurations, Pin 1 orientation must be designated on one edge of the ribbon cable and also on the keyed connector of the SCSI peripheral device.

Although an external connector is optional, an external connector must be a high-density connector as defined in the SCSI-2 standard.

Clearly label connectors for each SCSI adapter, peripheral, cable, and terminator to indicate the bus type. All external SCSI connectors must display the appropriate SCSI icon defined in the SCSI Parallel Interface (SPI) standard, Annex H, and must display any clarifying abbreviations or acronyms. The following are applicable acronyms and their definitions:

  • DIFF (differential). A signaling method that employs differential drivers and receivers to improve signal-to-noise ratios and increase maximum cable lengths. This method includes both low voltage differential (LVD) and high voltage differential (HVD) types.
  • SE (single-ended). A signaling method that employs drivers and receivers to increase circuit density.
  • LVD (low voltage differential). A signaling method with low signaling voltages supporting higher transfer rates.
  • HVD (high voltage differential). A signaling method with high signaling voltages.
SCSI–0109. Differential devices support DIFFSENS as defined in the SPI-3 Standard

Without DIFFSENS, the differential bus drivers, a single-ended device, or both could be damaged if a single-ended device is connected to a differential bus.

The standard for DIFFSENS is defined in the SPI-3 standards document.

SCSI–0110. Automatic termination circuit and SCSI terminators meet SPI-3 standard

SCSI add-on adapters and on-board controllers must use automatic termination, which allows a user to add external devices without removing the PC case. Terminators used in the SCSI host adapter must be regulated terminators, also known as active, SCSI-2 alternative-2, or Boulay terminators. SCSI termination built onto internal cables must meet SCSI-3 standard.

SCSI–0111. TERMPWR is supplied to the SCSI bus with overcurrent protection

This requirement includes the following two components.

  • SCSI–0111.1. Host adapter supplies TERMPWR. The base requirement for system-board implementations using PCI or another expansion bus is that the host adapter must supply terminator power (TERMPWR) to the SCSI bus. All terminators on the host adapter, as well as those on the internal and external SCSI bus, must be powered from the TERMPWR lines on the SCSI bus.
  • SCSI–0111.2. The circuit that supplies TERMPWR has built-in overcurrent protection. Devices that provide TERMPWR must also provide some means of limiting the current through use of a self-resetting device. For example, a positive-temperature coefficient device or circuit breaker can be designed into the circuit. These devices open during an overcurrent condition and close after the end of the overcurrent condition.

Mobile PC Note

This feature is not required for battery-powered systems that implement the SCSI host adapter as a PC Card device because of battery consumption issues.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Plug and Play for SCSI Host Adapters

This subsection summarizes the Plug and Play requirements for SCSI controllers.

SCSI–0113. SCAM support is disabled by default

If support is present, it must be disabled by default. SCSI Configured AutoMagically (SCAM) is not supported by the Windows family of operating systems; enabling SCAM can cause the system to become unstable or inoperable.

SCSI–0114. SCSI controllers provide multi-initiator support

Multi-initiator support allows two SCSI controllers—each installed in a separate computer system—to coexist on a shared SCSI bus with a set of shared devices. If this capability is supported, the SCSI IDs must be changeable from the default SCSI controller ID of 7, and the boot-time SCSI bus reset operation must be able to be disabled on each controller attached to a shared bus.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


PCI Core Requirements

This section summarizes the basic design requirements for PCI.

PCI–0123. All PCI components comply with PCI 2.2

All system-board bus hardware and add-on devices that use PCI must comply with the PCI Local Bus Specification, Revision 2.2 (PCI 2.2).

Bus designs must fully implement all bus requirements on every expansion card connector.

PCI–0057. 66-MHz and 64-bit PCI buses comply with PCI 2.2 requirements

If either 66-MHz or 64-bit PCI buses are implemented in a system, all devices connected to these buses must meet the requirements defined in PCI 2.2.

PCI–0124. PCI-to-PCI bridges comply with the PCI-to-PCI bridge specification

In particular, nonsubtractive decode PCI bridges must implement the standard method to close base address register (BAR) windows as defined in the PCI to PCI Bridge Architecture Specification Rev. 1.1. Setting the BAR to its maximum value and the limit register to zeros effectively closes the I/O or memory window references in that bridge BAR.

PCI–0125. All PCI devices complete memory write transaction (as a target) within specified times

All devices must comply with the Maximum Completion Time requirements in PCI 2.2. Complying with this requirement ensures shorter transaction latencies on PCI, allowing more robust handling of isochronous streams in the system.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Plug and Play for PCI Controllers and Peripherals

This section lists the Plug and Play requirements for PCI devices.

PCI–0126. PCI device IDs include Subsystem IDs

The Subsystem ID (SID) and SVID fields must comply with the SID requirement in PCI 2.2. For more information, see the white paper, "PCI Device Subsystem IDs and Windows," listed in "Buses and Interfaces References." Appropriate values for the SID and SVID fields are described below.

  • The PCI Special Interest Group assigns valid, nonzero Vendor ID values to member companies. This Vendor ID value must be used to populate the SVID register.
  • The vendor assigns values for the SID register. To be valid, these values must be nonzero and unique to a subsystem configuration.

Note: For subsystems on system boards that contain a PCI device, the SVID and SID registers must also be loaded with valid nonzero values before the operating system accesses the device. The exception to this requirement is core chip sets.

PCI–0127. PCI interrupt routing is supported using ACPI

The system must provide interrupt routing information using a _PRT object, as defined in Section 6.2.3 of the ACPI 1.0b specification.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Power Management for PCI Controllers and Peripherals

This section lists the specific PCI power management requirements.

PCI–0130. All PCI components comply with PCI Bus Power Management Interface specification

PCI Bus Power Management Interface Specification, Revision 1.1, is the only industry specification that ensures compatibility with the power management capabilities of Windows 2000, which uses PME# as the wakeup signal.

The primary PCI bus controller, PCI-to-PCI bridges, and all PCI add-on devices that implement PME# must comply with the PCI Bus Power Management Interface Specification, Revision 1.1. PCI add-on devices that do not implement PME# must comply with PCI Bus Power Management Interface Specification, Revision 1.0. Minimum requirements consist of the following.

PCI-CardBus bridges are required to comply with the PC Card Standard,
Release 7.

  • PCI–0130.1. All components correctly implement configuration space registers used for power management. This requirement includes correct implementation of the PCI Configuration Space registers used by power management operations, and the appropriate device state definitions.

A PCI function is a set of logic represented by a single Configuration Space. Some examples include PCI-to-PCI bridges, USB host controllers, and IDE controllers. If a function is integrated as part of the core chip set, and thus is not an add-on capable device, it can use ACPI rather than PCI Power Management registers for its power management interface.

  • PCI–0130.2. PCI add-on cards using 3.3Vaux operate correctly. PCI add-on cards that use 3.3Vaux must operate correctly. This applies when the system supports 3.3Vaux to the PCI connectors.

PC add-on cards designed and built exclusively for installation in systems—and which are never sold through retail distribution channels—are not required to supply the static field effect transistor (FET) switches described in section 7.4.4 of PCI Bus Power Management Interface Specification.

A method that PCI add-on cards can use to meet this requirement is described in Section 7.4.4 of PCI Bus Power Management Interface Specification, Revision 1.0.

PCI–0131. System provides support for 3.3Vaux

System support for delivery of 3.3Vaux to the PCI bus must be capable of powering a single PCI slot with 375 mA at 3.3V and it must also be capable of powering each of the other PCI slots on the segment with 20 mA at 3.3V whenever the PCI bus is in the B3 state. See also SYS–0002.1, "System supports S3, S4, and S5 states," in Chapter 3.

Systems must be capable of delivering 375 mA at 3.3V to all PCI slots whenever the PCI bus is in any bus-powered state: B0, B1, or B2.

Mobile PC Note

For mobile PCs, the requirement for delivery of 3.3Vaux is 10 mA at 3.3V because mobile platforms often need to support Small PCI or Mini PCI add-in cards while the bus is in the B3 state.

PCI–0132. PCI-based modem and network adapters support wakeup

PCI-based modem and network adapters must support wakeup as defined in Chapter 13, "Modems," and Chapter 14, "Network Communications."

Note: CardBus-based modem cards are not required to support wakeup.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Bluetooth Host Controllers

The following requirements apply to host controllers that are used connect a PC to other Bluetooth devices.

BTH–0396. All Bluetooth Host controllers meet current Bluetooth specifications

Bluetooth Host controllers must meet HCI functional specifications stated in "Part H:1 Bluetooth Host Controller Interface Functional Specification." HCI in the defined transport classes also must meet the corresponding specifications:

  • USB must meet "Part H:2 USB Transport Layer."
  • RS232 must meet "Part H:3 HCI RS232 Transport Layer."
  • Universal Asynchronous Receiver/Transmitters (UARTs) must meet "Part H:4 HCI UART Transport Layer."
BTH–0397. All Bluetooth Host controllers provide Plug and Play and revision information

To minimize the need for new drivers, Bluetooth HCI must do both of the following:

  • Conform to the Plug and Play specifications for the applicable bus, such as USB, PCI, Cardbus
  • Support Part H:1 requirements for reporting the revision of the supported HCI specification

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Bluetooth PC Peripherals

The following requirements apply to the devices themselves.

BTH–0398. Peripherals equipped with Bluetooth wireless technology provide Plug and Play information

The Bluetooth system defines a Service Discovery Protocol (SDP). Bluetooth PC peripherals must support SDP and support the Bluetooth Specification 1.0.

BTH-0399. Bluetooth peripherals support Windows class driver requirements

Bluetooth peripherals must meet other requirements stated in this guide for the corresponding device types. For example, Bluetooth HID devices, modems, printers, or cameras must meet any applicable corresponding requirements in Chapters 7, 13, 15, or 16 of this design guide respectively.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Digital Monitor Requirements

This section describes the specific requirements for digital monitors. For DVI graphics adapter requirements, see GRPH–0169, "Adapter meets industry specifications for external display interface," in Chapter 8.

MON–0241. Digital display interface is DVI compliant

Digital Visual Interface (DVI), Revision 1.0 is the industry standard interface for digital display device interconnect interface. Any system implementing digital monitor output capabilities must implement a DVI-compliant port. Any monitor or display device accepting digital input for display data must implement a DVI-compliant port.

MON–0242. Digital monitor supports hot plug detection

A digital monitor must provide a +5 volt (V) signal to the system within 250 milliseconds (ms) of the system’s assertion of the +5V DDC signal to indicate that the monitor is present and capable of transmitting EDID data. A digital monitor must provide the +5V hot plug detection signal to the system as long as the system is providing the +5V DDC signal to the monitor.

MON–0243. Digital monitor supports VESA VGA Text Mode 3 timings,
640 × 480 and 640 × 400

Digital monitors must support lower resolution scanning formats as defined in the VESA VGA Text Mode 3 standard. Support for both 640 × 480 and 640 × 400 at 60 Hz is required. During system boot and in the event an error displays, Windows uses formats such as 640 × 480, 640 × 400, and "text mode 3."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Analog Monitor Requirements

This section describes the specific requirements for analog monitors.

MON–0244. Analog monitor complies with device-class power management reference specification

Display Device Class Power Management Reference Specification, Version 1.0b provides definitions of the OnNow device power states (D0–D3) for graphics adapters and monitors. The specification also covers device functionality expected in each power state and the possible wakeup event definitions for the class, if any.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


SCSI Storage

This section presents requirements for SCSI storage. See also "SCSI" in Chapter 6, "Buses and Interfaces."

SCSI–0109. Differential devices support DIFFSENS as defined in SPI-3 or later standard

Without DIFFSENS, the differential bus drivers, a single-ended device, or both could be damaged if a single-ended device is connected to a differential bus. The standard for DIFFSENS is defined in Section 5.4.2 of the SPI-3 or later standard.

STOR–0345. External devices use automatic termination or an accessible termination switch

An external SCSI peripheral device must provide automatic termination. At a minimum, a mechanical means must be provided for setting termination and the switch must be accessible to the user without opening the device chassis.

STOR–0346. Devices supports the STOP/START UNIT command as defined in the SBC standard

SCSI peripherals must be able to fully recover from a software-initiated spin down without rebooting the system or cycling power. To properly support power management on SCSI drives and to see that the operating system responds to appropriate driver calls, the STOP/START UNIT command must be implemented as defined in the SCSI-3 Block Commands (SBC) standard.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


ATA and ATAPI Storage

This section defines the requirements for all ATAPI storage devices. See also "ATA and ATAPI" in Chapter 6, "Buses and Interfaces." Discrete ATA/ATAPI-5 controllers in docked mobile PCs must comply with ATA–0122, "Discrete PCI ATA controllers in mobile docking stations implement in PCI Native-Mode ATA" in Chapter 6.

STOR–0347. Peripherals comply with ATA/ATAPI-5

The ATA/ATAPI-5 standard defines hardware and software design requirements for ATAPI devices.

STOR–0348. ATAPI devices support DEVICE RESET command

ATAPI devices must respond to the DEVICE RESET command as defined in the ATA/ATAPI-5 standard, regardless of their internal state. The controller can be reset when the computer is turned on (requests cleared, signature present), but any nondefault mode values must be left in their current state with the device driver (DRV) bit unchanged.

Devices such as hard disk drives that do not implement the PACKET command feature set must not implement the DEVICE RESET command.

STOR–0349. ATA device supports ATA STANDBY command

ATA drives must implement the ATA STANDBY command, as defined in the ATA/ATAPI-5 standard. Information on system power states and transitions can be found in Storage Device Class Power Management Reference Specification, Version 1.0.

STOR–0350. ATA devices support Ultra DMA

All ATA primary storage devices must support Ultra DMA at transfer rates of 33 MB per second or higher as defined in the ATA/ATAPI-5 standard, and as described in ATA–0119, "Controller supports Ultra DMA (ATA/33)," in Chapter 6.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Manageability Component Instrumentation Requirements - PC 2001

This section presents new requirements for PC 2001 systems related to the Wired for Management (WfM) initiative and the Zero Administration initiative for Windows. The WfM initiative seeks to raise the level of management capabilities for mobile, desktop, and workstation platforms. The Zero Administration initiative seeks to provide a controlled, highly manageable enterprise.

The baseline for these requirements is Windows Hardware Instrumentation Implementation Guidelines, Version 1.0, which also defines the Windows-specific requirements of the Wired for Management Baseline Specification, Version 2.0, for hardware instrumentation.

Collectively, the items in this section represent the Manageability Baseline requirements for Windows 2000.

SYS–0048. System supports WHIIG

The related requirement is defined in Windows Hardware Instrumentation Implementation Guidelines, Version 1.0.

Mobile PC Note

Support for WHIIG, WMI, and enabling a management information service provider is required for mobile systems targeted for use with Windows 2000.

SYS–0049. Expansion devices on desktop systems can be remotely managed

Devices provided as expansion devices must be capable of being remotely managed so that control and Total Cost of Ownership (TCO) policies can be realized. For example, for any implementation of a floppy disk drive on a Windows 2000 system, the drive must be capable of being remotely disabled as a boot selection and provisions must be made for locking.

Certain devices are not required to be capable of being remotely disabled, including the primary HDD, the network adapter, and any standard devices that use legacy connections, such as a keyboard or pointing device that uses a PS/2-compatible connection. However, it must be possible that permissions, policies, or other methods can be used to remotely manage capabilities such as hard disk access or to control end-user ability to change the MAC address or configuration settings for the network adapter.

See also requirement BIOS–0014, "BIOS supports remote boot."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Network Adapter Requirements - PC 2001

This section defines basic hardware feature requirements for all network adapters, including IEEE 802 LAN adapters, ISDN adapters, cable modems, ATM adapters, ADSL, and so on. The applicable requirements for each device category are listed in the related sections later in this chapter.

NET–0245. Network adapter uses NDIS 5.0 miniport driver

The network adapter driver must be based on and comply with NDIS 5.0 in order to take advantage of new operating system capabilities. The driver must follow the NDIS 5.0 miniport driver model defined in the Windows 2000 DDK.

Important: The development of full media access control (MAC) drivers is no longer supported.

If the network device is for connection-oriented media, such as ATM, ISDN, frame relay, or X.25, it must have a connection-oriented miniport driver that follows the connection-oriented model defined for NDIS 5.0. Also, for connection-oriented media, there must be an NDIS 5.0 call manager driver as defined in the Windows 2000 DDK.

In some cases, such as ATM, the call manager driver is included in the operating system. Consequently, for an ATM adapter, the vendor needs to provide only an NDIS 5.0 connection-oriented miniport driver. For connection-oriented media such as ISDN or X.25, the vendor must provide a call manager driver with the hardware, because the call manager is not included in the operating system. Call manager support can be integrated in the connection-oriented miniport driver or implemented as a separate NDIS 5.0 call manager driver. Documentation for both integrated and separated call managers is included in the Windows 2000 DDK.

An NDIS 5.0 miniport driver is required for network adapters that connect to the PC using IEEE 1394 or USB buses. This driver exposes its media type to NDIS 5.0 at its upper edge, and it interfaces with the appropriate bus driver at its lower edge.

NET–0246. Adapter automatically senses presence of functional network connection

Where the network allows it, the network adapter must be capable of dynamically determining whether it is functionally connected to a link partner such as a hub, switch, or router. The device must indicate the link state in the following cases:

  • At boot time
  • After returning to D0 power state
  • When the link state changes while in the D0 power state (no time limit is specified for the required detection or status indication)

If the adapter is on an expansion card that is not used as a boot device, the device drivers can determine the presence of the functional link. If the adapter is not functionally connected to a link partner, the miniport driver must provide appropriate NDIS status indication using support for cable sense in NDIS 5.0.

For information about NDIS status codes and indication mechanisms, see the Windows 2000 DDK.

NET–0247. Adapter automatically senses transceiver type

Network adapters that support multiple transceivers must be capable of automatically detecting which transceiver type is connected to the network unless detection is not possible with the network media available. The network adapter then must automatically drive the correct connection. In all cases, the user must not be required to set jumpers or manually enter information to inform the operating system of the transceiver type.

NET–0248. Adapter can transmit packets from buffers aligned on any boundary

Buffer alignment refers to whether a buffer begins on an odd-byte, word, double word, or other boundary. Adapters must be able to transmit packets, any of whose fragments are on an odd-byte boundary.

For performance reasons, packets must be received into contiguous buffers on a double word boundary.

NET–0249. Adapter communicates with driver across any bridge

If the adapter uses a bridge, all communications must be free of errors across any bridge, such as a PCI bridge adapter.

NET–0250. Networking media supports IP

Any networking media must support IP, yet not preclude the use of other protocols.

NET–0251. PCI-based network adapters are bus masters

The PCI-based network adapter must support PCI bus mastering. PCI bus mastering must be enabled by default. CardBus and mini-PCI implementations need not be bus masters.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


ISDN Requirements - PC 2001

This section summarizes the design features for ISDN devices. It defines general requirements for ISDN and specific requirements for ISDN terminal adapters. For information about the requirements for ISDN modems, see Chapter 13, "Modems."

The phrase "ISDN modem" indicates an ISDN device that operates as a modem controlled by the AT command set.

In this section, "internal ISDN device" refers to the ISDN terminal adapter, which exposes raw access to its B channels using NDIS miniports. Alternatively, ISDN terminal adapters could be attached to the PC using WDM-supported bus classes such as USB or IEEE 1394, which would physically be an external device.

NET–0258. Internal ISDN device meets PC 2001 network adapter requirements

ISDN adapters must meet all requirements stated in "Network Adapter Requirements," with the exception of NET–0251, "PCI-based network adapters are bus masters." PCI ISDN adapters are not required to be bus masters.

NET–0259. Internal ISDN device supports synchronous HDLC framing

High-level Data Link Control (HDLC) framing is a standard for sending synchronous data. Other framing methods are allowed if the miniport driver provides simple HDLC-framed, synchronous PPP packets to NDIS.

NET–0260. NDIS interface and driver support raw, unframed synchronous B channel I/O

The internal ISDN device and the driver must support raw, unframed (non-HDLC) synchronous B channel I/O at 64 Kbps per B channel, with each B channel individually accessible. This support enables H.320 as well as voice calls over ISDN without audio breakup.

For these raw interfaces, the direct path to each B channel must support synchronous transmission and reception of H.221 frames, which are of 20 ms duration. Since underruns or overruns cause degraded audio, hardware buffering must be adequate to prevent B channel underruns and overruns. For Windows Me and Windows 2000, 20 ms is adequate.

NET–0261. ISDN driver supports unattended installation, with limitations

Configuration of the dependent parameters, such as SPIDs and switch-type IDs, must be done through the ISDN configuration wizard included in the operating system.

NET–0262. ISDN device includes software-selectable terminating resistors

If the ISDN device has an S/T-interface for connecting additional ISDN devices, it must also have software-configurable terminating resistors that can be selected on or off. The default value of the termination is on in North America, but off in all other countries, where phone companies unconditionally provide the termination.

Cable Modem Requirements - PC 2001

Cable modem provides two-way services: data flows downstream from the cable operator’s head end and upstream from the customer’s PC. At the head end, the cable data system is terminated by the cable modem termination system (CMTS), which terminates the upstream and downstream RF, MAC layer, and possibly Layer 3 protocols from the cable side. CMTS provides the internetwork connection between the cable system and the rest of the network at the head end. CMTS can be implemented on a proprietary hardware platform or a PC platform running Windows 2000. CMTS can provide different networking functions such as routing or QOS support, for example, Resource Reservation Setup Protocol (RSVP).

The three current cable modem specifications are:

  • Data-Over-Cable Service Interface Specifications (DOCSIS) developed by the Multimedia Cable Network System (MCNS) consortium.
  • IEEE 802.14 Cable TV Working Group, developed by IEEE.
  • Digital Video Broadcasting/Digital Audio-Visual Council (DVB/DAVIC), developed by DAVIC and DVB and adopted by European Telecommunications Standards Institute (ETSI) and ITU.

Industry support for DOCSIS is growing rapidly in North America. In present form, its upper layers fully describe IP traffic encapsulated by 802.3/Digital-Intel-Xerox (DIX) Ethernet framing. ATM is left for future study.

External Ethernet DOCSIS cable modems provide IEEE 802.1d bridging for one or more customer premises equipment. A PC attaches to the cable modem indirectly through its 10B-T network adapter. Integrated cable modems attach directly to the PC over buses such as USB, PCI, and IEEE 1394, and they require a vendor-supplied NDIS 5.0 miniport driver. This driver exposes an 802.3/DIX Ethernet adapter interface to the operating system.

In contrast to DOCSIS, both the IEEE 802.14 and the DVB/DAVIC efforts are focused on using ATM, typically implementing an ATM adapter interface and using an NDIS 5.0 ATM miniport driver.

NET–0263. Integrated cable modem meets PC 2001 network adapter requirements

Cable modems must meet all requirements stated in "Network Adapter Requirements." In addition, the requirement NET–0254, "Adapter supports filtering for at least 16 multicast addresses" applies for an integrated cable modem exposing an Ethernet interface.

NET–0264. Integrated cable modem exposes an ATM or Ethernet interface

An integrated cable modem must expose an ATM or Ethernet interface to the operating system. For the specific requirements if an ATM/cable modem solution is implemented, see "ATM Adapter Requirements."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


ATM Adapter Requirements - PC 2001

This section summarizes requirements for ATM hardware. These requirements also apply to Asymmetric Digital Subscriber Line (ADSL) devices; see "ADSL Requirements."

The NDIS 5.0 extensions provide kernel-mode NDIS 5.0 client drivers with direct access to connection-oriented media such as ATM. The new architecture for Windows Me and Windows 2000 extends native ATM support to Windows Sockets 2.0 (WinSock), TAPI, and DirectShow-based applications by providing system-level components that map the applicable WinSock, TAPI, and DirectShow APIs to NDIS 5.0, extending direct ATM access to user-mode applications.

If ATM is included in a PC 2001 system or is specifically designed for Windows Me or Windows 2000, it must meet the requirements defined in this chapter.

For more information related to these requirements, see "ATM Layer Specification," in ATM User Network Interface (UNI) Specification Version 3.1, 1/e. This specification includes references to other relevant specifications.

NET–0265. ATM adapter meets PC 2001 network adapter requirements

ATM adapters must meet all requirements stated in "Network Adapter Requirements."

NET–0266. ATM adapter supports a minimum number of simultaneous connections

The virtual path ID (VPI) and virtual channel ID (VCI) ranges supported by the adapter affect the maximum number of simultaneous connections supported on a system.

This affects the applicability of the adapter to ATM applications such as LAN emulation, where at least one dedicated virtual channel (VC) is created between each pair of communicating ATM hosts.

System type | Simultaneous connections
Client (ATM adapter) | 64 or more
Client (Integrated ATM/ADSL adapter) | 32 or more

A sample driver is provided in the Windows 2000 DDK to guide developers in properly supporting resources to meet this requirement.

NET–0267. ATM adapter supports UBR service type

Unspecified bit rate (UBR) service is used by default for standard ATM services such as LAN Emulation and IP over ATM. In addition, PPP is a widely used model for residential network access, and UBR is used by default for PPP-over-ATM virtual circuits. Therefore, ATM adapters must support the UBR service type.

NET–0268. ATM adapter supports a minimum number of simultaneously active VBR or CBR connections

Support is required for at least two simultaneously active variable bit rate (VBR) or constant bit rate (CBR) connections for basic ATM signaling and management. Support for at least six VBR/CBR connections is needed for ATM adapters that support multimedia or other traffic that demands QOS.

NET–0269. ATM adapter supports traffic shaping

The ATM adapter must support and enforce all the traffic-shaping rules specified for each service type it supports, including CBR, VBR, available bit rate (ABR), and UBR. This includes enforcement of peak cell rate on UBR virtual circuits, as described in the following requirement.

NET–0270. ATM adapter enforces PCR on UBR virtual circuits

ATM adapters can be used to connect the router, remote access, and content servers to the public ATM network. High-speed residential broadband access networks, such as ADSL and cable modem, can enable direct connection, using an ATM virtual circuit, from home or small office computers to these servers.

To avoid packet loss and ensure efficient network utilization, it is critical that all ATM adapters, integrated ATM/ADSL adapters, and ATM/cable modem adapters enforce requested PCR on UBR virtual circuits. ATM adapters must be able to schedule cells on a UBR virtual circuit at a peak rate less than the line or link rate.

Because any ATM adapter might be installed in a server to which clients connect through the public network, this requirement applies to all ATM adapters.

NET–0271. ATM adapter and driver support dynamic link speed configuration

When connected to a residential broadband network, an ATM adapter must restrict the aggregate transmission rate across all active virtual circuits so that it does not exceed the upstream bandwidth provided by the residential broadband network.

Therefore, all integrated ATM/ADSL adapters and ATM/cable modem adapters must support aggregate shaping of upstream bandwidth, according to the provisioned upstream bandwidth or the trained bandwith, whichever is lower. Some implementations can support rate adoption, and lower-than-provisioned rates might be negotiated because of poor line conditions. In addition, because any 25 Mbps ATM adapter might be used to connect to an ADSL network by way of an external ADSL modem, it is required that all 25 Mbps ATM adapters support this as well. This support is optional for ATM adapters with line rates higher than 25 Mbps.

The Windows ATM Call Manager uses Interim Local Management Interface (ILMI) to query the public network to determine the maximum line rates provisioned for incoming and outgoing traffic. The Call Manager then uses the OID_GEN_CO_LINK_SPEED NDIS request (in SET mode) to set the line rate for both incoming and outgoing traffic, within which the adapter can shape the aggregate of all ATM traffic.

NET–0272. ATM adapter that supports OAM responds to F4 and F5 loopback cells

Adapters that receive F4 and F5 loopback operation and maintenance (OAM) calls must be responded to on adapters that support OAM. This capability is needed for diagnostics. Support for layers F1–F3 is optional.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Chapter 3 Bus and Device Requirements

This chapter defines specific requirements for buses and devices provided in a Basic server system.

Tips for selecting I/O performance components. For manufacturers who want to select high-performance components for server systems, the following are design features to look for in I/O components:

  • The system has minimal or no reliance on embedded ISA or low pin count (LPC) and no ISA or LPC slots.
  • Adapter supports bus mastering.
  • PCI adapter properly supports higher-level PCI commands for efficient data transfer.
  • Drivers are tuned for 32-bit performance on an IA-32 system, and tuned for 64-bit performance on an IA-64 system. For example, 32-bit alignments on the adapter do not interface with 16-bit alignments on odd addresses, nor do 64-bit alignments interface with 32-bit alignments.
  • All devices and controllers must be capable of being identified and configured by software through the defined bus mechanisms.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Chapter 4 Networking and Communications Requirements

This chapter defines basic feature requirements for network adapters and other communications hardware. See also the related requirements for remote new system setup and service boot support using DHCP and TFTP as defined in "Manageability Requirements" of Chapter 7, "Reliability, Availability, and Serviceability Requirements."

In this guide, all network communications devices are based on the same NDIS 5.0 requirements, which includes requirements for power management and Plug and Play capabilities. NDIS 5.0 represents a number of extensions to the interface described in NDIS 3.0 and 4.0. The basic requirements, services, terminology, and architecture of these earlier versions also apply to NDIS 5.0.

The NDIS architecture is included in Windows 2000 and is documented in "Network Drivers" in the Windows 2000 DDK. For additional background information about NDIS 5.0, see the web site at http://www.microsoft.com/hwdev/network/.

Notes:

1. References to adapters, network interfaces, and so on in this chapter should be taken to apply to add-on network adapter cards, network implementations on the system board, and external network interfaces equally and without preference for any of these types of implementation, unless otherwise noted.

2. This design guide does not contain requirements for Bluetooth devices. However, future versions of Windows operating systems will use Bluetooth technology as a wireless external bus, rather than as a wireless networking technology. Therefore, Bluetooth devices are not subject to the requirements contained in this chapter; in particular, they do not require NDIS drivers.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Chapter 5 Storage Device Requirements

This section summarizes the requirements for storage devices used with servers.

Tips for selecting high-performance storage components: For manufacturers who want to select high-performance components for server systems, the following are the design features to look for in storage components:

  • System relies on the SCSI or Fibre Channel controller for primary storage.
  • Controller supports bus mastering, which is a requirement in these guidelines.
  • Disks support reduced latency and fast rotational speeds.
  • Drivers are tuned for 32-bit performance on an IA-32 platform, and tuned for 64-bit performance on an IA-64 system. For example, 32-bit alignments on the adapter do not interface with 16-bit alignments on odd addresses, nor do 64-bit alignments interface with 32-bit alignments.
  • Components do not use ISA or LPC.
  • SCSI High-Voltage Differential (HVD) differential devices must support DIFFSENS as described in SPI-3.
  • PCI burst mode reduces disk controller time spent on the PCI bus.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Chapter 6 Physical Design and Hardware Security Requirements

This chapter summarizes physical design and hardware security requirements and recommendations.

Physical Design Requirements

This section presents the requirements related to the physical design of servers.

202. Icons are provided for all external connectors

Required

This requirement helps ensure that the end user can correctly make the physical connections required for adding a device to a system. This requirement includes the following:

  • Wherever possible, keyed or shrouded connectors or other configurations should be used to prevent misconnection. The physical design of the connector must ensure that the user cannot mistakenly insert the connector into the wrong port.
  • Icons are provided for all external connectors. The icons can be molded, printed, or affixed as permanent stickers, which can include text. Icons can be based on existing vendor designs or on the examples shown at http://www.pcdesguide.com/documents/icons.htm.
  • Systems and peripherals must use a color-coding scheme for connectors and ports.
Recommendation

The following list displays the recommendation for standard color-coding of connectors and ports. The selection of these specific colors was done using criteria established by Human Factors and Industrial Design professionals from multiple companies who are involved in the design of computer hardware.

Connector | Recommended color | Pantone
Analog VGA | Blue | 661C
Audio line in | Light blue | 284C
Audio line out | Lime | 577C
Digital monitor/flat panel | White |
IEEE 1394 | Grey | 424C
Microphone | Pink | 701C
MIDI/game | Gold | 131C
Parallel | Burgundy | 235C
PS/2-compatible keyboard | Purple | 2715C
PS/2-compatible mouse | Green | 3395C
Serial | Teal or Turquoise | 322C
Speaker out/subwoofer | Orange | 157C
Right-to-left speaker | Brown | 4645C
USB | Black | 426C
Video out | Yellow | 123C
SCSI, network, telephone, modem, and so on | None | —

It is recommended that retail peripherals also implement color-coding, and those that do are required to use the colors in order to correspond with servers that adopt this scheme.

Note: It is recognized that the design for legacy ports, such as the PS/2-compatible mouse and keyboard ports, analog audio and video jacks, and the microphone and speaker jacks, will not change and therefore cannot fully meet this requirement. However, icons and labels must be provided wherever possible to help the user make the correct connections.

Color coding is required for server systems, but the color codes listed earlier are only recommended. The intent is to standardize the industry on a single color-coding scheme; these specific colors will become a requirement for systems in future versions of the design guidelines.

For the following classes of retail peripherals, color-coding is required and must follow the color codes listed earlier. These classes are:

  • Audio peripherals
  • Display peripherals
  • USB peripherals
  • IEEE 1394 peripherals

203. All expansion slots in the system are accessible for users to insert cards

Required

The space for expansion cards that will reside in associated expansion slots cannot be physically blocked by components or devices provided with the system. However, this requirement does not exclude configurations that provide half-height cards for some slots, passive back planes for connectors, and so on. It is understood that in order to install expansion cards in some expansion slot implementations, users might have to temporarily move other system components to gain access to the slot. In general, designers should minimize this juggling as much as possible.

204. System and device design include protected switches

Recommended

Switches can be covered with a hood or other protection to prevent inadvertent switching. Locks can also be provided to prevent unauthorized access.

205. System design includes locking case

Recommended

The computer case can be protected with key locks to prevent unauthorized access. Other recommended features include:

  • Key lock removes the computer case without additional tools—if this can be done while maintaining compliance with other safety standards.
  • Software management of physical components as documented in WHIIG 1.0, which also defines the Windows-specific requirements of the Wired for Management Baseline Specification, Version 2.0, for hardware instrumentation.

206. System and device design include positive retention connectors

Recommended

Positive retention mechanisms should be implemented to ensure connections. The retention mechanism should be operated by hand, requiring no tools for mating and breaking the connection. It is recognized that certain legacy connector implementations, such as PS/2-compatible pointing devices and keyboards, will not generally allow this. However, locking cable connections provide a valuable feature for end users.

207. If present on an IA-32 system, parallel port design provides sufficient space for connector assembly

Required

The parallel port design must provide enough space between the connectors and the surrounding enclosure to allow for a mating connector, connector shell, and latch assembly.

Recommendation

The IEEE 1284 specification recommends an IEEE 1284-C connector for all new ports and devices.

Note: Parallel ports must not be present on IA-64 systems.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Chapter 7 Reliability, Availability, and Serviceability Requirements

These requirements and recommendations relate to ease of use, ease of maintenance, manageability, and failure tolerance. Design guidelines that make server configuration, management, and servicing easier for end users and administrators are defined to help reduce the total cost of ownership for servers.

Reducing the total cost of ownership is an important goal for servers; a key priority in this effort for servers is minimizing downtime. This goal is achieved through mechanisms for backup and reliability, remote management, and emergency and preboot management.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


General Component Requirements

This section lists requirements and recommendations for system components such as memory and power management.

1. System and components properly support all dates

Required

The firmware, real-time clock, system clocks, and the system as a whole must work correctly for all dates.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


System Microprocessor Requirements

This section summarizes processor requirements for server systems.

Note: It is recognized that OEMs supply systems with specific feature requirements to corporations, which can include providing servers that do not include any processors pre-installed before shipping.

2. Multiprocessor-capable system meets Windows requirements and minimum expansion requirements

Required

2.1 Enterprise class server system supports expansion to at least four processors
2.2 IA-32 multiprocessor-capable system supports ACPI 1.0b

For systems in which more than one processor can be installed, the system must employ those processors symmetrically; that is, all processors must be able to access all I/O buses and system memory, and cache coherency must be maintained. The system must also comply with the ACPI 1.0b specification.

In addition, Advanced Programmable Interrupt Controller (APIC) support must comply with ACPI 1.0b by including the Multiple APIC Description Table defined in Section 5.2.8.

Note that Windows 2000 and later versions of Windows use ACPI on all ACPI-based systems, and therefore compliance with MultiProcessor Specification, Version 1.4 (MPS 1.4) is no longer required.

For information about the requirements for PCI IRQ routing on a multiprocessor ACPI system, see http://www.microsoft.com/hwdev/onnow/acpi-mp.htm.

Note on Multiprocessor Wake-up: 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 multi-processor 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.

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 into 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 wake-up problem.

Intel provides additional information about this issue through the Intel Technical Support Hotline at 1-800-628-8686 or 916-377-7000.

2.3 IA-64 multiprocessor-capable system complies with ACPI 2.0

For an IA-64 system in which more than one processor can be installed, the system must employ those processors symmetrically; that is, all processors must be able to access all I/O buses and system memory, and cache coherency must be maintained. The system must also comply with the ACPI 2.0 specification.

In addition, an IA-64 system must include a Multiple SAPIC Description Table that complies with ACPI 2.0.

Note that MPS 1.4 support is not a requirement for systems with 64-bit processors and will not be used by any version of the 64-bit Windows operating system.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Memory Requirements

This section defines minimum memory requirements for server systems.

Note: It is recognized that OEMs supply systems with specific feature requirements to corporations, which can include providing servers that do not include any memory pre-installed before shipping or otherwise fulfill specific customer requirements for installed memory.

3. For IA-32 system, installed memory meets minimum requirements

Windows 2000 Server, Small Business Server | Windows 2000 Advanced Server, Windows 2000 Datacenter Server
For 1–2 installed processors, 512 MB Required | For 1–4 installed processors, 1 GB Required
For more than 2 installed processors, 256 MB per installed processor Required | For more than 4 installed processors, 256 MB per installed processor, Required

Memory requirements are defined in relation to the installed operating system. There are no requirements defined in relation to the server type.

All memory visible to the operating system as system memory must be cacheable. All system memory except for 4 MB must be completely available for the system to use at boot time and cannot be locked from use by the operating system. This minimum requirement for memory available to the operating system does not preclude applications that use dynamically-allocated memory for temporary uses.

Recommended: Larger installed memory configurations, which will increase performance.

4. For IA-64 system installed memory meets minimum requirements

Required

The minimum installed memory requirement for IA-64 systems is 1 GB of system memory.

All memory visible to the operating system as system memory must be cacheable. All system memory except for 4 MB must be completely available for the system to use at boot time and cannot be locked from use by the operating system. This minimum requirement for memory available to the operating system does not preclude applications that use dynamically allocated memory for temporary uses.

Recommendation

Recommended: Larger installed memory configurations, which will increase performance.

5. For IA-32 system, memory capacity meets minimum requirements

Systems that provide support for <4 processors: 2GB Required

Systems that provide support for 4 or more processors: 8 GB Required

This requirement defines minimum RAM expansion capabilities for an IA-32 system. All memory visible to the operating system as system memory must be cacheable.

6. For IA-64 system, memory capacity meets minimum requirements

Systems that provide support for <4 processors: 16 GB Required

Systems that provide support for 4 or more processors: 32 GB Required

This requirement defines minimum RAM expansion capabilities for an IA-64 system. All memory visible to the operating system as system memory must be cacheable.

7. System memory includes ECC memory protection

Required

The system memory and cache must be protected with Error Correction Code (ECC) memory protection. All ECC RAM visible to the operating system must be cacheable. The ECC hardware must have the ability to detect at least a double-bit error in one word and to correct a single-bit error in one word, where "word" means the width in bits of the memory subsystem. A detected error that cannot be corrected must result in a system fault.

8. NUMA and NUMA-"lite" system design maintains near:far memory access time ratios of 1:3 or less

Recommended

For optimal performance with Windows 2000 and later operating systems, it is recommended that system designers building platforms that present memories with different access times keep the ratio for access to "near" versus "far" memories relative to a given microprocessor at a 1:3 ratio or less as seen by the operating system.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


ACPI and Power Management Requirements

This section defines the system and BIOS requirements for ACPI and power management.

9. System design meets ACPI and related requirements

Required for all server types, with additional requirements for SOHO servers

IA-64 system board sets must support ACPI 2.0 or later.

IA-32 system board sets must support ACPI 1.0b or later.

This requirement ensures that the system correctly supports the Plug and Play and power management functionality described in this guide.

9.1 Server system implements basic ACPI and power management capabilities

ACPI support for all server systems must include the following required capabilities:

  • Power management timer. System control interrupt and necessary Status and Enable (STS/EN) bits must be provided.
  • Support for a description table that defines the complete hierarchy for system-board devices, including host PCI bridges. The description table must include all non-Plug and Play devices to be enumerated and all other devices for which power management or removal capabilities have been added by the system-board design.
  • Each bus and device enumerated using ACPI includes the ACPI control methods necessary to configure these devices. This includes requirements defined in these guidelines for automatic device configuration, resource allocation, and dynamic disable capabilities.

For information about Plug and Play support under Windows 2000, see "Setup, Plug & Play, Power Management" in the Windows 2000 DDK. Standard system devices are excluded from related requirements, as described in guideline "#16. System and device configuration meet Plug and Play requirements."

  • Thermal model and fan control, if implemented, comply with ACPI. IA-64 systems must comply with Section 12 of ACPI 2.0. IA-32 systems must comply with Section 12 of ACPI 1.0b. Notice also that a server that supports thermal controls must have active thermal control such as a fan and cannot use passive thermal control under normal operating circumstances.

This requirement, however, does allow proprietary value-added features that cannot be implemented using ACPI. For example, systems are permitted to use out-of-band methods to provide cooling when the operating system is not booted.

  • Support for at least one processor power state. This can be either C1, C2, or C3.
  • No capabilities for the end user to disable system ACPI support using CMOS or other means. Disabling ACPI will cause boot failures because Windows 2000 relies on ACPI to identify and initialize system devices.

This requirement, however, does allow proprietary value-added features that cannot be implemented using ACPI.

9.2 SOHO server implements additional ACPI and power management capabilities

The following ACPI support is required for SOHO servers and recommended for other server types:

  • Power button complies with ACPI. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b. This is described in guideline "#10. Hardware design supports OnNow initiative."

Note: Very large, or rack-mountable, or partitionable systems may face challenges with actual "physical" ACPI power buttons. A possible alternative for server systems is a "virtual" ACPI power button which acts as an ACPI power button but which is "activated" via a service processor action or other form of remote management (instead of via an actual administrator pressing a button physically located on the server).

  • Real-time clock alarm that supports wake-up based on a scheduled time and day of the month. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b. If this feature is implemented, the day-of-month feature is required under these guidelines, although it is an optional feature in the ACPI specification. Also, if this feature is implemented, system control interrupt and necessary STS/EN bits must be provided.
  • ACPI-compliant support for the S5 soft-off state. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b. If a soft-off feature is supported, it must meet the requirements for the S5 state defined in the ACPI specification.
  • Support for either the S1, S2, or S3 sleep state. Support for at least one of the S1, S2 or S3 sleep states must be provided by SOHO servers.

Support for the S3 state (Suspend to RAM), which provides the optimal user experience and power savings, is likely to become a requirement in a future version of this design guide.

  • USB host controller can wake the system. If a USB host controller is present in the system, it must support wake-up capabilities in one of the following system states: S1 or S2. If the system contains multiple USB host controllers, all host controllers integrated on the system board (that is, not add-on cards) must meet this requirement. USB devices and USB client software and drivers must not fail over system suspend and resume cycles.
Recommendation

Recommended: Support wake-up from the S3 state.

Notice that if wake-up from the S2 or S3 state is supported, wake-up must be supported for all higher power sleep states. For example, if the controller supports wake-up from the S2 state, it must also support wake-up from the S1 state.

Note: For IA-64 systems, a server system implementing system-board power management or configuration features that are defined in the ACPI 2.0 specification must comply with ACPI 2.0, even if those features are not specific requirements or recommendations in these guidelines. This requirement, however, does allow proprietary value-added features that cannot be implemented using ACPI.

For IA-32 systems, a server system implementing system-board power management or configuration features that are defined in the ACPI 1.0b specification must comply with ACPI 1.0b, even if those features are not specific requirements or recommendations in these guidelines. This requirement also allows proprietary value-added features that cannot be implemented using ACPI.

10. Hardware design supports OnNow initiative

Required for all server types, with additional requirements for SOHO servers

Elements of the OnNow design initiative ensure that the operating system and device drivers control the state of individual devices and the system board set.

10.1 Buses on system that supports S1–S3 meet bus power management requirements

SOHO servers and any Basic or Enterprise server that supports any one of the S1, S2, and S3 sleep states must—and all servers should—provide PCI, USB, and IEEE 1394 buses that support power management requirements, as defined in the related bus standards.

10.2 All devices and drivers support D0 and D3 power states

All devices and drivers must support the D0 and D3 power states consistent with the definitions in the Default Device Class Power Management Specification and the relevant device class power management reference specification. This requirement must be implemented so that each device can successfully survive a system sleep/wake transition (device D3 to D0 transition) without requiring user intervention to restore functionality.

This requirement applies whether or not system power is removed while the computer is in an S1–S4 state. The operating system supports the S4 state without system-board support, so all devices and drivers must meet this requirement.

It should be noted that when PAE mode is used to allow access to more than 4 GB of physical memory on servers running either Windows 2000 Advanced Server or Windows 2000 Datacenter Server, S4 hibernation will not be supported by the operating system. This is because the time and disk space needed to save and restore the system image for a system with 4 GB or more of system memory will typically greatly exceed the amount of time needed to reboot such a system. However, all systems, devices, and drivers must still meet the requirements within this guideline as it is always possible that even a large system may have less than 4 GB of physical memory or not be running in PAE mode.

Notice that there is no power consumption requirement for devices in the D3 state. It is recommended, however, that devices implement the D3 state so that device power consumption is reduced to near zero, with the recognition that there is no requirement to retain any device context because it will be preserved or restored by the driver when returning to the D0 state.

Recommendation

Recommended: Devices and drivers should support the D1, D2, or both low-power states, and they should support the defined wake events as designated in the relevant device class power management reference specification.

10.3 System provides software-controlled, ACPI-based power switch

For SOHO servers, the system must provide an easily accessible power switch that can be controlled by software.

Recommendation

Recommendation: This is a recommendation for Basic and Enterprise servers.

The following provides implementation guidelines for the power switch. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b.

  • A single ACPI button design is preferred. This button must be the user’s primary switch interface, and must be implemented as a power button as defined by the ACPI specification.
  • If a two ACPI button design is used, the sleep button must be the user’s primary switch interface, and be easily distinguishable from the power button. The preferred implementation in a two-button design is to hide the power button behind a door or on the rear of the system.

The function of these buttons is determined by the operating system.

  • In case of a hardware or software failure that prevents normal operation of the software-controlled buttons, the switch capabilities must include an override mechanism for turning off the server.
Recommendation

Recommended: A 4-second override mechanism as described in Section 4.7.2.2.1 of ACPI 1.0b and in Section 4..7.2.12.1.3 of ACPI 2.0. The override must be associated with the user’s primary switch interface, in order to establish an industry-standard implementation.

Notice that the override mechanism is not an alternative way for the user to turn off the server in normal operation; it is only a fail-safe function for fault conditions.

  • If the power switch is provided on the keyboard, the key must be clearly labeled and must consist of a single keystroke for turning on the server, to ensure accessibility for persons with disabilities. (Two keystrokes can be used to turn off the server.)

For information about scan codes for keyboard power switches, see http://www.microsoft.com/hwdev/desinit/scancode.htm.

10.4 System that support S1–S3 provides one or more indicators to show whether the system is in the working or sleep state

This capability is required for all SOHO servers and any other server systems that support S1, S2, and S3.

Recommendation

Recommended: A non-flashing, light-emitting diode (LED) sleep indicator that is a different color than the wake indicator. A slowly blinking LED indicator (less than 1 Hz) is also an acceptable implementation. This applies for S1, S2, and S3 system states.

The nonvolatile sleep state, S4, should appear to the user as the off state (S5); therefore, both of these states should have the same indicator.

10.5 For SOHO server and any other server that supports S3, the system power supply provides "standby" power for wake-up events

The system must supply adequate standby power to support wake-up events. The system must provide, at a minimum, power for the core chipset including memory and all integrated wake devices, wake-up from the keyboard, a pointing device, and a single network device such as a local area network (LAN) or wide area network (WAN) adapter connected via an external bus or open PCI slot when the system is in the S3 or S4 state.

Additional information about this requirement can be found in EPS Power Supply: A Server System Infrastructure (SSI) Specification for Entry Chassis Power Supplies, at http://www.ssiforum.org/docs/entrylevelpowersupply.pdf.

This capability is required for SOHO servers. If a Basic or Enterprise server supports the S3 sleep state, this capability is required, otherwise, it is optional.

11. System startup meets requirements for OnNow support
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Optional | Optional | Optional
Enterprise: | Optional | Optional | Optional
SOHO: | Required | Required | Required

The intention of this recommendation is to ensure that the end user is not presented with unnecessary visual displays and to ensure that access to error information remains available using a hot key.

The following is required for SOHO servers. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b.

  • System firmware supports fast POST. The system should be available to the user as quickly as possible. Although a specific time limit is not established, the basic recommendation is that power on to the boot.strap loader should occur within 5 seconds, plus hard-disk ready time, option ROMs, and time required for memory subsystem initialization and ECC.

The following are recommended ways to reduce processing overhead to make system boot time as fast as possible:

  • No video memory test and limited test for dynamic RAM (DRAM) size
  • No tests for serial or parallel ports
  • No floppy disk test or media check (boot from hard disk only)
  • No tests for hard disk controller or drive type (if the system does not include swappable drives)

Fast Power-On Self Test (POST) mode for system firmware can be disabled by the user for troubleshooting.

  • Resume from sleep state (S1–S3) to operating system handoff should occur within 500 ms. This recommendation does not apply to the S4 state. For all other sleep states, the time to operating system handoff means when the processor starts running (first instruction) until the system firmware jumps to the Waking Vector in the ACPI firmware con.trol structure table, as described in Section 5.2.6 in ACPI 1.0b or in Section 5.6.2.1 in ACPI 2.0.
  • Minimal startup display. System startup should draw the end user’s attention only when errors occur or when user action is needed.

The default configuration should allow a beep during the boot process only in case of an error, and the only screen display should be the OEM splash screen, which can include information such as copyright notices. By default, the system should be configured so the screen display does not show memory counts, device status, and so on. The display should present a "clean" system firmware startup so that the end user is not presented with cryptic and unnecessary information.

However, the system start-up process can include the following:

  • A blank start-up screen.
  • A hot-key override to display screen messages for troubleshooting or to display user-definable CMOS settings.
  • Text-based, end-user action messages. Examples are: messages to display the setup hot key, the system help hot key, password entry, network log-on for remote booting, and so on.
  • Manufacturer branding messages.
  • A CMOS option to turn the clean start-up screen off and on.

Recommendation

Recommended for SOHO servers: Compliance with Simple Boot Flag Specification, Version 1.0 or later. This enables the BIOS to boot quickly when the last boot was successful and to perform diagnostics only if a problem occurred on the previous boot.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Startup Support Requirements

This section defines the firmware and other requirements to support system startup.

12. System firmware meets general boot support requirements

Required

Notice that the Extended System Configuration Data (ESCD) calling interface is not supported by Windows 2000.

The requirements for boot support are summarized in the following items.

12.1 System firmware supports SMBIOS 2.3

This mechanism is required to provide platform specific information at boot time, including the server’s Universally Unique Identifier (UUID). System Management BIOS Reference Specification, Version 2.3, is available at http://www.phoenix.com/products/specs-smbios.pdf.

In addition, the UUID must be provided to the user in printed form, for assistance in environments where it could be used as part of pre-staging systems. This mechanism is left up to the system manufacturer, but suggested means include posting the UUID on the system chassis or case, or printing it the shipping carton.

12.2 Firmware implements security, such as a preboot password

This is provided to protect enable and disable capabilities for hardware components before the operating system boots. At a minimum, User and Administrator levels of password protection must be provided in the system firmware. This capability prevents end users from accidentally or purposefully circumventing operating system-level security and control as applied by an administrator.

12.3 Firmware supports BIS

For systems that include integrity or authentication services for downloaded remote boot images, the system’s firmware must provide these capabilities as defined in Boot Integrity Services (BIS), Version 1.0, available at http://developer.intel.com/ial/wfm/wfmspecs.htm.

In addition to the management data required by SMBIOS 2.3, BIS requires inclusion of Type 31 (BIS Entry Point) in the table of exported SMBIOS structures.

12.4 Firmware provides boot support for CD and DVD drives

The system firmware or option ROM must support the No Emulation mode in El Torito, Version 1.0.

For related information for IA-64 systems, see guideline "#14.5 EFI IA-64 system firmware provides boot support for CD and DVD drives."

12.5 System supports firmware update mechanism

System administrators must be able to upgrade system firmware to a new image. The following methods can be used to meet this requirement:

  • Remote new-system setup mechanism based on PXE capabilities allowing programs to be downloaded and executed at boot time.
  • Normal file access and execution methods when the system is fully booted into the normal operating system environment.

Recommendation

Recommended for all system types:

  • If option ROMs are provided, they should also be capable of being updated.
  • Implement a mechanism to authenticate the requester of the update programming. Implement a mechanism to validate that the program arrived intact after download.

See also the BIOS requirements and recommendations for ATA support in guideline "#177. ATA controller and peripherals comply with ATA/ATAPI-5 standard commands for features implemented and support Ultra-DMA (ATA/33, minimum)."

13. IA-32 BIOS boot system supports remote/network boot, USB boot devices, and firmware update

Required

13.1 IA-32 BIOS boot system supports PXE 2.1

If a server provides support for network adapters that provide remote boot capabilities using Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol (TFTP), the server must also provide support for the preboot execution environment. For IA-32 BIOS boot systems, this is described in PXE 2.1, available at http://developer.intel.com/ial/wfm/wfmspecs.htm.

13.2 IA-32 BIOS boot system supports CIP BIOS Boot 1.01 for network-based boot

BIOS supports booting the system from the network, with a mechanism for setting the order of precedence for boot devices. If a server provides support for BIOS boot from a network adapter, the system BIOS must comply with the requirements defined in Sections 3 and 4 (as they apply to Plug and Play devices) of CIP BIOS Boot 1.1, which describes the requirements for Initial Program Load (IPL) devices.

The BIOS must allow all boot devices to be configured according to order of precedence for boot. This mechanism must clearly show how the system will order boot devices when end users are making configuration choices. For example, in a system that permits booting from floppy drive, hard drive, CD or DVD drive, and network adapter, it must be clear to the end user how to set a boot order that favors a specific device, such as the CD drive.

In addition, for any system that includes a network adapter capable of PXE-based remote boot, a key sequence must be provided to allow the user to force a boot initiated from the network adapter, either directly or via a pop-up screen. This key sequence must be enabled by default. Configuration of this feature may be provided through a CMOS configuration setting. When this feature is enabled, the boot display must indicate the key sequence that will invoke the pop-up screen allowing a network boot.

This display must appear for a duration sufficient to be read by users, but must not lengthen the overall time needed to boot the machine. This feature must be implemented in accordance with Appendix C of CIP BIOS Boot 1.01. Note that this feature is a requirement in this Hardware Design Guide, although it is optional in CIP BIOS Boot 1.01.

For consistent user experience across all system brands and types, it is suggested that system and BIOS manufacturers standardize on the F12 key to perform this action. It is expected that F12 or another standard key sequence will become a requirement in a future version of this design guide.

13.3 IA-32 BIOS boot system supports USB keyboards, pointing devices, and hubs as boot devices

For a server that includes a USB keyboard as the only keyboard in the system, the system BIOS must provide support during the bootstrap process for USB keyboards, pointing devices, and hubs. This BIOS support is defined in the USB Device Class Definitions for Human Interface Devices, Version 1.1 (HID 1.1), with particular attention to the Keyboard Boot Protocol. This BIOS support must provide the ability for the user to enter the BIOS setup utility; it must also provide enough functionality to install and boot an operating system that recognizes USB peripherals. USB keyboards built as standalone devices, part of a composite device, or part of a compound device must be recognized and usable. The BIOS is required to support keyboards behind at least one level of external hub.

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).

Keyboard and pointing devices must be functional for all modes of the operating system, including the bootstrap process, loading, recovery console, and operating system installation.

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.

13.4 IA-32 BIOS boot system firmware supports console redirection to a serial port, if serial headless server support is implemented in the system

If serial port based headless server support is provided by the system, the system must provide support for redirection of all BIOS driven console I/O to the serial port. The driver for the serial console must be capable of supporting the capabilities documented in Extensions to the VT100 Terminal Definition, available at http://www.microsoft.com/hwdev/headless/.

An IA-32 BIOS boot system must provide information about the location and configuration of this serial port via ACPI and the methods described in Serial Port Console Redirection Table available at http://www.microsoft.com/hwdev/headless/. The BIOS must release the serial port as soon as the Windows loader is called.

Additionally, if the system BIOS supports localization, it must meet the requirements specified in Extensions to the VT100 Terminal Definition.

Recommendation

Recommended: IA-32 BIOS boot system support should include the following, where appropriate:

  • An IA-32 BIOS boot system should use the E820 interface to report memory. The E820 interface allows systems to report (and test) memory, and also allows memory to be reclaimed. Information about this interface can be found in Paragraph 2 of Section 9.3.2, "BIOS Initialization of Memory," in ACPI 1.0b, which states that the E820 specification has been updated and lists the new memory range types.
  • System BIOS on an IA-32 BIOS boot system or option ROM provides ARMD-compliant boot support for ATAPI bootable floppy disk drive. Complying with the ATAPI Removable Media BIOS Specification (ARMD), Version 1.0 or later specification provides Int 13h and Int 40h support for bootable floppy drives as the primary or secondary floppy device.

14. IA-64 system complies with EFI 1.0 or later, with support for USB boot devices, firmware update, and PXE_BC, SERIAL_IO, and SIMPLE_NETWORK protocols

Required

The only boot mechanism supported for platforms running 64-bit Windows is defined in EFI 1.0 or later. BIOS-based boot is not supported and will not work with 64-bit Windows.

Note: Although the PXE_BC (remote/network boot), SERIAL_IO, and SIMPLE_NETWORK protocols are defined as optional implementation elements in the EFI specification, in this guideline they are requirements for EFI systems.

14.1. EFI IA-64 system supports network-based boot via EFI boot manager

EFI systems must provide support for booting systems from the network as defined in EFI 1.0 or later. This support includes the capability, via the EFI boot manager, to configure boot devices in order of preference by the administrator of the server, plus a method for forcing a network-based boot. These mechanisms must be available to the administrator in the pre-boot state of the system.

14.2. EFI IA-64 system provides boot support for USB keyboard and bus

The system firmware must provide EFI boot support for USB keyboards, pointing devices, and hubs.

The system firmware must also support the keyboard behind at least one level of external hub. This support must provide the ability for the user to enter the system’s firmware-based configuration utilities and provide sufficient functionality to get EFI-aware versions of Windows installed and booted. USB keyboards built as standalone devices, part of a composite device, or part of a compound device must be recognized and usable.

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

Keyboard and pointing devices must be functional for all modes of the operating system, including booting, loading, recovery console, and operating system installation.

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

14.3. EFI IA-64 system implements SAL, including firmware update method

The System Abstraction Layer (SAL) is a firmware layer provided by OEMs. The implementation of this layer must conform to RS-IA-64 System Abstraction Layer (SAL) Specification, Revision 2.7 or later, including implementation of a call that will allow the firmware to be updated.

SAL abstracts platform uniqueness by providing a consistent interface to a higher level of the software stack to discover and control an IA-64 system. It exports components and their associated access details to the operating system through EFI using the SAL System Table.

14.4. EFI IA-64 system firmware supports console redirection to a serial port

The system must provide support for redirection of all console I/O to the serial port. The driver for the serial console must be capable of supporting the capabilities documented in Extensions to the VT100 Terminal Definition. Note that unlike BIOS, EFI firmware must indicate which serial port is used for console I/O and the configuration of that serial port through the console device path for the serial port as specified in EFI 1.0.

14.5. EFI IA-64 system firmware provides boot support for CD and DVD drives

The system firmware must support the No Emulation mode in El Torito, Version 1.0, and the additional requirements for EFI as defined in Section 16.2.2, "ISO-9660 and El Torito," in EFI 1.0.

14.6. EFI IA-64 system provides minimum required boot list variable storage

The minimum required non-volatile storage for boot list variables (used by the EFI boot manager) is 4 K. Note that this is storage reserved solely for use by boot list variables and may not be used for any other variables or purposes.

14.7. EFI IA-64 system provides a minimum, firmware-based driver set sufficient to allow boot, installation, and recovery operations without the presence of loadable media-based EFI drivers

The minimum set of capabilities required under this guideline include EFI console capabilities and sufficient other EFI drivers to permit access to devices needed for boot, installation, and recovery operations.

Note: An example of a specific problem that this guideline addresses is the possible case of a system that, in order to reach a given disk drive, must load a driver off that particular disk drive. It can readily be seen that such cases would result in an uninstallable system.

15. System provides a debug port solution

Required

All systems are required to provide a debug port solution, including the necessary hardware and system firmware to fully implement the solution. This capability provides support for debugging and troubleshooting activities.

15.1. IA-32 system meets debug port and configuration requirements

IA-32 system designers may choose to support one or more of the following debug port technologies:

  • Legacy serial port. The system firmware must configure at least one serial port to use either 2F8h or 3F8h. This allows the port to be treated as a boot device by the firmware and to be used by components as a diagnostic port if system debugging is required by either the firmware or the operating system.

Note that systems designed to implement a legacy serial port for debug purpose must not share this function with a serial port utilizing the Windows native serial port "headless server" functionality; in such a case, two serial ports are required.

  • Non-legacy debug ports. A system designed to implement an alternative Windows-compatible debug port must implement a debug solution that complies with the Debug Port Specification, available at http://www.microsoft.com/hwdev/NewPC/debugspec.htm.

15.2. IA-64 system meets debug port and configuration requirements

IA-64 system designers must provide a legacy serial port for use as a debug port. The platform firmware must configure at least one serial port to use either 2F8h or 3F8h. This allows the port to be treated as a boot device by the firmware and to be used by components as a diagnostic port if system debugging is required by either the firmware or the operating system.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Plug and Play Requirements

This section defines the specific requirements for Plug and Play.

16. System and device configuration meet Plug and Play requirements

Required

Windows 2000 Server implements complete support for Plug and Play configuration. Each bus and device provided in a server system must meet the current Plug and Play specifications related to its class, including:

  • Requirements defined in Section 6 of ACPI 2.0 (for IA-64 systems) or Section 6 of ACPI 1.0b (for IA-32 systems).
  • Bus class specifications, such as PCI Local Bus Specification, Revision 2.2 (PCI 2.2), USB 1.1 or later, and so on.
  • 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, available at http://www.pcdesguide.org/legacypnp/.

Note: Standard system devices are excluded from the Plug and Play requirement. 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.

Also, this requirement does not apply to 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.

17. Unique Plug and Play ID is provided for each system device and add-on device

Required

Each device connected to an expansion bus must be able to supply its own unique identifier, as defined in the current Plug and Play specification for the bus that it uses. The following defines the specific requirements for Plug and Play device IDs:

  • Each separate function or device on the system board set must be separately enumerated. Therefore, each must provide a device identifier in the manner required for the bus it uses.
  • If a device on an expansion card is enumerated by the system firmware, it must have a unique ID and its own resources according to the 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.

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. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b.
  • 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 the Windows 2000 operating system.
  • 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.

In addition, 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.

18. "PNP" vendor code is used only to define a legacy device’s Compatible ID

Required

All legacy devices not enumerated by the system board set interface must not use "PNP" in their vendor and device codes. The PNP vendor code is reserved for Microsoft and vendors whose hardware is specifically assigned a particular ID. Other hardware can use a PNP code only when defining a device’s Compatible ID (CID) and only after first indicating the device’s Hardware ID in the Plug and Play header.

Recommendation

Recommended: Use CIDs for devices that use device drivers provided with the Windows 2000 operating system, such as a standard COM port (PNP0500).

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


“Headless Server” Requirements

Reference Only: Server Design Guide 3.0

"Headless Server" Requirements

Windows Whistler provides native support for "headless server" operation on IA-32 platforms. Support for full headless server operation for IA-64 platforms will be available in a future version of Windows after Windows Whistler. The following guidelines describe requirements for hardware leveraging these capabilities.

19. IA-32 system provides headless server capabilities meeting Hardware Design Guide requirements

Required for Enterprise class systems

Recommended for Basic and SOHO class systems

To permit remote management of a system, it is required that all Enterprise class IA-32 servers provide headless server capabilities complying with at least one of the solutions described in guidelines #20, 21, and 22. This is recommended for Basic and SOHO class systems, and is expected to become a requirement for these classes in a future version of this guide.

The three cases that these guidelines describe are, respectively:

  1. The case where headless out-of-band remote management is provided by serial port hardware only.
  2. The case where such capabilities are provided by a management service processor that provides external serial support, either as a sole connection or in addition to other types of connections.
  3. The case where such capabilities are provided by a management service processor that provides no external serial connection capabilities.

20. IA-32 system that implements headless capabilities without management service processor provides serial headless support

Required if system implements headless support without a management service processor

This guideline addresses the minimum capabilities needed for serial headless server support if a system implements a solution for headless support but does not include a management service processor. This requirement is an optional solution to the basic requirement stated in "#19, IA-32 system provides headless server capabilities meeting Hardware Design Guide requirements."

20.1. IA-32 system without management service processor supports BIOS redirection of console output to the headless serial port

IA-32 systems must provide the redirection capabilities documented in "#13.4 IA-32 BIOS boot system firmware supports console redirection to a serial port, if serial headless server support is implemented in the system."

Recommendation

Recommended: Use COM1 as the headless serial port.

20.2. IA-32 system without management service processor provides properly configured legacy serial port

For use with the headless server capabilities of Windows Whistler, IA-32 systems must provide a legacy serial port that is addressable at either COM1 (03F8h) or COM2 (02F8h), configured to the default settings of 9600 bps, 8 bits, no parity, and 1 stop bit. This port must also comply with the requirements for legacy serial ports elsewhere in this document.

Note: Future versions of Windows will provide additional physical connection choices for headless servers.

20.3. IA-32 system headless connections are null modem cables that support Carrier Detect signal

Cables used for connection to a Windows Whistler headless server on a serial port must be null modem cables that provide support for the Carrier Detect signal. Carrier Detect is required because Windows will not provide console I/O if Carrier Detect is not active.

21. IA-32 system that implements management service processor and external serial headless capability supports required external serial port and remote system reset

Required if the service processor exposes a UART interface via hardware to the operating system or if the serial port is the only full-time management connection

This guideline addresses the minimum capabilities needed for headless server support with service processors that provide external serial capabilities. This requirement is an optional solution to the basic requirement stated in "#19, IA-32 system provides headless server capabilities meeting Hardware Design Guide requirements."

Management service processors that provide both serial and LAN-based full-time management connections but do not provide an internal 16550 UART hardware interface (i.e. Service Processor does not provide a serial port interface or the serial port interface is provided by a Windows driver and is not available before Windows is loaded) must provide at least the capabilities in this guideline for the serial connection (except 21.2), or must provide the capabilities outlined in #22 "IA-32 system that implements a management service processor but no external serial connection meets reset and display redirection requirements" for the alternate LAN-based management connection. It is recommended that service processors with both types of the above ports provide both sets of capabilities.

21.1. IA-32 system with management service processor and external serial headless capability supports BIOS redirection of console output, plus serial port and serial headless cabling requirements

Systems with service processors that provide external serial support must meet the requirements in guideline "#20. IA-32 system that implements headless capabilities without management service processor provides serial headless support," plus the additional requirements listed in this guideline.

21.2. IA-32 system with management service processor and external serial headless capability supports sharing of the service processor serial port with Windows

If a management service processor provides a serial port interface externally, this port must allow unconstrained communication between an external device (such as a management platform) and Windows. This communication path must be available as soon as the loader is called. The shared serial port must be locatable via the mechanism described in Serial Port Console Redirection Table.

Additionally, the service processor must comply with the requirements of Extensions to the VT100 Terminal Definition. The service processor may interrupt Windows’ use of the shared port per the mechanisms required in Extensions to the VT100 Terminal Definition. The serial port must not appear altered in any fashion from the perspective of Windows when the port is in use by the service processor. Also, the service processor’s output to the serial port must comply with Extensions to the VT100 Terminal Definition.

21.3. IA-32 system with management service processor and external serial headless capability supports remote system reset capabilities

The management service processor must support a remote system reset capability as described in Extensions to the VT100 Terminal Definition.

22. IA-32 system that implements a management service processor but no external serial connection meets reset and display redirection requirements

Required if system implements headless support with a management service processor

This requirement is an optional solution to the basic requirement stated in "#19, IA-32 system provides headless server capabilities meeting Hardware Design Guide requirements."

For enhanced out-of-band management capabilities, systems can provide a management service processor. This processor can enable such advanced capabilities as remote system reset and assistance with disaster recovery.

Note that an IA-32 system is not required to provide a management service processor. This guideline addresses the minimum capabilities needed for headless server support with service processors but no external serial connection capabilities.

The management service processor must support a remote system reset capability. This capability may be provided through OEM-specific mechanisms.

Recommendation

Recommended: Systems with service processors provide display redirection capabilities for both text and graphics modes.

23. Uninterruptible power supply that has pass-through legacy serial port supports sharing of pass-through serial port with Windows headless capabilities

Recommended

If an uninterruptible power supply (UPS) uses an external pass-through serial port interface, this port should allow unconstrained communication among the system for which the UPS provides backup power, a management platform, and Windows. The UPS may interrupt Windows’ use of the pass-through port per the mechanisms required in Extensions to the VT100 Terminal Definition.

Additionally, the UPS should comply with the requirements of Extensions to the VT100 Terminal Definition. The entire end-to-end pass-through serial path should present the serial signals from the platform under management to the management console as though from a serial port through a null modem cable as described in "#20.3 IA-32 system headless connections are null modem cables that support Carrier Detect signal."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Other Requirements

24. IA-32 system includes APIC support

Required

IA-32 servers must include Advanced Programmable Interrupt Controller (APIC) support that complies with ACPI 1.0b, implemented by including the Multiple APIC Description Table defined in Section 5.2.8 of ACPI 1.0b. Features such as targeted interrupts, broadcast interrupts, and prior-owner interrupts must be supported. The local APIC in a processor must be hardware enabled, all hardware interrupts must be connected to an IOAPIC, and the IOAPIC must be connected to local APIC in the processor (or processors). If multiple APICS, processors, or IOAPICs are present, then all components must meet this requirement.

Implementation of APIC support on server systems provides a greater number of IRQ resources, even within traditional server architectures.

25. IA-64 system includes SAPIC support

Required

An IA-64 system must include SAPIC support that complies with the 64-bit extensions to ACPI, implemented by including the Multiple SAPIC Description Table as defined in ACPI 2.0, Section 5.2.10.4.

25.1. IA-64 core chipset interrupt delivery mechanisms use SAPIC-compatible programming model

IA-64 interrupt delivery mechanisms must use a SAPIC-compatible programming model.

25.2. IA-64 system uses SAPIC-compatible programming model

Regardless of the hardware interrupt delivery mechanism, interrupt controllers in IA-64 servers must use a programming model compatible with the SAPIC extension for IA-64 processors defined in ACPI 2.0, Section 5.2.10.4.

26. IA-64 system supports message-signaled interrupts

Recommended

As the I/O subsystems in servers become more complex, the requirement to provide each PCI slot and device access to a nonshared interrupt line becomes increasingly more difficult and expensive to implement on the system board. Thus, providing support for message-signaled interrupts (MSI) as specified in PCI 2.2 provides an infrastructure to help alleviate this burden.

It is expected that the physical (non-MSI) interrupt mechanism will be supported in the system, but that the MSI will be present to facilitate enhanced expandability.

This recommendation will become a requirement in a future version of this guide.

27. System with no 8042 or other port 60h and port 64h based keyboard controller meets Hardware Design Guide requirements

Required

System designs that remove legacy (port 60h/port 64h) keyboard controllers, typically implemented using 8042 or similar controllers, must meet these requirements to function with Windows. Specifically, these systems must properly set Fixed ACPI Description Table Boot Architecture Flags as described in the ACPI specification and "Proposed ACPI Specification Changes for Legacy Free," available at http://www.microsoft.com/hwdev/onnow/download/LFreeACPI.doc. IA-64 systems must comply with ACPI 2.0. IA-32 systems must comply with ACPI 1.0b.

28. IA-32 system provides necessary ISR support

Required

IA-32 system designs that reduce the amount of legacy ISR support in conjunction with other legacy removal efforts (such as 8042 removal) must still provide the necessary ISRs required to boot IA-32 systems using BIOS. The minimum requirements include support for ISR 8h, 13h, and 19h (all functions), and ISR 15h, function E820h.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


I/O Bus Requirements

This section summarizes requirements for the I/O bus, with emphasis on requirements related to the PCI bus.

29. System provides an I/O bus based on industry standard specification

Required

Currently, for most systems, this requirement is met with PCI.

30. All PCI adapters function properly on system supporting more than 4 GB memory

Required

On IA-32 and IA-64 systems that provide support for more than 4 GB of system memory, all 32-bit and 64-bit PCI adapters in the system must be able to function properly. In addition, certain classes of adapters—such as those on the primary data path where the majority of network and storage I/O occurs—must also be able to address the full physical address space of the platform.

For 32-bit PCI adapters that will be used on the primary data path, this means that the adapter must be able to support the PCI Dual Address Cycle (DAC) command. Note that 10/100 Ethernet adapters and embedded 10/100 Ethernet devices do not need to support DAC; however, such devices must still function properly in these systems even if they do not implement DAC support. Any other 32-bit devices that do not support DAC and are configured on the same 32-bit PCI bus must not interfere with the ability of the devices that support DAC to address all of memory.

Additionally, all 32-bit PCI buses, host bridges, and PCI-to-PCI bridges must support DAC.

There are special considerations that system designers must address when using legacy devices, adapters, and bridges in systems that provide support for more than 4 GB of memory. For information about how Windows 2000 Advanced Server and Windows 2000 Datacenter Server behave in the case where a non-DAC capable bus is detected on a system that supports more than 4 GB of memory, please see the white paper at http://www.microsoft.com/hwdev/newPC/PAEdrv.htm.

31. All PCI bridges in an IA-64 system support DAC

Required

For IA-64 systems, all PCI bridges on the motherboard must support DAC for inbound access, and DAC-capable devices must not be connected below non-DAC-capable bridges, for example, on adapter cards.

New 64-bit adapters must be DAC capable.

This DAC requirement does not apply to outbound accesses to PCI devices. However, for systems where DAC is not supported on outbound accesses to PCI devices, the system firmware must not claim that the bus aperture can be placed above the 4-GB boundary.

32. System supports a 64-bit PCI bus architecture

Required for all IA-64 systems

Required for all IA-32 systems that support more than 4 GB of system memory

All 64-bit PCI adapters must be able to address any location in the address space supported by the platform.

The server system must support a 64-bit PCI bus if the server has 64-bit processors or has the capability to support more than 4 GB of physical memory.

Recommendation

Recommended: Support for a 66 MHz PCI bus.

33. PCI bus and devices comply with PCI 2.2 and other requirements

Required

If PCI is present in the system, the PCI bus and PCI expansion connectors must meet the requirements defined in the PCI 2.2 specification, plus any additional PCI requirements in this guide. The system must also support the addition of PCI bridge cards, and all PCI connectors on the system board set must be able to allow any PCI expansion card to have bus master privileges.

All server systems also must meet the PCI requirements defined in this section, which include requirements to ensure effective Plug and Play support. In particular, see the required implementation for PCI 2.2 Subsystem Vendor IDs in guideline "#45. Device IDs include PCI Subsystem IDs."

Servers that provide support for more than 4 GB of physical memory and that provide 32-bit PCI bus capabilities must provide support for the PCI DAC command on 32-bit PCI buses, host bridges, and PCI to PCI bridges, and specific classes of PCI adapters as described in guideline "#30. All PCI adapters function properly on system supporting more than 4 GB memory."

Recommendation

Recommended: PCI controllers should be implemented as peer bridges to provide more effective bus bandwidth.

Note on PCI to PCI bridge configuration: The system firmware must correctly configure PCI-to-PCI bridges if the system has a VGA device behind a bridge. Specifically, the system firmware must correctly set the VGA Enable and ISA Enable bits on the bridges, to prevent the bridges from conflicting with each other.

Additional details with illustrated examples of correct configurations of PCI-to-PCI bridge devices are provided in the white paper, "Configuring PCI-to-PCI Bridges with VGA Cards," available on the web at http://www.microsoft.com/hwdev/pci/vgacard.htm.

34. PCI devices in an IA-64 system support message-signaled interrupts

Recommended

As the I/O subsystems in servers become more complex, the requirement to provide each PCI slot and device access to a nonshared interrupt line becomes increasingly more difficult and expensive to implement on the system board. Thus, requiring the PCI devices in IA-64 systems to provide support for MSI as specified in PCI 2.2 will provide an infrastructure to help alleviate this burden.

This recommendation will become a requirement in the next version of this guide.

35. System makes a best effort to provide each PCI slot and device type access to a non-shared interrupt line

Required

System designers must make a best effort to provide access to non-shared interrupt lines by meeting these conditions:

  • The system design enables all PCI slots and PCI device types to obtain exclusive use of an interrupt line when exclusive access increases performance.
  • Dedicated PCI interrupts must not use vectors from ISA bus interrupts.

The high-end and low-end commodity server platforms present certain design challenges. For high-end servers, PCI 2.2 taken by itself imposes a limitation for Intel Architecture-based systems because the values written to the Interrupt Line register in configuration space must correspond to IRQ numbers 0-15 of the standard dual 8259 configuration, or to the value 255 which means "unknown" or "no connection." The values between 15 and 255 are reserved. This fixed connection legacy dual 8259 configuration, if examined alone, constrains Intel Architecture-based systems, even when they use sophisticated interrupt-routing hardware and APIC support. For low-end servers, some core logic offerings provide little or no interrupt-routing support, and designers implement rotating access to interrupt resources using simple wire-OR techniques, such as those illustrated in the implementation note in Section 2.2.6 of PCI 2.2.

Windows 2000, with its support for both MPS 1.4 and ACPI on 32-bit platforms and ACPI on IA-64 systems, uses mechanisms beyond the legacy methods of routing all PCI interrupts through the legacy cascaded 8259 interrupt controllers to determine proper allocation and routing of PCI bus IRQs. This Windows 2000 capability allows use of interrupts beyond the 0-15 range permitted by the strict reading of the current PCI 2.2 specification language for Intel Architecture systems. System designers should include sufficient interrupt resources in their systems to provide at least one dedicated interrupt per PCI function for embedded devices and one interrupt per PCI INTA# - INTD# line on a PCI slot. This will become a requirement for all servers in a future version of this guideline.

When system designers cannot provide a non-shared interrupt line to a particular PCI device or slot because of the situations cited, the server system’s documentation must explain clearly to the end user of the system how interrupt resources are allocated on the platform and which devices cannot avoid sharing interrupts. System designers may provide this documentation or information as they deem most appropriate for their product. Some possible mechanisms include:

  • Documenting slots according to the order in which cards should be inserted to prevent interrupt sharing for as long as possible
  • Providing information on interrupt routing and sharing via system setup programs

Some instances need additional clarification to fit within the context of this guideline. At the system designer’s discretion, PCI devices can share an interrupt line under the following conditions:

  • One system interrupt line can be shared by all PCI devices on an expansion card. In other words, PCI INTA# - INTD# may share the use of a single system interrupt directed to a given PCI expansion slot. This instance of line sharing applies to both expansion card designs based on PCI multifunction devices and to expansion card designs using PCI-to-PCI bridges.
  • Devices can share an interrupt in a design where a system-board set has multiple instances of a given PCI device performing a specific function.

For example, two embedded PCI small computer system interface (SCSI) controllers on a system board can share a single system interrupt line. A single line can be shared when the functions of the devices are very similar, such as a case where one embedded SCSI controller may be dedicated to "narrow" (8-bit wide) SCSI devices and the other is dedicated to "wide" (16-bit wide) SCSI devices.

On the other hand, an embedded SCSI controller may not share an interrupt with an embedded network adapter on a system board, because they perform two different functions within the system and could contend for the shared interrupt in ways that will reduce overall system performance.

36. System does not contain ghost devices

Required

A computer must not include any ghost devices, which are devices that do not correctly decode the Type 1/Type 0 indicator. Such a device will appear on multiple PCI buses.

A PCI card should be visible through hardware configuration access at only one bus/device/function coordinate.

37. PCI-to-PCI bridges comply with PCI to PCI Bridge Specification 1.1

Required

PCI-to-PCI bridges must comply with PCI to PCI Bridge Specification, Revision 1.1.

38. System uses standard method to close BAR windows on nonsubtractive decode PCI bridges

Required

Setting the base address register (BAR) to its maximum value and the limit register to zeroes must effectively close the I/O or memory window references in that bridge BAR.

39. PCI devices do not use the <1 MB BAR type

Required

Devices must take any 32-bit BAR address.

Recommendation

Recommended for Enterprise class servers: Devices on a 64-bit PCI bus must take any 64-bit BAR address.

40. PCI devices decode only their own cycles

Required

PCI devices must not decode cycles that are not their own to avoid contention on the PCI bus. Notice that this requirement does not in any way prohibit the standard interfaces provided for by the PCI cache support option discussed in PCI 2.2, which allows the use of a snooping cache coherency mechanism. Auxiliary hardware that is used to provide non-local console support is permitted within the scope of this requirement.

41. VGA-compatible devices do not use non-video I/O ports

Required

A VGA-compatible device must not use any legacy I/O ports that are not set aside for video in the PCI 2.2 specification.

Recommendation

Recommended: Device includes a mode that does not require ISA VGA ports to function.

42. PCI chipsets support Ultra DMA (ATA/33, minimum)

Required

For servers that implement PCI ATA connectivity, PCI chipsets must implement DMA as defined in ATA/ATAPI-5, and implement Ultra DMA (also known as Ultra-ATA) as defined in the ATA-5 standard.

43. Functions in a multifunction PCI device do not share writable PCI configuration space bits

Required

The operating system treats each function of a multifunction PCI device as an independent device. As such, there can be no sharing between functions of writable PCI configuration space bits (such as the Command register).

44. Devices use the PCI configuration space for their Plug and Play IDs

Required

PCI 2.2 describes the configuration space used by the system to identify and configure each device attached to the bus. The configuration space is made up of a 256-byte address space for each device, and it contains sufficient information for the system to identify the capabilities of the device. Configuration of the device is also controlled from this address space.

The configuration space is made up of a header region and a device-dependent region. Each configuration space must have a 64-byte header at offset 0. All the device registers that the device circuit uses for initialization, configuration, and catastrophic error handling must fit within the space between byte 64 and byte 255.

All other registers that the device uses during normal operation must be located in normal I/O or memory space. Unimplemented registers or reads to reserved registers must complete normally and return zero. Writes to reserved registers must complete normally, and the data must be discarded.

All registers required by the device at interrupt time must be in I/O or memory space.

45. Device IDs include PCI Subsystem IDs

Required

The Subsystem ID (SID) and Subsystem Vendor ID (SVID) fields are required to comply with PCI 2.2.

The device designer is responsible for ensuring that the SID and SVID registers are implemented. The adapter designer or system-board designer who uses this device is responsible for ensuring that these registers are loaded with valid non-zero values before the operating system accesses this device.

  • To be valid, the SVID must be provided by the PCI SIG.
  • Values in the SID field are vendor-specific, but to be valid must be unique to a subsystem configuration. For example, if two system boards have the same graphics chipset, but one supports an internal expansion connector while the other has added functionality such as a TV output function, then each must load the SID field with a different, unique value.

For implementation details, see "PCI Device Subsystem IDs and Windows" at http://www.microsoft.com/hwdev/devdes/pciids.htm.

46. Interrupt routing is supported using ACPI

Required

The system must provide interrupt routing information using a _PRT object, as defined in Section 6.2.3 of ACPI 1.0b (for IA-32 systems) and Section 6.2.8 of ACPI 2.0 (for IA-64 systems). It is important to note that the _PRT object is the only method available for interrupt routing on IA-64 systems.

47. System that supports hot swapping or hot plugging for any PCI device uses ACPI-based methods

Required

Windows Whistler supports dynamic enumeration, installation, and removal of PCI devices if the implementation strictly complies with the hardware insert/remove notification mechanism as defined in Section 5.6.3 of ACPI 1.0b.

Other hot-plug implementations will work under Windows 2000 only if there is a supported hardware insert/remove notification mechanism, such as a bus standard. An example of an implementation based on an appropriate standards-based notification mechanism is a CardBus bus controller.

Note 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.

For more information about Windows 2000 and PCI Hot Plug, see http://www.microsoft.com/hwdev/pci/hotplugpci.htm.

48. All 66-MHz and 64-bit PCI buses in a server system comply with PCI 2.2 and other requirements

Required

If PCI buses that are 66 MHz, 64-bit, or both are present in a server system, all devices connected to these buses must meet the requirements defined in PCI 2.2 or later.

Recommendation

Recommended: 33-MHz/32-bit PCI devices and 66-MHz/64-bit PCI devices should be placed on separate PCI buses to allow the best use of I/O bandwidth in a server system.

49. All PCI devices complete memory write transaction (as a target) within specified times

Required

All devices must comply with the PCI 2.2 Maximum Completion Time requirement. Complying with this requirement ensures shorter transaction latencies on PCI, allowing more robust handling of isochronous streams in the system.

50. All PCI components comply with PCI Bus Power Management Interface specification
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
Enterprise: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
SOHO: | Required | Required | Required

The PCI bus, any PCI-to-PCI bridges on the bus, and all add-on capable devices on the PCI bus must comply with PCI Bus Power Management Interface Specification, Revision 1.1 or later. This includes correct implementation of the PCI configuration space registers used by power management operations, and the appropriate device state (Dx) definitions for the PCI bus, any PCI-to-PCI bridges on the bus, and all add-on-capable devices on the PCI bus. ACPI is not an acceptable alternative.

51. System that supports S3 or S4 state provides support for 3.3Vaux
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Recommended | Recommended
Enterprise: | Recommended | Recommended | Recommended
SOHO: | Required | Required | Required

System support for delivery of 3.3Vaux to a PCI bus segment must be capable of powering a single PCI slot on that bus segment with 375 mA at 3.3V and it must also be capable of powering each of the other PCI slots on the segment with 20 mA at 3.3V whenever the PCI bus is in the B3 state.

In the case of systems with multiple PCI bus segments, delivering 3.3Vaux to one PCI bus segment does not mean that all PCI bus segments will be required to implement delivery of 3.3Vaux. However, if a system with multiple PCI bus segments provides 3.3Vaux to one or more segments and not to all segments in the system, these capabilities must be clearly marked and documented so that the end user can determine which slots support this capability. Examples of methods for indicating which slots support 3.3Vaux include icons silk-screened on system board sets, slot color-coding, and chassis icons.

Systems must be capable of delivering 375 mA at 3.3V to all PCI slots on a power-managed bus segment whenever the PCI bus is in any "bus powered" state: B0, B1, or B2.

52. PCI bus power states are correctly implemented
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
Enterprise: | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported | Required if S1, S2, or S3 supported
SOHO: | Required | Required | Required

The PCI bus must be in a bus state (Bx) no higher than the system sleeping state (Sx). This means that if the system enters S1, the bus must be in B1, B2, or B3. If the system enters S2, the bus must be in B2 or B3, and if the system enters S3, the bus must be in B3. Of course, in S4 and S5, the system power is removed, so the bus state is B3. A PCI bus segment must not transition to the B3 state until all downstream devices have transitioned to D3.

Control of a PCI bus segment’s power is managed using the originating bus bridge for that PCI bus segment.

  • For CPU-to-PCI bridges, these controls must be implemented using ACPI or the PCI Power Management Interface Specification, Revision 1.1 (PCI-PM 1.1) or later.
  • For PCI-to-PCI bridges, these controls must be implemented in compliance with PCI-PM 1.1 or later.

53. Software PCI configuration space accesses on an IA-64 system use SAL procedures

Required

In particular, access to PCI configuration space must use mechanisms that do not directly reference PCI configuration space but that instead use the services provided by the SAL or other services which in turn call SAL services.

54. PCI-X buses and devices, if present, meet requirements for device and driver support

Required

Systems are not required to provide PCI-X capabilities. However, a system that implements PCI-X must comply with the PCI-X Addendum, Revision 1.0 or later specification, plus other relevant PCI device and driver requirements defined in this guide.

Recommendation

Recommended: PCI-X devices should not be mixed with PCI devices on a PCI-X bus in order to ensure optimum use of system I/O bandwidth.

55. InfiniBand fabric connections, fabrics, and devices, if present, meet requirements for device and driver support

Required

Systems are not required to provide InfiniBand capabilities. However, a system that implements InfiniBand must comply with the requirements defined in the version 1.0 or later specification, plus other relevant InfiniBand device and driver requirements as defined by this guide.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


USB Requirements

This section summarizes requirements for Universal Serial Bus.

56. System includes USB controller with at least one USB port

Required

To facilitate the eventual migration away from legacy connections for keyboards, pointing devices, serial devices, and parallel devices, server designers must integrate USB functionality into their server platforms with the minimum support being one USB controller with at least one available USB port. USB ports must comply with the related USB requirements in this guide.

57. All USB hardware complies with USB 1.1

Required

All USB hardware present on a server system and USB devices, including hubs, must comply with USB 1.1 or later.

When a system has more than one host controller, each host controller must provide full bandwidth and isochronous support. Host controllers should be located on PCI to meet this requirement. The host controller providing USB 1.1 functionality must comply with the specifications for either Open Host Controller Interface (OpenHCI), published by Compaq, Microsoft, and National Semiconductor, or Universal HCI (UHCI), published by Intel. Hardware manufacturers who design to one of these specifications are not required to provide an additional Windows 2000 device driver for their host controller.

Multiple OpenHCI and UHCI USB controllers are supported concurrently by the operating system.

58. USB devices and drivers support maximum flexibility of hardware interface options

Required

Device and driver designs must provide maximum flexibility for interface options to allow user-preference coordination by the operating system or other resource managers. This flexibility allows graceful use of multiple simultaneous devices and applications in a dynamic environment.

Minimum requirements consist of the following:

  • Must provide multiple alternate settings for each interface where any alternate setting consumes isochronous bandwidth.
  • Must not use isochronous bandwidth for alternate setting 0. Devices must consume bandwidth only when they are in use.

59. System and devices comply with USB power management requirements

Required

The server system must comply with the power management requirements in USB 1.1 or later. In addition, USB devices must comply with the Interface Power Management feature in the USB Common Class Specification, Revision 1.1 or later.

60. USB devices comply with their related USB device class specifications

Required

A USB peripheral that fits into one of the USB device class definitions must comply with the related USB device class specification. USB class drivers in the operating system are implemented to support compliant devices in each particular class. Class driver extensions and WDM allow hardware manufacturers to innovate and differentiate their products while still complying with class specifications in their base operational modes.

61. USB hubs are self-powered

Required

This requirement does not apply for hubs integrated into keyboards. To minimize USB power consumption requirements, bus-powered hubs must provide ports that can be individually power switched. This contributes to the goal of reducing overall system power consumption.

62. USB devices install without pre-loading software

Required

A user must not be required to install software before hot-plugging a USB device. Instead, the user must be able to hot-plug the USB device, and then load any software in response to the operating system detection of the newly-attached device.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Other Bus Requirements

This section summarizes requirements related to other buses.

63. Any subsystems implementing I2O comply with standards and other requirements

Required

If I2O is implemented in a system, it must meet the requirements defined in this guide and in the I2O Architecture Specification, Version 1.5 or later, available at http://www.i2osig.org.

If I2O is implemented on a system, the system firmware must support I2O devices for the following configurations:

  • An I2O-capable system that includes no I2O-intelligent devices, whether provided on the system board set or as add-on devices. The system can have an installed adapter that is I2O-ready or I2O-compliant, and the system firmware must initialize the device as a multifunction device. The system cannot boot from this I2O device, because the system firmware does not support initialization of I2O bootable device.
  • An I2O-ready system that has some sort of intelligence on the system board set or on an add-on adapter that enables sending and receiving messages, as defined in the I2O specification. This intelligence can be an off-the-shelf processor, an application-specific integrated circuit (ASIC) when it is on the system board set, or it can be included as an add-on adapter. In these cases, the system firmware must support initializing and configuring the device, including support for multifunction PCI. Initialization and configuration of a PCI device does not imply that the system firmware supports compliant I2O initialization of boot devices or that the system can boot from an I2O device.
  • An I2O-compliant system that includes support for initializing and booting from I2O devices, whether provided on the system board set or as add-on devices. The system as a whole must be able to pass I2O compliance testing with Windows 2000.

64. System does not include ISA or LPC expansion slots

Required

No ISA or LPC expansion slots are allowed in servers designed to comply with these guidelines. The benefits of an ISA-free system include improved performance, easier and more stable system configuration, and lower support costs. There are no permitted exemption cases.

65. System does not include embedded ISA or LPC network adapters, storage controllers, or graphics adapters

Required

The benefits of an ISA-free system include improved performance, easier and more stable system configuration, and lower support costs.

66. System does not include ISA or LPC expansion devices

Required

An ISA or LPC expansion device in this context is defined as being an expansion adapter or device installed in an ISA or LPC slot.

No ISA or LPC expansion devices are allowed. There are no permitted exemptions to this requirement.

67. System that supports Winsock Direct connectivity meets requirements for device and driver support

Required

Systems are not required to provide Winsock Direct (WSD) connectivity capabilities. However, those systems that do must meet the following guidelines:

  • Provide a reliable transport through the combination of WSD hardware and software.

The Winsock Direct Specification is provided in the Windows 2000 DDK, and is available online at
http://www.microsoft.com/DDK/DDKdocs/Win2k/wsdpspec_1h66.htm.

  • Provide the necessary hardware, software, and driver support to facilitate access via the fast alternate paths. This would include the "normal" Network Driver Interface Specification (NDIS) 5.0-compliant miniport, plus a System Area Network Windows Sockets (Winsock) provider and a System Area Network Management driver. Installers for these components and any needed network management software components must also be provided.

Hardware characteristics and provider guidelines are defined in the Windows 2000 DDK, and are available online at http://www.microsoft.com/DDK/DDKdocs/Win2k/wsd_hw_0aur.htm.

Additionally, hardware must have page tables to translate user addresses to physical addresses. This allows direct user-mode access to the hardware, permitting endpoint resources to be mapped directly into the address space of a user-mode process. This permits application processes to post messaging requests directly to the hardware, with no system calls and no intermediate data copying.

Notes:
1. Winsock Direct and associated hardware are targeted for use in physically secure computer systems and environments, such as those associated with "back end" or "glass house" computing environments.
2. Vendors who are sizing their page table hardware should take into account the number of simultaneous connections expected to be supported by the hardware in conjunction with the applications using this connection. The number of simultaneous connections may range widely (from thousands to hundreds). In addition to the number of simultaneous connections, designers need to take into account the page size (specific to the host computer system) and whether the connection is registering memory for RDMA operations in addition to memory registered for messages. Cards that support thousands of simultaneous connections will need to map tens of thousands of page table entries.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Device Requirements

This section summarizes requirements for the system devices and peripherals provided with server systems.

Note: It is recognized that administrators might not want a keyboard, mouse, or monitor attached directly as a local console to working servers. However, these devices, headless server capabilities, or ability to install the operating system using the Windows Remote Install Server are minimum requirements for installation of the operating system. Additionally, local console, headless server, or both capabilities are necessary to provide maintenance, diagnostic, and troubleshooting capabilities throughout the life of a server.

68. Device driver and installation meet Hardware Design Guide requirements

Required

Each device must have drivers for the Windows 2000 operating system. The manufacturer does not need to supply a driver if the device functions fully and correctly using a driver provided with the operating system.

If the manufacturer supplies drivers, the device drivers and installation requirements include the following.

68.1 All devices and drivers meet requirements defined in the guide.

Each device included in a server system must comply with the requirements defined in this section and must have supporting 32-bit (for IA-32 systems) or 64-bit (for IA-64 systems) device drivers. The installation and loading of a driver must not reduce or eliminate functionality of other devices installed on the system. The following are also required:

  • Every driver (or minidriver) must support Plug and Play and power management I/O request packets (IRPs).
  • Real-mode or 16-bit protected-mode components must not be provided to operate under Windows 2000. Only 32-bit protected-mode components are installed on IA-32 systems. All devices in IA-64 systems must have 64-bit Windows 2000-compatible drivers.
  • Any device with WDM-based operating system support must have a manufacturer-supplied WDM minidriver or use the driver support provided with the operating system.

68.2 All configuration settings are stored in the registry.

The driver must not use INI files for configuration settings. The driver must also include correct provider, version, and copyright entries. This information is displayed in the user interface.

68.3 Files have correct identifiers and are stored in the correct locations.

The correct minidriver and any other manufacturer-supplied files specified in the device’s INF must be installed in the correct location.

For manufacturer-provided files, the vendor must not be identified as Microsoft; all other copyright and version information must be correct for the manufacturer.

Driver files provided by the vendor must not use the same file names used by files included in Microsoft operating systems and provided as either retail or OEM products, unless specifically agreed upon with Microsoft.

68.4 Driver installation and removal use methods defined in the Windows 2000 DDK.

The device driver must be removable using Windows-based software by using either the Windows Control Panel option for removing devices or its own remove utility. For information, see "Setup, Plug & Play, Power Management" in the Windows 2000 DDK.

However, any software applications included with the device can be installed using an alternate Windows-based installation method as defined in the Microsoft Platform Software Development Kit (SDK). Also, any software components and registry entries installed during driver installation must be removed during driver removal.

68.5 Driver supports unattended installation.

It must be possible for a user to install a device’s driver without being present. This unattended installation can be done using a mechanism such as a script or special software for supplying the required parameters.

68.6 Windows Help file is provided if special driver parameters are used.

This requirement ensures that the user can correctly change settings. The device’s installation routine must install the Help file as part of the setup program. The user interface for the device’s dialog boxes must display the correct Help file; the Help file must contain relevant information to assist the user. The guidelines for implementing Help are defined in the Microsoft Platform SDK.

69. Keyboard and mouse connections meet requirements for bus and device classes

Required

These requirements, which depend on the type of connection designed into the system, ensure that all Plug and Play requirements are met and that Microsoft drivers support this device.

If a PS/2-style keyboard port is used, the following requirements must be met:

  • Comply in full with requirements in the IBM Personal System/2 specifications
  • Use IRQ 1 (via PIC or APIC) to interrupt the processor
  • Map the I/O address ports to 60h and 64h.
  • Return expected scan codes, including send ID (0F2h) and response ACK (0FAh), plus 2-byte ID.

If a PS/2-style mouse port is used, the following requirements must be met:

  • Comply in full with requirements in the IBM Personal System/2 specifications.
  • Use a device with an 8042-compatible interface to the keyboard controller function to ensure compatibility with Windows 2000. In most cases, the existing 8042 keyboard port is sufficient.
  • The mouse port must assert an interrupt that is distinct from the keyboard interrupt.
  • Return expected codes, including send ID (0F2h) and response ACK (0FAh) + 1-byte ID.

If a USB connection is used, the following requirements must be met:

  • Comply with USB 1.1 or later.
  • Comply with USB Human Interface Device Class Specifications, Version 1.1 or later.
  • Implement minidriver support based on WDM HID class support in the operating system, as defined in "Drivers for Input Devices" the Windows 2000 DDK.

If a USB keyboard is the sole keyboard implementation, the system must provide boot support as specified in "Startup Support Requirements" of Chapter 2, "System Component Requirements," and as defined in Universal Serial Bus PC Legacy Compatibility Specification, Version 0.9 or later. This support must provide the ability for the user to enter the system’s firmware-based setup program and provide enough functionality to get a USB-aware operating system installed and booted.

70. Serial port adapter meets device class specifications for its bus

Required

A serial port implementation that uses a non-legacy bus must meet the specific device class requirements for that bus. For example, a USB to serial adapter must comply with all related USB specifications, including:

  • USB 1.1 or later.
  • USB Class Definition for Communication Devices, Version 1.0 (CDC 1.0)or later.

The "Standard Serial Interface Circuit Emulation" appendix in USB CDC 1.0 specifically addresses serial-port compatibility.

If a legacy serial port is implemented in a server system, it must meet the following requirements:

  • A 16550A buffered Universal Asynchronous Receiver/Transmitter (UART) or equivalent buffered legacy serial port is required to support high-speed communications while reducing the CPU requirements for servicing the device. The device must be able to support 115.2K baud.
  • A legacy serial port must provide flexible resource configuration and complete dynamic disable capabilities as defined in Plug and Play External COM Device Specification, Version 1.0. Two IRQs are required for each port implemented.
  • In the event of an irreconcilable conflict with other serial ports on the system, a legacy serial port must be capable of being disabled by Plug and Play software. This capability allows at least one of the two conflicting serial ports to operate correctly.
  • The firmware must configure at least one serial port to use either 2F8h or 3F8h. This requirement allows the port to be treated as a boot device by the firmware so that components can use the port for diagnostic purposes in the event that system debugging is required by either the BIOS or the operating system.
Recommendation

The following are the recommended resource settings for non-PCI devices:

  • Four I/O locations for each port (standard ISA I/O addresses are 3F8h, 2F8h, 3E8h, and 2E8h). Using the standard addresses ensures the proper functioning of software that directly addresses these locations.
  • Two IRQ signals (standard is PIC-based IRQ 3, IRQ 4). Support of the standard IRQ signals ensures the proper functioning of software written for systems that use standard IRQ signals.
  • If two serial ports are implemented in the system, the following IRQ assignments are recommended:
  • For serial port A: selection between PIC-based IRQ 4 and IRQ 11.
  • For serial port B: selection between PIC-based IRQ 3 and IRQ 10.

71. IA-64 system does not include parallel port

Required

64-bit Windows does not provide native legacy parallel port support. Parallel ports must not be present in IA-64 systems.

72. If present on IA-32 system, legacy parallel port meets requirements for bus and device classes

Required for all IA-32 server types, with ECP support Required for SOHO servers

This requirement presents information that is useful for system designers who want to incorporate parallel port support in their server designs. There is no requirement that a parallel port be present on a server; designers are strongly discouraged from incorporating parallel ports based on legacy parallel port technologies. However, if a parallel port is present on a server, then it must meet the applicable requirements in this guideline.

In addition to other capabilities listed here, the parallel port on a SOHO system must support the ECP protocol as defined by the IEEE 1284-1994 specification. This capability allows connections with higher-speed parallel peripherals.

If implemented in a server system, a legacy parallel port must provide flexible resource configuration following the Plug and Play Parallel Port Device Specification, Version 1.0b. Resource requirements must be met for each device of this type on the system. The requirements cannot be split between two ports on the system.

For non-PCI devices, the minimum resource requirements for each parallel port on the system are as follows:

  • The parallel port must support ISA I/O addresses of 378h and 278h, plus 3BC or a vendor-assigned I/O address. Using these standard I/O addresses ensures proper functioning of software written for operating systems that directly address these locations.
Recommendation

Recommended: Map the base I/O address to four additional locations.

  • The parallel port must support PIC-based IRQ 5 and IRQ 7. Using these standard IRQs ensures proper functioning of software written for operating systems that use standard IRQ signals.
Recommendation

Recommended: Support five additional IRQ signals.

  • The parallel port must support two unique DMA channel selections if its design supports block data transfers to memory using DMA controllers. Notice also that the DMA function will not work on a parallel port without an IRQ because the end of a DMA transfer is signaled by an interrupt.
  • To ensure Plug and Play support for resolution of resource conflicts, a full list of options for all possible configuration combinations must be enumerated, including:
  • Options for both extended capabilities port (ECP) mode, which requires an I/O address, an IRQ, and a DMA selection, and standard LPT mode, which requires only an I/O address.
  • Options that specify only the I/O address, which allows Windows 2000 to assign the IRQ and DMA channel.

On all ACPI-based systems, Windows 2000 obtains information on the parallel port base addresses through the ACPI tree (for parallel ports implemented on the system board set rather than on an expansion card on an expansion bus).

A legacy parallel port implemented in a server system must also meet the following requirements:

  • Enhanced parallel port (EPP) support does not use restricted I/O addresses. Some EPP implementations require eight contiguous I/O ports. If EPP support is implemented, the hardware cannot use the ISA I/O address 3BCh as a base I/O address because VGA devices require use of port 3C0h.
  • Compatibility, nibble mode, and ECP protocols meet IEEE 1284-1994 specifications. Support for a parallel port must include the compatibility mode and nibble mode protocols required by the IEEE 1284-1994 specification for minimum compliance. This support allows other IEEE 1284-compliant devices to be connected without problems.
Recommendation

Recommended: Legacy parallel port supports the ECP protocol as defined by IEEE 1284, allowing connections with higher-speed parallel peripherals. However, if the port can support the compatibility and nibble mode protocols as described earlier, it complies with the Basic and Enterprise class guidelines that allow connection of other IEEE 1284-compliant devices.

  • Port connectors meet the minimum requirements defined in the IEEE 1284-I specifications. IEEE 1284-I–compliant ports must use a standard DB25 connector found on existing system parallel port designs. This connector is called an IEEE 1284-A connector in the specification.

IEEE 1284-II–compliant ports must use an IEEE 1284-C connector. This connector is used on both the port and the peripheral device.

  • IEEE 1284 peripherals have Plug and Play device IDs. The device ID is described fully in the IEEE 1284 specification. All characters in the device identification string must consist only of ASCII values 20h–7Fh. The device identification string consists of a leading zero, a hexadecimal value that represents the length of the string, and then a set of fields, in ASCII, with a unique identification string.

In addition to the requirements specified in the Plug and Play Parallel Port Device Specification, Version 1.0b, the device ID string must contain the following keys, at a minimum. The keys are case sensitive and can be abbreviated in INF files as indicated.

Required key | Abbreviated string
MANUFACTURER | MFG
MODEL | MDL
CLASS | CLS
DESCRIPTION | DES

All MANUFACTURER and MODEL key values must remain unique for each manufacturer. All MANUFACTURER, MODEL, CLASS, and DESCRIPTION key values must remain static for a specific unit; ID values do not change for different hardware configurations. For example, a user adding a memory module to a printer should not change the MODEL key value reported as part of the device identifier. However, if the user adds memory by installing an upgrade kit that requires a different driver or requires the existing driver to behave differently, then changing the MODEL value is acceptable as part of the upgrade installation process.

The CLASS key describes the type of parallel device. The CLASS key can contain the values PRINTER, MODEM, NET, HDC, PCMCIA, MEDIA, FDC, PORTS, SCANNER, or DIGCAM. HDC refers to hard disk controller. MEDIA refers to any multimedia device. FDC refers to floppy disk controller.

The DESCRIPTION key is an ASCII string of up to 128 characters that contains a description of the device that the manufacturer wants to have presented if a device driver is not found for the peripheral.

For information, see "How Does Setup Select a Driver For a Device?" in the Windows 2000 DDK.

Recommendation

Recommended: The CID key can provide a value that exactly matches a peripheral name supported by a device driver shipped with Windows 2000 Server. The value must match a value listed in the device’s INF file.

73. USB-to-printer port adapters comply with USB specifications

Required

A USB to printer port (IEEE 1284, or "parallel") adapter must comply with all related USB specifications, including:

  • USB 1.1 or later.
  • Universal Serial Bus Class Definition for Printing Devices, Version 1.0 or later.
74. System includes emergency repair support

Required

If an OEM does not provide a floppy disk drive for this purpose, an alternate emergency repair method must be provided.

Recommendation

Recommended: Floppy disk support is recommended for emergency repair disk purposes. If a floppy disk drive is provided, the recommended support should be a solution based on an external bus, supporting migration away from legacy devices. If implemented as an ATA floppy drive, the drive must comply with ARMD 1.0 or later.

75. Primary graphics adapter on IA-64 system meets minimum requirements

Required

At a minimum, the adapter must support 800 × 600 × 256 color, following the VESA monitor timing standards and guidelines for this mode.

The adapter must also work normally with the default VGA mode driver, which is required for installing the operating system, so the primary adapter must support 4-bit planar VGA mode.

76. Primary graphics adapter on IA-32 system, if present, meets minimum requirements

Required

Server systems which meet the requirements in this design guide for 32-bit Windows "headless server" capabilities are not required to supply a local console primary graphics adapter. However, if a primary graphics adapter is present in the system, at a minimum, the adapter must support 800 × 600 × 256 color, following the VESA monitor timing standards and guidelines for this mode.

The adapter must also work normally with the default VGA mode driver, which is required for installing the operating system, so the primary adapter must support 4-bit planar VGA mode.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Network Adapter Requirements

This section describes the requirements for network adapters. Many of these requirements also apply to other network communications devices such as Integrated Service Digital Network (ISDN), cable modem, and Asymmetric Digital Subscriber Line (ADSL), as indicated later in this guide.

Note: It is recognized that OEMs supply server systems to customers in situations where the customer will insert network adapters at the end-user site. Systems designed for specific customers are exempt from including a network adapter. However, if a network adapter is included in the system, it must meet these requirements.

Also, references in this chapter to adapters, network interfaces and so on should be taken to apply equally to add-in network adapter cards, network implementations on the system motherboard, and external network interfaces, without preference for any of these types of implementation unless otherwise noted.

77. System includes non-ISA/non-LPC NDIS 5.0 network adapter

Required

An ISA or LPC-based network adapter solution is not allowed for a server system.

78. Network adapter uses NDIS 5.0 miniport driver

Required

A network adapter must use an NDIS 5.0 miniport driver and meet the following requirements.

78.1 The network adapter driver must be based on and comply with NDIS 5.0 in order to take advantage of Windows 2000 operating system capabilities.

The driver must follow the NDIS miniport driver model defined in "Network Drivers" in the Windows 2000 DDK.

Important: The development of full MAC drivers is no longer supported. Support for full MAC drivers will be removed in future versions of Windows.

78.2 If the network device is for connection-oriented media, it must meet connection-oriented miniport driver and call manager driver requirements.

This is required for connection-oriented media such as Asynchronous Transfer Mode (ATM), ISDN, Frame Relay, or X.25. Drivers for such devices must follow the guidelines in "Connection-Oriented NDIS" in the Windows 2000 DDK.

In some cases, such as ATM, the call manager driver is included in the operating system and the vendor needs to provide only an NDIS 5.0 connection-oriented miniport driver. For other connection-oriented media, such as ISDN or X.25, the call manager is not included in the operating system and must be provided with the hardware. The call manager support can be integrated in the connection-oriented miniport driver or implemented as a separate NDIS 5.0 call manager driver. The documentation for both integrated or separated call manager driver is included in "Connection-Oriented NDIS" in the Windows 2000 DDK.

78.3 An intermediate NDIS 5.0 miniport driver is required for network adapters that connect to the system using IEEE 1394 or USB buses.

This driver exposes its media type to NDIS at its upper edge and interfaces with the appropriate bus driver, IEEE 1394 or USB, at its lower edge.

The NDIS 5.0 miniport driver must also meet these requirements:

78.4 Driver works correctly with Microsoft network clients and protocols

This includes the 32-bit Microsoft client and NetWare-compatible clients provided with Windows, whether connected to a Windows 2000-based server, a Novell NetWare 3.x, 4.x, or 5.x server, or a Windows-based peer server. In all cases, this includes connections using Microsoft Transmission Control Protocol/ Internet Protocol (TCP/IP), IPX/SPX-compatible protocol, and NetBIOS Extended User Interface (NetBEUI) in LANs. In WANs, connections must work correctly using TCP/IP.

78.5 Driver makes only NDIS library calls or WDM system calls

NDIS conformance must be validated over single and multiple network connections. For Windows 2000, this must be validated on a multiprocessor system as part of the testing process.

78.6 Driver uses Windows 2000 INF format

All network components must use the Windows 2000 INF format. For information, see "Creating an INF File" in the Windows 2000 DDK.

For Windows 2000, there is no legacy INF support.

78.7 Driver is deserialized

NDIS 5.0 introduces support for deserialized miniports, enabling performance improvements and scalability on Windows 2000 multiprocessor systems.

79. NDIS 5.0 miniport driver supports high-performance send and receive calls

Required

NDIS drivers for server-side network adapters must support the higher performance send (NdisSendPackets) and receive (NdisMIndicateReceivePacket) calls as documented in the Windows 2000 DDK.

80. Full-duplex adapter automatically detects and switches to full-duplex mode

Required

The network adapter must negotiate full duplex operation by default when both the network adapter and switch port in a link pair support full duplex and the networking technology provides a standard way for each to detect and/or negotiate the duplex mode. Half duplex can be used if that is the only mode supported by one or both link partners or if it can be configured manually when warranted by special conditions. The goal is to configure this setting automatically without end-user intervention.

81. Network adapter automatically senses presence of functional network connection

Required

Where the network media allows it, the network adapter must be capable of dynamically determining whether it is connected to a functional link partner such as a hub, switch, or router. The device must indicate the link state in the following cases:

  • At boot time
  • After returning to D0 power state

When the link state changes while in the D0 power state (no time limit is specified for the required detection or status indication)

If the adapter is on an expansion card not used as a boot device, then the device drivers can determine the presence of the functional link. If the device is not connected to a functional link partner, the miniport driver must provide appropriate NDIS status indication, using support for cable sense in NDIS 5.0.

For information about NDIS status codes and indication mechanisms, see "Reporting Hardware Status" in the Windows 2000 DDK.

82. Network adapter automatically senses transceiver type

Required

Network adapters that support multiple transceivers must be capable of automatically detecting which transceiver type is connected to the network unless this is not possible with the network media at hand. The network adapter then must automatically drive the correct connection. In all cases, the user must not be required to set jumpers or manually enter information to inform the operating system of the transceiver type.

83. Network adapter can transmit packets from buffers aligned on any boundary

Required

Buffer alignment refers to whether a buffer begins on an odd-byte, word, double word, or other boundary. Adapters must be able to transmit packets any of whose fragments are on an odd-byte boundary.

For performance reasons, packets should be received into contiguous buffers on a double word boundary.

84. Network adapter communicates with driver across any bridge

Required

If the adapter uses a bridge, all communications must be free of errors across any bridge, such as a PCI bridge adapter.

85. Network adapter supports configuration capabilities and registry settings for performance tuning

Required

Some network adapters and drivers might support additional configuration capabilities for performance tuning when used in special environments or applications. Any tuning parameters that are set by the user, an application, or the operating system must be controlled through registry variables.

An example of such performance optimizations might be adjustment of interrupt moderation or the number of receive buffers for systems used as dedicated routers.

In addition to Dynamic Interrupt Moderation, there are other techniques that can be implemented on network adapters to maximize system performance for special environments or applications.

User-tunable parameters must be set through registry variables as parameters for network adapters and must not be set in .INI files, configuration files, or in other locations. These parameters can be accessed using the Advanced Page in the Device Manager. The variables should be set through standard user interfaces provided in Windows.

86. PCI network adapter properly supports higher-level PCI commands

Required

Specifically, network adapters must properly support the Memory Read Multiple (MRM), Memory Read Line (MRL), and Memory Write and Invalidate (MWI) commands. PCI commands are defined in the PCI 2.2 specification. This requirement ensures efficient data transfer.

87. PCI network adapters are bus masters

Required

To improve the system performance by decreasing the load on the system processor, the PCI network adapters must be bus masters.

88. USB or IEEE 1394 network device complies with related device class specifications

Required

External networking devices attached using a serial bus (USB, USB 2.0, or IEEE 1394) must support standard control interface specifications where applicable.

All external USB networking devices must support USB CDC 1.1 and must support one of the following:

  • Ethernet connection model (CDC 1.1)
  • Remote NDIS over CDC 1.1
  • Communications API (CAPI) over CDC 1.1 (ISDN modems)

External IEEE 1394 networking adapters must support Remote NDIS over SBP-2.

89. Network device and driver meet Plug and Play and power management requirements.

Required

The additional Plug and Play and power management requirements for network communications devices include the following:

  • Plug and Play capabilities support multiple adapters. For network communications devices, the Plug and Play IDs and resource support must be sufficient to automatically support the addition of multiple network communications devices to the system. This is true for the same and different types of network communications devices.
  • All resource settings are reported in the user interface. All resource settings must be viewable in the Device Manager and in adapter properties dialog boxes. All resource settings that can be changed by the user must be changed using the standard Windows user interface and not by way of INI files or other setting files.

This implies that all device resources must be set and read through the device’s standard bus interfaces. For PCI devices, this interface is the PCI configuration space. Further, device parameter settings must be stored in the registry.

90. Network communications device supports wake-up events

Recommended

This recommendation applies specifically to the following network communications devices and their associated NDIS 5.0 miniport drivers:

  • Ethernet and Token Ring network adapters
  • Integrated Data-Over-Cable Service Interface Specification (DOCSIS) cable modems
  • Other or future devices that transfer 802.3/DIX Ethernet framed packets

Note: The Network Device Class Power Management Reference Specification, Version 1.0 or later, does not yet define wake-up mechanisms for ISDN adapters or any network communications adapter that uses ATM signaling.

The system must be capable of being awakened from a lower power state based on network events specified by the local networking software. This capability yields the result that any standard Windows network access—such as connections to shared drives and Winsock connections, plus service and management applications—can awaken a system from lower power states transparently.

As defined in Network Device Class Power Management Reference Specification, a network adapter and its driver must support wake-up on receipt of a network wake-up frame. Support for wake-up on detection of a change in the network link state or on receipt of a Magic Packet event is optional. Implementation details are described in the "Network Wake-up Frames" and "Network Wake-up Frame Details" sections of Network Device Class Power Management Reference Specification, Version 1.0a and in the Windows 2000 DDK. See also the implementation notes at http://www.microsoft.com/hwdev/devdes/netpm.htm.

The packet patterns that define the wake-up frames are provided to the NDIS 5.0 miniport driver by the operating system. To enable Wake-On-LAN capability for basic networking scenarios, the network interface card must be capable of storing information describing a minimum of four wake-up packet patterns, and it must be able to recognize wake-up packets based on pattern matches anywhere in the first 128 bytes of the packet. The network adapters should be capable of storing infor.mation describing at least eight wake-up packet patterns to enable more advanced applications such as Wake-On-LAN capability on multi-homed systems or on receipt of multicast packets, in addition to the basic scenarios described here.

PCI-based network adapters must support the generation of a power management event (PME# assertion) from the D3 cold device state if the physical layer technology is generally capable of operating under the voltage and current constraints of the D3 cold device state. For example, 100Base-TX adapters can meet this requirement based on the state of the art in mid-1988. 1000Base-SX, 1000Base-LX, or 1000Base-TX (gigabit Ethernet using optical fiber or copper media) cannot meet this requirement because of the power required to operate the optical physical layer.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Connectionless Networking Requirements

This section lists the design guidelines that apply to all connectionless networking media, such as IEEE 802 LAN adapters (except for wireless) and Fiber Distributed Data Interface (FDDI) adapters.

91. Network adapter offloads TCP/IP checksum, IP Security encryption, and TCP message segmentation

Recommended

Server-side network adapters should support task-offload mechanisms to offload TCP/IP checksum calculation, IP Security encryption, and TCP message segmentation to intelligent hardware. This provides better utilization of computing resources on the server system. Mechanisms for off-loading these tasks are documented in the "Task Offload" topic in the Windows 2000 DDK.

92. Network adapter supports filtering for at least 32 multicast addresses

Required

This requirement applies to those networking technologies that support multicast, such as Ethernet, but it does not apply to those which do not support multicast, such as Token Ring, which distributes IP multicast traffic using the functional address as specified in RFC 1469.

This capability is needed to support "push" technology applications such as Microsoft NetShow®, Active Desktop, and Internet Explorer 5.0 and later. The minimum required capability is for filtering 32 multicast addresses (also known as channels).

93. Server network adapter supports Load Balancing and Failover capabilities

Recommended

Server network adapters should support the bundling of multiple physical network links into a single logical link for the purpose of bandwidth aggregation and physical link failure protection. This capability is dependent on the features of the network switching elements and should support commonly implemented network switches and their respective link aggregation and fail-over techniques.

94. Server network adapter supports remote system setup capabilities

Recommended

It is strongly recommended that server network adapters support remote new system setup capabilities as defined in PXE 2.1.

95. Network connections used for remote boot meet PXE requirements

Required

On server systems that support remote new system setup, network connections used for remote boot must comply with remote new system setup capabilities as described in PXE 2.1 or later (for IA-32 systems), or EFI 1.0 (for IA-64 systems). It must be possible to enable and disable the remote boot (remote new system setup) capabilities through administrative control in order to maintain server security.

Note: Multiport network adapters can supply remote system setup capabilities on none, any, or all ports.

96. Network adapter and driver support promiscuous mode

Required

This ensures that the adapter can be used with Microsoft Network Monitor Agent. This requirement applies only to LAN (non-switched) media.

Notice that, by default, promiscuous mode is not turned on. Enabling promiscuous mode should be possible only by using the Microsoft Network Monitor Agent or another similar administrative application.

97. Network adapter and driver support multicast promiscuous mode

Required

By supporting this feature, the adapter and the driver enable performance improvements for special-purpose servers and applications, such as multicast routers. This requirement applies to those networking technologies that support multicast, such as Ethernet, and not to those that do not support multicast, such as Token Ring.

Notice that, by default, multicast promiscuous mode is not turned on.

98. Network adapter and driver support priority for IEEE 802-style networks

Required

Windows Quality of Service (QoS) components provide link layer priority information to NDIS 5.0 miniport drivers in each transmitted packet’s NDIS_PER_PACKET_INFO structure. Priority values are derived by mapping Internet Engineering Task Force (IETF) Integrated Services (intserv) service types to 802.1p priority values (referred to as the "user priority" object in http://search.ietf.org/internet-drafts/draft-ietf-issll-is802-svc-mapping-01.txt, which is likely to be superceded by a later draft or final specification). The intserv service type used for the mapping is determined by QoS-aware applications or on behalf of the application, by QoS-aware operating system components.

802.1p/q-capable Ethernet drivers are expected to use the priority level indicated in the NDIS_PER_PACKET_INFO structure to generate the corresponding field in the 802.1p/q MAC headers of transmitted packets. Similarly, these drivers are expected to extract the appropriate information from the MAC headers of received packets and to copy the priority to the NDIS_PER_PACKET_INFO structure before indicating the packet to higher protocol layers.

Note that any link layer driver may interpret the priority information in the NDIS_PER_PACKET_INFO structure and use it as appropriate for the particular media.

For more information, see "Packet Support for 802.1p Priority" in the Windows 2000 DDK. See also "QoS: Assigning Priority in IEEE 802-style Networks," available at http://www.microsoft.com/devdes/qos802.htm.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Modem Requirements

This section presents general requirements for modems. There are two types of modems to consider.

  • Traditional serial modems

These modems, originally designed for PCs, are connected to the server system by a serial port, or are implemented as a driver that emulates a traditional modem. The fundamental design principle for compatibility with Windows 2000 is for a serial modem to be supported by the Universal Modem Driver (Unimodem), which uses INF files to characterize device operation. Unimodem INF design is described in the Modem Developer’s Kit (MDK), included in the Windows 2000 DDK.

  • Networking modems (Public Switched Telephone Network (PSTN) modem configured as networking devices, ADSL modems, cable modems)

These modems are designed for large servers and connected to the system using networking drivers—for example, NDIS 5.0 miniports. The fundamental design principle for compatibility with Windows 2000 is for a networking modem to be supported by NDIS 5.0, as defined in "Network Drivers" in the Windows 2000 DDK.

Server Types and PSTN Modem Usage. SOHO servers typically have a small number of serial modems, used for Remote Access (in or out), shared ISP access, fax (in or out) and interactive voice response (IVR). The modems used are traditional serial modems. These modems are typically connected by individual PSTN phone lines or by ISDN BRI lines.

In an enterprise, the modem servers may support hundreds of modems, used primarily for inbound remote data access such as for an ISP or corporate network. The modems are typically connected to public networks on high-speed digital lines (T1, ISDN, or PRI). Different servers may be used for dedicated incoming fax reception or IVR. Note that Windows 2000 Unimodem and Telephony Application Program Interface (TAPI) can be used to support hundreds of modems for each server.

Design Issues for Server PSTN Modems. The following are the design issues to consider, based on server types:

  • For modems designed for Basic servers, the most important additional design issues are:
  • Support for V.90, as host side modems where possible, which requires an ISDN BRI or other digital network connection.
  • Do not migrate the modem signaling function, for example, V.90 or V.34, into the system.
  • For SOHO Server modems, the most important design issues are:
  • Adaptive answering features: V.8, V.8bis, V.251.
  • Full duplex voice strongly recommended, using V.253, to support small scale Interactive Voice Response.
  • For Enterprise Server modems, the most important design issues are:
  • The NDIS 5.0 miniport interface is preferred.
  • Fax is optional, not mandatory, because the most common solutions use separate hardware and drivers, on separate public network connections.

99. System includes WAN communications device

Recommended

The following device options, as defined later in this chapter, can meet this requirement:

  • Serial modem with V.34 and V.90 capabilities, supporting server fax capabilities (two or more ports recommended)
  • ISDN adapter (NDIS driver) or ISDN modem (Unimodem driver)
  • ATM adapter (NDIS driver)
  • ADSL adapter (NDIS driver)
  • Cable modem (NDIS driver)

Note: It is recognized that OEMs supply systems to customers in situations where the customer will insert modem devices at the end-user site or where the customer has particular feature demands. Server systems designed for specific customers are exempt from these requirements.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


IrDA Communications Requirements

Infrared capabilities are neither required nor recommended on servers. If they are implemented, they must meet the requirements in this section.

The interface between Infrared Data Association (IrDA) hardware (framers) and the Windows IrDA stack is through NDIS 5.0 miniport drivers, as described "IrDA Miniport NIC Drivers" in the Windows 2000 DDK. The Windows 2000 IrDA stack expects that the hardware and NDIS drivers deal with framing, transparency, and error detection, and also support media sense and speed change commands. Miniport drivers are responsible for discarding incoming frames with bad cyclic redundancy checks. These frames must never be forwarded to the protocol.

140. Infrared network adapter meets network adapter requirements

Required

IrDA network adapters must meet all requirements listed in "Network Adapter Requirements" earlier in this design guide.

141. Infrared device supports both FIR and SIR

Required

All infrared devices must comply with approved IrDA specifications, including support for serial IR (SIR) and fast IR (FIR) data devices.

142. IrDA hardware reports a unique Plug and Play ID sufficient to support unattended driver installation

Required

FIR Plug and Play hardware must report a unique Plug and Play ID that matches the combination of the chipset, transceiver, and any other system-specific parameters, in order for the operating system to find and install the correct INF, and the associated driver for the IrDA hardware.

In the best case, the IrDA hardware has only one Plug and Play ID, associated INF file, and a miniport driver that can auto detect the transceiver type and other system-specific parameters. This enables the installation and configuration of the hardware and the driver without any user intervention.

In other cases, for example, where the driver can not autodetect the transceiver type, or any other system specific parameters, a unique Plug and Play ID for each combination of the chipset and the transceiver type must be reported, and an associated driver and INF file describing the configuration parameters must be provided by the vendor for each combination.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Wireless Networking Requirements

Wireless networking media types enable WAN, LAN and personal area network (PAN) connectivity. This section lists additional requirements for wireless media. Servers are not required to have wireless LAN connectivity.

Note: This design guide does not contain requirements for Bluetooth devices. However, future versions of Windows operating systems will use Bluetooth technology as a wireless external bus, rather than as a wireless networking technology. Therefore, Bluetooth devices are not subject to the requirements contained in this chapter; in particular, they do not require NDIS drivers.

143. Wireless networking media adapters meets network adapter requirements

Required

Wireless network media adapters must meet all requirements for network adapters defined earlier in "Network Adapter Requirements."

144. Wireless networking media adapters support wireless extensions to NDIS

Required

Wireless extensions to NDIS are documented in "Network-Dependent Wireless Objects" in the Windows 2000 DDK. These extensions are based on the work of the Portable Computer and Communications Association, published in PCCA-STD-201.

145. Wireless networking adapters support industry specifications

Required

IEEE 802.11 wireless networking adapters must support the following specifications:

  • 11Mb/s signaling using Direct Sequence Spread Spectrum (DSSS)
  • Wired Equivalent Privacy (WEP) for security.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Storage Device General Requirements

This section presents general requirements for controllers and peripherals.

Note: It is recognized that OEMs supply systems with specific feature requirements to corporations, which can include providing servers that do not include any disks installed before shipping to a particular corporate client.

146. Host controllers and devices support bus mastering

Required

Bus master capabilities must meet the related specification for the particular controller. The host controller must not use the ISA or LPC bus.

Note: This requirement does not apply to legacy FDCs and will not become a requirement for the FDC in the future.

147. System and Option ROMs support Int 13h Extensions on IA-32 BIOS boot system

Required

On IA-32 BIOS boot systems, BIOS and option ROMs must support Int 13h Extensions as defined in "Int 13h Extension APIs" of the Windows 98 DDK. This support is needed during the Windows 2000 boot process on BIOS-based systems.

148. Block rewritable optical ATAPI device complies with SFF 8070i

Required

The SFF 8070i standard defines the requirements for block rewritable ATAPI devices (optical storage devices), including specifications for logical unit number (LUN) implementation, media status notification, and device write protection. This definition includes required support for the Read Format Capacities command.

149. Controller and peripherals support media status notification

Required

The following list shows the required specifications for implementing media status notification, depending on device type.

Device Type | Media Status Notification Implementation
CD or DVD devices | Comply with ANSI NCITS T10 Multi-Media Command Set-2 (MMC-2) standard for Media Status Event Notification.
ATAPI floppy/optical direct access drives | Comply with either MMC-2 standard or SFF 8070i Version 1.1.
IEEE 1394 storage devices | Comply with NCITS Reduced Block Commands standard (RBC; T10/97-260r0) standard.
ATA and non-ATAPI storage devices | Comply with Media Status Notification Support, Version 1.03.
Other ATA/ATAPI devices, including tape drives | If implemented, comply with Media Status Notification Support Specification, Version 1.03, or SFF 8070i.
Other types of SCSI removable devices | If implemented, support based on NCITS Reduced Block Commands standard.

150. Operating system recognizes the boot drive in a multiple-drive system

Required

150.1 IA-32 BIOS boot system uses CIP BIOS Boot 1.01 method to determine boot drive

The implementation of boot-drive determination in multiple-drive systems is defined in Section 5.0 of the CIP BIOS Boot 1.01. This is the format that Windows 2000 uses for determining the boot drive when new bootable devices are introduced for servers.

150.2 EFI IA-64 system complies with EFI 1.0 or later for detection of boot devices, plus Hardware Design Guide requirements

The requirements for management of the EFI boot process are documented in EFI 1.0 or later. In addition, EFI-based systems must meet other EFI requirements in these guidelines.

151. IA-64 system provides GPT-partitioned hard drive for boot

Required

64-bit Windows requires bootable hard drives to be partitioned using the GPT mechanism defined in EFI 1.0. This is also the 64-bit Windows default partitioning scheme for all non-removable storage media. At least one locally-attached hard drive must be available for booting an installed operating system image.

152. IA-64 system with GPT-partitioned bootable hard disks provide one ESP of correct size

Required

64-bit Windows requires bootable hard drives to contain a single EFI System Partition (ESP) of size Max(100MB, min (1% of the physical disk size, 1GB)) as defined in EFI 1.0. This formula is to be read, in words, as "the size of the ESP must be the larger of these two numbers, 100MB or 1% of the physical disk size (up to 1GB)." The physical disk size is measured at the time of disk partitioning.

153. IA-64 system with ESP contains only components needed for system boot, installation, or recovery

Required

The ESP may only be used for components required for system boot, installation, or recovery. Examples of such components include operating system loaders, EFI drivers, firmware utilities, configuration tools, and diagnostics.

154. EFI IA-64 system provides restoration tool for recovery of critical ESP and OEM special partition contents

Required

An EFI system must provide a tool that will permit the user to restore the critical EFI System Partition contents and any OEM special partition contents in the event of a catastrophic failure. This tool does not need to restore any operating system or other non-OEM–supplied ESP contents.

155. For EFI IA-64 system, MSR partition of correct size is present on every physical or virtual hard disk manifested to the operating system when such disks are otherwise being partitioned by the provider of the system

Required

All entities that represent themselves as a hard disk to an EFI system—whether single drives, or collections of drives behind an intelligent controller that represents the assembly as a whole as a single "disk"—must contain an Microsoft Reserved (MSR) partition of correct size.

This guideline applies only to disks shipped with systems being partitioned by the provider of the system, such as disks that contain system utilities or are otherwise preinstalled with software for use by or with Windows. It is not required for disks that are "blank"—in other words, those disks that have no partitions present on them when installed by the manufacturer and that will be configured by the user.

The formula for calculation of the size of an MSR is as follows:

if (disksize < 16 GB) {

MSR = 32 MB;

} else {

MSR = 128 MB;

}

The GUID for such partitions is defined as follows:

DEFINE_GUID(PARTITION_MSFT_RESERVED_GUID, 0xE3C9E316L, 0x0B5C, 0x4DB8, 0x81, 0x7D, 0xF9, 0x2D, 0xF0, 0x02, 0x15, 0xAE);

156. For IA-64 system, non-ESP partitions do not contain software required for boot

Required

No software required for system boot can be stored in an OEM-specific, non-ESP partition. Instead, such software must reside in an ESP or in system firmware.

157. For IA-64 system, ESP resides only on a device that can be reached through firmware-resident EFI drivers

Required

To prevent problems that can occur if a driver needs to reach a disk containing an ESP that is actually contained on that disk (resulting in a non-bootable system), ESPs must be placed only on devices that can be reached using firmware-resident EFI drivers. The system must also comply with "#14.7 "EFI systems provide a minimum, firmware-based driver set sufficient to allow boot, installation, and recovery operations without the presence of loadable media-based EFI drivers."

158. USB-based mass storage device complies with USB specifications

Required

If a USB-based mass-storage device—including tape, UHD floppy drive, and CD drive—is implemented in a server system, it must meet the requirements in this design guide and the requirements defined in Universal Serial Bus Mass Storage Class Specification Overview 1.0 or later.

159. IEEE 1394-based mass storage complies with 1394 OpenHCI 1.1

Required

If an IEEE 1394 storage device is implemented in a server system, it must meet all IEEE 1394 requirements in this design guide and comply with OpenHCI 1.1.

A removable IEEE 1394 mass storage device must not be the primary boot device.

160. Drivers for devices that use SBP-2 command protocols follow Windows 2000 guidelines

Required

Drivers for devices using the SBP-2 protocol must conform to the guidelines in "SBP-2 Support and Windows 2000" at http://www.microsoft.com/hwdev/print/sbp2_w2000.htm.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


SCSI Controllers and Peripherals

SCSI is a flexible I/O bus that is used in the design of a variety of peripherals, including disk drives, CD drives, tape drives, magneto-optical drives, and scanners. This section presents the requirements for SCSI hardware that is compatible with Windows 2000, including adapters, peripherals, and any device that uses a SCSI controller.

161. System includes SCSI host controller and SCSI peripherals
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

The SCSI host adapter is the circuitry that serves as an interface between the system and one or more SCSI peripherals. A host adapter can be a card that plugs into the system’s expansion bus, such as a PCI card, or it can be designed directly into the system board set.

The host controller must support PCI bus mastering, with bus mastering enabled by default.

Recommendation

Recommended: Fibre Channel, especially for servers running Windows 2000 Advanced Server or Datacenter Server.

Note: Servers that implement Fibre Channel as the storage connection are not required to also provide SCSI capabilities.

162. SCSI controllers with external connectors that can function as cluster nodes provide multi-initiator support

Required

Multi-initiator support allows two SCSI controllers—each installed in a separate computer system—to coexist on a shared SCSI bus with a set of shared devices.

For use in a system intended as a node in a cluster using shared SCSI, the SCSI IDs must be changeable from the default SCSI controller ID of 7, and the boot-time SCSI bus reset operation must be able to be disabled on each controller attached to a shared bus.

For any SCSI controller with external connectors that can be used as a node in a cluster, as described previously, the connector must be clearly labeled as available for cluster connections. This labeling must be positioned so that it is clearly visible to a user when attaching external devices to the affected external connector.

163. Bus type is clearly indicated on connectors for all adapters, peripherals, cables, and terminators

Required

Connectors for each Fibre Channel or SCSI adapter, peripheral, cable, and terminator must be clearly labeled to show the bus type. All external SCSI connectors must display the appropriate SCSI icon defined in SCSI-3 Parallel Interface (SPI) specification, Annex F, plus any clarifying abbreviations or acronyms. The following shows the related acronyms and their definitions:

  • Single-ended (SGL or SE). The most commonly used signal type, such as found in home PCs and high-end workstations.
  • Low voltage differential (LVD). A signaling method similar to Differential (DIFF) but with lower signaling voltages supporting higher transfer rates.
  • High voltage differential (HVD). A signaling method similar to DIFF but with higher signaling voltages.
  • Differential (DIFF). A signaling method that employs differential drivers and receivers to improve signal-to-noise rations and increase maximum cable lengths. This method includes both LVD and HVD types.

164. Differential devices support DIFFSENS as defined in SPI-3 standard

Required

Without DIFFSENS, the differential bus drivers or a single-ended device will suffer fatal thermal damage if a single-ended device is put on a differential bus.

The specification for DIFFSENS is defined in Section 5.4.2 of the SPI-3 standard.

165. Automatic termination circuit and SCSI terminators comply with SCSI-3

Required

Parallel SCSI add-on adapters and on-board controllers must use automatic termination that allows a user to add external devices without removing the server case. Terminators used in the SCSI host adapter must be regulated terminators, which are also known as active, SCSI-3 SPI, SCSI-2 alternative-2, or Boulay terminators. SCSI termination built onto internal cables must meet the SCSI-3 specification.

166. Terminator power is supplied to the SCSI bus, with over-current protection

Required

The host adapter must supply terminator power (TERMPWR) to the SCSI bus for system-board implementations using PCI or another expansion bus. All terminators on the external SCSI bus must be powered from the TERMPWR lines in the SCSI bus.

In addition, the circuit that supplies TERMPWR must have overcurrent protection built into it. Devices that provide TERMPWR must also provide some means of limiting the current through use of a self-resetting device. For example, a positive-temperature coefficient device or circuit breaker can be designed into the circuit. These devices open during an over-current condition and close after the condition ends.

167. External connector complies with SCSI-2 or later

Required

If an external connector is implemented, it must meet the requirements defined in SCSI-2 or a later specification.

168. Controller and peripherals implement SCSI data protection signal

Required

All SCSI peripherals and the SCSI host adapter must implement the SCSI bus data protection signal defined in the SPI standard, and data protection must be enabled by default.

169. SCSI connections use keyed and shrouded connectors

Required

For internal and external configurations, the SCSI bus cable must be plugged into shrouded and keyed connectors on the host adapter and devices. This ensures that the cable is properly positioned so the user cannot plug in cables incorrectly. For internal configurations, pin 1 orientation must be designated on one edge of the ribbon cable and also on the keyed connector for the SCSI peripheral device.

For an external configuration, the SCSI connector must not use the same connector type as any other non-SCSI connector on the system.

170. External devices provide SCSI-3-compliant termination

Required

External SCSI devices must provide termination compliant with the SCSI-3 specifications per the requirements in guideline "#165. Automatic termination circuit and SCSI terminators comply with SCSI-3."

171. SCAM support is not present

Required

SCSI Configured AutoMatically (SCAM) capabilities must not be present on server systems or peripherals. SCAM is not supported by the Windows 2000 operating system; enabling SCAM can cause the system to become unstable or inoperable.

172. Hardware supports the STOP/START UNIT command as defined in SBC specification

Required

The hardware in SCSI peripherals must be able to fully recover from a software-initiated spin down without rebooting the system or cycling power. To properly support power management on SCSI drives and to ensure that the operating system responds to appropriate driver calls, be sure to correctly implement the STOP/START UNIT command as defined in the SCSI Block Commands specification.

173. STOP/START UNIT command can be used to decrease power consumption

Recommended

Wherever appropriate, for example, for storage disks, the STOP UNIT command can be used to decrease power consumption of the base platform.

174. SCSI devices that support hot-plugging comply with Annex D of SPI-3

Required

Annex D of SPI-3 addresses SCSI device insertion and removal, with and without command activity.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


ATA Controllers and Peripherals

This section presents requirements for ATA hardware that is compatible with Windows 2000, including adapters, peripherals, and any device that uses an ATA controller.

175. System does not use ATA host controller or peripherals
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

ATA disks should not be present in a server. If ATA is implemented in a system, the ATA host controller and peripherals must meet all related requirements for devices and drivers, and they must meet the requirements defined in this section.

ATA devices may not be used as the primary storage channel on a server running Windows 2000 Advanced Server or Datacenter Server. For these operating systems, the server can use an ATA device only as a boot or installation device. An exemption is allowed for Basic and SOHO class servers that are not designed for deployment with MSCS clustering.

176. Dual ATA adapters use single FIFO with asynchronous access or dual FIFOs and channels

Required

PCI dual ATA adapters must be designed so that either channel can be used at any time; the operating system must not have to serialize access between the primary and secondary channel. Therefore, either the two channels are totally independent or a hardware arbitrator protects anything shared, such as a programmed I/O (PIO) read pre-fetch buffer.

A design implementing a single first in/first out (FIFO) with a hardware solution to synchronize access to both channels meets this requirement if the design does not require that a request on one channel be completed before another can be started. A software-based solution is not acceptable.

ATA-based systems must be tested with ATA DMA enabled; the system must not have an embedded single-FIFO dual-channel ATA controller.

EFI Note

Section 5.0 of the CIP BIOS Boot 1.01 defines the implementation for dual asynchronous channels. Note that this particular issue is also relevant for EFI systems, and designers of these systems will also use this specification for clarification of this particular implementation issue even though the rest of this specification is superseded by EFI.

Dual-channel controllers that require special software to serialize channel I/O for a single prefetch FIFO do not meet these requirements. Such designs require serial access to one of four devices, defeating the primary advantage of asynchronous dual-channel controllers. Furthermore, such devices are non-standard and require custom driver support.

177. ATA controller and peripherals comply with ATA/ATAPI-5 standard commands for features implemented and support Ultra-DMA (ATA/33, minimum)

Required

All controllers and ATA peripherals must support Ultra DMA (also known as Ultra-ATA) at transfer rates up to 33 MB per second as defined in ATA/ATAPI-5. In addition to improved transfer rates, Ultra DMA also provides error checking for improved robustness over previous ATA implementations. PCI chipsets must implement DMA as defined in SFF 8038i.

ATA drives must comply with ATA-5, which defines the programming register set for PCI ATA bus master DMA, to ensure fully featured hardware and Windows-compatible device driver support.

Support for ATA Bus Master DMA:

  • Required for ATA controllers
  • Required for ATA devices and ATAPI peripherals, including CD and DVD devices
  • Recommended for ATA/ATAPI tape drives
  • Recommended for ATAPI removable media drives

Recommendation

Recommended support includes:

  • For all systems: Controller and peripherals support Ultra-DMA/66.
  • For IA-32 BIOS boot systems: The system BIOS should configure the drive and host controller, optimized for Ultra DMA operation if possible, though the PIO mode must continue to work. The ACPI software should also support the restoration of these settings in ACPI control methods _GTM, _STM, and _GTF. There are no standard registers for these ACPI control methods if the controller loses timing context across a suspend and resume cycle. The BIOS pre-operating system boot disk services, INT13h read and write, need not actually use Ultra DMA for access to the drive prior to operating system boot. Definitions for these ACPI control methods can be found in Section 10 of ACPI 1.0b.
  • For EFI systems: The system firmware should configure the drive and host controller, optimized for Ultra DMA operation if possible, though the PIO mode must continue to work. The ACPI software should also support the restoration of these settings in ACPI control methods _GTM, _STM, and _GTF. There are no standard registers for these ACPI control methods if the controller loses timing context across a suspend and resume cycle. These ACPI control methods are defined in Section 10.8 of ACPI 2.0.

See also the BIOS recommendations in guideline "#12. System firmware meets general boot support requirements."

178. ATA controller and peripheral connections include Pin 1 cable designation with keyed and shrouded connectors

Required

Pin 1 orientation must be designated by one edge of the ribbon cable and also on the keyed connector of the ATA or ATAPI controller and peripheral device. Designation of the keyed connector must be clearly indicated on or near the connector.

179. ATAPI peripherals comply with ATA/ATAPI-5 standard commands for features implemented

Required

The ATA/ATAPI-5 standard defines the fundamental hardware and software design guidelines for ATAPI devices. See also guideline "# 147. System and Option ROMs support Int 13h Extensions on IA-32 BIOS boot systems."

180. ATAPI devices support DEVICE RESET command

Required

ATAPI devices must respond to the DEVICE RESET command regardless of their internal state, as defined in the ATA/ATAPI-5 standard. The controller can be reset by going into a power-on state (requests cleared, signature present), but any non-default mode values must be left in their current state with the DRV bit unchanged.

Devices that do not implement the PACKET command feature set, such as hard disk drives, must not implement the DEVICE RESET command.

181. ATA/ATAPI device supports ATA STANDBY command

Required

The ATA drive must implement the ATA STANDBY command according to the ATA standard. This command is defined in ATA/ATAPI-5.

The hard disk drive should spin up and be able to complete a Read operation within 10 seconds of applying power or leaving ATA STANDBY mode and transitioning to ATA ACTIVE, as specified in the Storage Device Class Power Management Reference Specification, Version 1.0 or later.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Fibre Channel Controllers and Peripherals

This section presents requirements for Windows 2000–compatible adapters, peripherals, and any devices that use Fibre Channel technology.

182. System includes Fibre Channel controller and peripherals
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Recommended | Recommended
Enterprise: | Recommended | Recommended | Recommended
SOHO: | Optional | Optional | Optional

Fibre Channel is a technology for 1 gigabit per second or greater data transfer that maps common transport protocols such as SCSI and IP, merging networking and high-speed I/O in a single connectivity technology. It is an open standard, defined by ANSI and Open System Interface (OSI) standards, that operates over copper and fiber-optic cabling at distances of up to 10 km.

If implemented on a server system, Fibre Channel must use the X3T11 Private Loop Direct Attach (PLDA) profile as the storage base to use the native Windows 2000 support. The Physical Layers implementation must comply with Fibre Channel Physical (FC-PH), Revision 4.3 or later. For more information from the Fibre Channel Association, see http://www.fibrechannel.com.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Erasable Disk Drives

This section presents the requirements for erasable disk drives provided with a server system or designed for use with Windows 2000 Server. This category includes 3.5-inch, 5.25-inch, and 12-inch magneto-optical or phase-change drives and media. It does not include CD, CD-R, CD-RW, and DVD drives or media.

183. SCSI erasable drives support SCSI commands

Required

The following commands or features must be supported by the device’s driver:

  • Erase (2C): full side and selected block erase
  • Format requirements reported with Format command
  • Mode Select: write cache disable
  • Mode Sense: total spare blocks available, write protect status
  • Prevent/Allow Medium Removal, Start/Stop Unit
  • Read (28), Verify (2F)
  • Reassign Blocks, Read Defect Data
  • Reserve, Release
  • Seek (SCSI CDB Opcode – 2B)
  • Test Unit Ready, Request Sense, Read Capacity, Inquiry
  • Write (2A), Write and Verify (2E)
  • Write without pre-erase, for erasable optical only

Recommendation

Recommended: Inquiry with support for reporting serial number or other unique unit ID should be supported by the device’s driver.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


CD and DVD Drives

This section presents the requirements for CD and DVD drives.

184. System includes CD or DVD drive or other method for installing the operating system

Required

The server system must include either CD or DVD drive support or another method to enable the installation (or reinstallation) of the operating system.

CD Drive Requirements

This section summarizes requirements for CD drives. A CD drive is not required if another method is provided to support operating system installation. However, if a CD drive is present, it must comply with these requirements.

185. CD drive provides 8x or higher performance

Required

This requirement is intended to set the minimum speed needed for production-level CD reading on Windows platforms. This requirement applies to the minimum read speed (8x) on any production level CD media, such as application software, at any location on the disc. This requirement does not apply to end-user recorded CD data discs, or discs being read in error-correcting, defect management mode.

186. CD drive is CD-Enhanced compatible

Required

The CD drive must be able to mount multisession CD-ROM discs, even if track 1 is Red Book audio.

CD-Enhanced support must comply with Blue Book standards, as defined in the MMC-2 standard.

Recommendation

Recommended: Use of the Sony ReadTOC method for SCSI-2 multisession support, as noted in the MMC-2 standard.

187. CD drive supports specified logical and physical CD formats

Required

At a minimum, the CD device must be compatible with the following formats to ensure cross-media compatibility, based on compliance with the Optical Storage Technology Association (OSTA) MultiRead Specification for CD-ROM, CD-R, CD-R/RW, and DVD-ROM Devices, Version 1.11:

  • Logical formats: CD Red Book (CD-Audio), Yellow Book (CD-ROM), Orange Book parts II and III (packet writing if recordable), White Book, Blue Book, and Universal Disk Format Specification, Version 1.5 and 2.0
  • Physical formats: ROM (stamped), and Orange Book part II (CD-R) and part II (CD-RW)

Note: Any ATAPI CD drive designed to play back CD-I content must return a minimum of two track entries for the READ-TOC (0x43) command. These two track entries must be a track 01 entry and a track 0xAA entry for the lead-out address. Drives that do not comply with this minimum requirement cannot play back CD-I movies.

188. ATA/ATAPI CD drive complies with MMC-2

Required

CD drives attached to the system using the ATA interface must support MMC-2.

189. CD drive supports multisession and compatibility forms of the READ_TOC command

Required

Both multisession forms (01b and 10b), as well as the compatibility form (00b) of the READ_TOC command, must be implemented. This requirement ensures complete support for CD multisession capabilities.

190. ATA/ATAPI CD changer meets MMC-2 standard

Required

If an ATAPI-compatible CD changer is present that has a capacity for seven or fewer discs, the device must comply with MMC-2 standard.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Backup Devices

Backup devices are an important part of guaranteeing data availability at a corporate site. Windows 2000 Server includes a graphical tool named Backup that supports backup of Windows 2000 Server-based data.

If a backup device is provided in a server system, it must comply with the requirements and recommendations in this section.

195. System includes device for local backup

Recommended

System administrators will commonly want offline backup capabilities to be available. If a backup device is provided with a server system, either as a built-in or peripheral add-on device, it must meet the minimum requirements defined in this section.

196. Single-backup device meets minimum capacity requirements
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | 10 GB Required | 10 GB Required | 10 GB Required
Enterprise: | 20 GB Required | 20 GB Required | 20 GB Required
SOHO: | 10 GB Required | 10 GB Required | 10 GB Required

Minimum uncompressed, formatted storage capacity is required for any backup device designed to comply with these guidelines.

Recommendation

Recommended: 20 GB minimum capacity for Basic and SOHO servers.

197. Backup device meets industry standards

Required

A SCSI tape or SCSI backup peripheral must comply with the appropriate SCSI command set and with the requirements defined in "SCSI Controllers and Peripherals" earlier in this chapter.

ATA is not recommended for servers, but if an ATA backup peripheral is implemented, it must comply with the appropriate ATA/ATAPI 5 standard sections covering that device’s operation.

198. Driver integrated with Removable Storage Manager

Required

For a backup device designed for Windows 2000 Server, the manufacturer must provide a Windows 2000 driver that integrates with Removable Storage Manager (RSM), formerly Windows NT Media Services. This ensures that applications which are RSM-aware (such as the native Windows 2000 backup and hierarchical storage management applications) will be properly able to utilize the backup device.

RSM is intended to allow software that accesses backup devices to be independent of the specific device. A hardware vendor can also choose to include a backup application. However, such software should also be integrated with and use the RSM infrastructure.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Media Changers

This section defines requirements for media changers.

CD Changers

This section provides requirements for CD changers.

There is no requirement or recommendation for providing a CD changer with a server system, but if present or designed to be compatible with Windows 2000, it must comply with these requirements.

199. If present, CD changer for seven or fewer discs meets MMC-2 standard

Required

If an ATAPI-compatible CD changer is present that has a capacity for seven or fewer discs, the device must comply with MMC-2 standard.

Tape and Optical Disk Changers

This section provides requirements for tape and optical disk changers. There is no requirement or recommendation for providing a tape or optical disk changer, but if a device is present or is designed to be compatible with Windows 2000, it must meet the requirements defined in this section.

This includes changers that support the following drive/media types:

  • 3.5-inch, 5.25-inch, and 12-inch magneto-optical or phase-change drives and media
  • All magnetic tape drives and media

It does not include changers that support CD-ROM, CD-R, CD-RW, or DVD drive/media types.

200. SCSI changer and drive support auto-configuration

Required

To meet requirements for auto-configuration of changers and their associated drives, the following changer requirements and configuration restrictions are defined:

  • For changers where autoconfiguration under RSM control is a targeted feature, all changer tape or optical disk drives must be connected to the same SCSI bus as the changer.

Changer systems that are not configured this way will not be autoconfigurable under RSM in Windows 2000 and must provide documentation that describes the appropriate manual configuration process for use with RSM. Examples of proper documentation are available in Appendix A of Windows NT Removable Storage Manager Programming Documentation, at http://www.highground.com/developer/documents/ntmsdocu.htm.

The Removable Storage Manager functions are documented in the Microsoft Platform SDK at http://msdn.microsoft.com/library/psdk/zaw/ntms_api_5nz9.htm.

  • The changer’s Read Element Status–Data Transfer Element Descriptor must support the reporting of the SCSI Bus Address and LUN of each drive in the library unit.
  • If drive cleaning is required and can be automated, a specific slot that is accessible by way of a Move Medium command must be designated in the Operator’s Guide.
  • The changer must be able to report if a bar-code reader is installed in the unit.
  • The changer must be able to report on the current of (magazine) slots and drives by using the Read Element Status command.

Recommendation

Recommended for changers: SCSI changers should avoid behaviors as a side effect of SCSI bus reset which unduly delay operations of the changer and availability of media via the changer. An example would be a lengthy auto-inventory process which delays media loading.

201. SCSI tape and optical disk changers support SCSI commands

Required

The following commands or features must be supported by the changer:

  • Initialize Element Status (with/without bar-code reading)
  • Mode Sense—Pages 1D, 1E, 1F
  • Move Medium
  • Prevent/Allow Media Removal (door access and IEPORT locking)
  • Read Element Status
  • Reserve, Release
  • Send Volume Tag, Request Volume Element Address
  • Test Unit Ready, Request Sense, Inquiry

Recommendation

Recommended: Inquiry with support for reporting serial number or other unique unit ID should be supported by the changer.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Hardware Security Requirements

This section summarizes the system hardware security requirements and recommendations.

208. C2 evaluation for hardware

Recommended

C2-evaluated hardware meets requirements defined in the Orange Book.

For hardware designed for customers outside the U.S., equivalent evaluation might be defined in local standards, such as F-C2/E3 ratings in Europe.

209. Peripherals follow hardware security recommendations

Recommended

OEM-specific solutions can be implemented to meet these recommendations. The following hardware security features are recommended:

  • External drive devices should have locking capabilities. Each removable media device on a server system should be capable of being locked to prevent unauthorized access to data. A single locked door covering the drives is sufficient. The locking mechanism must render the device useless, whether locking is done electronically or mechanically.
  • Computer case and switches should have locking capabilities to prevent unauthorized internal access. An OEM-specific method can be implemented, either electronically or mechanically.
  • Remote software management should be supported for physical components.
  • Controls and remote alerts should be provided for chassis-open intrusion.

For servers running either Windows 2000 Server or Windows 2000 Advanced Server or Datacenter Server, smart card readers and cards should be provided. If provided with a server system, smart card devices must be compatible with Interoperability Specification for ICCs and Personal Computer Systems, available at http://www.pcscworkgroup.com/.

In addition, smart card readers and device drivers must be Plug and Play-compliant and must be implemented as described in "Smart Card Drivers" in the Windows 2000 DDK. Smart card applications and service-provider dynamic link libraries (DLLs) must adhere to the Microsoft Smart Card SDK that is part of the Microsoft Platform SDK.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Backup and Reliability Requirements

This section summarizes the backup and reliability requirements and recommendations for servers.

Backup Hardware

This section defines the requirements for backup hardware for servers.

210. System includes integrated backup solution

Recommended

An integrated tape drive or other device should be included in the system. Although the recommended method to back up files on a server is to use a backup service under Windows 2000 Server, system administrators will commonly want offline backup capabilities to be available.

For information about hardware requirements related to backup capabilities, such as tape drives and so on, see Chapter 5, "Storage Device Requirements."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


High Availability Requirements

This section summarizes the requirements for high availability.

Through ACPI and OnNow power management capabilities, Windows 2000 allows more control of dynamic configuration changes and power state changes. These features help implementers in handling event-based issues such as lights that are keyed to system failures, pending failures, or system power states.

223. System includes alert indicators for occurrence of failure
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

Alert indicators should be provided that indicate hard failure. In addition to visual alerting mechanisms, a design can also provide software alerts such as paging, fax, or e-mail notifications.

The following are required sources of alert indicators for hard failures for systems running Windows 2000 Advanced Server and Datacenter Server. These indicators are recommended for servers running other server versions of Windows 2000.

  • Cooling fan malfunction, including system fans and power supply fans
  • System and processor over-temperature
  • Power supply over-temperature (if implemented)
  • Disk drive error
  • N+1 power module (if implemented) failure

Recommendation

Recommended: These sources of alert indicators for hard failures are recommended for all servers:

  • Chassis cover open (intrusion)
  • NMI, processor internal error, and time-out of watchdog timer
  • Processor power failure

224. Hot-swappable drive includes a local disk drive replacement indicator

Required

A hot-swappable drive must have a local indicator that shows which drive or drives are ready for replacement, facilitating the servicing process and improving reliability by reducing possible errors.

This indicator should be on the drive chassis, not on the screen. The Device Bay "eject" signal can be used to activate a replacement indicator. Designers can choose to use existing LEDs for dual purposes to fulfill this requirement, but the LED display should clearly show when a drive is ready for removal, as opposed to other information the display would normally provide.

For systems with multiple drives, an individual replacement indicator should be physically associated with each hot-swappable drive slot.

225. System includes alert indicators for imminence of failure
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

Alert indicators that indicate informative failure are required for servers running Advanced Server or Datacenter Server and should be provided for all servers. The hard failure and informative failure indicators cannot be on simultaneously. In addition to visual alerting mechanisms, a design can also provide software alerts such as paging, fax, or e-mail notifications.

The following are required sources of alert indicators for imminent failures for systems running Windows 2000 Advanced Server and Datacenter Server. These are recommended for servers running other server versions of Windows 2000:

  • Abnormal temperature of processor or inside chassis
  • AC power line failure (operated by UPS if present)
226. IA-64 system supports monitoring for power and down conditions

Required

The following monitoring capabilities are required for the hardware, SAL and firmware on IA-64 systems.

  • Platform supports platform-down monitoring. Platform-down detection is a hardware mechanism in the platform that supports the detection of system software or processor hangs. A hardware watchdog timer is one way to implement this capability. For example, a common hardware watchdog implementation would allow system software to periodically access the timer in order to keep it from expiring. Upon expiration, the timer would typically provide a selectable set of actions, such as system power down, hard reset, power cycle, priority interrupt, and so on.
  • Platform supports power supply fault monitoring. The platform must monitor the status of the primary power source. This includes redundant (for example, distributed) power supplies.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Manageability Baseline Requirements

This section presents server requirements related to the Wired for Management (WfM) initiative and the Zero Administration initiative for Windows. The WfM initiative seeks to raise the level of management capabilities on mobile, desktop, and server platforms. The Zero Administration initiative seeks to ensure a controlled, highly manageable enterprise.

The baseline for these requirements is WHIIG 1.0, which also defines the Windows 2000-specific requirements of the WfM 2.0 specification for hardware instrumentation.

Collectively, the items in this section represent the "Manageability Baseline" requirements.

Tips for implementing management capabilities. For manufacturers who want to implement management capabilities for server systems and components, these are the design steps to pursue:

  • Implement the recommended component instrumentation features defined for servers in WHIIG.
  • For those components that require WMI, ensure that WMI is enabled in device minidrivers as defined in "Supporting WMI" in the Windows 2000 DDK.
  • Refer to WHIIG for other driver requirements and design tips.
  • For all instrumented components, test against the baseline features required in WHIIG.
  • For each component, extend the WBEM and CIM schemas to expose the device’s custom features in any CIM-ready management browser.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Unimodem-supported Modem Requirements

The following requirements apply to modems connected as logically serial modems, using Unimodem as the TAPI service provider.

100. Modem controller meets minimum requirements

Required

The following are minimum requirements for the modem controller, in addition to supporting V.250:

  • Unimodem Diagnostics command, AT#UD
  • Software-upgradeable modem controller (upgradable ROM or Windows modem)
  • AT command buffer of at least 60 characters
  • Semicolon (;) character dial string modifier, unless prohibited by national regulations

101. PSTN modem supports ITU-T V.250 command set

Required

ITU V.250 (formerly V.25 ter) is a superset of TIA-602. TIA-602 codifies the most common data modem commands and responses.

If the AT command for a particular function is implemented, the corresponding V250 AT command must be supported.

The essential V.250 commands are the following:

  • All basic modem commands from TIA-602 (no + prefix)
  • Identification: +GMI, +GMM, +GMR, +GCI
  • Port control: +IPR, +IFC, +ILRR
  • Modulation: +MS, +MR
  • Error control: +ES, +ER
  • Data compression: +DS, +DR

102. Device complies with device class power management

Required

The Communications Device Class Power Management Reference Specification, Version 1.0 or later, provides definitions for the OnNow device power states (D0–D3) for modems. The specification also covers the device functionality expected in each power state and the possible wake-up event definitions for the class. Power states D0 and D3 cold, including wake-on-ring support, are required for modems on power managed buses, including PCI and USB. Modem adapters that use the PCI bus must be capable of generating a power management event (PME# assertion) from the D3 cold device state.

Recommendation

Recommended: Modem adapters should also support capture of Caller ID with hardware support for the AT+VRID "resend caller ID" voice modem command.

103. Device supports wake-up events

Required

A modem must be able to cause a wake-up event on an incoming ring as defined in Communications Device Class Power Management Reference Specification. This applies for modems on all power-managed buses, including PCI and USB. PCI devices are required to support D3 cold on a PCI 2.2-based system with auxiliary power. On all other power-managed buses (such as USB), support for either D2 or D3 is acceptable.

104. Data modem supports v.90 and v.34 modulation and other requirements

Required

The requirements for a data modem include the following:

  • V.90 modulation
  • V.34 modulation
  • V.42 LAPM error control
  • V.42bis data compression
  • V.80 synchronous data access protocol

105. Data modem supports digital connection to support host-side V.90 operation
 | Windows2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Required | Required | Required
SOHO: | Recommended | Required | Recommended

V.90 depends on a digital connection for the host-side modem to the public telephone network, typically using T1 or ISDN. Server modems should be designed for digital connection, to support host side V.90, where digital connections are available.

106. Fax modem supports 14.4 Kbps (V.17) with Class 1 (T.31) command set

Required for PSTN connected modems, Recommended for ISDN connected modems

If fax modem capabilities are implemented, the fax modem must support 14.4 Kbps (V.17) with the Class 1 (ITU T.31) command set.

If fax modems include fax/data media detection (for example, T.32 +FAA command), the INF must include the necessary registry keys, as defined in the MDK in the Windows 2000 DDK.

Recommendation

The following are recommended:

  • Class 1.0 (ITU T.31) +FAR support, which allows the hardware to perform adaptive carrier detection
  • Class 2.0 (ITU T.32 or TIA-592) for server modems, which offloads the T.30 session protocol to the modem

107. Modem supports call control signaling, controlled using V.251 modem commands

Required

Modems must support the ITU V.251 standard for PC-controlled call control, including:

  • Support Data Communications Equipment (DCE) controlled V.8 operation with DTE notification
  • Support DTE-controlled V.8 operation (<a8a> values of 2, 3 and 4)
  • Support DTE-controlled V.8bis operation
  • Support backward compatibility for media detection with terminals using V.25 signaling, for example, data calling tone and fax calling tone
  • Support backward compatibility for media detection with older modems, for example, V.32 and V.32 bis
  • Provide a means for turning on the V.8 Calling Indicator (CI) signal for originating calls

108. Modem supports blacklisted and delayed number clearing

Required where applicable

During certain international Post, Telephone, and Telegraph (PTT) certification processes, modems must support the blacklisted and delayed numbers feature. That means that when the modem fails to connect to a specific number for a certain number of times, the dialed number is stored in an internal list. Any subsequent automated dialing operation to this number is then either delayed for a time (delayed) or forbidden until some form of manual intervention occurs (blacklisted). The international certification processes specify that manual intervention using an external device is required in order to clear these numbers.

Recommendation

Recommended: The modem should clear its blacklisted and delayed number tables if the associated handset goes off hook.

109. Voice modem support is provided
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Optional | Optional | Optional
Enterprise: | Optional | Optional | Optional
SOHO: | Recommended | Recommended | Recommended

Voice capability is recommended for SOHO server modems to support Interactive Voice Response and 3-way DATA/FAX/Voice call classification on the same phone lines. This support, if implemented, must meet the requirements documented in guideline "#110. Voice modem supports ITU V.253 (AT+V)."

110. Voice modem supports ITU V.253 (AT+V)

Required for PSTN connected modems; Recommended for ISDN or T1 connected modems

Voice capability is not mandatory, but if support for voice modem is implemented in a server system, it must meet the following requirements:

  • V.253 compliance
  • Voice recording and playback (+VTX, +VRX, +VTR)
  • DTMF generation and detection during voice I/O
  • Voice I/O support of 8-bit, 8-kHz pulse coded modulation (PCM) formats: unsigned linear, G.711 (A-law and u-law)
  • Programmable gain control for all audio channels
  • Caller ID Detection and Reporting (+VCID)

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


ATM Adapter Requirements

This section summarizes requirements for ATM hardware.

The NDIS 5.0 extensions provide kernel-mode NDIS 5.0 client drivers with direct access to connection-oriented media such as ATM. The architecture for Windows 2000 extends native ATM support to Winsock 2.0, TAPI, and applications based on Microsoft DirectShow® by providing system-level components that map the applicable Winsock, TAPI, and DirectShow APIs to NDIS 5.0, extending direct ATM access to user-mode applications.

ATM is not required for any of the server classes. If an ATM adapter is designed for operation under Windows 2000 in the server system, it must meet the requirements defined in this section. For more details about the following requirements, see "ATM Layer Specification" in ATM User-Network Interface Specification, Version 3.1. This specification also includes references to other relevant specifications.

111. ATM adapter meets network adapter requirements

Required

ATM adapters must meet all requirements listed in "Network Adapter Requirements" earlier in this guide.

112. ATM adapter supports a minimum number of simultaneous connections

Required

The Virtual Path Identifier (VPI) and Virtual Channel Identifier (VCI) ranges supported by the adapter affect the maximum number of simultaneous connections supported on a system.

This affects the applicability of the adapter to ATM applications such as LAN Emulation, where at least one dedicated virtual channel is created between each pair of communicating ATM hosts.

System type | Simultaneous connections
Client (ATM adapter) | 64 or more
Client (Integrated ATM/ADSL-adapter) | 16 or more
Server | 2048 or more

A sample driver is provided in the Windows 2000 DDK to guide developers in properly supporting resources to meet this requirement.

113. ATM adapter supports all service types defined by the ATM Forum
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

The ATM adapter should support the constant bit rate (CBR), variable bit rate (VBR), available bit rate (ABR), and unspecified bit rate (UBR) service types as defined by the ATM Forum.

114. ATM adapter supports UBR service type

Required

UBR is used by default for standard ATM services such as LAN Emulation and IP over ATM. In addition, Point-to-Point Protocol (PPP) is a widely used model for residential network access and UBR is used by default for PPP over ATM virtual circuits. Therefore, it is required that ATM adapters support the UBR service type.

115. ATM adapter supports a minimum number of simultaneously active VBR or CBR connections

Required

Support for at least two simultaneously active VBR or CBR connections is required for basic ATM signaling and management.

Support for additional VBR/CBR connections is needed for ATM adapters that support multimedia or other traffic that demands QoS. These are listed in the following table.

System type | Simultaneous active VBR/CBR connections
Client | 6
Server | 500

116. ATM adapter supports traffic shaping

Required

The ATM adapter must support and enforce all the traffic-shaping rules specified for each service type it supports, including CBR, VBR, ABR, and UBR.

Note: This includes enforcement of peak cell rate on UBR virtual circuits.

117. ATM adapter enforces PCR on UBR virtual circuits

Required

ATM adapters will be used to connect router, remote access, and content servers to the public ATM network. High-speed residential broadband access networks such as ADSL and cable modem will use an ATM virtual circuit from home or small office computers to connect directly to these servers. When the Windows Dial-Up Networking UI is used to connect from a home or small business computer to a remote router or server, a PPP link is established over an ATM virtual circuit.

The service type used on this PPP-over-ATM virtual circuit is UBR. When creating the UBR virtual circuit, Windows requests upstream and downstream line rates, or Peak Cell Rates (PCR), equal to the upstream and downstream line rates provisioned for the user. Windows uses the ATM Interim Local Management Interface (ILMI) protocol to obtain information, such as getting the user’s provisioned line rates from the public network.

To avoid packet loss and ensure efficient network utilization, it is critical that all ATM, integrated ATM/ADSL adapters, and ATM/cable modem adapters enforce requested PCR on UBR virtual circuits.

Because any ATM adapter might be installed in a server to which clients connect through the public network, this requirement applies to all ATM adapters.

118. ATM adapter and driver support dynamic link speed configuration

Required

When connected to a residential broadband network, ATM adapters must restrict the aggregate transmission rate across all active virtual circuits so that it does not exceed the provisioned upstream bandwidth of the residential broadband network.

All integrated ATM/ADSL and ATM/cable modem adapters must support aggregate shaping of upstream bandwidth according to the provisioned upstream bandwidth or the trained bandwidth, whichever is lower. Some implementations can support rate adaptation, and lower-than-provisioned rates may be negotiated due to poor line conditions. All 25-Mbps ATM adapters must support this as well, because any 25-Mbps ATM adapter could be used to connect by way of an external ADSL modem to an ADSL network. This support is optional for ATM adapters with line rates higher than 25 Mbps.

The Windows ATM Call Manager uses ILMI to query the public network to discover the provisioned maximum line rates for incoming and outgoing traffic. The Call Manager then uses the OID_GEN_CO_LINK_SPEED NDIS request (in SET mode) to set the line rate for both incoming and outgoing traffic. The adapter must shape the aggregate of ATM traffic within these incoming and outgoing rates.

119. ATM adapter supports OAM

Required

Operation and maintenance (OAM) is needed for diagnostics. This capability is required for a server system. At minimum, the ATM adapter must respond to received F4 and F5 loopback OAM cells. Support for other layers, F1–F3 is optional.

120. ATM adapter supports buffer chaining (Tx + Rx)

Required

This feature is needed for large packets. This capability is required for server systems, but is recommended for client systems.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


ADSL Device Requirements

This section summarizes requirements for ADSL hardware.

Support is provided in the Windows 2000 Server operating system for ADSL adapters and external ADSL modems, such as those using USB, which provide a faster method for moving data over regular phone lines. ADSL adapters are not required for any server type, but if an adapter is included in a server, it must meet the requirements in this section. ADSL is not required in a server system, but if present, it must comply with these requirements.

Please review the white paper, An Interoperable End-to-End Broadband Service Architecture over ADSL Systems, Version 3.0, which discusses end-to-end service interoperability over ADSL. This paper, which is available from the web site at http://www.microsoft.com/hwdev/publicnet/, was jointly developed by over 30 leading ADSL vendors. The core idea of this white paper (PPP-over-ATM over ADSL) has been adopted by the ADSL Forum.

121. ADSL device is implemented as an integrated ADSL modem

Recommended

System designers should integrate the ADSL modem and higher-layer transmission and media access functions on a single network device. A typical implementation integrates an ADSL modem and ATM interface on a single PCI network adapter. Another example is a device that connects to the server using the USB or IEEE 1394 bus.

If external ADSL modems are provided (other than IEEE 1394 or USB), they should have an ATM interface for the ADSL modem to server connection. In addition, an Ethernet interface can also be included.

122. Integrated ADSL modem meets network adapter requirements

Required

Integrated ADSL modems must meet all requirements listed in "Network Adapter Requirements" earlier in this guide.

An integrated ADSL modem exposing an Ethernet interface must also meet the requirements in guideline "#92. Network adapter supports filtering for at least 32 multicast addresses."

123. ATM/ADSL solution is implemented for integrated ADSL modems

Recommended

An integrated ADSL modem should expose ATM to the operating system. For ATM-specific requirements when an ATM/ADSL solution is implemented, see the requirements in "ATM Adapter Requirements" earlier in this chapter. This should comply with the PPP over ATM architecture discussed earlier.

Note: ATM/ADSL is a requirement for Universal ADSL implementations. Currently there are both ATM/ADSL-based and Ethernet/ADSL-based implementations to provide full rate ADSL services in the market. For compatibility with the Universal ADSL-based services that will be rolled out within the next couple of years, PPP/ATM/ADSL is the required implementation.

124. ADSL modem supports DMT line encoding

Recommended

The ADSL modem must support discrete multi-tone (DMT) line encoding, which is recognized as the industry standard for ADSL by American National Standards Institute (ANSI) as the T1.413 Issue 2 specification and also by the Universal ADSL Working Group.

Note: DMT is a requirement for Universal ADSL implementations. The Universal ADSL Working Group has adopted DMT specified by T1.413, with modifications being made to work in a splitterless environment.

125. ADSL modem supports rate adaptation

Recommended

On a rate adaptive digital subscriber line (RA-ADSL), the downstream and upstream data rates are independently set either by an automatic adaptive algorithm or by manual selection.

RA-ADSL provides the capability to optimize the transmission speed and per.formance over a wide range of telephone-line loop distances. Adaptive channel equalization ensures more robust performance in the presence of channel impairments and narrow-band interference.

This also helps telephone companies to provision RA-ADSL access on their existing networks. RA-ADSL products can be provisioned on many telephone lines without costly and time-consuming network upgrades.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Cable Modem Requirements

Cable modems are not required on servers. If they are implemented, they must meet the requirements in this section.

Cable modem provides two-way services: Data flows downstream from the cable operator’s head end and upstream from the customer’s PC. At the head end, the cable data system is terminated by the cable modem termination system (CMTS), which terminates the upstream and downstream radio frequency (RF), MAC layer, and possibly Layer 3 protocols from the cable side. CMTS provides the internetwork connection between the cable system and the rest of the network at the head end. CMTS can be implemented on a proprietary hardware platform or a PC platform running Windows 2000 to provide different networking functions such as routing, QoS support, such as Resource Reservation Setup Protocol (RSVP), and so on.

Some implementations transmit upstream using narrow-band networks such as ISDN or analog modem, but as cable companies upgrade their networks, an increasing number of RF return modems, for example, two-way modems, are being deployed. Two-way modems are preferred, because they are always connected, perform better, and do not tie up phone lines or require modem banks.

The three current cable modem specifications are:

  • DOCSIS, developed by the Multimedia Cable Network System (MCNS) consortium.
  • IEEE 802.14, developed by IEEE.
  • Digital Video Broadcasting/Digital Audio-Visual Council (DVB/DAVIC), developed by DAVIC and DVB and adopted by European Telecommunication Standards Institute (ETSI) and International Telecommunication Union (ITU).

Industry support for DOCSIS is growing rapidly in North America. In present form, its upper layers fully describe IP traffic encapsulated by 802.3/DIX Ethernet framing. ATM is left for future study.

External Ethernet DOCSIS cable modems provide IEEE 802.1d bridging for one or more Customer Premises Equipment (CPE); a system attaches to the cable modem indirectly through its 10Base-T network adapter. Integrated cable modems attach directly to the system over buses such as USB, PCI, and IEEE 1394, and require a vendor-supplied NDIS 5.0 miniport driver. This driver exposes an 802.3/DIX Ethernet adapter interface to the operating system and it interfaces to the cable modem hardware using the appropriate bus (PCI) or bus interface driver (USB or IEEE 1394) at its bottom edge.

In contrast to DOCSIS, both the 802.14 and the DVB/DAVIC efforts are focused on using ATM, typically implementing an ATM adapter interface and using an NDIS 5.0 ATM miniport driver.

126. Device is implemented as an integrated cable modem

Recommended

An integrated cable modem should be used for servers. This recommendation means integrating everything from the cable modem’s physical interface layer, such as an RF coax connector, up through a standard PC 802.3/DIX Ethernet or ATM adapter MAC interface onto a single device. In other words, the software perceives the integrated cable modem as a standard Ethernet or ATM network adapter.

An example of this is a USB-attached DOCSIS implementation that integrates cable modem Physical Media Dependent, downstream convergence, cable MAC, link security, 802.3/DIX MAC "adapter" filtering, and USB device interface functions in the same box. Similar devices can be implemented that are attached using PCI or IEEE 1394 buses.

127. Integrated cable modem meets network adapter requirements

Required

  • Integrated cable modems must meet all requirements listed earlier in "Network Adapter Requirements."

Integrated cable modems exposing an Ethernet interface must also meet the requirements in guideline "#92. Network adapter supports filtering for at least 32 multicast addresses."

128. Integrated cable modem exposes an ATM or Ethernet interface

Required

Refer to ATM Adapter requirements for ATM-specific requirements if an ATM/cable modem solution is implemented.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


ISDN Requirements

This section summarizes requirements for ISDN hardware.

ISDN is recommended, but not required, for high-speed connections under these guidelines. If implemented in a server system, ISDN must meet the requirements defined in this section.

There are two classes of ISDN adapters:

  • Serial port devices, supported by Unimodem with INFs
  • Parallel bus devices, supported by NDIS WAN drivers

In this section, "internal ISDN device" refers to the ISDN terminal adapter, which exposes raw access to its B channels using NDIS miniports. WDM-supported bus classes, such as USB or IEEE 1394, can also be used to attach external devices using NDIS miniports.

"ISDN modem" refers to an internal or external ISDN device that exposes itself as a modem controlled by the AT command set. To the operating system, these devices look like and can be used as modems, provided that the hardware manufacturer has done the work needed to ensure that these devices have the following capabilities:

  • Interpretation of the standard modem AT command set, either in the ISDN device itself or in a serial port driver. For more information, see the TIA-602 specification, which is a subset of ITU V.250.
  • A modem INF file for installing the device and for telling Unimodem which commands to use to control the ISDN device.

Serial ISDN Modem Requirements

The requirements in this section apply for a serial ISDN modem designed for or included with a server system that complies with Hardware Design Guide.

ISDN modems share the following features:

  • ISDN Basic Rate interface (2B+D)
  • Serial AT command language, with proprietary ISDN extensions

ISDN modems also share the following differences from wireline PSTN modems:

  • User (or device) must configure for switch type and service profile ID (SPID)
  • Data only, in increments of one or two 64,000 bps B channels
  • Fax not available
  • V.42 and V.42bis usually not available

129. ISDN modem supports required command set

Required

An ISDN modem must support basic AT commands as defined in TIA-602, which is a subset of ITU V.250. The ISDN modem shall support commands to select the end-to-end protocol used over the ISDN; synchronous PPP, V.110, V.120, and so on. Also, commands must be included to set the switch type, subscriber numbers or directory numbers (where applicable), and service profile identifier (SPID) or EAZ (where applicable), to allow user selection if auto-detection fails. These can be implemented in the device or in the communications driver.

130. ISDN modem exposes both B channels

Recommended

ISDN modems should expose both B channels so that they can leverage the multilink PPP support included in the operating system.

Multilink PPP, as defined in RFC 1717, combines several ISDN B channels to increase the bandwidth of PPP links.

When using ISDN modems connected to the server using a single serial port, the capabilities included in the operating system cannot be leveraged and the users may not be able to fully benefit from the features in the ISDN device, such as supporting two B-channels and combining them into one fast link.

This is because Windows 2000 cannot see both B channels of the ISDN connection unless each B channel is exposed to the operating system, either as a COM port, or by way of NDIS.

External ISDN modems should be on a port fast enough to expose the full bandwidth of both B channels, such as USB. Providing two separate COM-port cables is not an acceptable solution.

131. ISDN modem supports asynchronous-to-synchronous conversion

Required

These types of ISDN devices are treated as modems, not as internal ISDN devices supported using NDIS WAN miniports. In the external case, the primary implication is that the operating system will send byte-level PPP, also known as asynchronous PPP. In the NDIS WAN case, the implication is that the operating system will send bit-level PPP, also known as synchronous PPP.

Because ISDN is a synchronous service and an ISDN modem connects to an asynchronous port on the system, the device must provide some means of converting asynchronous data to synchronous data.

132. ISDN modem uses high-speed port

Recommended

Because of speed limitations inherent in a server’s COM ports, the connection for ISDN modems should be high speed, such as USB or IEEE 1394. A specification for controlling an ISDN TA over USB is in development by the USB Communications Device Class working group.

133. ISDN modem driver supports unattended installation, with limitations

Required

Configuration of the dependent parameters, such as SPIDs and switch-type IDs, must be done using the ISDN Configuration Wizard included in the operating system.

Parallel ISDN Device Requirements

This section defines general requirements for ISDN and specific requirements for ISDN terminal adapters.

134. Internal ISDN device meets network adapter requirements

Required

Internal parallel ISDN devices must meet all requirements listed earlier in "Network Adapter Requirements."

135. Internal ISDN device supports synchronous HDLC framing

Required

High-level data link control (HDLC) framing is a standard for sending synchronous data. Other framing methods are allowed if the miniport driver provides simple HDLC framed synchronous PPP packets to NDIS.

136. Internal ISDN device and driver support raw unframed synchronous B channel I/O

Required

The internal ISDN device and the driver must support raw unframed (non-HDLC) synchronous B channel I/O at 64 Kbps for each B channel, with each B channel individually accessible. This will enable H.320 and voice calls over ISDN without audio breakup.

For these raw interfaces, the direct path to each B channel must support synchronous transmission and reception of H.221 frames, which are of 20 ms duration. To achieve this without additional latency to H.221, there must be support for overlapped I/O buffers at intervals of less than or equal to 20 ms in each direction. As underruns or overruns cause degraded audio, hardware buffering must be adequate to prevent B channel underruns and overruns. For Windows 2000, 20 ms is adequate.

This can be achieved by making buffering software configurable with adequate range to handle foreseeable real-world conditions. The miniport driver should make I/O completion callbacks to NDIS for each I/O buffer as soon as the I/O for that buffer is complete and should not coalesce or delay callbacks.

137. Driver for ISDN internal device supports unattended installation, with limitations

Required

Configuration of the dependent parameters, such as SPIDs and switch-type IDs, must be done using the ISDN Configuration Wizard included in the operating system.

138. ISDN device with U-interface includes built-in NT-1 capability

Recommended

Note: This recommendation applies only in the United States.

A network terminator (NT-1) splits the duplexed transmit and receive signals from the ISDN line into separate transmit and receive components. An ISDN device with a built-in NT-1 can connect directly to the ISDN line. However, doing so prevents other devices from being attached to the ISDN line because only one NT-1 can be connected to an ISDN line. If the ISDN device has a built-in NT-1, it also should have a connector for either analog phone or another ISDN device (S/T-interface), such as an ISDN phone.

Adding an analog (POTS) port or S/T-interface to the ISDN device delivers convenience to the SOHO market, allowing customers to use one ISDN line to meet all their telecommuting needs at minimal cost. Many customers do not want a separate analog or digital phone line for their fax machines, modems, or phone when ISDN can do this with a device that has a POTS port or S/T-interface.

139. Internal ISDN device has software-selectable terminating resistors

Required

If the ISDN device has an S/T-interface for connecting additional ISDN devices and has configurable terminating resistors, they must be software configurable. The software selectable resistors can be selected on or off. The default value of termination is on in North America, but off in all countries where phone companies unconditionally provide the termination.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


DVD Drive Requirements

This section summarizes requirements for supporting DVD drives. A DVD drive is not required in a server system, but if present, it must comply with these requirements. Systems targeted for use with Windows 2000 Advanced Server or Datacenter Server should provide DVD drive capabilities.

For more information about DVD support under Windows 2000, see the articles at http://www.microsoft.com/hwdev/dvd/.

191. DVD device provides 2 MB minimum transfer rate or better performance anywhere on the disk

Required

This requirement is intended to set the minimum speed needed for DVD-Video playback during MPEG-2 decoding on Windows platforms. This requirement applies to the minimum read speed (2 MB/s) on any production-level DVD-Video media, at any location on the disc. This requirement does not apply to end-user recorded DVD data discs, or discs being read in error-correcting, defect management mode.

192. DVD drive meets minimum compatibility requirements

Required

DVD drives must support all the functionality of CD drives as outlined in this document. The DVD drive must also be compatible with the following formats to ensure that the DVD drive can read earlier media:

  • Physical formats: ROM (stamped), Orange Book part II (CD-R) and part III (CD-RW), and ECMA-267 and ECMA-268 (DVD-ROM).

Conforming to OSTA MultiRead Specification, Version 1.11, indicates compliance with all of these CD compatibility requirements.

193. DVD drive supports defect management

Required

The drive must support the defect management that is transparent to the operating system, according to industry standards. Defect management for DVD-RAM media is defined in DVD Specifications for Rewritable Disc, Part 1: Physical Specifications, published by Toshiba Corporation. Defect management for DVD+RW is defined in ECMA-274.

194. DVD-Video playback, if present, meets DVD-Video playback requirements

Required

Servers that provide DVD drives only as storage devices do not have to include the additional capabilities required for DVD-Video playback on a local display device. Only servers that provide the specific feature of DVD-Video playback to the local server display must meet the DVD-Video playback requirements specified in these guidelines.

The following capabilities are required for DVD drives that support DVD-Video playback:

  • DVD decoder driver correctly handles media types, time discontinuity, and decode-rate adjustment. This requirement specifies that the vendor-supplied minidrivers for DVD, MPEG-2, and AC-3 decoders have the following capabilities:
  • Use correct media types. This includes validating all format block fields on connection and on every IPin::QueryAccept message.
  • Query for IMediaSample2 on every received media sample to test for a time discontinuity bit. It is also acceptable to query on every video/audio frame to reduce CPU overhead.
  • Adjust decode rate in response to IPin::NewSegment() calls for video and subpicture.
  • DVD decoder supports subpicture compositing and closed captioning. The system must be capable of displaying subpicture data as well as providing closed-captioning support for all such data stored on the disc. This requires YUV offscreen surface support, as defined later in this list.

Subpicture streams must be supported as defined in the DVD Specification, Version 1.0, from Toshiba Corporation. Alpha blending, or a simulation implemented in the driver, is required for static menus.

  • Subpicture decoder correctly handles subpicture properties and other functions. The minidriver for the subpicture decoder must be able to correctly handle the following:
  • Set the subpicture property
  • Turn subpicture compositing on and off
  • Set the highlight rect parameters

For information, see the Microsoft DirectX® SDK (provided in the Microsoft Platform SDK) and the DirectX information in Windows 2000 DDK.

  • System supports seamless DVD-Video 1.0 navigation. This requirement includes menu navigation and video selection, and language and subpicture track selection to support the user’s ability to navigate DVD-Video discs. Test sources include, but are not limited to, the following:
  • Matsushita Electronics Incorporated (MEI) test disc
  • Joe Kane Productions Video Essentials disc
  • Microsoft test disc
  • MPEG-2 playback provides high-quality video output. MPEG-2 solutions must provide high-quality video display output, as defined by the following:
  • Smooth frame delivery, with all video fields and frames from the MPEG source decoded.
  • Audio and video synchronized to within one and a half video frames, with synchronization not allowed to drift out over time.
  • No tearing—provide proper video buffering, such as double buffering.
  • Correct display of multiple-aspect ratio content. The material should be displayed according to the aspect ratio information in the MPEG header.

This requires support for YUV offscreen surface and up/down interpolated scaling, as defined in the following requirement.

  • Graphics adapter supports DVD movie playback features. Any system with a DVD drive that includes the ability to play back MPEG-2 data streams must meet the requirements listed here. However, this requirement does not apply for systems that include DVD drive for storage purposes but do not include DVD-Video playback software. The following capabilities are required for solutions that use either hardware or software MPEG-2 decoders:
  • Up and down scaling with bilinear interpolation
Recommendation

Recommended: 5 taps, both vertically and horizontally

  • YUV 4:2:2 and 4:2:0 planar offscreen surface support
  • VGA destination color keying for video rectangle
  • AGP or PCI bus mastering

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Power Supply

This section defines the guaranteed power requirements for servers.

211. System includes UPS provided with system

Recommended

For servers deployed in many corporate environments, the more common choice will be to provide guaranteed power for the server room.

212. System includes power supply protection using N+1 (extra unit)
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Recommended | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Recommended | Recommended

The system overvoltage/undervoltage protection and power supply switch-over circuitry should have the capability to regulate according to the system load. For each voltage used in the system, the output voltages of the redundant power supplies should be within the range of values that can guarantee the proper operation of the system, no matter which supply is active. Power-supply switch-over should occur swiftly enough to maintain normal server system operation.

213. System supports replacement of power supplies

Required

Systems are required to allow for the replacement of the module (or modules) constituting their source of power by a qualified individual in the field. The minimum requirement is that this capability be provided when the system is powered off, that is, when the server is in a "down" condition.

Recommendation

Recommended: Hot-swapping capabilities for power supply replacement and power supply redundancy.

214. System supports replacement of fans

Required

Systems are required to allow for the replacement of the fan (or fans) by a qualified individual in the field. The minimum requirement is that this capability be provided when the system is powered off, that is, when the server is in a "down" condition.

Recommendation

Recommended: Hot-swap fans should be implemented to maximize server up time.

215. System includes local hot-swap power supply replacement indicators
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

Any system that provides hot-swap power supply replacement and power supply redundancy should have local indicators that unambiguously indicate the supplies that must be replaced. These indicators guide service personnel to replace the correct power supply. Automatic retention mechanisms that prevent incorrect supply removal also satisfy this guideline.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Fault-Tolerant Hardware

This section provides design guidelines for fault-tolerance features and capabilities.

216. System supports multiple hard drives
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Recommended | Required | Recommended
SOHO: | Recommended | Required | Recommended

Bus mastering is required for the drive controllers. Use of multiple hard drives and controllers in a server system provides both performance and reliability benefits. It is not a requirement that the drives all be physically housed in the server system chassis.

Recommendation

Recommended: Hot-swappable drives.

217. System includes intelligent RAID controller with adequate storage capacity

Required for all Enterprise class systems

Required for Basic and SOHO class systems deploying MSCS clustering

An intelligent RAID controller—where the controller itself has the capability to run the array management software locally rather than simply executing disk accesses for host-based array software—provides the benefit of reduced demands on the host processor or processors, thereby freeing those computing resources and allowing their use by other tasks. The intelligent RAID controller may be internal to the server chassis, or within an external drive enclosure.

If an intelligent RAID controller is provided in a system, it should be capable of handling sufficient amounts of disk storage to fulfill the needs of the targeted usage model for that server. These needs will vary based on the storage-intensive nature of the server’s tasks.

218. System supports at least one of RAID 1, 5, or 1/0

Required for all Enterprise class systems

Required for Basic and SOHO class systems deploying MSCS clustering

RAID 1 and RAID 1/0 are recommended. RAID 5 is also acceptable. RAID 0 (for enhanced performance but no added reliability) is optional.

219. RAID support includes notification of failed drive

Required

If RAID support is implemented, notification of a failed drive must be provided by the disk subsystem, with notification sent to the system administrator.

220. RAID subsystem supports automatic replacement of failed drive

Required for all Enterprise class systems

Required for Basic and SOHO class systems deploying MSCS clustering

The RAID subsystem must provide automatic replacement of a failed drive by a standby disk and must rebuild lost data without interfering with system operations.

221. RAID subsystem supports manual replacement of failed drive

Required for all Enterprise class systems

Required for Basic and SOHO class systems deploying MSCS clustering

The RAID subsystem must provide for manual replacement of a failed drive without shutting down or halting the system. The subsystem must also allow lost data to be rebuilt without interfering with system operations beyond some decreased performance of drive array access.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Serviceability Requirements

This section provides design guidelines for serviceability features and capabilities.

222. IA-32 system includes protected forced dump switch or other mechanism for system diagnosis
 | Windows 2000 Server | Advanced Server, Datacenter Server | Small Business Server
Basic Server: | Recommended | Required | Recommended
Enterprise: | Required | Required | Required
SOHO: | Recommended | Required | Recommended

The system should include a protected switch or other mechanism to force an NMI on a stalled system. This device permits the system to perform a memory dump that can then be used for diagnosis of system failures. If implemented, this device must be protected in such a way that only an authorized administrator can perform this action.

For additional information on the "dump switch" support in Windows 2000, which may be helpful for designers of IA-32 systems, please see http://www.microsoft.com/hwdev/debugging/dmpsw.htm. Note that this white paper presents only concept suggestions for designers and is not intended to provide precise implementation detail.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


General Manageability Baseline Requirements

This section defines requirements related to centralized control and configurability and BIOS support for system manageability.

227. Remote new system setup and service boot support use DHCP and TFTP

Recommended

The complete mechanism for remote new system setup is defined in PXE 2.1 or later.

If remote new system setup capabilities are implemented, there must be a way for this capability to be enabled or disabled by way of administrative control to maintain server security.

See also the requirement for the preboot execution environment in guideline "#13. IA-32 BIOS boot system supports remote/network boot, USB boot devices, and firmware update," and guideline "#14 IA-64 system complies with EFI 1.0 or later, with support for USB boot devices, firmware update, and PXE_BC, SERIAL_IO, and SIMPLE_NETWORK protocols."

228. Expansion devices can be remotely managed

Recommended

Devices provided as expansion devices should be capable of being remotely managed, ensuring that control and TCO policies can be realized. The requirements for remote management capabilities are defined in "Manageability Component Instrumentation Requirements" later in this chapter.

For example, for any implementation of a floppy drive, the floppy drive should be capable of being remotely disabled as a boot selection and should be able to be locked.

Certain devices are not required to have remote disabling capabilities, including the primary hard disk drive, the network adapter, and any standard devices that use legacy connections, such as a keyboard or pointing device that uses a PS/2 connection. However, it must be possible to use permissions, policies, or other methods to remotely manage capabilities such as hard disk access or to control certain users’ ability to change the MAC address or configuration settings for the network adapter.

If implemented, there must be a way to enable and disable this capability by way of administrative control to maintain server security.

See also the requirement for the firmware to ensure secure preboot access to hardware components in guideline "#12. System firmware meets general boot support requirements."

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.


Manageability Component Instrumentation Requirements

Platform management information requirements are defined for two key areas:

  • Component instrumentation: Interfaces through which information is supplied by platform management components.
  • Management information providers: Interfaces used by applications to access platform management information.

229. System supports Windows Hardware Instrumentation Implementation Guidelines

Required

These guidelines are defined in WHIIG 1.0.

230. IA-64 hardware and firmware support IA-64 Machine Check Architecture

Required

Many features of 64-bit Windows depend on platform support for IA-64 Machine Check Architecture. IA-64 systems must implement hardware and firmware that support IA-64 Machine Check Architecture.

230.1. IA-64 system uses Machine Check Architecture for error reporting and logging

The IA-64 Machine Check Architecture has a complete method for reporting processor errors and many system errors. System designers must use the Machine Check Architecture for system-wide error reporting and logging. The Machine Check Architecture must be used to report platform errors, including errors within the system processors, memory, internal buses, and expansion buses.

Note: Certain established interfaces, such as TCP/IP in the networking space and SCSI in the storage space, have extensive error reporting and recovery mechanisms in their protocol stacks. Some interfaces (for example, serial ports, LPC, and so on) may have limited or no hardware support for reporting errors. Subsystems such as this are excluded from this requirement.

230.2. IA-64 firmware implements support for Machine Check Architecture

IA-64 system firmware must implement the IA-64 Machine Check Architecture. Using Machine Check Architecture, every firmware layer in the system may check for recoverable errors and log errors, and perform error recovery where possible. All machine check recovery code must use Machine Check Architecture firmware hooks.

Discontinue use of Platform Management Interrupt (PMI) for doing machine check and recovery.

230.3. IA-64 Machine Check Architecture supports code resources

All IA-64 Machine Check recovery code must use Machine Check Architecture firmware hooks as specified in SAL 2.7 or later. Platform machine check hardware must provide relevant status bits for all sources of hardware errors that need to be handled in Machine Check Abort code.

Discontinue use of PMI and NMI for performing machine check and error recovery.

231. IA-64 system supports event logging for critical events

Required

The hardware, SAL, and firmware on IA-64 systems must provide the capability to log all critical events. It is required that an event log be made available that can be accessed by management software.

© 2000 Intel Corporation and Microsoft Corporation. All rights reserved.