desktop and mobile pc requirementsdownload.microsoft.com/download/1/6/1/161ba512-40e2-4cc9... ·...

Microsoft Windows Logo Program

Desktop and Mobile PC Requirements

Design and Test Requirements for Systems and Components that Run Microsoft® Windows® 2000 Professional, Windows 98 Second Edition, and Windows Millennium Edition Operating Systems

Version 1.1 — June 23, 2000

Microsoft Corporation

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.

Portions of this document specify software that is still in development. Some of the information in this documentation may be inaccurate or may not be an accurate representation of the functionality of final documentation or software. Microsoft assumes no responsibility for any damages that might occur directly or indirectly from these inaccuracies.

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-2000 Microsoft Corporation. All rights reserved.

Direct3D, DirectDraw, DirectInput, DirectShow, DirectSound, DirectX, Encarta, Hotmail, Microsoft, Microsoft Office, MS-DOS, Outlook, NetMeeting, Windows, the Windows logo, Win32, Win64, 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 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/.

© 1999-2000, Microsoft Corporation. All rights reserved.

iii

Contents

Chapter 1 Introduction to Windows Logo Program for Hardware 1About the Microsoft Windows Logo.........................................................................................................1“Designed for Windows” Logo Options....................................................................................................2Windows Logo Program Dates................................................................................................................3What’s New in This Version.....................................................................................................................4How to Use These Guidelines.................................................................................................................5

Chapter 2 PC Hardware Requirements for Windows Logo 7

Chapter 3 Recommendations and Future Requirements 15Recommended System Capabilities......................................................................................................16Recommended End-user Experience....................................................................................................17Recommended Device and Driver Capabilities.....................................................................................18“Best Practices” Recommendations......................................................................................................20

Chapter 4 Getting the Windows Logo for Hardware 21

Appendix A PC System Requirement Details 23How to Use This Appendix....................................................................................................................23A1.0 General PC System Requirements...............................................................................................24A2.0 Desktop Client Requirements........................................................................................................34A3.0 Mobile Client Requirements..........................................................................................................35A4.0 Legacy-Free System Requirements.............................................................................................39

Appendix B Device Requirement Details 39How to Use This Appendix....................................................................................................................39B1.0 General Device and Driver Quality...............................................................................................39B2.0 Bus/Device Controllers..................................................................................................................39

B2.1 CardBus/PCMCIA Controllers and Devices.............................................................................39B2.2 IEEE 1394 Controllers and Devices.........................................................................................39B2.3 Infrared/Wireless.......................................................................................................................39B2.4 Parallel/Serial Devices..............................................................................................................39B2.5 PCI Controllers and Devices....................................................................................................39B2.6 USB Controllers and Devices...................................................................................................39

B3.0 Audio Devices................................................................................................................................39B3.1 General Audio...........................................................................................................................39

B4.0 Display...........................................................................................................................................39B4.1 Display Adapters/Chipsets.......................................................................................................39B4.2 Monitors....................................................................................................................................39

B5.0 Input and HID.................................................................................................................................39B5.1 General Input............................................................................................................................39B5.2 Keyboard...................................................................................................................................39B5.3 Input/Pointing............................................................................................................................39B5.4 Input/Game...............................................................................................................................39B5.5 Input/Keyboard-Video-Mouse...................................................................................................39B5.6 Smart Card Readers.................................................................................................................39

B6.0 Modems.........................................................................................................................................39B6.1 General Modem........................................................................................................................39

B7.0 Network Devices...........................................................................................................................39B7.1 General Network.......................................................................................................................39B7.2 Cable Modem............................................................................................................................39B7.3 DSL Device...............................................................................................................................39B7.4 ISDN Net Device.......................................................................................................................39B7.5 ATM Device..............................................................................................................................39

B8.0 Printers..........................................................................................................................................39B8.1 General Printers........................................................................................................................39

B9.0 Still Image Devices........................................................................................................................39B9.1 General Still Image Devices.....................................................................................................39

B10.0 Storage Controllers and Devices................................................................................................39B10.1 General Storage......................................................................................................................39B10.2 IDE ATA/ATAPI Controllers/Devices......................................................................................3910.3 SCSI Controllers/Devices.........................................................................................................39


iv

B10.4 Hard Disk Drives.....................................................................................................................39B10.5 CD/DVD Drives.......................................................................................................................39B10.6 Removable Media Drives........................................................................................................39B10.7 Tape Drives.............................................................................................................................39B10.8 Media Changer Devices.........................................................................................................39B10.9 RAID.......................................................................................................................................39B10.10 Fibre Channel........................................................................................................................39

B11.0 Streaming Media and Broadcast.................................................................................................39B11.1 General Streaming..................................................................................................................39B11.2 DVD Playback.........................................................................................................................39B11.3 TV Tuner.................................................................................................................................39B11.4 Video Input/Capture................................................................................................................39

B12.0 Miscellaneous..............................................................................................................................39B12.1 Multifunction Devices..............................................................................................................39

Appendix C Designing for Success 39

© 1999-2000, Microsoft Corporation. All rights reserved. iv

1

Chapter 1 Introduction to Windows Logo Program for Hardware

Welcome to the Microsoft Windows Logo Program for Desktop and Mobile PC Requirements.

This document describes the scope and purpose of the Microsoft Windows Logo Program, and it tells how to obtain the Windows Logo for desktop and mobile PC systems and components that run the Microsoft® Windows® 2000 Professional and Windows Millennium Edition (Windows Me) operating systems. This document defines the Windows Logo Program requirements that must be met by PC hardware vendors and system manufacturers who want to license the Windows Logo.

This document is revised in relation to each release of a new version of client versions of Windows operating systems. To receive notice and review opportunity for future revision, please complete the information request form at http://www.microsoft.com/winlogo/.

This document does not address requirements related to server systems or server-specific components. For information, see http://www.microsoft.com/winlogo/Server/.

About the Microsoft Windows LogoMicrosoft 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 PC 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.

Products that carry the Windows Logo (for hardware or software) 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 2000 or any later version of the operating systems for which the system or component carries the logo.



Customer BenefitsWindows 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, driver, and related software components. In particular:

The user is assured that a product that has received the Windows Logo will be stable when running under the operating systems listed on the Windows Logo carried by that product.

The user can easily begin and complete component installation or removal. Installing and using a component that has passed Windows Logo testing 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.

CAUTION: 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. Please note, as summarized from the licensing agreement for the Windows Logo:

You may only use the Windows Logo as a symbol that your product has passed the applicable Microsoft Windows compatibility testing. You may not explicitly state or imply that Microsoft or the testing organization in any way endorses your product. Also, the Windows Logo program is not intended to be a "certification" program—that is, the Windows Logo does not represent that Microsoft or the testing organization certifies your product in any way.

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

Microsoft designates different logos for specific systems and devices. The specific Windows Logo for the system or device indicates which operating system versions the manufacturer installs on the system or supports for the device. The current, comprehensive listing of the logo options is available at http://www.microsoft.com/hwtest/search/details.asp?ID=270

Windows Logo Program requirements may vary for different classes of products (for example, desktop versus mobile) and for different market segments (for example, commercial desktop, consumer desktop, or workstation). Where PC 99 System Design Guide 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 the Windows 2000 Professional operating system preinstalled.

Consumer PC: The system comes with Windows 98 preinstalled or with a future Consumer Windows operating system based on the Windows 2000 code base.

In addition, Microsoft has a long-term goal to provide operating systems for all PC market segments based on the Windows 2000 code base. For details about Windows Logo Program requirements that support this goal, see Logo Requirement #8, “System components migrate correctly upon upgrade to later operating system,” in Chapter 2, “PC Hardware Requirements for Windows Logo.”

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

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

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 is preinstalled on the PC system.

For example, support for Plug and Play and multiple monitors was added to the Windows Logo Program requirements a few years ago because new support was being introduced in Windows operating systems. The applicability of these types of requirements depends on the operating system that is preinstalled on the system—for example, in past years, a system with Windows NT 4.0 preinstalled was not required to fully support the Plug and Play requirements.

Another current example is support for legacy-free designs, which is being 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 PC must meet the specific Windows Logo Program requirements when the vendor begins shipping that system.

Industry Advances. Some technical requirements that advance the PC platform 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.

In this case, some technical advances proposed in the PC Design Guides and adopted as Windows Logo Program requirements are defined in order to support



features in yet-to-be-released versions of Windows operating systems. For example, Advanced Configuration and Power Interface (ACPI) BIOS and system-board support was proposed in the Design Guides before versions of Windows were available that supported ACPI.

The goal for requiring these kinds of design changes in advance of the avail-ability of the operating system is 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 PC systems that meet the tests for operating system compatibility and also comply with Windows Logo Program requirements, see Appendix A, “Designing for Success.”

To plan for Windows Logo requirements related to advances in the PC platform, OEMs should participate in the PC Design Guide review process, as described at http://www.pcdesguide.org/.

What’s New in This VersionThis version supersedes Version 1.0, which was published in January 2000 to summarize the 1999–2000 scope and requirements for the Logo Program in relation to requirements for PCs and peripherals for Windows Me and Windows 2000.

This version adds only the following new information:

New requirements in relation to Windows Me, first presented in the appendix of Version 1.0 of this document.

Most of the Windows Me-related requirements map to new requirements defined in PC 2001 System Design Guide, Version 0.7.

New requirements that go into effect for the Windows Logo Program on July 1, 2000. These proposed new requirements were presented in Chapter 3 of Version 1.0 of this document. Many of these requirements also map to new requirements defined in PC 2001 System Design Guide, Version 0.7.

New appendixes providing detailed lists of requirements per device class, bus class, and system type.

NOTE: These appendixes contain new requirements only in relation to the first two cases. As a whole, these appendixes provide a summary of the requirements already enforced for the Logo Program.



How to Use These GuidelinesThis document lists all the technical requirements necessary to obtain the Windows Logo for hardware. You must complete the agreements and submit your hardware, as described in Chapter 4 of this guide.

This document includes the following chapters.Chapter Description

Chapter 1, Introduction to Windows Logo Program for Hardware

Presents a summary of the Windows Logo Program and background information and resources.

Chapter 2, PC 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 for desktop and mobile systems, 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, PC System Requirement Details

Provides a summary list of requirements for systems, based on the preinstalled operating system.

Appendix B, Device Requirement Details

Provides a summary list 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.



The following conventional terms are used throughout this guide. Term Definition

Required/Requirement

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

Exception These are situations in which a requirement may not apply.

NEW Indicates a new Logo requirement that applies for systems where Windows Me is preinstalled or that refers to a requirement previously scheduled to become effective July 1, 2000. This tag appears beside any new requirements introduced since v. 1.0 of this document was published.

The following provides a list of Microsoft resources that can help you build hardware that meets the Windows Logo requirements. Resource Address

Windows Logo Program web site http://www.microsoft.com/winlogo/

Feedback on logo requirementsand related issues

[email protected]

Hardware testing tools and test submission information

http://www.microsoft.com/hwtest/

Digital signing for drivers [email protected]

Logo information e-mail (artwork and other issues)

[email protected]

Knowledge Base http://support.microsoft.com/support/

Information for manufacturers and driver developers

http://www.microsoft.com/hwdev/E-mail: [email protected]

General information for developers

http://msdn.microsoft.com/developer/

Hardware glossary http://www.microsoft.com/hwdev/glossary.htm

Windows Driver Development Kits (DDKs)

http://www.microsoft.com/ddk/Provided with Microsoft Developer Network (MSDN) Professional Subscription. To subscribe:

E-mail: [email protected]://www.microsoft.com/msdn/subscribe/


7

Chapter 2 PC 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.

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

Summary of Windows Logo RequirementsThe Windows Logo requirements consist of the following for each operating system for which the vendor is seeking the logo:

Current Microsoft Hardware Compatibility Tests (HCTs) from WHQL, available on the web at http://www.microsoft.com/hwtest/testkits/

The requirements in this chapter, Appendix B, “Device Requirement Details,” and Appendix A, “PC System Requirement Details,” plus any addenda listed on the Windows Logo Program for Hardware web site at http://www.microsoft.com/winlogo/

Implementation guidelines for drivers are defined in the Microsoft Windows 98 DDK and Windows 2000 DDK. System and component design guidelines are defined in PC 99 System Design Guide and PC 99 Addendum, with additional clarifications and implementation guidelines on the Hardware and Driver Developers web site at http://www.microsoft.com/hwdev/.

Note that the PC 99 Design Guide does not define the Windows Logo Program requirements; rather, it provides feature guidelines for system and component design.

Windows Logo Program RequirementsWL-1 System and devices support required operating systems

WL-2 System processor, cache, and memory in combination provide 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 migrate correctly upon upgrade to a later operating system

RationaleFor 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: Meeting these requirements ensures that the hardware runs in a stable, reliable manner, and it ensures that the hardware results 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 to function due to 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.

This section provides information about the specific requirements.

WL-1. System and devices support required operating systemsAt a minimum, a system or device submitted for Windows Logo Program testing must provide 32-bit driver support for the Windows 2000 operating system, plus driver support for any other Windows operating systems that will be preinstalled on the system. For systems, a Microsoft operating system must be preinstalled on the hard disk.

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 compliance testing using a driver provided with the operating system.

WL-2. System cache and memory in combination provide a satisfactory user experienceBecause objective benchmarks are not available, the intent of this requirement is to define a combination of cache and memory size that represents the baseline of acceptable Windows performance.

Equivalent or better performance can be obtained by increasing cache size (L1 or L2), increased front-side bus speed (FSB), faster processors, or a combination of all three. For example, lower CPU clock speeds could be compensated for by larger L2 cache or faster FSB, or by moving to a higher-speed CPU bus architecture. For Windows performance, RAM is treated separately from cache, because of the direct



performance relationship between RAM size and the Windows operating system working set.

The following summarizes the Windows Logo Program performance requirements.

2000-2001 Minimum Equivalent Performance Requirements RAM

System type Windows Me Windows 2000 L2 cache

Mobile 32 MB 64 MB 128 KB

Desktop 32 MB 64 MB 128 KB

WL-3. System includes required set of buses and devicesThe system must include the following buses, connectors, and devices, with driver solutions implemented as defined in the DDKs:

Primary storage host controller and primary hard driver

Graphics adapter

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 and devices with icons or labels for keyboard and pointing device, and for external expansion and peripherals

For more information, see Appendix A, “PC System Requirement Details.”

WL-4. All components and devices meet Windows compatibility and quality design guidelinesThe compatibility and quality guidelines include requirements for devices, drivers, and software included with the system or retail component.

For specific component feature and functionality requirements, see Appendix A, “PC System Requirement Details.”

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 and be logo’d itself if there are requirements defined for that component under the Windows Logo Program.

The complete definition of these requirements is provided in Appendix B, “Device Requirement Details.”

Driver and Software RequirementsThese requirements ensure a good user experience with installing and using any component:



Windows-compatible driver support. Each device must have drivers for 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 98 and Windows 2000 DDKs. For 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.

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 2000 driver, no errors can occur under the Driver Verifier facility provided with the Windows 2000 DDK. Although Driver Verifier is not available for Windows 98/Me, every WDM driver should be tested with Driver Verifier on Windows 2000.

Poorly written kernel mode drivers have the potential to cause the system to stop working. Therefore, it is critical that all kernel-mode drivers be thoroughly tested to minimize this risk. See http://www.microsoft.com/hwdev/driver/driververify.htm for information about using Driver Verifier and diagnosing driver problems. Driver Verifier is provided in the System HCT from WHQL.

Driver signing. Drivers submitted for testing must meet the guidelines for driver signing as defined at http://www.microsoft.com/hwdev/desinit/digitsign.htm.

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

Implementation Guidelines: Windows Me DDK, Windows 98 DDK, Windows 2000 DDK: http://www.microsoft.com/ddk/.

“New Technology” RequirementsFor 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 PC 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 2000 Professional.

Use native operating system support whenever possible. If the related feature is supported natively under a preinstalled version of Windows or Windows 2000, comply with the related industry specification, create drivers based on DDK guidelines, and meet the design requirements defined in PC 2001 System Design Guide, version 0.7 or later.

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 2000 or Windows Me preinstalled, comply with the industry specification, implement WDM minidriver support as defined in the 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 DDK guidelines for related bus and device class driver implementations, 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 feature, you must still use the related Windows driver model for adding support. In this example, driver support must be implemented as an Network Driver Interface Specification (NDIS) 5.0 miniport, as defined in the Windows 2000 DDK and cited in the guidelines for wireless devices in PC 99 System Design Guide.

WL-5. System and components meet reduced legacy support goalsHardware Legacy Reduction Requirements. Retail components and components included with a system must not use the ISA expansion bus. For desktop and mobile systems, no devices that use the parallel or serial ports can be included with the system. As of January 1, 2000, desktop PC systems must not include user-accessible ISA expansion slots.

Software Legacy Reduction Requirements. All software included with a system or peripheral device must be Microsoft Win32®-based software. The software must not require MS-DOS®–based decompression or installers.

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

This requirement does not apply for the emergency recovery software or boot device software.



Legacy-Free System Requirements. A system will be 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 the 8042 controller).

No components claim to use the restricted port addresses.

The complete hardware and BIOS requirements for legacy-free design that is compatible with Windows operating systems—including exceptions and issues for mobile PCs—are described in Appendix A, “PC System Requirement Details.”

WL-6. System and components support operating system configuration and control of devicesThe 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 DDK implementation guidelines for Plug and Play and other functional capabilities of the operating system.

Details and references for operating system compatibility and design guidelines are defined in Appendix A, “PC System Requirement Details.”

WL-7. System and peripherals implement ease-of-use guidelines for a good end-user experienceThe following basic ease-of-use guidelines are cited for the Windows Logo:

Connections use icons, plus keyed or shrouded connectors

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

Minimal user interaction is needed to install and configure devices, which is ensured by following the device installation guidelines defined in the Windows 2000 and Windows 98 DDKs.

Driver and utility installation do not require a system reboot.

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

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



WL-8. System components migrate correctly upon upgrade to later operating systemA component installed on an earlier operating system must remain fully functional after an upgrade to a later operating system version.

In particular, consider a system that comes preinstalled with Windows 98 Second Edition. When this system is upgraded to Windows 2000, all features present under Windows 98 that are supported in Windows 2000 must be fully operational after the upgrade.

If your system provides a proprietary implementation under an older version of the operating system, the implementation must be transparent to the operating system and must upgrade when the next version of the operating system is installed.

Upgrading from Windows NT to Windows 2000 These requirements apply for systems that receive the “Designed for Windows 2000 and Windows NT 4” logo where Windows NT 4 is preinstalled:

System includes Windows 2000–ready, ACPI-compliant BIOS. Tests and related information are available at http://www.microsoft.com/hwdev/onnow/.

Supported features are functional after upgrade. All features present on the system that are supported in Windows 2000 must be fully operational after the upgrade.

“Windows 2000 Upgrade Help Icon” is preinstalled on the Windows Desktop. A help file must be preinstalled, with an icon appearing on the Windows Desktop. 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 upgrading the system to Windows 2000.

Preinstalled applications are “upgrade ready.” Every application that is included with a system must be capable of running after the system is upgraded to Windows 2000. To achieve this, any of the following solutions can be implemented:

Place a new Windows 2000–compatible version of the application on the hard disk, so that the user can perform an upgrade installation after migrating to Windows 2000.

Place any necessary patch files on the hard disk, so that the user can run these “fixes” after migrating to Windows 2000.

Place a migration dynamic-link library (DLL) on the hard disk, so the user can run this utility after migrating to Windows 2000. 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.

Preinstall a link to a URL for the OEM’s web site that contains the migration DLLs, patches, or replacement software that the user needs to ensure that all preinstalled applications run after migrating to Windows 2000. This web site must be available and populated with correct files when the system is shipped to the end user.



Preinstalled devices are “upgrade ready.” For any device that does not have a driver included as part of the Windows 2000 product, a signed Windows 2000 driver must be placed on the system’s hard disk before shipping the system to the user.

All features in custom utilities are available after upgrade. For all OEM-provided utilities that are preinstalled on the system, one of the following conditions must be met:

If no user functionality is lost after upgrading to Windows 2000, the utility can be removed or turned off.

This case applies when built-in Windows 2000 features such as ACPI-based power management replace functionality that the OEM provided under Windows NT 4.0 through custom utilities.

If user functionality is lost, replacement software must be provided on the hard disk, as defined earlier for preinstalled applications.

Upgrading from Windows 98 to Windows 2000These requirements apply for systems that receive the “Designed for Windows 98 and Windows 2000 Professional” logo, where Windows 98 or Windows Me is preinstalled:

Supported features are functional after upgrade. All features present on the system that are supported in Windows 2000 must be fully operational after the upgrade.

System includes Windows 2000–ready ACPI BIOS.Preinstalled applications are “upgrade ready.” All features in custom utilities are available after upgrade. These requirements are described in “Upgrading from Windows NT to Windows 2000” earlier in this section.

Preinstalled devices are “upgrade ready.” For any device that does not have a driver included as part of the Windows 2000 product, a digitally signed Windows 2000 driver must be placed on the system’s hard disk before shipping the system to the user.


15

Chapter 3 Recommendations and Future Requirements

This chapter presents specific design practices that Microsoft encourages for desktop and mobile systems to provide an optimal end-user experience.

FUTURE REQUIREMENTS: This chapter also indicates which recommended practices will become requirements under the Windows Logo Program in the future.

As a general 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.

Microsoft is coauthoring design guidelines in PC 2001 System Design Guide with Intel Corporation. Microsoft will refer to these guidelines when defining future hardware-related requirements under the Windows Logo Program. OEMs and independent hardware vendors (IHVs) are encouraged to review and submit comments on the proposed PC 2001 draft. For information and current draft availability, see http://www.pcdesguide.org/.

To provide comments to Microsoft about future Windows Logo requirements, please send e-mail to [email protected]. Please be sure to include your name, title, company name, and company type.

Note: This chapter summarizes high-level future requirements planned in relation to the next release of the Windows 2000 operating system, code-named “Whistler.” Details about new requirements for systems and devices based on new design guidelines in PC 2001 System Design Guide are summarized by system and device class categories in Appendixes A and B of this document.



Windows Logo Program Recommendations and Future RequirementsR1. System meets “legacy free” design requirements

R2. System includes bootable CD or DVD device

R3. Desktop system includes APIC bus, clocked and connected to all APICs in the system

R4. System implements S3, S4, and S5 sleep states

R5. System and component design practices follow accessibility guidelines

R6. Graphics adapter supports 3-D features for the next-generation Windows GDI

R7. Audio is “digital ready”

R8. PCI components support DAC and 64-bit guidelines

R9. Driver and application software use 64-bit compatible data types and follow guidelines for 64-bit Windows environment

R10. Soft devices meet resource usage guidelines

R11. Installed software meets guidelines for globalization

R12. Applications conform to “Application Specification for Microsoft Windows 2000 for Desktop Applications”

Recommended System CapabilitiesR1. System meets “legacy free” design requirementsWindows Logo Program requirements for legacy-free systems that run Windows Me or Windows 2000 are defined at http://www.microsoft.com/hwdev/NewPC/LF.htm.

Microsoft strongly encourages system designers to understand and implement the legacy-free design guidelines for new systems.

R2. System includes bootable CD or DVD deviceThis recommendation is to provide a bootable CD or DVD device with the system. The system BIOS requirements for booting from CD—as defined in El Torito—Bootable CD-ROM Format Specification, Version 1.0, by IBM and Phoenix Technologies—are currently part of the general system BIOS requirements for the Windows Logo program.

FUTURE REQUIREMENT: This is a requirement for legacy-free systems. Future requirements for other system types have not been defined.

R3. Desktop system includes APIC bus, clocked and connected to all APICs in the systemAll 32-bit desktop systems should include Advanced Programmable Interrupt Controller (APIC) support that complies with ACPI 1.0b, implemented by including the Multiple APIC Description Table (ACPI 1.0b, Section 5.2.8). Features such as targeted interrupts, broadcast interrupts, and prior-owner interrupts should be supported.



Implementation of APIC support on desktop systems provides resource management flexibility and a greater number of IRQ resources, even within traditional PC architectures.

FUTURE REQUIREMENT: Inclusion of an APIC in desktop systems will become a requirement for the Windows Logo Program with the release of Windows Whistler. As of July 1, 2000, all systems with APICs present must have all APICs properly clocked and wired. (See Appendix A, item A1.3.3)

Design Guidelines: Key Benefits of the I/O APIC at http://www.microsoft.com/hwdev/newpc/io-apic.htm

R4. System implements S3, S4, and S5 sleep statesAt a minimum, this should include the following, in addition to the OnNow/power management requirements already defined for the Windows Logo Program:

System supports S3, S4, and S5 sleep states

Fast power-on self test (POST) implemented

FUTURE REQUIREMENT: This will become a requirement for the Windows Logo Program for all desktop and mobile PC systems with the release of Windows “Whistler.”

Design Guidelines: PC 2001 System Design Guide, version 0.7 or later; reference SYS-0002.

Recommended End-user ExperienceR5. System and component design practices follow accessibility guidelinesAt a minimum, the manufacturer and driver writer should:

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, including Fn and similar OEM-specific 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.

FUTURE REQUIREMENT: This will become a requirement for the Windows Logo Program for all desktop and mobile PC systems with the release of Windows Whistler.



Recommended Device and Driver CapabilitiesR6. Graphics adapter supports 3-D features for the next-generation Windows GDIGDI+ is the next-generation graphics device interface (GDI). GDI+ is being implemented in the next version of Consumer Windows, which is based on Windows 2000. GDI+ creates the infrastructure for new desktop user interface innovation, permits easy integration of 2-D and 3-D, and raises the standard for desktop graphics and performance. GDI+ offers enhanced graphics capabilities, such as alpha blending, anti-aliasing, texturing, and advanced typography and imaging. GDI+ will emphasize hardware acceleration with excellent visual quality.

FUTURE REQUIREMENT: This will become a requirement for the Windows Logo Program for all desktop PC systems (not mobile PCs) with the release of Windows Whistler.

Design Guidelines: See design notes for GDI+ at http://www.microsoft.com/hwdev/video/gdinext.htm.See also 2-D and 3-D acceleration, plus video guidelines in PC 2001 System Design Guide “Graphics Adapters” chapter, version 0.7 or later:

R7. Audio is “digital ready”To be digital ready, the audio subsystem must not utilize analog mixing of audio sources for output. All audio sources should be available as digital audio streams accessible to the system-wide kernel mixer. This includes the CD/DVD drive, TV tuner, hardware synthesizer, and so on. All audio content should be available at both the analog jack and Universal Serial Bus (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.

FUTURE REQUIREMENT: This will become a requirement for the Windows Logo Program for all desktop and standard mobile PC systems with the release of Windows Whistler.

Design Guidelines: See design notes for digital audio and Human Interface Device (HID)-based audio controls at http://www.microsoft.com/hwdev/audio/; PC 2001 System Design Guide “Audio” chapter, version 0.7 or later:

R8. PCI components support DAC and 64-bit guidelinesOn systems that provide support for more than 4 GB of system memory, all 32-bit and 64-bit Peripheral Component Interconnect (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.

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

FUTURE REQUIREMENT: This is currently a server requirement. It will become a requirement for the Windows Logo Program for PCI components on 64-bit desktop systems with the release of Windows Whistler. See also related Server requirements at http://www.microsoft.com/hwdev/serverdg.htm.

Design Guidelines: http://www.microsoft.com/hwdev/pae/. See also PC 2001 System Design Guide reference: WORK-0055.

R9. Driver and application software use 64-bit compatible data types and follow guidelines for 64-bit Windows environmentThe Microsoft team creating the 64-bit version of Windows wants to make it possible for developers to use a single source-code base for their Win32- and Win64™-based applications. Microsoft has added this support by introducing new data types in the Microsoft Platform Software Developer’s Kit (SDK) at http://msdn.microsoft.com/library/psdk/buildapp/64bitwin_410z.htm.

R10. Soft devices meet resource usage guidelinesSeveral 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.

FUTURE REQUIREMENT: Windows Logo requirements and implementation dates will be announced as tests become available.

Design Guidelines: Guidelines for WDM-based Software Modems at http://www.microsoft.com/hwdev/modem/softmodem.htm; PC 99:19.26-19.31.



Guidelines are in development for soft audio and soft digital subscriber line (DSL) modems.

“Best Practices” RecommendationsR11. Installed software meets guidelines for globalizationThese 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.

R12. Applications conform to “Application Specification for Microsoft Windows 2000 for Desktop Applications”This publication is available on the web at http://msdn.microsoft.com/winlogo/. This specification was created to help software developers take advantage of new technologies in Windows 2000 that can make applications more manageable and more reliable, leading to a lower TCO.


21

Chapter 4 Getting the Windows Logo for Hardware

The complete guidelines for submitting systems for Windows Logo Program testing are defined on the web at http://www.microsoft.com/hwtest/sysdocs/. This chapter provides a brief overview.

Submitting Systems for Windows Logo Program TestingTo submit a system for Logo Program testing Follow the submission rules at http://www.microsoft.com/hwtest/systems/

Submitting Devices for Windows Logo Program TestingTo submit a system 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 SubmissionWHQL will acknowledge all Test Submissions within three days of when they receive the e-mail submission. Submission ID numbers and missing items (if any) will be listed. Note: If you send a test submission to WHQL and do not receive this confirmation e-mail, please contact [email protected] 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.

WHQL will process the test submission in the following time frame.

Full Test Programs: Allow 30 days for completion of the submission process.

Self-Test Programs: Allow 7 days for completion of the submission process.

Customers can check the WHQL Submission Status web page at http://www.microsoft.com/hwtest/status/ for submission-related information during this time.

For devices submitted for Full Test, or those submitted for Self Test that were selected to participate in the Audit program: When your device completes WHQL processing, you will receive a Test Report that includes technical feedback on any problems that were found. If your device passes WHQL testing, you may also receive the following:

A signed Windows Logo License Agreement, with a Windows Logo Kit containing the camera-ready logo artwork.

Inclusion of your product on the HCL.



Information Contacts for Windows Logo TestingThe up-to-date list of contacts is provided at http://www.microsoft.com/hwtest/support/ (including additional contacts for server-related submissions).


23

Appendix A PC System Requirement Details

This appendix presents the detailed list of requirements for desktop and mobile systems. This list encompasses current requirements plus new requirements that apply for Windows Millennium Edition or that were previously announced to take effect on July 1, 2000. The current versions of these requirements are provided on http://www.microsoft.com/winlogo/.

Note that testing for all Windows versions must also include logs for Windows 2000, even if the desired Logo artwork does not specify Windows 2000.

Requirements apply for all tested operating systems unless otherwise indicated in bold:

Windows 2000Windows MeWindows 98/Me

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

How to Use This AppendixPC System Sections and SubsectionsIn the PC System Requirement Details, each system type is identified in a separate section.

Each group of system-specific requirements is divided into these subsections:

<system>.1 = Windows Compatibility. Requirements that ensure the system will run correctly under Windows, including:

DDK references for correct driver implementation

Links to Microsoft white papers that describe implementation details for Windows compatibility

<system>.2 Industry Standards. Required industry specifications, upon which operating system support is based. These are provided as Internet links for the convenience of designers and testers.

<system>.3 Quality. Requirements for testing the system to ensure the quality of implementation under Windows.

<system>.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 PC System Design Guides that are important to the success of the Windows experience.



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

In v.1.1 of the Logo Requirements, the FAQ list incorporates all information published in the PC 9 Addendum and later FAQs for the Windows Logo Program previously published at http://www.microsoft.com/winlogo/.

After publication of v.1.1 of the Logo Requirements, each <device>.5 section on the http://www.microsoft.com/winlogo/ web site will contain additional clarifications and announcements of any new requirements.

<system>.R Future Requirements. In this version of the Logo Requirements, the Future Requirements sections include specific items from PC 2001 v.0.7 that describe the design guidelines for capabilities that will become new Logo requirements with the release of Windows Whistler.

This section also includes new quality and implementation requirements related to future versions of the Windows operating system not identified in design guides or other documents.

After publication of v.1.1 of the Logo Requirements, each <system>.R section on the http://www.microsoft.com/winlogo/ web site will contain announcements of any additional future requirements planned for Windows Whistler or later.

Tips for DDK ReferencesThe DDK references in this appendix link directly to the current online version of the Windows 2000 DDK and Windows 98 DDK. The online DDK links do not always help you to readily understand or see the material in the whole context of the DDK.We recommend that you search for the topic name cited in your local version of the DDK documentation.

Tip for "NEW" ItemsIn this appendix, the tag "NEW" appears beside any item introduced as a requirement since v. 1.0 of this document was published. Typically, this tag appears with requirements that apply for systems where Windows Me is preinstalled or with requirement that were previously scheduled to become effective July 1, 2000.

A1.0 General PC System Requirements

A1.1 Windows Compatibility1. Devices meet all Windows compatibility requirements as defined in Appendix B,

“Device Requirement Details”

Note: Non-PCI devices that receive the “Designed for Windows 2000 Server” logo can be included in a PC desktop or mobile system without restriction and without being separately tested and qualified under the requirements defined for client systems.

2. ACPI system board and Windows 2000–ready ACPI BIOS per ACPI Section 1.6



ACPI BIOS cannot be disabled by end user; the default setting is for OS Plug and Play

Power management and Plug and Play capabilities are ACPI compliant

Windows 2000: “Setup, Plug & Play, Power Management” in the Windows 2000 DDK

Windows 98/Me: “OnNow Power Management for Display Device Class Drivers” and “Device Power Management for VxDs” in the Windows 98 DDK

3. All components correctly implement Plug and Play based on the related bus specification; internal and legacy components meet requirements defined in Legacy Plug and Play Guidelines

Note: PCI components implement System Vendor IDs (SIDs) and Subsystem Vendor IDs (SVIDs) as defined in PCI v.2.2 (and in an engineering change notice (ECN) for PCI 2.1).Systems that support hot plugging for any PCI device use ACPI-based methods (PC99a:9.16; see FAQ A1.5.4, A1.5.13)

4. BIOS requirements:

Correctly configure PCI-to-PCI bridges if the system has a video graphics adapter (VGA) device behind a bridge (See FAQ A1.5.4)

Support timer at system boot; timer interrupts occur as part of POST or RESET (PC99a:3.2.1)

Support all calendar dates correctly (PC99a:3.5.4)

Support booting from CD or DVD device per El Torito v. 1.0 No Emulation mode (PC99a:3.5.2, 18.8)

Support unique PXENV system ID structure (PC99a:3.5.1)

Windows 2000: Universally unique identifier (UUID) also provided in print form (See FAQ A1.5.7)

Support boot-drive determination in multiple-drive systems per Compaq-Intel-Phoenix BIOS Boot Specification, v. 1.01, Section 5 (PC99a:3.49)

Support booting from network per Compaq-Intel-Phoenix BIOS Boot Spec, v. 1.01, App. CIf system includes network adapter, support key sequence to force network boot (PC99a:3.5.3)

Windows 2000: Support BIOS update, security such as pre-boot password, and SMBIOS 2.2 static table data (PC99a:3.5.5, 3.5.6, 3.55)

Support console redirection of serial port or Debug Port Specification (PC99a:3.5.8)

Support Int13h Extensions for correct support for high-capacity hard drives (PC99a:3.45)

Configure each PCI boot device IRQ to a PCI-based IRQ and write the IRQ into the interrupt line register 3Ch (PC99a:9.15)



Provide PCI interrupt routing information using a _PRT object per ACPI 1.0b Section 6.2.3 (PC99a:9.13)

Support logical block addressing (LBA) for ATA disks (PC99a:10.5)

Enumeration of ATA Packet Interface (ATAPI) devices complies with ATA/ATAPI-4 or SFF 8020i v.2.5; if bootable removable media is supported, comply with ARMD (PC99a:10.6, 10.11, 18.9)

NEW: For a system board that supports a riser card: Detect and enumerate that type of riser device; represent that device so that the Windows bus enumerator can detect it, and locate and install appropriate drivers (See FAQ

A1.5.3)

5. Multiprocessor system compatibility requirements:

Comply with ACPI 1.0b

Contain only one processor steppingSee Multiprocessor Systems and Windows Processor Steppings Support at http://www.microsoft.com/hwdev/desguid/SMP.htm; see also FAQ A1.5.5

PCI IRQ routing as described in PCI IRQ Routing on a Multiprocessor ACPI System at http://www.microsoft.com/hwdev/onnow/acpi-mp.htm

Wakeup solution implemented as described in FAQ A1.5.6

A1.2 Industry Standards1. Advanced Configuration and Power Interface Specification, Revision 1.0b:

http://www.teleport.com/~acpi/tech.htm (ACPI v.1.0b is available; ACPI 2.0 is under development and review)

2. Plug and Play specifications: http://www.microsoft.com/hwdev/respec/pnpspecs.htm, plus Legacy Plug and Play Guidelines: http://www.pcdesguide.org/LegacyPnP/

3. Industry bus specifications: links from http://www.microsoft.com/hwdev/specs/, plus see detailed requirements in Appendix B, “Device Requirement Details”

4. Windows Hardware Instrumentation Implementation Guidelines (WHIIG): http://www.pcdesguide.org/whiig.htm

5. Compaq-Intel-Phoenix BIOS Boot Specification, v. 1.01El Torito—Bootable CD-ROM Format Specification, v. 1.0:http://www.ptltd.com/techs/specs.html

6. PXENV in Appendix B, Network PC Design Guide, V. 1.0b: http://www.microsoft.com/hwdev/netpc.htm

7. Debug Port Specification, V. 1.0: http://www.microsoft.com/hwdev/NewPC/debugspec.htm

8. MPS 1.4 specification is obsolete. Under Windows 2000 and future operating systems, implementation must comply with ACPI 1.0b

9. System Management BIOS Reference Specification: http://www.phoenix.com/techs/specs.html



A1.3 Quality1. Product is submitted to the appropriate WHQL test program and passes

pretesting (vendor completed), vendor self-testing (if applicable), and Microsoft testing (at WHQL)

2. The ROM BIOS must make sure that the timer is on at system boot and that timer interrupts are occurring as part of POST or RESET.

3. NEW: APIC bus is clocked and connected to all APICs in the system, if present (see FAQ A1.5.2)

A1.4 Windows Experience1. Upgrade scenarios with minimal user interference: Windows 98 > Windows

2000; Windows NT 4.0 > Windows 2000, as described in Chapter 2, “PC Hardware Requirements for Windows Logo”

2. Correct implementation of power management in the system and all its components, including:

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 (PC99a:3.3-3.5; see FAQ A1.5.14)

NEW: Windows 2000/Windows Me: If system supports S3 or S4 sleep state, system ensures optimal user experience for suspend and hibernate, including correct BIOS support for the supported sleep state plus a Fast POST implementation

Support for S4 (hibernate) is required for all systems that preinstall Windows 2000 or Windows Me.

Graphics adapter and all other devices support related Device Class Power Management Reference Specifications and correctly implement D3 state such that the operating system can correctly hibernate and resume from all sleep states supported on the system

Modem, network adapter, and any other devices that support wakeup capabilities correctly support wake from D3cold

3. System contains required devices and buses:

Host controller and storage device (see FAQ A1.5.12)

Graphics adapterNote: System uses write combining with higher-performance processors (PC99a:14.3)

Keyboard and pointing device

Support for installing the operating system (see FAQ A1.5.10)

USB port (see related requirements for each system type)

Expansion slots in the system are accessible for users to insert cards (PC99a:3.6; see FAQ A1.5.8)

No ISA slots or devices (PC99a:3.28)



Industry-standard connections and icons for external keyboard, mouse, parallel and serial devices (legacy systems only)

USB standard connector and icons for all USB ports and devices

Device and bus requirements are defined in Appendix B.

4. Windows 2000: Hardware management instrumentation is provided per WHIIG specification (PC99a:3.51; see FAQ A1.5.11)

Design Guidelines: OnNow and ACPI compatibility and implementation notes:

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

PC 99 System Design Guide: Part 2

A1.5 FAQs1. Current general FAQ items are collected at

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

2. New APIC Requirement [Clarification]: If any chip set in a desktop system includes an APIC that uses the APIC bus, the APIC bus must be clocked and properly connected to all APICs in the system, including those in the processors, so that the system can be configured in either APIC mode or standard PIC mode. Both of these modes must be supported for the system to boot properly.

Chip makers implement I/O APICs in chip sets, but it is up to the system manufacturer to correctly wire the APIC to the processor. Without an I/O APIC wired in the system, any local APICs are useless—the possible additional IRQs for device interrupts are not made available to the Windows 2000 operating system.

For background information, see Key Benefits of the I/O APIC at http://www.microsoft.com/hwdev/newpc/io-apic.htmFor technical information about how to implement this requirement, see the related chip-set guide from your chip-set vendor.

This is introduced as a Logo Program requirement to better assure platform interoperation and to promote a relatively small evolutionary step to make APICs actually useful for the operating system. This requirement applies for systems submitted after July 1, 2000.FAQ date: July 8, 1999; revisions August 16, 1999 and August 26, 1999

3. Riser Cards [Logo Program Clarification]: The BIOS for a system board that supports any type of 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 as of July 1, 2000.FAQ date: December 22, 1999; revised May 9, 2000 (PC 99:3.2.3)

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.pdfSimilar provisions exist in the CNR and ACR specifications.

For information about WHQL testing for riser cards, see http://www.microsoft.com/hwtest/.See AC ‘97 and AMR Plug and Play Design.FAQ date: June 2, 1999; revised May 9, 2000

4. PCI-to-PCI bridges [Clarification]: The system BIOS must correctly configure PCI-to-PCI bridges if the system has a VGA device behind a bridge. Specifically, the BIOS must correctly set the VGA Enable and ISA Enable bits on the bridges, to avoid causing the bridges to be in conflict with each other. See http://www.microsoft.com/hwdev/pci/vgacard.htm.FAQ date: March 12, 1999 (PC99a:9.1)

5. Multiprocessor Systems Compatibility Testing [Clarification]: As of mid-1999, WHQL accepts multiprocessor submissions for Windows Logo Program and Windows 2000 compatibility testing that contain mixed processor steppings. However, the following requirements for multiprocessor systems must be followed:

Systems must use the lowest stepping processor as the bootstrap processor.

Systems must not contain processors from multiple processor manufacturers, mixed speeds, or mixed cache sizes.



Systems designed to run the Windows 2000 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.FAQ date: August 26, 1999

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 [email protected] 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 1-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

7. BIOS support for preboot execution environment, with UUID provided in print [Clarification]: The specification cited for a unique PXENV system identifier is Network PC System Design Guidelines, Version 1.0b, plus the additional information in the related FAQ at http://www.microsoft.com/hwdev/netpc.htm. This is the specification upon which the Windows 2000 implementation was based; it is not the later information defined in Wired for Management, Version 2.0 or later. As indicated in PC 99 System Design Guide, one possible implementation for remote boot is defined in Wired for Management, Version 1.1a.

Mobile Note: See FAQ A3.5 for mobile exceptions.FAQ date: March 19, 1999 (PC99a:3.5.1)

8. AGP and requirement for expansion slots to be accessible to end users [Clarification]: For designs implementing the proposed 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 (PC99a:3.6)

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. FAQ date: June 19, 2000 (PC99a:3.18)

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 (PC99a:3.50)



11. WHIIG [Clarification]: The requirements in items 3.51-3.53 will not be tested or enforced until nine months after Windows Hardware Instrumentation Implementation Guide (WHIIG) V.1.0 is published. The current version of WHIIG is available on http://www.pcdesguide.org/whiig.htm. FAQ date: October 7, 1998 (PC99a:3.51)

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

13. PCI SVID/SID on system boards [Clarification]: 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 subsystem exceptions to this requirement are certain subclasses of bridges and core chip-set components, which are specified in section 6.2.4 and Appendix D of the PCI 2.2 Local Bus Specification. The PCI 2.2 specification became the industry standard on December 18, 1998. For the convenience of the reader, the excepted sub-classes of bridges (PCI base class 6) and core chip-set components (PCI base class 8) are listed here, but for full information, the reader must refer to the PCI 2.2 specification:

Bridges (PCI base class 6)

Host bridge (Sub-class 0)

ISA bridge (Sub-class 1)

EISA bridge (Sub-class 2)

MCA bridge (Sub-class 3)

PCI-to-PCI bridge and Subtractive Decode PCI-to-PCI bridge (Sub-class 4)

Core chip-set components (PCI base class 8)

Generic 8259, ISA, EISA, and I/O APIC programmable interrupt controllers (Sub-class 0)

Generic 8237, ISA, and EISA DMA controllers (Sub-class 1)

Generic 8254, ISA, and EISA system timers (Sub-class 2)

Generic and ISA RTC controllers (Sub-class 3)FAQ date: May 28, 1999

14. Resume from Sleep State Requirements [Logo Program Change]: Resume from sleep state (S1–S3) to operating system handoff occurs within 500 ms (PC99a:3.4.2 previously stated S1-S4)

A1.R Future RequirementsAnnouncement of additional future requirements will be published at http://www.microsoft.com/winlogo/system/



1. System minimum performance requirements, based on preinstalled operating system:

Windows Whistler “consumer”: 64 MB RAM minimum, 128 KB of cache (enabled)

Windows 2000 Professional/Windows Whistler Professional: 128 MB RAM minimum, 128 KB of cache (enabled)

2. Uniprocessor desktop: S1, S3, S4, S5Desktop system supports wake from all supported sleep states (S4 and S5 not required)

3. System and component design practices follow accessibility guidelines (see Logo Chapter 4, “Recommendations and Requirements”)

4. New BIOS requirements:

For systems that include integrity or authentication services for downloaded remote boot images, support Boot Integrity Services (BIS); comply with Boot Integrity Services, Version 1.0 (PC2001:BIOS-0014.4)

Support four extended (not including root) USB hubs connected to the system (PC2001:BIOS-0005.2)

Provide remote lockout capability (PC2001:BIOS-0014.5)

Support Preboot Execution Environment (PXE) based on PXE Specification, Version 2.1 (PC2001:BIOS–0014.1)Also, BIOS supports SMBIOS 2.3 (PC2001:BIOS–0006)

Note: System UUID must be provided in print for all system types, in accordance with the Open Group’s Common Application Environment (CAE) Specification:http://www.opengroup.org/onlinepubs/9629399/toc.htm

Support for booting from the network includes F12 (or alternative) key to force a system boot (PC2001:BIOS–0014.2)

5. Multiprocessor systems support S1, S4, and S5. (PC2001:SYS-0002.1)

6. Power on to the bootstrap loader handoff occurs in 7 seconds or less for systems not using SCSI as the primary storage connection (PC2001:BIOS-0004.1)

7. Power/sleep button requirements:

If a single-button design is used, it must be the user’s primary switch interface and must be a power button as defined by 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. (PC2001:SYS-0003.3)

8. System provides video playback capabilities (related requirements are defined in Appendix B, “Device Requirement Details”

9. Peripherals (other than keyboards and mice) included with the system offer a non-legacy interface such as PCI, USB, SCSI, IEEE 1394, or CardBus (PC2001:SYS–0042)



10. System is capable of recovery and upgrade of the hard drive image and BIOS independent of an Floppy disk controller (FDC)-based floppy disk drive (PC2001:SYS–0067)

11. Interrupt handlers preserve values in all registers.

ROM BIOS hardware interrupt handlers and SMI handlers must preserve the values in all registers, including the high 16 bits of 32-bit registers. ROM BIOS 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, because this is least likely to cause 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: CARRY, AUX-CARRY, PARITY, ZERO, SIGN, and OVERFLOW. The values of the other bits in the flags register must be preserved unless the API is documented to modify them.

A2.0 Desktop Client RequirementsThis section describes additional requirements or exceptions to the requirements defined earlier in Section A1.0.

A2.1 Windows CompatibilitySee A1.1

A2.2 Industry Standards1. USB specifications, and other USB requirements as defined in Section B2.6 in

Appendix B, “Device Requirement Details”

A2.3 Quality1. BIOS correctly supports input and boot devices on system boot

See FAQ A2.5.2

2. NEW: BIOS correctly handles long descriptors read from any USB device attached to the PC at boot timeSee FAQ A2.5.2

A2.4 Windows Experience1. Two USB ports, with system BIOS boot support for USB input devices (four

ports for legacy-free systems)

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



Design Guidelines: PC 99 System Design Guide: Chapter 3



2. BIOS support for USB [Logo Program correction]: As defined for the current Logo requirements, USB host controller and USB input device support must be enabled by default in the BIOS, and the BIOS must ensure that USB input devices, such as keyboards and mice, are available at boot time. This includes implementing all related support defined in USB Device Class Definition for Human Interface Devices, Version 1.1 (HID 1.1), with particular attention to the Keyboard Boot Protocol.

In addition, the BIOS must correctly handle long descriptors read from any USB device attached to the PC at boot time. For USB keyboards and mice connected through hubs, the BIOS must also be able to enumerate the devices across the USB topology. This additional requirement for USB support in the BIOS is of Windows Logo Program compliance testing for all desktop systems as of July 1, 2000, and applies now for all legacy-free systems submitted for testing.FAQ date: December 22, 1999 (PC99:3.5.7; 7.2)


1. Desktop system includes APIC, 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(PC2001:SYS-0001.3)

2. If IEEE 1394 is included in a system, at least two externally-accessible sockets are required (PC2001:SYS-0022)

3. Expansion devices on desktop systems can be remotely managed (PC2001:SYS–

0049)

4. Desktop system includes CD or DVD device (PC2001:SYS–0039)

5. Four USB ports in all systems (PC2001:SYS–0021)

A3.0 Mobile Client RequirementsThis section describes additional requirements or exceptions to the requirements defined earlier in Section A1.0.



A3.1 Windows Compatibility1. ACPI-compliant support for mobile PC docking station interface and state

change notification, including fail-safe docking based on capabilities and methods in ACPI Sections 6.3 and 5.6.4

2. Windows 2000: Windows 2000 Support for Mobile System Displays: http://www.microsoft.com/hwdev/video/mobiledisplay.htm

A3.2 Industry Standards1. Smart Battery Specifications: http://www.sbs-forum.org(PC99a:6.2)

2. ACPI Docking for Windows 2000: http://www.microsoft.com/hwdev/onnow/ACPIdock.htm

3. ICC Profile Format Specification, Spec ICC.1:1988-09 and Addendum 2, ICC.1A:1999-04: http://www.color.org/profiles.html

A3.3 QualitySee A1.3

A3.4 Windows Experience1. Power and power management requirements:

Every device in a mobile PC system functions fully on both AC and DC power (See FAQ A3.5.8)

Smart Battery or ACPI Control Method Battery (PC99a:6.2; see FAQ A3.5.8.5)

2. BIOS requirements:

Support for external pointing device (See FAQ A3.5.3)

Support PXENV if system includes integrated network adapter (See FAQ

A3.5.7)

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) (PC99a:6.4)

4. Mobile system contains required devices and buses:

Integrated keyboard and pointing devices use standard system-board devices; add-on devices meet Windows Logo requirements (PC99a:6.9)

External mouse support provided using a connector other than a serial port

One USB port (PC99a:6.5, 6.6)

One 32-bit Type-2 CardBus slot (PC99a:6.8)

System maintains mapping of IRQ Routing Register bits to system interrupt vectors for CardBus (PC99a:12.4)

IRQ connections for CardBus can be determined by using the 0805 register (PC99a:12.5)

Integrated graphics device minimum requirements:



2-D hardware acceleration, 800 × 600, low resolution modes (PC99a:6.18)

If 3-D is supported, 640 × 460 × 16 bpp; no minimum texture cache, alpha blending, hardware text mapping requirements (PC99a:6.19)

No multiple adapter support required in mobile unit; multiple monitor support is optional (PC99a:6.20; see FAQ A3.5.4)

Display data channel (DDC) monitor detection required only for external graphics interface (PC99a:6.21)

AGP 1.0, with minimum speed of 1x; GART is not required (PC99a:6.23)

International Color Consortium (ICC) color profile and INF preinstalled if DDC detection cannot be used (PC99a:6.25)

5. ATA controllers and devices on mobile unit support Ultra DMA 33 or better (See FAQ A3.5.10)

6. CD drive, if present, supports transfer rate of at least 600 KB per second when fully on

7. Docking station requirements:

Docked mobile PC supports state change notification using ACPI; interface is supported using ACPI-defined mechanisms; combination supports automatic resource assignment and dynamic disable capabilities (PC99a:6.27,

6.30-32, 6.33)

Docked mobile PC can uniquely identify the dock (PC99a:6.28, 6.29)

Docking station supports warm docking and fail-safe docking (PC99a:6.34, 6.35)

See also FAQ A3.5.6, A3.5.9

8. Mini-dock requirements:

Mini-dock supports automatic resource assignment and dynamic disable capabilities for replacement devices (PC99a:6.38)

Mini-dock supports warm docking and fail-safe docking (PC99a:6.39, 6.40)

See also FAQ A3.5.6, A3.5.9




2. Manageability requirements [Clarification]: SMBIOS 2.2 and remote management of expansion devices are not required.FAQ Date: May 4, 2000

3. BIOS support of external pointing device [Clarification]: 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 (PC99a:6.9)

4. DDC monitor detection [Clarification]: Because of the power limitations placed on mobile computers, they are not required to supply + 5 V 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 (PC99a:6.21)

5. ICC profile for mobile PCs [Clarification]: Because most Mobile PCs do not support Plug and Play for their installed liquid crystal display (LCD) panels, the ICC profile must be installed manually 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. FAQ date: March 19, 1999 (PC99a:16.2)

6. Port replicator and mini-dock definitions [Clarification]:

Port Replicator: A port replicator is a module that manages external cable connections. It adds no new features, functionality, or devices. All cable connector receptacles on a port replicator are simple extensions of the wiring for connector receptacles on the back panel of the mobile PC platform. An event notification message should be sent and properly handled when the mobile unit is attached to or detached from the port replicator. The module should have mechanisms to determine attach or detach events that do not require active electronics in the port replicator. For example, a switch in the mobile unit might be activated when the port replicator is mated.

Mini-Dock: A mini-dock can perform the same functions as a port replicator, with one additional feature: A mini-dock incorporates some form of active electronics to create extended mobile PC platform features and functions. The added active electronics might provide additional user-accessible PC Card slots, communication receptacles, or both. These slots and receptacles might be RS-232, IEEE 1284, IEEE 1394, and so on. The mini-dock does not provide user-accessible expansion slots other than CardBus slots, but it might provide internal expansion capabilities accessible only to the OEM.

A mini-dock does not have internal user-upgradeable capabilities for adding desktop peripherals or I/O expansion cards. Therefore, a mini-dock can be considered a sealed docking station, where all expansion capabilities are provided using external expansion ports so that the operating system always knows what to expect about available devices. However, being sealed does not preclude designs that include internal components that the OEM or trained service personnel can upgrade. When such upgrades are done, the mini-dock must employ mechanisms that result in the operating system



establishing a new configuration for the mini-dock.FAQ date: May 28, 1999

7. BIOS support for PXENV [Clarification]: Only mobile PCs that ship with an integrated network adapter are required to provide the unique system ID in printed form. The initial use of the unique system ID will be for creating a Machine Account Object for the remote installation service. Currently, no Microsoft operating system supports remote installation using a PC Card network adapter. FAQ date: November 15, 1998 (PC99a:3.5.1)

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

8.5 Proposed Compatibility Testing for ACPI Control Method Batteries: Battery Remaining Capacity shall be measured by:

Battery preconditioned by fully charging and discharging 3 times. Start with a fully charged battery.

Read the control method battery's Design Capacity.

Read the control method battery's Battery Remaining Capacity.

Discharge the battery using a constant power load set to the battery's Design Capacity / 2 until the Battery Remaining Capacity reaches the Design Capacity of Low alarm value. Continue discharging the battery until it is exhausted.

The total delivered energy must be greater than or equal to the Battery Remaining Capacity reported at the beginning of the test. Additionally, the energy the battery delivers after it reaches the Design Capacity of Low value must be greater than or equal to the Design Capacity of Low value.

Batteries must accurately report the Battery Present Rate. They must report in data that is not stale. Accuracy and data timeliness shall be measured by:

The reported Battery Present Rate value shall be within +/-3 percent of the measured rate.

Battery Present Rate shall return values that have been measured within 5 seconds of the request.FAQ date: November 27, 1998 (PC99a:6.2)



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.

The objective of this requirement is 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 automatically selected, 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 (PC99a:6.38)

10. Ultra DMA supports [Clarification]: Ultra DMA support for ATA controllers is only recommended for controllers in docking stations, because of a lack of controllers that support Ultra DMA and provide fully-relocatable resources. Under Windows 2000, controllers that do not have fully-relocatable resources will not function in a docking station. Controllers in mobile PC units are required to support Ultra DMA.FAQ date: January 11, 1999 (PC99a:18.6)


1. Mobile system implements either S1 or S3, S4, and S5 sleep states (no “wake from S3 or S4” requirement) (PC2001:SYS-0002.1)

2. Battery systems that support battery calibration must use the Smart Battery System Manager optional calibrate support bits in the BatterySystemStateCont register (PC2001:MOBL–0062.1)

3. Docked mobile PC requirements:

Meet the PC 2001 BIOS requirement for multiple adapters and multiple monitors (PC2001:MOBL–0076)

Enumerate, configure, and disable non–Plug and Play devices using ACPI-based methods (PC2001:MOBL–0078)

4. Mobile unit’s BIOS contains at least these docking-related ACPI functions:

DCK_CAP=1 in FACP table.

_Lxx methods handle dock insertion event and Fail Safe Ejection notification. _Lxx method includes a Notify to the dock object.



ACPI descriptions for ports located on the mobile PC and passed through the docking connector include an _EJD method.

_WAK method performs a Notify to the dock object.

A dock object must be specified and must include a device named to represent the docking station, including:

UID method for presenting the dock’s model number and unique ID to Windows.

_DCK method connecting and disconnecting the docking bus.

_STA method for checking the status of the dock.

_Ejx methods to identify the sleep states in which docking can occur. If hot docking is implemented, the _EJ0 control method must not return until the ejection is complete per ACPI 1.0b section 6.3.2.(PC2001:MOBL-0078)

5. If IEEE 1394 is included in a system, at least one externally-accessible socket is required (PC2001:SYS-0022)

A4.0 Legacy-Free System RequirementsThis section describes additional requirements or exceptions to the requirements defined earlier in Section A1.0.

A4.1 Windows Compatibility1. ACPI legacy-free support is reported as described in “ACPI Changes for Legacy

Free” at http://www.microsoft.com/hwdev/onnow/download/LFreeACPI.doc, including:

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

2. Plug and Play detection does not report the presence of Super I/O–dependent components (based on addresses and exceptions listed in the following requirement)

3. No components claim to use the restricted port 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 Infrared Data Association (IrDA) support through 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.

NEW: Systems that do not have an 8042 controller must reserve I/O addresses 0060 and 0064 as reserved motherboard resources. Failure to reserve these I/O addressed will result in display of a false device in Device Manager under Windows Me.

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

5. Legacy-free debug interface per Debug Port Specification.

6. A20M# is always de-asserted (pulled high) or removed, with no way to mask the A20 address line.

If A20M# generation logic is still present in the system, this logic must be terminated such that software writes do not result in A20M# being asserted to the processor.

7. Interrupt handlers preserve values in all registers, as described in A1.R.11

8. NEW: 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 NT, and 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 Industry Standards1. “ACPI Changes for Legacy-Free PCs” at

http://www.microsoft.com/hwdev/onnow/download/LFreeACPI.doc

2. Debug Port Specification, V. 1.0 or later: http://www.microsoft.com/hwdev/NewPC/debugspec.htm

A4.3 Quality1. No BIOS boot dependencies on ISA or other legacy devices, and no ISA-related

components appear on BIOS setup screen

2. 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, version 0.7 or later

A4.4 Windows Experience1. 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

2. Two USB ports free for end-user expansion—that is, not used by components bundled with the system

Mobile Note: A mobile PC can provide one free USB port.

3. Desktop system includes a bootable CD or DVD device

4. No FDC detected

5. System recovery media and BIOS updates are provided on bootable CD or DVD media or means other than floppy disks; BIOS updates do not require booting from a floppy disk if a floppy disk isn’t included with the system

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

7. External USB input devices included with the system are HID compliant

8. MS-DOS is not be required to install or run any utilities, games, or other software provided with the system (with the exception of software on the recovery CD provided for Windows Me)

Mobile Note: New docking stations designed for legacy-free mobile PCs must follow these requirements

Design Guidelines: http://www.microsoft.com/hwdev/NewPC/LF.htm. See also PC 2001 System Design Guide, version 0.7 or later.





2. Early legacy-free systems [Clarification]: Early legacy-free systems may have obvious components removed from the user’s perspective—for example, slots, ports, and so on. However, these systems might retain internal remnants of some components until the available silicon solutions mature and the adoption of legacy-free design becomes more prevalent. Therefore, for purposes of the Windows Logo Program, a requirement such as “No FDC” means that the operating system does not detect the presence of the FDC and nothing uses the related restricted addresses.

Mobile Note: For legacy-free mobile PCs, form-factor/size issues may preclude providing a built-in CD or DVD drive; in such cases, this requirement will 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.

Also, 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.R Future RequirementsNo future legacy-free requirements are identified at this time. Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/system/


45

Appendix B Device Requirement Details

This appendix presents the detailed list of requirements for the Windows Logo Program requirement WL#4: “All components and devices meet Windows compatibility and quality design guidelines” for desktop and mobile client PCs.

This list encompasses current requirements plus new requirements that apply for Windows Millennium Edition or that were previously announced to take effect on July 1, 2000. The current versions of these requirements are provided on http://www.microsoft.com/winlogo/.

Note that testing for all Windows versions must also include logs for Windows 2000, even if the desired Windows Logo does not target Windows 2000. Requirements apply for all tested operating systems unless otherwise indicated in bold:

Windows 2000Windows MeWindows 98/Me

How to Use This AppendixDevice Class Sections and SubsectionsIn the Device Requirement Details for desktop and mobile client PCs, each device class is identified in a separate section. These section numbers do not necessarily correlate directly with WHQL test categories and are not related to how the device attaches itself to the computer.

Each group of device class-specific requirements are divided into these subsections:

<device>.1 = Windows Compatibility. Requirements that ensure the 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

<device>.2 Industry Standards. Required industry specifications, upon which operating system support is based. These are provided as Internet links for the convenience of designers and testers.

<device>.3 Quality. Requirements for testing device and driver—including requirements such as testing Windows 2000 drivers with Driver Verifier—to ensure the quality of implementation under Windows.

<device>.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 PC and Server Design Guides that are important to the success of the Windows experience.

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



In v.1.1 of the Logo Requirements, the FAQ list incorporates all information published in the PC 99 Addendum, Server Design Guide v.2.0 FAQ, and later FAQs for the Windows Logo Program previously published on the http://www.microsoft.com/winlogo/ web site.

After publication of v.1.1 of the Logo Requirements, each <device>.5 section on the http://www.microsoft.com/winlogo/ web site will contain additional clarifications and announcement of any new requirements.

<device>.R Future Requirements. In this version of the Logo Requirements, the Future Requirements sections include specific items from PC 2001 v.0.7 that describe the design guidelines for capabilities that will become new Logo requirements with the release of Windows Whistler.

This section also includes new driver quality and implementation requirements related to future versions of the Windows operating system not identified in design guides or other documents.

After publication of v.1.1 of the Logo Requirements, each <device>.R section on the http://www.microsoft.com/winlogo/ web site will contain announcements of any additional future requirements planned for Windows Whistler or later.

Tips for DDK ReferencesThe DDK references in this appendix link directly to the current online version of the Windows 2000 DDK and Windows 98 DDK. The online DDK links do not always help you to readily understand or see the material in the whole context of the DDK.We recommend that you search for the topic name cited in your local version of the DDK documentation.

Tip for "NEW" ItemsIn this appendix, the tag "NEW" appears beside any item introduced as a requirement since v. 1.0 of this document was published. Typically, this tag appears with requirements that apply for systems where Windows Me is preinstalled or with requirement that were previously scheduled to become effective July 1, 2000.

B1.0 General Device and Driver QualityAll devices must comply with these general device and driver compatibility and quality requirements.

B1.1 Windows Compatibility1. Device drivers comply with DDK requirements for its operating system:

Windows 2000 DDK and Windows 98/Me DDK: download the DDK at http://www.microsoft.com/ddk/Third-party applications comply with Microsoft Platform SDK requirements

2. OnNow and ACPI compatibility and implementation notes: http://www.microsoft.com/hwdev/onnow/

3. WDM driver implementation notes (for device classes supported under WDM): http://www.microsoft.com/hwdev/wdm/



B1.2 Industry Standards1. Advanced Configuration and Power Interface Specification:

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

2. Device Class Power Management Reference Specifications: http://www.microsoft.com/hwdev/specs/Pmref/

3. Plug and Play specifications: http://www.microsoft.com/hwdev/respec/pnpspecs.htm Legacy Plug and Play Guidelines http://www.pcdesguide.org/LegacyPnP/ (PC99a:3.12)

4. Each device or connection meets requirements for its bus class (see B2.0) (PC99a:3.11)

B1.3 Quality1. Product is submitted to the appropriate WHQL test program and passes pre-

testing (vendor completed), vendor self-testing (if applicable), and Microsoft testing (at WHQL):

Enumeration, bus tests, Disabler.exe, and so on

2. Windows 2000: Vendor-supplied drivers pass Driver Verifier test

3. Device driver installs via an INF; tested via INFCatReady.exeWindows 2000: ”Creating an INF File”;Windows 98/Me: “Installers, Device Manager, and Control Panel”

4. Drivers submitted for testing meet the guidelines for driver signing as defined at http://www.microsoft.com/hwdev/desinit/digitsign.htm

B1.4 Windows Experience1. Device ID is present, device is properly enumerated, and correct driver is found;

device can be disabled automatically by Windows (PC99a:3.13; 3.17.2, and per-device

references)

2. Driver or software installation does not replace any Microsoft-authored system components, and the driver does not bypass any operating system components (PC99a:3.16.1)

If the manufacturer’s INF copies any files supplied by the operating system, those files are copied from the Windows product disk, unless the component is a licensed, redistributable component.Driver must not use initialization files (INI) for configuration settings (PC99a:3.16.4)

3. Installing and loading the driver does not reduce or eliminate functionality of other devices installed on the system (PC99a:3.16.1)

4. Device is immediately functional without restarting the system; device installation does not cause the system to stop running or reboots

5. Device and driver comply with ACPI specification, Default Device Class Power Management Reference Spec, and other relevant device class power management specification (PC99a:3.2 and per-device references)



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

Modem, network adapter, and any other devices that support wakeup capabilities correctly support wake from D3cold

6. Driver supports unattended installation (PC99a:3.16.7)

7. Windows Help file is provided if special driver parameters are used (PC99a:3.16.8)

8. Hardware management instrumentation, if implemented, is provided per WHIIG (http://www.pcdesguide.org/whiig.htm) (PC99a:3.51)

9. Device has an icon on connectors Color coding is not required

10. Any supporting software included with the device must install without any manual steps or file editing using Windows-based installation methods.All supporting software must be 32-bit Windows applications; no (16-bit or 32-bit) console applications are allowed. (See FAQ B1.5.2)

11. Device driver and related software are removable using Windows-based software (PC99a:3.16.5)

At a minimum, any "virtual drivers" and software components installed with the driver must be capable of being removed.

Design Guidelines:

PC 99 System Design Guide: PC99a:3.16, 3.17

Server Design Guide 2: Chapter 2 and FAQ

B1.5 FAQs1. Current general FAQ items are collected at


2. 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 the Windows 95/98 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 Future Requirements1. Announcement of additional future requirements will be published at


2. NEW: For Windows Whistler, systems will be 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.

B2.0 Bus/Device Controllers

B2.1 CardBus/PCMCIA Controllers and DevicesAll general requirements in B1.0 are included by reference.

B2.1.1 Windows Compatibility1. Windows 2000: “Part 7: PCMCIA Drivers” in the “Kernel-Mode Drivers

Design Guide” in the Windows 2000 DDK

2. Windows 98/Me: “PCMCIA Device Drivers” in “Windows 95 Programmers Guide” in the Windows 98 DDK

3. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/cardbus/

4. CardBus Host Controllers and Windows Compatibility: http://www.microsoft.com/hwdev/busbios/CARDBUS1.HTM

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)

6. Windows 2000: Legacy PCI Interrupt Routing and CardBus in Windows 2000: http://www.microsoft.com/hwdev/cardbus/Spir.htm

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 Industry Standards1. PC Card Controller Device Class Power Management Reference Specification,

V. 1.0: http://www.microsoft.com/HWDev/specs/PMref/PMcard.htm (PC99a:12.17)

2. PC Card Standard Guidelines: http://www.pc-card.com/bookstore.htm (PC99a:12.1,

12.14)

3. PCI Bus Power Management Interface Specification for PCI to CardBus Bridge, Revision 1.0: http://www.pcisig.com/specs.html (PC99a:12.19)

4. PCI to PCMCIA CardBus Bridge Register Description: http://www.pc-card.com/bookstore.htm



B2.1.3 Quality1. Pass WHQL tests: Pcmcia.exe, Refresh.exe, Whqltest.vxd, plus relevant device

class tests for devices

B2.1.4 Windows Experience1. Controller complies with industry standards and Windows-compatible

configuration:

Exchangeable Card Architecture register set (PC99a:12.3)

CardBus bridges (PC99a:12.7)

ISA and PCI interrupts (PC99a:12.6; see FAQ B2.1.5.2)

Writable PCI Configuration Space bits are not shared (PC99a:12.9)

Each 16-bit PC Card memory window has it own page register (PC99a:12.10)

2. CardBus cards are configured correctly (PC99a:12.14-16)

3. 16-bit PC Cards are configured correctly (PC99a:12.11-13, 12.18)

Driver supports sharing of level-mode interrupts (PC99a:12.23)

4. No user intervention and no system restart when installing devices (PC99a:12.20,

12.21)

5. ZV-compatible 16-bit PC Cards comply with ZV standard definitions, and driver uses Microsoft DirectDraw® video port extensions (PC99a:12.2, 12.22)


B2.1.5 FAQs1. Current PC Card/CardBus FAQ items are collected at

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

2. CardBus controllers support ISA and PCI interrupts [clarification]: 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), 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 irrelevant 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 (PC99a:12.6)

3. Windows 2000 CardBus controllers and PCI bus power management: 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 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 2000.FAQ date: October 7, 1998 (PC99a:12:19)

B2.1.R Future RequirementsNo additional requirements are identified at this time. Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/cardbus/

B2.2 IEEE 1394 Controllers and DevicesAll general requirements in B1.0 are included by reference.

B2.2.1 Windows Compatibility1. WDM support for devices that use the IEEE 1394 bus: “IEEE 1394 Drivers” in

the Windows 2000 DDK

2. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/1394/

3. Plug and Play Specification for IEEE 1394: http://www.microsoft.com/hwdev/respec/pnpspecs.htm#1394 (PC99a:8.9)

4. IEEE 1394 Support in Windows 98 and Windows 2000: http://www.microsoft.com/hwdev/busbios/1394support.htm

B2.2.2 Industry Standards1. 1394 Open Host Controller Interface Specification, Revision 1.0:

ftp://ftp.austin.ibm.com/pub/chrptech/1394ohci/ohcir100.pdf (PC99a:8.2)

OHCI 1.1 is recommended: http://www.microsoft.com/hwdev/1394/

2. 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/ (PC99a:8.37)

See FAQ B2.2.5.1

3. IEEE 1394 Standards: (PC99a:8.1, 8.3)

IEEE 1394-1995 or later standards, and IEEE 1394a

IEEE 1212-1991 and function discovery in IEEE 1212rGlobal Engineering Documents

4. IEEE 1394 devices must comply with appropriate industry-recognized transport and command standards: (PC99a:8.6)

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

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.htmFAQ date: March 19, 1999 (PC99a:8.6, 8.19)

B2.2.3 Quality1. Pass WHQL tests: Enable/Disable, 1394 Asynchronous & Isochronous Tests,

and Manual Interoperability

B2.2.4 Windows Experience 1. Open Host Controller Interface (OHCI) controllers and devices support advances

defined in IEEE 1394a-1999, including peak data rate requirements (PC99a:8.3-8.4,

8.7)

2. Correctly implemented device configuration ROM (PC99a:8.13-8.20)

3. Devices demonstrate interoperability with other devices (PC99a:8.9)

4. Devices that initiate peer-to-peer communications support remote programming (PC99a:8.12)

5. Devices use approved IEEE 1394 connectors and cables (PC99a:8.24, 8.26)

6. Self-powered devices propagate the power bus through each connector (PC99a:8.25)

7. Vendor and model leafs support textual descriptor leaf format (PC99a:8.21)

8. Only single-port leaf-node devices use 4-pin connectors (PC99a:8.26)

9. IEEE 1394-enabled PC provides cable power source compliant with IEEE 1394a-1999 (PC99a:8.34) See FAQ B2.2.5.2


B2.2.5 FAQs1. Current IEEE 1394 FAQ items are collected at

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

2. Power management requirements [Logo clarification]: Devices and controllers are not required to comply with 1394 Trade Association Power Specification, Part 3: Power State Management. This standard version will be required with the release of Windows Whistler.FAQ date: May 28, 1999 (PC99a:8.34)



3. Non-requirements [Logo clarification]: The following PC 99 guidelines are not Windows Logo Program requirements: PC99a:8.30, 35, 36, 38Devices should meet appropriate local regulatory approval (for example, UL, CSA, and so on), rather than following PC 99 guidelines.FAQ Date: May 28, 1999

B2.2.R Future RequirementsAnnouncement of additional future requirements will be published at http://www.microsoft.com/winlogo/1394/

New requirements for the Windows Logo Program, expected to take effect with the release of Windows Whistler:

1. OHCI 1.1 is required (PC2001:1394–0091)

2. The host controller’s PHY must support data rates of S100 Mb/s, S200 Mb/s and S400 Mb/s as specified in IEEE 1394-1995 and IEEE 1394a-2000 (PC2001:1394–

0092)

3. Support remote programming through a remote control interface (PC2001:1394–

0097)

4. A system that implements externally accessible sockets must provide a method for connecting to devices that only support IEEE 1394-1995 or its supplement, IEEE 1394a-2000; there must not be a mixture of IEEE 1394–like media socket types on the back panel (PC2001:1394–0093)

5. Descriptors are required for Vendor_ID and Model_ID entries in the Configuration Status Register (CSR) space (PC2001:1394–0101)

B2.3 Infrared/WirelessAll general requirements in B1.0 are included by reference.

B2.3.1 Windows Compatibility1. Windows 2000, Windows 98/Me: “Chapter 13 IrDA Miniport NIC Drivers” in

the Windows 2000 DDK (PC99a:13.27)

2. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/infrared/

3. Windows 2000: IrDA Plug and Play Issues and Windows 2000: http://www.microsoft.com/hwdev/infrared/IrDAPnP.htm

4. Windows 2000: IrTran-P, IrLPT, and IrDA Networking Support under Windows 2000: http://www.microsoft.com/hwdev/infrared/IrCOMM.htm

B2.3.2 Industry Standards1. IrDA documents at http://www.irda.org/: Serial Infrared Physical Layer

Specification; Control IR Specification (PC99a:13.28)



B2.3.3 Quality1. Pass WHQL tests: IrDA enumeration (PC99a:13.29, 13.30)

B2.3.4 Windows Experience1. Infrared (IR) device meets USB guidelines for interfacing with IrDA Data and

IrDA Control devices (PC99a:13.31)

2. System supports standard input speeds of 4 Mb/s (PC99a:13.32)

3. System provides a separate, physically-isolated transceiver for each IR protocol supported (PC99a:13.33)


B2.3.5 FAQs1. Current IR/wireless FAQ items are collected at

http://www.microsoft.com/winlogo/input/

B2.3.R Future RequirementsAnnouncement of additional future requirements will be published at http://www.microsoft.com/winlogo/wireless/


1. Mobile PC IR devices support D0 and D3 stated as defined in Section 3.4 of ACPI 1.0b (PC2001:MOBL–0152)

2. Bluetooth wireless host controllers (radios with HCI) will have the following requirements:

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

3. Bluetooth-connected PC peripherals will have the following requirements:

Meet all device class-specific Logo requirements (for example, B3.0 for audio, B5.1 for HID, B6.1 for modem, and so on)

Comply with all applicable Bluetooth-specific specifications, including usage profiles

Support Bluetooth Simple Discovery Protocol (SDP) and the PnPInformation Service Class

B2.4 Parallel/Serial DevicesAll general requirements in B1.0 are included by reference.



B2.4.1 Windows Compatibility1. Windows 2000: “Serial and Parallel Drivers” in the Windows 2000 DDK

2. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/comm/

3. Windows 2000: Enumerating Serial Devices in Windows 2000: http://www.microsoft.com/hwdev/desinit/serddvr.htm

4. Windows 98/Me: VCOMM Port Driver Power Management Interface: http://www.microsoft.com/hwdev/devdes/vcomm.htm

B2.4.2 Industry Standards1. Standard Signaling Method for a Bi-directional Parallel Peripheral Interface for

Personal Computers (IEEE 1284 specification): Global Engineering Documents

B2.4.3 Quality1. Pass WHQL tests: COM PnP Enum, LPT PnP Enum

B2.4.4 Windows Experience1. Plug and Play capabilities and operating system compatibility implemented as

defined in Legacy Plug and Play Guidelines (http://www.pcdesguide.org/LegacyPnP/)

Note: The following summarizes these legacy requirements. Future versions of these Logo requirements will refer only to Legacy Plug and Play Guidelines.

Serial port meets device class specifications for its bus (PC99a:13.9)

Legacy serial port is implemented as 16550A UART or equivalent and supports 115.2K baud (PC99a:13.10)

Legacy serial port supports dynamic resource configuration (PC99a:13.11)

Conflict resolution for legacy serial port ensures availability of at least one serial port (PC99a:13.12)

Parallel port meets device class specifications for its bus (PC99a:13.13)

Flexible resource configuration supported for each parallel port (PC99a:13.14)

EPP support does not use restricted I/O addresses (PC99a:13.15)

Compatibility, nibble mode, and extended capabilities port (ECP) protocols meet IEEE 1284-1994 specifications (PC99a:13.16)

Port connectors meet IEEE 1284-I specifications, at minimum (PC99a:13.17)

IEEE 1284 peripherals have Plug and Play device IDs (PC99a:13.18)

Device identification string provides a Compatible ID key (PC99a:13.19)

Daisy-chained parallel port device is Plug and Play capable (PC99a:13.20)




B2.4.5 FAQs1. Current legacy ports FAQ items are collected at


B2.4.R Future RequirementsNo new requirements are planned at this time. Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/input/

B2.5 PCI Controllers and DevicesAll general requirements in B1.0 are included by reference.

B2.5.1 Windows Compatibility1. Driver support: device class support in related DDKs; bus driver support is built

in

2. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/pci/

3. PCI Device Subsystem IDs and Windows: http://www.microsoft.com/hwdev/devdes/pciids.htm

4. Compatibility Testing for Hot-Plugging Support for PCI Devices: http://www.microsoft.com/hwdev/pci/hotplugtest.htm

5. PCI Subsystem IDs and PCI-to-PCI Bridge Devices: http://www.microsoft.com/hwdev/pci/pcibridge.htm

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

B2.5.2 Industry Standards1. PCI Bus Power Management Interface Specification, Revision 1.1 and later

(PC99a:9.17; see FAQ B2.5.5.5)

2. PCI Bus Power Management Interface Specification for PCI to CardBus Bridge, Revision 1.0

3. PCI Local Bus Specification, Revision 2.1 (PCI 2.1) or later, plus all ECNs approved by July 1, 1998, including Maximum Completion Time ECN and Subsystem ID ECN (PC99a:9.1, 9.6)

Note: PCI 2.2 is the current version, approved December 18, 1998

4. PCI to PCI Bridge Specification, Revision 1.0

5. PCI-X Specification, Revision 1.0: http://www.pcisig.com/data/news/1999/pci-x_v10.pdf

6. Mini PCI specification

B2.5.3 Quality1. Pass WHQL tests: PCItest.exe; INFCatReady



2. Correct PCI implementations:

System does not contain ghost devices (PC99a:9.2)

System uses standard method to close base address register (BAR) windows on nonsubtractive decode PCI bridges (PC99a:9.3)

Bus master privileges are supported for all connectors (PC99a:9.7)

Functions in a multifunction PCI device do not share writable PCI Configuration Space bit (PC99a:9.8)

PCI devices complete memory write transaction within specified times (PC99a:9.9)

Configuration Space is correctly populated (PC99a:9.12)

Interrupt routing is supported using ACPI (PC99a:9.13)

Adapters address full physical address space on a 64-bit platform (see FAQ

B2.5.5.2)

B2.5.4 Windows Experience1. Power management supported as defined in PCI Power Management 1.0:

System provides 3.3 V to all PCI connectors (PC99a:9.4);

System supports 3.3 Vaux if a system supports S3 or S4 states (PC99a:9.18; see

FAQ B2.5.5.5 and B2.5.5.6)

Bus power states are correctly implemented (PC99a:9.19)

Local area network (LAN) and modem devices support wake-up per PCI Power Management 1.1 (PC99a:9.20)

See FAQs in B2.5.5; see also “PCI Power Management and Device Drivers”: http://www.microsoft.com/hwdev/desinit/pcipm.htm

2. PCI add-on devices support both 5 V and 3.3 V signaling (PC99a:9.5)

3. Mini PCI devices support PCI 2.2, PCI-PM v. 1.1, and Mini PCI specifications, and all other Logo requirements for PCI devices

4. Hot-Plug PCI supported via ACPI: “Compatibility Testing for Hot-Plugging Support for PCI Devices” at http://www.microsoft.com/hwdev/pci/hotplugtest.htm; see also Hot-Plug PCI and Windows 2000: http://www.microsoft.com/hwdev/pci/hotplugpci.htm (PC99a:9.16)


B2.5.5 FAQs1. Current PCI-related FAQ items are collected at

http://www.microsoft.com/winlogo/PCI/

2. DAC requirement [Clarification]: On 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 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.

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.htmFAQ date: November 27, 1998; revised May 4, 2000

3. AMR/MR PCI IDs [Clarification] AMR devices and MR devices on the system board are not exempt from the requirement for SID and SVID.May 28, 1999 (PC99a:9.11)

4. Control Method for PCI IDs [Logo Program Clarification]: The 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. So _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 (PC99a:9.11)

5. PCI-PM 1.1 and PME# [Logo Program Clarification]:

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 2000, which uses PME# as the wake-up signal. The changes between PCI-PM 1.0 and 1.1 only apply for devices that are required to support a wake-up signal.



For example, PCI network adapters and modems are required to generate a PME# assertion. For other device classes that that are not required to and do not support wake up, the Windows Logo Program only requires compliance with PCI-PM 1.0.FAQ Date: May 6, 1999; December 22, 1999 (PC99a:9.17)

Bus and bridge requirements: The PCI bus must comply with the PCI Bus Power Management Interface Specification, Revision 1.1 or later, whether or not the system in which they are installed provides 3.3 Vaux to its PCI connectors.

A method that PCI add-on cards can use to meet this requirement is described in Section 7.4.4 of the PCI Bus Power Management Interface Specification: Static FET switches on the add-on card re-route 3.3 VPCI, or converted 5 VPCI, to the 3.3 Vaux power plane when the card is installed in a system that does not supply 3.3 Vaux. However, the added cost of these static FET switches is not justified for PCI add-on cards installed exclusively in OEM systems.

On OEM systems that supply 3.3 Vaux, the OEM-version PCI add-on card's split Vaux power plane is tied directly to the 3.3 Vaux pin on the system PCI connector. For systems that do not deliver 3.3 Vaux, the OEM-version PCI add-on card's Vaux power plane is tied directly to the required 3.3 VPCI source.

PC add-on cards designed and built exclusively for installation in OEM systems—and which are never sold through retail distribution channels—are not required to supply the static FET switches described in section 7.4.4 of the PCI Bus Power Management Specification. This requirement includes correct implementation of the PCI Configuration Space registers used by power management operations, and the appropriate device state (Dx) definitions. ACPI is not an acceptable alternative.

Functions (for example, PCI-to-PCI bridges, USB host controllers, IDE controllers, and so on) that are integrated as part of the core chipset, and thus not add-on capable devices, can use ACPI (and not PCI Power Management registers) for their power management interface.FAQ Date: May 6, 1999; May 28, 1999 (P99:9.17)

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 Future RequirementsAnnouncement of additional future requirements will be published at http://www.microsoft.com/winlogo/pci/




1. PCI 2.2, PCI_PM 1.1 for all components, and other specification version updates, required with the release of Windows Whistler (PC2001:1394–0091, PCI–

0123)

2. Bus designs implement all bus requirements on expansion card connectors (PC2001:PCI–0123)

3. 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 Bus Power Management Interface Specification (PC2001:PCI–0130.2)

4. BIOS does not configure I/O systems to share PCI interrupts when APIC is activated (PC2001:PCI–0016)

B2.6 USB Controllers and DevicesAll 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 (Appendix A).

B2.6.1 Windows Compatibility1. WDM support for devices that use the USB bus: “Supporting USB Devices” in

the Windows 2000 DDK

2. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/usb/

3. USB Plug and Play IDs and Selecting Device Drivers to Load: http://www.microsoft.com/hwdev/busbios/usbpnp.htm

B2.6.2 Industry Standards1. OpenHCI: Open Host Controller Interface Specification for USB, Release 1.0a

Or Universal HCI specification (PC99a:7.6)

2. USB specifications:

USB 1.0 Specification (or later)—USB 1.1 applies if implemented (PC99a:7.4)

USB PC Legacy Compatibility Specification, Revision 0.9 or later

USB Common Class Base Specification, Revision 1.0

B2.6.3 Quality1. All USB hardware complies with USB 1.0 and passes USB Chapter 9 and

Chapter 11 tests, including:

Device has unique VID/Program ID (PID) combination

Serial number, if implemented, is unique

Hub reports the correct number of ports



2. Pass WHQL tests: Hidview, Suspend/Resume, Enable/Disable, Remove/Refresh, Interop

B2.6.4 Windows Experience1. Devices comply with USB power management requirements (PC99a:7.10)

2. Connections use USB icon, per USB specification (PC99a:7.4)

3. USB host controller can wake the system (PC99a:7.7)

4. Devices and drivers support maximum flexibility of hardware interface options (PC99a:7.5)

5. Devices meet requirements in related USB device class specifications (PC99a:7.11;

see FAQ B2.6.5.2)


B2.6.5 FAQs1. Current USB-related FAQ items are collected at

http://www.microsoft.com/winlogo/USB/

2. USB device definition [Logo Program clarification]: 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 Version 1.0 (or later) 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 (PC99a:7.11)

B2.6.R Future RequirementsAnnouncement of additional future requirements will be published at http://www.microsoft.com/winlogo/usb/


1. USB 1.1 for all components, and other specification version updates, required with the release of Windows Whistler. If a hub or device supports USB 2.0, it must comply with USB 2.0 (PC2001:USB–0081)

2. USB devices install without preloading software (PC2001:USB–0089)

B3.0 Audio Devices

B3.1 General AudioAll general requirements in B1.0 are included by reference.All bus-specific requirements in B2.0 are included by reference.



B3.1.1 Windows Compatibility1. WDM device driver support for audio: “WDM Audio Driver Design Guide” in

the Windows 2000 DDK (PC99a:17.8, 17.31; see FAQ B3.1.5.8)

2. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/audio/

3. Audio Codec (AC) '97 and AMR Plug and Play Design: http://www.microsoft.com/hwdev/audio/AMR.htm

4. WDM Audio Drivers for Windows 2000: http://www.microsoft.com/hwdev/devdes/wdmaudio.htmDirectSound driver support: see Windows 2000 DDK

5. NEW: Windows Me: USB MIDI takes advantage of built-in operating system support for USB MIDI (documented in Windows 2000 DDK).

B3.1.2 Industry Standards1. AC ’97 Component Specification:

http://developer.intel.com/solutions/tech/audio.htm

2. Audio Device Class Power Management Reference Specification, V. 1.0: http://www.microsoft.com/hwdev/specs/pmref/pmaudio.htm (PC99a:17.29; see FAQ

B3.1.5.7)

3. DLS Specification, V. 1.0 or later: http://www.midi.org/

4. Personal Computer Audio Quality Measurements: http://www.cirrus.com/products/papers/meas/meas.html

5. USB Device Class Definition for Audio Devices, V. 0.9 (PC99a:17.25)

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

See B5.1.5 for HID control requirements

B3.1.3 Quality1. Pass WHQL tests: Mixer Driver, DirectSound Driver, Wave Driver, and MIDI

Driver

2. Driver is disabled and enabled properly—Disabler (PC99a:17.19, 17.30)

B3.1.4 Windows Experience1. No legacy components: No ISA; no legacy hardware interfaces for MS-DOS–

based applications; no DB-15 analog joystick/MIDI port (PC99a:17.2, 17.3, 17.17)

2. Full Duplex—Internet Telephony (PC99a:17.5-6); see FAQ B3.1.5.4

3. Plays sounds before and after Suspend/Resume (PC99a:17.28)

4. Record and Playback works properly—WHQL Audio test;Audio performance

Mobile Note: Exceptions are defined for mobile PCs (PC99a:17.4; See FAQ B3.1.5.3)



5. Audio subsystem supports full-duplex operation at independent sampling rates (PC99a:17.6)

6. Analog microphone input meets jack and circuit specifications (PC99a:17.7; see FAQ

B3.1.5.7)

7. Audio driver reports sample position for stream synchronization (PC99a:17.8)

8. PCI device minimum requirements: (PC99a:17.20, 17.28)

Supports initiator, target, and block transfer (PC99a:17.21)

Supports non-DWORD-aligned audio buffers (PC99a:17.22; see FAQ B3.1.5.6)

Does not use ISA-based resources (PC99a:17.23)

Is digital ready (PC99a:17.24)

9. USB audio device uses HID controls (PC99a:17.26)

10. Support required for Microsoft DirectX® functions as specified in the DirectX DDK

11. NEW: Windows Me: If device supports Digital Rights Management, implement support as defined in “Introducing Digital Rights Management” at http://www.microsoft.com/hwdev/audio/DRM.htm

The additional signature for Windows Me DRM capabilities for audio drivers is optional.


B3.1.5 FAQs1. Current related Audio FAQ items are collected at

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

2. AC ‘97 devices on riser cards [Logo Program clarification]: AC ‘97 devices on riser cards such as AMR 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 the related article, AC '97 and AMR Plug and Play Design: http://www.microsoft.com/hwdev/audio/AMR.htm.FAQ Date: June 2, 1999

3. Audio Minimum Performance Requirements [Clarification]: Windows 98 and Windows 2000 provide software mixing and sample rate conversion (SRC), which eliminate the need for hardware to support all possible rates. Therefore, the hardware is required to support only two key rates: 44.1 and 48 kHz:

44.1 kHz is required for efficiency reasons. Most game content uses a sampling rate that is an integer divisor of 44.1 kHz. In addition, 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 provides the best quality and least CPU overhead.

48k Hz is required because it is the highest frequency that consumer content uses. DVD audio is a good example. When 48 kHz content is present, the operating system will switch the audio output to 48 kHz.FAQ Date: October 7, 1998 (PC99a:17.4)

Requirement Value

Full-scale input voltage:

FSIP (A-D-PC) line input

FSIP (A-D-PC) microphone input

2.0 Vrms

100 mVrms

Full-scale output voltage:

FSOP (PC-D-A) line output 1.0 Vrms1

Analog pass-through (A-A):Line input to line output

Frequency response (-3 dB) Dynamic range (SNR)THD+N (-3 dB FS)

Microphone input to line outputFrequency response (-3 dB)Dynamic range (SNR)THD+N (-3 dB FS)

30 Hz to 20.0 kHz4

80 dB FS A4

–65 dB FS4

100 Hz to 12.0 kHz70 dB FS A4

–60 dB FS4

Line input to speaker output with 8-



Requirement Value

ohm load2

Frequency response (-3 dB)Dynamic range (SNR)THD+N (-3 dB FS)

30 Hz to 20.0 kHz4

70 dB FS A4

–55 dB FS4

Digital playback (PC-D-A) for line output:Frequency response (-3 dB)

44.1 kHz source material48.0 kHz source material

Dynamic range (SNR)

THD+N (-3 dB FS)

30 Hz to 17.6 kHz4

30 Hz to 19.2 kHz4

80 dB FS A3, 4

–65 dB FS4

Digital recording (A-D-PC) for line input:Frequency response

44.1 kHz destination 48.0 kHz destination

Dynamic range (SNR)

THD+N (-3 dB FS)

20 Hz to 17.6 kHz4

20 Hz to 19.2 kHz4

70 dB FS A4

–60 dB FS4

Digital recording (A-D-PC) for microphone input:Frequency response (-3 dB)

22.05 kHz destination

Dynamic range (SNR)

THD+N (-3 dB FS)

100 Hz to 8.8 kHz

70 dB FS A4

–60 dB FS4

Line output cross-talk:Channel separation between left and right line out channels (measured at 10 kHz)

60 dB4

Sampling frequency accuracy:Playback

Record

0.1%

0.1%1 For mobile PCs with 3.3 V audio subsystems, the required Full Scale Output Voltage for line output is 0.7 Vrms.2 Line input to speaker output is a requirement only if a line output is not supported.3 Decibels relative to full scale (FS), measured using “A weighting” filters.4 For mobile PCs:

The dynamic range requirements are relaxed by 10 dB FS A.The THD+N requirements are relaxed by 10 dB FS.The required frequency response is 20 Hz to 15 kHz, measured using 3 dB corners.The cross-talk requirements are relaxed by 10 dB FS.

4. Basic data formats for audio hardware [Clarification]: For all cases in this requirement (and similar audio requirements), the reference should be to "audio hardware," and not to "audio codec hardware." Also:



Output. The built-in or external audio hardware must support 16-bit stereo at 44.1 and 48 kHz at minimum. Output performance must meet or exceed minimum requirements stated in PC99a:17.4.

Input. The built-in or external audio hardware must support 16-bit stereo at 44.1 and 48 kHz at minimum. Input performance must meet or exceed minimum requirements stated in PC99a:17.4.FAQ Date: May 28, 1999 (PC99a:17.5)

5. Analog microphone input [Correction]: Three-conductor 1/8-inch (3.5 mm) 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 (ring and sleeve shorted together) plugs.

Minimum AC input impedance between tip and ground: minimum, 4 kOhm; recommended, 10 kOhm. FAQ Date: February 10, 1999; November 20, 1998 (PC99a:17.7)

6. PCI device supports non-DWORD-aligned audio buffers [Clarification]: This is a recommendation, not a requirement. The following items are added to the recommendations provided in PC99a:17.22, and might become requirements in the future.

The audio device should not consume more than 2 percent of the CPU transferring audio data. This is 2 percent for all streams, not per stream.

The audio device should 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 should not require the largest block of contiguous memory to exceed one page. This ensures audio support in docking and dynamic loading scenarios where memory may be completely fragmented page-wise.

The audio device should not introduce more than 1 ms latency. In this context, latency is defined as the time between when the driver receives the audio data and when the audio data leaves the device.

The intent here is to provide performance guidelines for developers, rather than to specify implementation requirements. FAQ Date: December 22, 1998 (PC99a: 17.22)

7. PCI power management requirements [Clarification]: 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.FAQ Date: November 12, 1999 (PC99a:17.29)

8. WDM Audio Driver Requirements [Logo Program Clarification]: WDM audio driver requirements apply based on the preinstalled operating system:

Windows 2000 and Windows Me Audio Drivers: All devices are required to use WDM drivers, as described in the guidelines defined in PC 99 System Design Guide.



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 will be addressed in the operating system update.

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). Note: This does not apply to Windows 98 Second Edition, which is covered earlier.

Audio drivers for Windows NT 4.0: Windows NT 4.0 does not support WDM and therefore the WDM requirement does not apply for Windows NT 4.0 submissions.FAQ Date: November 29, 1999 (PC99a:17.31)

B3.1.R Future Requirements Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/audio/


1. Advances on previous requirements:

Full duplex operation is supported for all sampling rates; sampling rates are time synchronized (PC2001:AUD–325)

Digital playback and recording values are increased from 20 Hz to 30 Hz Full-scale input voltage changed from 2.0 to 1.0 (PC2001:AUD–329)

2. Audio subsystem requirements:

Supports acoustic echo cancellation reference inputs (PC2001:AUD–330)

Does not rely on analog mixing (PC2001:AUD–339)

3. Headset microphone used for speech recognition meets performance requirements (PC2001:AUD–332)



4. Docked mobile PC allows user speaker selection (PC2001:AUD–339)

B4.0 Display

B4.1 Display Adapters/ChipsetsAll general requirements in B1.0 are included by reference.All bus-specific requirements in B2.0 are included by reference.

B4.1.1 Windows Compatibility1. Windows 2000: “Display and Video Miniport Drivers” and “Multiple Monitor

Support in the Display Driver” in the Windows 2000 DDKSoftware provided with graphics adapters designed for use with Windows 2000 must comply with the requirements defined in “Graphics Driver Design Guide” in the Windows 2000 DDK

2. Windows 98/Me: “Display Drivers” and “Multiple Monitor Support Implementation Design Notes” in the Windows 98 DDK

Windows Me: Correct driver support for Get_Adapter_Power_State_Caps() and Set_Adapter_Power_State() interfaces:http://www.microsoft.com/hwdev/video/Mill_D3display.htm

3. OpenGL support (if implemented): “Chapter 5 Mini Client Driver” in the Windows 2000 DDK

4. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/video/

5. Windows 2000: Compatibility Testing Requirements for Display and Video Miniport Drivers: http://www.microsoft.com/hwdev/video/vidminiport.htm

6. Windows 98/Me: Caution for Display Driver Dependencies on GDI: http://www.microsoft.com/hwdev/devdes/gdi.htm

7. DirectX 7: Support per DirectX 7 DDK (included in the Windows 2000 DDK) and the DirectX SDK at http://msdn.microsoft.com/directx/

B4.1.2 Industry Standards1. Accelerated Graphics Port Interface Specification, Revision 1.0 and later:

http://developer.intel.com/technology/agp/agp_index.htm (only AGP 2.0 is available on the Intel web site)

2. Digital Video Interface (DVI) Revision 1.0: http://www.ddwg.org/

3. Display Data Channel Standard, V. 3.0, Level 2B protocols:Video Electronics Standards Association (VESA) BIOS Extension Standard/Core Functions 2.0 (VBE/Core 2.0)VESA Video Interface Port (VIP) Specificationhttp://www.vesa.org/standards.html (PC99a:14.55)



4. Display Device Class Power Management Specification, V. 1.0: http://www.microsoft.com/hwdev/specs/PMref/PMdisplay.htm

B4.1.3 Quality1. Pass WHQL tests:

Installation and configuration; DDC and DPMS compatibility

Note: Display drivers prompt for reboot after installation in Windows 98/Me and Windows 2000.

PCI, AGP, GDI, and Microsoft DirectDraw

VGA and Safe Mode compatibility tests

Utilities tests (cursors, control panels, and so on)

Application compatibility (MS-DOS, DirectX, and so on)

Power management tests (PC99a:14.55)

Microsoft Direct3D® and OpenGL tests

B4.1.4 Windows Experience1. Multiple monitor /multiple display support (PC99a:14.5; 14.20, 14.21)

2. DirectX 7 driver support for hardware acceleration. Windows 98: DirectX 7 support is required as of April 14, 2000

3. NEW: Windows Me: If digital video interface is supported, implementation follows Digital Visual Interface 1.0 and PC 2001 v.0.7 (or later) guidelines This requirement applies effective with the release of Windows Whistler.

4. Adapter meets VESA specifications for ergonomic timing rates; screen resolution and local memory capacity meet minimum requirements

Mobile Note: Exceptions are defined for mobile PCs (PC99a:14.8, 14.9)

5. Color support:

All supported color depths are enumerated (PC99a:14.10)

Adapter supports downloadable RAMDAC entries for integrated color management (PC99a:14.12)

Driver supports dynamic color bit-depth change (PC99a:14.59)

6. Device configuration and detection requirements:

Graphics operations use relocatable registers only (PC99a:14.11)

Primary graphics adapter works normally with default VGA mode driver (PC99a:14.4)

Driver does not bypass any Microsoft-provided system components (PC99a:14.57 ; 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)

Mobile Note: Exceptions are defined for mobile PCs(PC99a:14.13, 14.48; See FAQ B4.1.5.2, B4.1.5.3)

Frame buffer can be accessed directly by applications (PC99a:14.22)

Adapter and driver support linear-mapped, low-resolution modes (PC99a:14.23)

System supports conflict resolution, VGA compatibility, and extended registers (PC99a:14.46)

BIOS supports large frame buffers for graphics adapters (PC99a:14.50)

Graphics adapter complies with VESA BIOS Extensions/Core 2.0 extensions for power management (PC99a:14.55)

7. Basic 2-D hardware acceleration requirements:

Hardware supports transparent blter (PC99a:14.24)

Hardware provides support to prevent tearing (PC99a:14.25)

Hardware supports programmable blter stride (PC99a:14.26)

Chips support linear packed-pixel frame buffer, relocatable above 16 MB (PC99a:14.47)

8. 3-D hardware (if implemented) supports required red, green, blue (RGB) rasterization, texture formats, and texture size limitations (PC99a:14.27, 14.30-31; See

FAQ B4.1.5.6)

9. Graphics adapter uses PCI, AGP, or another high-speed bus (PC99a:14.1)

AGP implementation meets guidelines (PC99a:14.51)

PCI device supports IRQ and correctly populates PCI BARs (PC99a:14.52)

PCI system-board graphics device is not hidden from Plug and Play enumeration (PC99a:14.53)

10. TV output capability, if present, meets requirements:

Default boot mode supports appropriate locale (PC99a:14.36)

Adapter supports underscan scaling (PC99a:14.37)

Adapter supports flicker filter (PC99a:14.38)

Adapter provides proper termination (PC99a:14.39)

Adapter with television output supports both VGA and television output (PC99a:14.41)

Software supports positioning (PC99a:14.42)

Software supports detection of television connection (PC99a:14.43)

11. Support for TV or DVD video playback (if feature is implemented):

Hardware supports video overlay surface with scaling (PC99a:14.14)



Hardware supports VGA destination color keying for video rectangle (PC99a:14.15; See FAQ B4.1.5.5)

Hardware supports alpha blending of graphics and video (PC99a:14.16)

Video port, if present, meets specifications (PC99a:14.17)

12. NEW: Windows Me: Graphics driver for a system with Windows Me preinstalled must properly support the D3 state such that Windows can hibernate and restore the PC from any sleep state the system supports. This includes correct driver support for Get_Adapter_Power_State_Caps() and Set_Adapter_Power_State() interfaces. For details, see:http://www.microsoft.com/hwdev/video/Mill_D3display.htm


B4.1.5 FAQs1. Current Display FAQ items are collected at

http://www.microsoft.com/winlogo/display/

2. DDC/EDID Standards [Clarification]: 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 both Windows 2000 and Windows 98/Me. FAQ Date: October 7, 1998 (P99A:14.13)

3. Mobile Note: +5 V power and mobile PCs [Clarification]: Because of the power limitations placed on mobile computers, they are not required to supply + 5 V 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

4. Shrink and zoom requirements [Correction]: The ability to shrink and zoom by a variable factor of up to 8:1 in one-pixel increments is required; the ability to shrink by a variable factor of up to 16:1 in one-pixel increments is recommended. All other requirements, exceptions, and so on are the same as originally defined in PC 99 System Design Guide. FAQ Date: October 7, 1998; revisions May 28, 1999 (PC99a:14.14.4)

5. Color/color range requirements [Correction]: The specific color/color range includes 8-bit, 15-bit, and 24-bit Super VGA (SVGA) modes (4-bit mode is not required).FAQ Date: October 7, 1998 (PC99a:14.15)

6. Source alpha blending requirement [Logo Program Clarification]: Support for source alpha blending (that is, the blend operation does not require an alpha channel in the render target) is required for all devices.

Support for destination alpha blending (that is, the blend operation requires an



alpha channel in the render target) is not required, but may be a requirement in the future. However, if destination alpha blending is implemented, the DESTALPHA and INVDESTALPHA blend modes must be supported as both a source and destination factor. All modes must be available in any combination. Devices that do not meet this criteria, as defined in the following table, must not indicate the capability to perform destination alpha blending.

The following table shows the blend modes that must be supported as source and destination factors for alpha blending:

Blend mode Source factor Destination factor

D3DBLEND_ ZERO Yes Yes

D3DBLEND_ ONE Yes Yes

D3DBLEND_SRCCOLOR N/A 2001

D3DBLEND_INVSRCCOLOR N/A 2001

D3DBLEND_ SRCALPHA Yes Yes

D3DBLEND_ INVSRCALPHA Yes Yes

D3DBLEND_DESTALPHA Note 1 Note 1

D3DBLEND_INVDESTALPHA Note 1 Note 1

D3DBLEND_DESTCOLOR Yes N/A

D3DBLEND_INVDESTCOLOR Yes N/A

D3DBLEND_SRCALPHASAT 2001 N/A

D3DBLEND_BOTHSRCALPHA 2001 N/A

D3DBLEND_BOTHINVSRCALPHA

2001 N/A

Legend:

Yes = Required for PC 99/99a and on.

2001 = Anticipated to be required for PC 2001 design guide.

N/A = Not applicable

Note 1: If destination alpha blending is implemented, these modes must be supported as both a source and destination factor. If they are not, then destination blending must not be enabled.

Note:

Because the blend modes are displayed as caps, they must function in any combination and without dependencies.

Parts that were logo'd under the tests in 1998–99 and that are otherwise logoable in relation to the 1999–2000 requirements as noted here will continue to be eligible for the Logo, provided they meet all other Logo requirements.

See the DirectX DDK in the Windows 2000 DDK.FAQ Date: October 7, 1998, August 26, 1999 (PC99a:14.28, 14.27.3)



B4.1.R Future RequirementsAnnouncement of additional future requirements will be published at http://www.microsoft.com/winlogo/display/


1. If digital video interface is supported, implementation follows Digital Visual Interface Specification, Revision 1.0 (PC2001:GRPH_0165)

2. Equivalent of AGP 2X required for discrete solutions; AGP 1X or equivalent required for integrated solutions (PC2001:GRPH–0163)

3. Adapter supports minimum screen resolution of 1024 × 768 × 32 bpp, double buffered in 2-D mode with a 32-bit Z-buffer in 3-D mode (PC2001:GRPH–0168)

Until January 1, 2002, integrated solutions are permitted 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.

4. Adapter supports gamma correction performed in hardware at 24 bpp or 32 bpp without using VGA resources (PC2001:GRPH–0178)

5. Adapter supports industry standards:

DDC level2B host requirements identified in EDDC (PC2001:GRPH–0179)

Ergonomic timings for supported resolutions, based on 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 supported) (PC2001:GRPH–0169)

6. Adapter supports hardware-accelerated 3-D graphics, including these additional new 3-D requirements for hardware support:

Multi-texturing (PC2001:GRPH–0186)

Source alpha blending and destination alpha blending; required texture size increases to 1024×1024 for all texture operations (PC2001:GRPH–0185, GRPH–

0188)

Until January 1, 2002, integrated solutions are not required to support destination alpha blending.

Texture format 8:8:8:8 alpha RGB (ARGB) (PC2001:GRPH–0187)

Until January 1, 2002, integrated solutions are not required to support texture format 8:8:8:8 ARGB.

Z comparison modes and Direct3D-compatible formats (PC2001:GRPH–0189)

Fog blending term is calculated on a per-pixel basis rather than per vertex. Driver support for triangle strips and fans (PC2001:GRPH–0185.3)

Until January 1, 2002, integrated solutions are allowed to support per-vertex fog rather than per-pixel fog.

Until January 1, 2002, integrated solutions are not required to support



MODULATEALPHA texture combinations. Also, multitexture support in combination with fogging and alpha blending is not required.

7. 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 (PC2001:GRPH–0206)

8. Graphics subsystem support for TV or DVD video playback, support at least one off-screen video overlay surface for 1280 × 720 or larger, fully operative at 640 × 480 and 1024 × 768 and color depths of 16 bpp and 32 bpp, plus:

YUV 4:2:2 (YUY2) and YUV 4:2:0 (YV12) color formats;YV12 support in overlay surface if double buffering is not supported

Video scaling implemented using DirectDraw and Microsoft DirectShow® APIs:

Bilinear scaling.

Shrink or zoom by a variable factor of up to 8:1 in one-pixel increments.

No perceptual degradation when shrinking by factors up to 2:1.

If not enabled for digital TV (DTV), accept a standard definition video input.

If DTV-enabled PC, accept an input with a rate of 720p60 (1280 horizontal pixels) and 540p60 (bobbed from 1080i) (1280 horizontal pixels).

Video quality and CPU utilization requirements apply independent of scaling ratios.

Scaling 4:2:2 or 4:2:0 YUV video must achieve two-pixel granularity.

Colorspace conversion can be configured for different color primary standards

Support ITU-R [BT.601-5] standard, formerly CCIR 601.

Support color keying for video overlays

Destination color keying must function in all video modes

(PC2001:GRPH–0392-GRPH–0395)

9. Mobile Note: Mobile systems meet basic graphics requirements to reliably run Windows and applications, plus requirements related to resolution capabilities (PC2001:GRPH-0392)

Supports DDC detection for external displays, but does not have to supply +5 V to the VGA connector at any time DVI connector must supply +5 V only during boot, when the user first enables external video, and when the system output is analog or digital video through the DVI connector.



Supports refresh frequencies only up to the native capabilities of the integrated display panel

Multiple adapter support not required unless system supports multi-head, multimonitor capabilities or mobile PC supports a docking station with PCI expansion slots

System that implements a single-chip multi-head configuration meets desktop resolution requirements, but not color depth for any attached monitor(PC2001:GRPH–00392)

Mobile Note: Optional 3-D capabilities meet minimum requirements. For mobile systems 3-D hardware acceleration is optional. If 3-D is supported, the mobile PC system must meet all 3-D requirements for the native display resolution (not less than 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/table-based fog is not required.

Support of 32-bit textures is not required; however, support of 16-bit textures is required.

Support of 16-bit Z buffers is requiredSupport of 32-bit Z buffers is not required

Support of 32 bpp (ARGB 8:8:8:8) is not required.

Support of non-square power-of-two textures up to 1024 × 1024 for all texture operations is not required.

Support for square, power-of-two textures of sizes up to and including 256 × 256 is required.

(PC2001:GRPH–00393)

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

B4.2.1 Windows Compatibility1. Windows 2000—monitor INF: “INF and Installation Requirements” in the

Windows 2000 DDK

2. Windows 98/Me—monitor INF: “Sample Display INF File”of “Windows 95 Documentation Programmers Guide” in the Windows 98 DDK

3. Image Color Management (ICM) APIs and functionality for Windows 98 and Windows 2000 are described in the Microsoft Platform SDK and “Color Management for Displays” in the Windows 2000 DDK (PC99a:16.2)



4. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/video/

5. Mobile Note - Windows 2000: Windows 2000 Support for Mobile System Displays: http://www.microsoft.com/hwdev/video/mobiledisplay.htm

6. Windows 98/Me: Implementing Display Control Panel Extensions in Windows 95/98: http://www.microsoft.com/hwdev/devdes/displaycpl.htm

B4.2.2 Industry Standards1. EDID Standard, V. 3.0:

VESA Display Data Channel StandardVESA and Industry Standards and Guidelines for Computer Display Monitor Timinghttp://www.vesa.org/standards.html


3. USB Monitor Control Class Specification, Revision 1.0

4. DVI Revision 1.0: http://www.ddwg.org/


Installation and configuration

INFCatReady, EDID (EdidTest.exe and EdidW2K.exe), and Refresh Rate (AutoRate.exe)

Add-on testing (speakers, microphones, cameras, controls, and so on)

ICM profile header validation (ProfWiz.exe)

Power management (Estar.exe)

B4.2.4 Windows Experience 1. Color monitor is DDC2B-compliant with unique EDID identifier (PC99a:16.1; See

FAQ B4.2.5.2, 4.2.5.4)

2. Monitor supports Image Color Management (PC99a:16.2; See FAQ B4.2.5.3)

3. Monitor meets minimum graphics resolution, based on monitor size (PC99a:16.5)

4. CRT-based monitor supports ergonomic timing standards (PC99a:16.6)

5. Entertainment monitor:

CRT-based monitor supports 800 × 600 at 60 Hz refresh rate (PC99a:16.9)

Operates at the lower scan rates used by the operating system (PC99a:16.10)

6. NEW: Windows Me: If digital video interface is supported, implementation follows Digital Visual Interface Specification, Revision 1.0 and PC 2001 v.0.7 guidelines




B4.2.5 FAQs1. Current Monitor FAQ items are collected at

http://www.microsoft.com/winlogo/display/

2. DDC standard [Clarification]: 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 both Windows 2000 and Windows 98/Me. FAQ Date: October 7, 1998 (P99A:16.1)

3. Default ICC Profile [Clarification]: The default ICC profile should be for the "optimal" display mode supported by the display. Typically, this mode is defined by the display manufacturer. Specifically, there is no need to have a separate default ICM profile for each color depth and/or resolution.

Mobile 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. FAQ Date: March 19, 1999 (PC99a:16.2)

4. EDID for analog CRTs [Correction]: 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 (PC99a:16.12)

5. Monitors support D0 and D3 states [Logo clarification]: Monitors are required to support only D0 and D3 states.FAQ Date: March 20, 2000 (PC99a:16.13)

B4.2.R Future RequirementsAnnouncement of additional future requirements will be published at http://www.microsoft.com/winlogo/display/


1. Advance required standards:

VESA Enhanced Extended Display Identification Data Standard (E-EDID), Release ADDC2B (PC2001:MON–232)

Monitor supports EDID 1.3 data structure (PC2001:MON–233)

2. Monitor associates an ICC profile. Devices that create standard RGB (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. (PC2001:MON–235)

3. Minimum graphics resolution, based on monitor size:



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 (PC2001:MON–237)

4. CRT-based monitor supports ergonomic timing standards in either the VESA Generalized Timing Formula, Version 1.1 or Computer Display Monitor Timing Specification, Version 1.0, Revision 0 (PC2001:MON–240)

5. CRT-based monitor synchronizes to a new format in less than three seconds (PC2001:MON–238)

6. Digital monitor supports DVI-compliant interface, hot-plug detection, VESA VGA Text Mode 3 timings, and 640 × 480 and 640 × 400 at 60 Hz (PC2001:MON–

241, MON–242, MON–243)

7. LCD monitor or built-in LCD display contains display characterization data (PC2001:MON–234)

8. USB functionality from either an HID or USB hub, if implemented, must be installed separately from the monitor INF; a USB hub included on a monitor must be self powered or externally powered; it cannot be a bus-powered hub (PC2001:MON–236)

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 Windows Compatibility1. Windows 2000: “Drivers for Input Devices” in the Windows 2000 DDK

2. Windows 98/Me: Follow Windows 2000 DDK for HID support

3. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/input/

4. Windows 2000: Input Device Drivers and Windows 2000: http://www.microsoft.com/hwdev/input/drv.htm

B5.1.2 Industry Standards1. IBM Personal System/2 Common Interfaces, Part No. S84F-9809: Order from

IBM Customer Publications Support:1-800-879-2755



2. USB HID references: (PC99a:13.26)

USB Device Class Definition for Human Interface Devices (HID), V. 1.0

USB HID Usage Tables, V. 1.0

USB Usage Tables for HID Power Devices, Release 1.0

3. Input Device Class Power Management Reference Specification (PC99a:13.50)

4. Legacy Plug and Play Guidelines (http://www.pcdesguide.org/LegacyPnP/) (Plug and Play requirements—PC99a:13.48, 13.49)

B5.1.3 Quality1. Pass WHQL tests: Winkey

2. All keys/buttons are functional at an end-user level after an INF installation

B5.1.4 Windows Experience1. Any power management buttons implemented are ACPI compliant (PC99a:3.3)

2. Hot-plugging does not damage system or device. (PC99a:3.19)

3. All input devices support Microsoft DirectInput® and work simultaneously (Windows 98 DDK; PC99a:3.23,13.53)

4. Wireless input device supports wake-up events (PC99a:13.51)


B5.1.5 FAQs1. Current input device FAQ items are collected at


2. Simultaneous Input Requirement [Clarification]: The built-in class drivers support simultaneous operation of multiple input devices. For information about implementing support for other drivers, see "Part 4: Drivers for Input Devices" in the Windows 2000 DDK. See also the sample code and documentation in the Windows 98 DDK at %98DDK%src\hid\ and in the Windows 2000 DDK at %NTDDK%\src\wdm\hid\.FAQ Date: May 28, 1999

B5.1.R Future RequirementsAnnouncement of additional future requirements will be published at http://www.microsoft.com/winlogo/input/


1. All nonintegrated USB input devices meet USB HID specifications (PC2001:INPT–

0133)

2. Devices use USB or external bus connections rather than legacy serial or parallel ports required for all system types (PC2001:INPT–0135)



3. Input device implementing a PIN data-entry keyboard complies with International Organization for Standardization (ISO) 13491-1 (PC2001:SMRT–0162)

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 Windows Compatibility1. Windows 2000: “Part 4: Drivers for Input Devices” in the “Kernel-Mode

Drivers Reference” in the Windows 2000 DDK

2. Windows 98/Me: Follow Windows 2000 DDK for HID support


4. Windows 2000: Scan Code Mapper for Windows 2000: http://www.microsoft.com/hwdev/input/W2kscan-map.htm

5. Keyboard Scan Code Specification: http://www.microsoft.com/hwdev/desinit/scancode.htm

6. Legacy Support for USB Keyboards and Mice and the Host Controller Driver: http://www.microsoft.com/hwdev/busbios/usbhost.htm

B5.2.2 Industry Standards1. Keyboard Scan Code Specification:

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

B5.2.3 Quality1. Pass WHQL tests: Winkey

2. All keys/buttons are functional at an end-user level after an INF installation (PC99a:13.52)

B5.2.4 Windows Experience1. Any power management buttons implemented are ACPI compliant (PC99a:3.3)

2. Hot-plugging does not damage system or deviceUSB keyboard is immediately functional after hot-plugging (PC99a:3.19)

3. USB keyboard installation does not require reboot (PC99a:3.17.1)

4. No interference occurs between multiple keyboards (PC99a:13.24)

5. Scan codes conform to industry standard (PC99a:13.25)




B5.2.5 FAQs1. Current keyboard FAQ items are collected at


2. USB HID to PS/2 Keyboard scan codes: 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 (PC99a:13.25)



1. Internet browser and multimedia keys use Microsoft APIs (PC2001:INPT–0145)

2. PIN data-entry keyboard complies with ISO 13491-1(PC2001:SMRT–0162)

B5.3 Input/PointingAll 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 Windows Compatibility1. Windows 2000: “Part 4: Drivers for Input Devices” in the Windows 2000 DDK

2. Windows 98/Me: Follow the Windows 2000 DDK for HID support


4. Legacy Support for USB Keyboards and Mice and the Host Controller Driver: http://www.microsoft.com/hwdev/busbios/usbhost.htm

B5.3.2 Industry StandardsSee B5.1.5

B5.3.3 Quality1. Hot-plugging does not damage system or device; USB devices are immediately

functional after hot-plugging (PC99a:3.19.1)

2. Pass WHQL tests:

Mouse Info (Mtest.exe) verifies buttons

DirectInput Mouse test (Mousedrv.exe)

3. Mobile Note: External PS/2 pointing device detected at boot and installed correctly



4. Mobile Note: Internal pointing device disabled or dual operation enabled (mobile PC only)

5. Plug and Play Device Manager validates serial devices

B5.3.4 Windows Experience1. 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


B5.3.5 FAQsCurrent pointing-device FAQ items are collected at http://www.microsoft.com/winlogo/input/


B5.4 Input/GameAll 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.




4. Designing HID Game Controllers for DirectInput: http://www.microsoft.com/hwdev/devdes/hidgame.htm


B5.4.3 Quality1. Installation meets dynamic miniport and user notification requirements

2. Pass WHQL tests: Game (Joydrv.exe)



B5.4.4 Windows Experience1. Hot-plugging does not damage system or device; USB devices are immediately

functional after hot-plugging (PC99a:3.19.1)

2. Device performs as expected with multimedia applications


B5.4.5 FAQs1. Current game port FAQ items are collected at


2. Game pad requirements for systems [Clarification]: If a game pad or joystick is included in a PC 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 PC system.FAQ Date: October 7, 1998 (PC99a:13.5)


B5.5 Input/Keyboard-Video-MouseAll 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.



3. Windows compatibility and implementation notes: http://www.microsoft.com/hwdev/input/


B5.5.3 Quality1. All the commands listed in the device’s user manual work correctly

2. Only documented commands are provided

3. All buttons on the Keyboard-Video-Mouse (KVM) work properly

B5.5.4 Windows Experience1. Cascading switch boxes



2. On-screen display for switching between machines

3. Ability to switch between machines using a keyboard

4. Computer recognizes any Plug and Play keyboard, mouse, or monitor connected to the KVM

5. Computer resets the device ports in case a corruption results in an incorrect output signal sent from a connected device to the operating system

6. All devices and cables connected to the KVM are hot pluggable and have proper icons and colors (PC99a:3.18.2)


B5.5.5 FAQsCurrent KVM FAQ items are collected at http://www.microsoft.com/winlogo/input/


B5.6 Smart Card ReadersAll 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 Windows Compatibility1. Windows 2000 and Windows 98/Me: “Smart Card Drivers Overview” in the

Windows 2000 DDK

2. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/smartcard/Note: Smart Card base components need to be installed before driver on Windows 98/Me; they are automatically installed on Windows 2000

B5.6.2 Industry Standards1. ISO/IEC DIS 7816 Identification Cards—Integrated circuit(s) cards with

contacts—Part 1: Physical characteristics: http://www.iso.ch/cate/d29257.htmlPart 2: Dimensions and location of the contacts: http://www.iso.ch/cate/d26536.htmlPart 3: Electronic signals and transmission protocols: http://www.iso.ch/cate/d14735.html(PC99a:13.38, 13.39)

2. Interoperability Specification for ICCs and Personal Computer Systems: http://www.pcscworkgroup.com/



B5.6.3 Quality1. Hot-plugging for PC Card does not cause system to stop running or other

problems; USB reader is functional upon hot-plugging (PC99a:3.19)

B5.6.4 Windows Experience1. Driver does not cause system to stop running if required resources are not

available

2. Driver supports multiple instances of the same device on system without problems

3. Windows 2000: Device works properly after system resumes from a hibernation stateNote: Hibernation tests on Windows 98/Me are automatically disabled, due to serial port problems

4. Reader supports required capabilities:

Inverse-convention smart cards (PC99a:13.40)

258 byte packets in T=0 and 259 byte packets in T=1 (PC99a:13.41)

Smart card insertion/removal monitor (PC99a:13.42)

PTS (PC99a:13.43; see FAQ B5.6.5.2)

3.5795 MHz minimum clock frequency (PC99a:13.44)

9600 bps minimum data rate (PC99a:13.45)

Reset command (PC99a:13.46; see FAQ B5.6.5.2)

Design Guidelines:

PC 99 System Design Guide: PC99a:13.38-13.46

Smart Card for Windows web site: http://www.microsoft.com/smartcard/

B5.6.5 FAQs1. Current smart card FAQ items are collected at


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.Note: Power Down command for ISO 7816-3 is optional, but Reset command is mandatory.FAQ Date: October 7, 1998 (PC99a:13.43)





1. New industry standards required: (PC2001:SMRT–0153) ISO/IEC 7811

Part 1: EmbossingPart 3: Location of embossed characters on ID-1 cards

ISO/IEC 7813:1995 Identification Cards—Financial transaction cardsISO/IEC 10373:1993 Identification cards—Test methods

2. PTS support is no longer required for PC2001:13.43. Reader must support negotiable and specific modes according to ISO/IEC 7816-3 (1997-12-15) Sections 6 and 7 (PC2001:SMRT–0158)

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 Windows Compatibility1. Windows Modem Development Kit – Unimodem driver (MDK for Windows

98/Me and Windows 2000) in the Windows 2000 DDK (PC99a:19.41)

2. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/modem/

3. Unimodem Diagnostics Command Reference Specification: http://www.microsoft.com/hwdev/respec/commspec.htm

4. Standard Modem Command Sets and Standard Modem INFs: http://www.microsoft.com/hwdev/modem/comndset.htm

5. Guidelines for WDM-based Software Modems: http://www.microsoft.com/hwdev/modem/softmodem.htm (PC99a:19.26)

B6.1.2 Industry Standards1. 1997 V. of National ISDN Basic Rate Interface Terminal Equipment Generic

Guidelines, Document Number SR-3888: http://www.telcordia.com/index.html

2. Bellcore Technical References: http://www.telcordia.com/index.html

3. Communications Device Class Power Management Reference Specification, V. 1.0: http://www.microsoft.com/hwdev/specs/PMref/PMcom.htm (PC99a:19.38,

19.39)

4. EIA Standard #ANSI/EIA-516-88: “Joint EIA/CVCC Recommended Practice for Teletext: North American Basic Teletext Specification (NABTS)”: http://www.tiaonline.org/

5. ETSI (European Telecommunication Standards Institute): http://www.etsi.org/

6. ITU (International Telecommunication Union) communications standards: http://www.itu.int/publications/index.html

7. Definitions for Communications Devices, V. 1.0



8. PHS Internal Access Forum Specification (PIAFS) : http://mitf.arib.or.jp/e/menu.html

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 Quality 1. Pass WHQL tests: Modem Test Kit

B6.1.4 Windows Experience1. Wake on Ring (if support is implemented) meets OnNow requirements

(PC99a:19.38, 19.39; See FAQ B6.1.5.9)

2. Analog modem supports additional capabilities:

V.90 connectivity, V.42 Link Access Protocol, Modem (LAPM), V.42 bis, and V. 80 Synchronous Access data protocols (PC99a:19.4, 19.6)

V.250 Extended AT Command Set (formerly V.25 ter) (PC99a:19.3)

Connection to two distinct V.90 host modems (such as 3Com and Conexant) at 40 Kbps or better

Call control signaling, controlled using V.251 modem commands (PC99a:19.7)

Voice modem supports ITU V.253 and speakerphone (PC99a:19.11, 19.13-14)

Fax—14.4 Kbps (V.17) with Class 1 (TIA-578-A) command set (PC99a:19.8)

Modem pair passes basic V.34 file transfer test, basic call connect reliability test, and concurrency test (PC99a:19.23-25; See FAQ B6.1.5.5)

3. Primary Domain Controller modem supports additional capabilities:

9.6 Kbps connectivity to analog modem

Connection to Aiwa PV-BW5606

Error control and blind dial

AT commands:ATA - accept ringingATD – dialATE - echo settingATH – hangupATI - get modem informationS0 - S0 register(0 value is to disable to accept ringing)ATV - response code styleATZ - reset- - Initialize- - Hard/Soft flow control

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 (PC99a:19.9)

5. Integrated Services Digital Network (ISDN) modem supports additional capabilities:

Unattended installation, with limitations (PC99a:19.17)

Required command set (PC99a:19.18)

Asynchronous-to-synchronous conversion (PC99a:19.20)

6. NEW: Windows Me: Video telephony (if support is implemented):

Essential V.250 AT commands (PC99a:19.2-3; see FAQ B6.1.5.2)

V.80 Synchronous Access data protocols

Call Control Signaling using V.251 modem commands

7. Global System for Mobile Communications or digital cellular phone support, if implemented, includes required command and protocol support (PC99a:19.16)


B6.1.5 FAQs1. Current Modem FAQ items are collected at

http://www.microsoft.com/winlogo/modem/

2. Modems and workstations [Clarification]: A modem or other communications support is not required for workstation systems (that is, dual-processor client systems running Windows 2000 Professional).FAQ Date: May 28, 1999 (PC99a:19.1)

3. Unimodem required commands [Clarification]: 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 (PC99a:19.3)

4. Voice recording and playback capabilities [Logo Program correction]: The capability for voice recording and playback (+VTX, +VRX) is not required.FAQ Date: July 8, 1999 (PC99a:19.11)

5. Concurrency test [Clarification]: A standard concurrency test procedure will be published as part of the Modem Test Kit. This will become part of compliance testing when a comprehensive and reproducible concurrency test is available.FAQ Date: November 27, 1999 (PC99a:19.25)

6. WDM support for driver-based modems [Logo Program clarification]: WDM support for driver-based modems is required for Windows Me and Windows 2000. For information about the Ccport.sys QFE for Windows 98, see http://www.microsoft.com/hwdev/devdes/modem_up.htmFAQ Date: July 28, 1999;

revisions August 26, 1999, March 3, 2000 (PC99a:19.25)



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 (PC99a: 19.29)

8. WDM modem latency tolerances [Clarifications]: A driver-based modem should be able to tolerate a period of 4 milliseconds with interrupts disabled.

A driver-based modem should be able to tolerate a continuous period of 8 milliseconds during which a queued DPC is held off from execution, possibly by other DPCs.

A WDM driver-based modem should be able to tolerate a 16-millisecond period when thread scheduling is continuously disabled.

See http://www.microsoft.com/hwdev/devdes/modem_up.htmFAQ Date: October 7, 1998 (PC99a:19.30)

9. Modem supports wake-up events [Clarification]: Support for power states D0 and D3 cold are required for PCI modems. 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. odem drivers must accept power management IRPs.FAQ Date: October 7, 1998; June 14, 2000 (PC99a:19.38,39)

B6.1.R Future RequirementsAnnouncement of additional future requirements will be published at http://www.microsoft.com/winlogo/modem/


1. Modem supports appropriate control commands (PC2001:MOD–368, MOD–376, MOD–386, MOD–387, MOD–388)

2. Modem call control meets The Video-Ready Modem Handbook, Revision 1.1 (PC2001:MOD–370)

3. [deleted]

4. [deleted]

5. Analog V.90 modems must be tested in conjunction with digital V.90 modems commonly deployed by Internet service providers (ISPs) (Telecommunications Industry Association (TIA) TSB-38 provides detailed test procedures and criteria) (PC2001:MOD–377, MOD–378)



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 (PC2001:MOD–379)

E-mail: Microsoft Outlook® Express over Microsoft Hotmail®.

Web browsing: Internet Explorer.

Video teleconferencing using H.323: Microsoft NetMeeting®.

6. ISDN modem supports asynchronous-to-synchronous conversion and RFC 1662 (PC2001:MOD–385)

7. Telephony applications meet communication and performance requirements (PC2001:MOD–389, MOD–390

System with telephony applications uses a common set of audio I/O devices for system audio and telephony applications

Telephony applications that support devices such as speakerphone or handset telephony must comply with telecomm industry requirements for such parameters as send and receive loudness, echo, and so forth

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.

B7.0 Network DevicesRequirements for enterprise-class network components, 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.

B7.1 General NetworkAll general requirements in B1.0 are included by reference.All bus-specific requirements in B2.0 are included by reference.

B7.1.1 Windows Compatibility1. Windows 2000/Windows Me and Windows 98: NDIS 5.0 miniport driver

model: “Network Drivers – Design Guide and Reference” in the Windows 2000 DDK (PC99a:20.7; 20.59)

2. Drivers for connection-oriented media: Part 2, Chapters 1–7 and 9, and Part 4, Chapter 1, of the “Network Drivers Design Guide” in the Windows 2000 DDK



NDIS 5.0 CoNDIS miniports are preferred, but NDIS 4 WAN miniports are acceptable.

3. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/network/

4. Network INF Format for Windows 2000 and Windows 98: http://www.microsoft.com/hwdev/devdes/netinf.htm and “Installing Network Components” in the Windows 2000 DDK Windows 2000/Windows Me: New INF format is required (PC99a:20.60)

Note: Windows 2000 and Windows Me share the same INF search path (that is, .nt in the decorated INF file)

B7.1.2 Industry Standards1. Network Device Class Power Management Reference Specification, V. 1.0a:

http://www.microsoft.com/hwdev/specs/PMref/PMnetwork.htm (PC99a:20.55)

2. Home Phoneline Networking Alliance, (HomePNA) 1.0 specification: http://www.homepna.org

3. PCI Bus Power Management Interface Specification, Revision 1.1: http://www.pcisig.com/specs.html

B7.1.3 Quality1. Full NDISTest one-adapter pass with Driver Verifier enabled on logo’d

multiprocessor and uniprocessor systems:

Adapter automatically senses presence of functional network connection (PC99a:20.10)

Adapter automatically senses transceiver type (PC99a:20.11)

Adapter can transmit packets from buffers aligned on any boundary (PC99a:20.12)

Adapter communicates with driver across any bridge (PC99a:20.13)

Adapter supports filtering for at least 16 multicast addresses (PC99a:20.14)

Adapter and driver support promiscuous mode (PC99a:20.15)

2. Two-card/two-machine NDIS test pass with Driver Verifier enabled, with free driver files to capture any asserts (NDIS test pass only if applicable, with separate tests using free Ndis.sys without Driver Verifier and checked Ndis.sys with Driver Verifier) (PC99a:20.7)

3. PCI network adapters are bus masters (PC99a:20.17)

4. Run transport driver interface (TDI) test to ensure Transmission Control Protocol/ Internet Protocol (TCP/IP) endpoint reliability (PC99a:20.28,50)

For WAN devices, run Winsock stress test for the network protocols (TCP/IP and Internet packet exchange/sequenced packet exchange) to capture any driver instabilities (PC99a:20.50,58)



B7.1.4 Windows Experiences1. UI and strings are correct, and Help files exist and are correct for network device

installed

2. Any included diagnostics or utilities work and can be accessed from the NCP Advanced Properties page

3. ATM network devices meet minimal performance expectations (PC99a:20.31-39)

4. Features such as Wake-On-LAN (WOL) and D0-D3 power states are available, as applicable, and device correctly wakes from D3cold (PC99a:20.56)

Note: WOL support is not required in the following cases:

Bus-powered USB devices

Multifunction, broadband, or LAN emulation devices

Windows 98/Me: PC Card and CardBus devices; WOL Pattern Match capabilitiesWindows 2000: PC Card, CardBus, and USB devices

5. Remote boot and remote install options for connection-less LAN devices on PCI bus (PC99a:20.16)

6. NEW: Windows Me: HomePNA technology, if implemented, complies with HomePNA 1.0 (or later), with NDIS 5.0 miniport driver

7. Infrared device supports both fast IR and serial IR, and unattended driver installation requirements (PC99a:20.45-20.47)

8. Full-duplex adapter automatically detects and switches to full duplex mode

(PC99a:20.9)

9. Plug and Play capabilities support multiple adapters; all resource settings are reported in the UI (PC99a:20.53,20.54)


B7.1.5 FAQs1. Current Network Device FAQ items are collected at

http://www.microsoft.com/winlogo/network/

2. NDIS status codes and indication mechanisms: see NdisMIndicateStatus in the Windows 2000 DDK.

3. Server Design Guide Version 2.0 FAQ:

On 32- and 64-bit platforms that provide support for more than 4 GB of system memory, all PCI adapters, including 32-bit PCI adapters, must be able to 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 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.



Systems providing support for WinSock Direct Path (WSDP) connectivity meet requirements for device and driver support

Systems are not required to provide WinSock Direct Path (WSDP) connectivity capabilities. However, those systems that do must meet the following guidelines:

Networking hardware provides reliable transport in hardware. This is what allows the bypass of the TCP/IP stack in software.

Provide the necessary software and driver support to facilitate access using the fast alternate paths. This would include the “normal” NDIS 5.0-compliant miniport, plus a System Area Network WinSock provider and a System Area Network Management driver, as well as a System Area Network TDI provider. Installers for the above components and any needed network management software components must also be provided.FAQ Date: July 2, 1999

B7.1.R Future RequirementsAnnouncement of additional future requirements will be published at http://www.microsoft.com/winlogo/network/


1. [deleted]

2. [deleted]

3. Asynchronous Transfer Mode (ATM) adapters must be able to schedule cells on an unspecified bit rate (UBR) virtual circuit at a peak rate less than the line or link rate (PC2001:NET–270).Adapter that supports call responds to F4 and F5 calls. (PC2001:NET-272)

4. PCI-based network adapters must support D3cold (PC2001:NET–290)

5. [deleted]

6. ATM/DSL simultaneous connections require support for 32 or more connections (PC2001:NET–266)

7. [deleted]

8. [deleted]

9. Wireless networking requirements (PC2001:NET–277-NET–279)

Media adapter drivers support wireless extensions to NDIS

IEEE 802.11 wireless networking adapters support 11 Mb/s signaling using Direct Sequence Spread Spectrum and Wired Equivalent Privacy

10. Home network adapter supports home networking media; if HomePNA, comply with HomePNA 1.0 specification (PC2001:NET–283-NET–285)



11. External networking devices support standard control interfaces as applicable; all external USB networking devices must support USB Communications Class Device 1.1 (PC2001:NET–288)

12. 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. Future requirements for Bluetooth HCI are listed in B2.3.R.

B7.2 Cable ModemAll 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 Windows Compatibility1. Windows compatibility and implementation notes (general):

http://www.microsoft.com/hwdev/network/cable/

B7.2.2 Industry Standards1. Cablelans DOCSIS Data-Over-Cable Service Interface Specifications:

http://www.cablemodem.com/

B7.2.3 Quality1. Run 1-card NDIS tests and 2-machine TDI tests

B7.2.4 Windows Experiences1. Performance meets minimal expectations on high-end broadband network

devices (PC99a:20.31-39)

2. Integrated cable modem meets Windows Logo Program network adapter requirements (PC99a:20.28)

3. Integrated cable modem exposes an ATM or Ethernet interface (PC99a:20.29)

B7.2.5 FAQsSee B7.1.5

B7.2.R Future RequirementsSee B7.1.R

B7.3 DSL DeviceAll 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 Windows Compatibility1. Windows compatibility and implementation notes:

http://www.microsoft.com/hwdev/network/dsl/

2. External DSL Modems Design Guidelines: http://www.microsoft.com/hwdev/network/dsl/extdslmodems.htm

B7.3.2 Industry Standards1. An Interoperable End-to-End Broadband Service Architecture over ADSL

System: http://www.microsoft.com/hwdev/network/dsl/

2. ATM User-Network Interface Specification, V. 3.1: http://www.atmforum.com/atmforum/specs/approved.html

3. DSL modem supports industry standards (PC99:20.41)

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 Quality1. Run ATM Dial Up and file transfer protocol (FTP) stress tests (if applicable) to

capture any driver instabilities (PC99a:20.30,31)

B7.3.4 Windows Experiences1. All requirements in B7.1.3, except B7.1.4 (WOL and power management)

2. Performance meets minimal expectations on high-end broadband network devices (PC99a:20.31-39)

3. Integrated ADSL modem meets Windows Logo Program network adapter requirements (PC99a:20.41)

B7.3.5 FAQs1. See B7.1.5

2. ATM/ADSL simultaneous connections [Correction]: For a Client Integrated ATM/ADSL adapter, the minimum required support is for 16 simultaneous connections FAQ Date: October 7, 1998 (PC99a:20.31)


B7.4 ISDN Net DeviceAll 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 Windows CompatibilitySee B7.1.1


B7.4.3 QualitySee B7.1.3

B7.4.4 Windows Experiences1. Performance meets minimal expectations on high-end broadband network

devices (PC99a:20.31-39)

2. Device meets Windows Logo network adapter requirements (PC99a:20.21)

3. Device supports synchronous high-level data link control framing (PC99a:20.22)

4. NDIS interface and driver support raw, unframed synchronous B channel I/O

(PC99a:20.23)

5. Driver supports unattended installation, with limitations (PC99a:20.24)

6. Device includes software-selectable terminating resistors (PC99a:20.26)



B7.5 ATM DeviceAll 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.3 Quality1. See B7.1.3

2. Run ATM Dial Up and FTP stress tests

B7.5.4 Windows Experiences1. ATM adapter supports essential connections and connection management

(PC99a:20.31-39)



B8.0 Printers

B8.1 General PrintersAll general requirements in B1.0 are included by reference.All bus-specific requirements in B2.0 are included by reference.

B8.1.1 Windows Compatibility1. Windows 2000: “Part 3: Printer Drivers and Spooler Components” in the

Windows 2000 DDK

2. Windows 98/Me: “Printer INF File Extensions,” “Printer-Specific INF File Extensions Reference,” and DEVMODE function in the Windows 98 DDK

3. ICM APIs and functionality for Windows 98/Me and Windows 2000: Microsoft Platform SDK and “Color Management for Displays” in the Windows 2000 DDK

4. Windows compatibility and implementation notes: http://www.microsoft.com/hwdev/print/

5. NEW: Windows 2000: IEEE 1394 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.htmMarch 19, 1999 (PC99a:8.6, 8.19)

B8.1.2 Industry Standards1. Universal Serial Bus Device Class Definition for Printing Devices, Version 1.0

or later: http://www.usb.org

2. Legacy Plug and Play Guidelines (http://www.pcdesguide.org/LegacyPnP/)—for IEEE 1284 or serial port (PC99a:21.3-21.6, 21.10)




B8.1.3 Quality1. WinPARTy application printing accuracy (WinPARTy.exe)

2. Printable regions accuracy (PrntArea.exe) (PC99a:21.18)

3. Printer driver runs only in user mode ("Choosing User Mode or Kernel Mode" in the DDK)

4. DevMode structure support (PrDevCap.exe) (PC99a:21.12, 21.19, 21.20)

5. Windows 98/Me: Dynamic load/unload from RAM (HeapWalk.exe)

6. Printer INF file and installation (PC99a:21.11)

B8.1.4 Windows Experience1. Network Point-and-Print (PC99a:21.16)

2. ICM profile header validation (ProfWiz.exe) (PC99a:21.14)

3. Windows 2000: Net printer supports Standard Port Monitor (PC99a:21.8)

4. Port monitor software meets DDK guidelines (PC99a:21.15)

5. Device is available immediately following installation (PC99a:21.17)


B8.1.5 FAQs1. Current Print Device FAQ items are collected at

http://www.microsoft.com/winlogo/printer/

2. Windows 2000: Printer driver runs only in user mode [Clarification]: 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 (PC99a:21.19)

3. ECP mode [Logo Program Clarification]: Support for ECP mode is required; support for bi-direction mode is not required.FAQ Date: May 4, 2000

B8.1.R Future RequirementsAnnouncement of additional future requirements will be published at http://www.microsoft.com/winlogo/printer/


1. Plug and Play IDs must be specific, and INF [Install] sections must only key off the most specific IDs, as described in the Windows 2000 DDK and Windows 98 DDK (PC2001:PRNT–298)



2. Network Point-and-Print capability must accommodate file-number limits and other differences between operating systems that might run on the client and server (PC2001:PRNT–303)

3. Device associates an ICC profile. 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 (PC2001:PRNT–300)

4. Print device provides non-legacy port connection (PC2001:PRNT–294- PRNT–297)

5. Color printer complies with Windows Color Quality Specifications for Printer OEMs:http://www.microsoft.com/hwdev/color/ (PC2001:PRNT–301)

6. Driver solution for USB printer must take advantage of built-in operating system support for USB printers (documented in Windows 2000 DDK)

B9.0 Still Image Devices

B9.1 General Still Image DevicesAll general requirements in B1.0 are included by reference.All bus-specific requirements in B2.0 are included by reference.

B9.1.1 Windows Compatibility1. Still image driver support: “Part 4: Still Image Drivers” in the Windows 2000

DDK

Note: Digital still cameras that stream video while tethered must have WDM stream class drivers (PC99:15.52)

2. “Color Management for Still Image Devices” in the Windows 2000 DDK

3. Windows compatibility and implementation notes (general): http://www.microsoft.com/hwdev/stillimage/

4. Windows Me: Windows Image Acquisition driver support: http://www.microsoft.com/hwdev/wia/

5. Windows 2000: Still Image Architecture and Windows 2000: http://www.microsoft.com/hwdev/stillimage/w2STI.htm

B9.1.2 Industry Standards1. Photographic and Imaging Manufacturers Association (PIMA) 15740,

“Requirements for communication with digital photography devices”: http://www.pima.net/standards/it10a.htm#15740

2. USB Still Image Capture Class Specification (v.0.9 or later)

3. Plug and Play External COM Device Specification v.1.0 (PC99a:22.17)




B9.1.3 Quality1. Driver supports TWAIN 1.7, if TWAIN support is implemented (TwainTst.exe)

(PC99a:22.25)

2. NEW: Windows Me: Vendor provides a Windows Image Acquisition (WIA) driver or supports PIMA 15740 in camera firmware (See FAQ B9.1.5.4)

3. Windows 2000/Windows 98: Driver supports Still Image Architecture (STI) driver interface (StillVue.exe) (PC99a:22.23)

B9.1.4 Windows Experience1. Device uses USB or IEEE 1394 connection (PC99a:22.1)

2. Device associates an ICC profile. 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. (PC99a:22.3)

3. Digital still image device with an IR interface uses Fast IR, provides a secondary PC interface, and uses the Winsock interface (PC99a:22.5-6, 22.26)

Cameras that support IrTran-P v1.0 or later need not provide a Winsock interface-based driver

4. SCSI device attaches to any Logo’d SCSI controller (PC99a:22.8)

5. USB device supports string descriptors (PC99a:22.10)

6. Digital camera uses PC-compatible file system for removable storage (PC99a:22.14)

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

7. Daisy-chained parallel port imaging devices must be Plug and Play capable. (PC99a:22.20)

Design Guidelines: WIA: http://www.microsoft.com/hwdev/wia/

PC 99 System Design Guide: Chapter 22

B9.1.5 FAQs1. The current still image FAQ items are collected at

http://www.microsoft.com/winlogo/stillimage/

2. NEW: ATA Flash Cards [Logo Program clarification]: 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 (PC99a:22.14)

3. USB Mass Storage and Cameras [Clarification]: It 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 set in Windows Me and future operating systems. FAQ Date: November 24, 1999

4. NEW: Windows Me—Requirement for Still Image Devices: Still image devices are supported under WIA architecture or PIMA 15740. For the Windows Logo Program, the vendor must provide a WIA driver for all still image peripherals. For digital cameras, however, vendors have the option of providing a WIA driver or supporting PIMA 15740 in camera firmware. This choice is provided because Windows Me will provide a WIA driver for PIMA 15740 devices, accomplishing the same functional purpose. This requirement is effective July 1, 2000.

Note: Optimum 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 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 deliver this functionality after initial installation.FAQ Date: December 22, 1999

B9.1.R Future RequirementsAnnouncement of additional future requirements will be published at http://www.microsoft.com/winlogo/stillimage/


1. Still image devices meet minimum throughput requirements (PC2001:IMAG–312)

Fast IR at 80 Kpixels/s

USB at 120 Kpixels/s

IEEE 1394 at 200 Kpixels/s



2. Imaging devices resolve at least 1/4 line per claimed pixel resolution in both directions (PC2001:IMAG–315)

3. Digital camera stores images in JPEG-compressed file format (PC2001:IMAG–314—

was recommended in PC99:22.15)

4. Asynchronous imaging device with an IEEE 1394 interface uses SBP2Port (PC2001:IMAG–321—was recommended in PC99)

B10.0 Storage Controllers and Devices

B10.1 General StorageAll 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 System Requirement Details item A1.1.4.

B10.1.1 Windows Compatibility1. Windows 2000: “Part 3: Storage Drivers” in the Windows 2000 DDK

2. Windows 98/Me: “Storage Technology Reference” in the Windows 95 DDK (included with the Windows 98 DDK)

3. Int 13h Extensions: “Chapter 14: Int 13 Extension APIs” in the “Storage Technology Reference” in the “Windows 95 Documentation” in the Windows 98 DDKWindows 98/Me/2000: Option ROM or BIOS supports Int 13 for boot devices (PC99a:3.45)

4. Windows compatibility and implementation notes: http://www.microsoft.com/hwdev/storage/

B10.1.2 Industry Standards1. AT Attachment 2 [X3T9.2 948D] and AT Attachment 3 [X3T10 2008D]

standards

2. ATA/ATAPI-4 Revision 17 Working Draft Standard (ATA/ATAPI-4)(replaces PC 99 references to SFF 8020i)Other ATA standards: Global Engineering Documents

3. ATAPI Removable Media Device BIOS Specification (ARMD), V. 1.0http://www.phoenix.com/products/specs.html

4. MMC-2 Multi-Media Command Set-2: ftp://ftp.t10.org/t10/drafts/mmc2/mmc2r11a.pdf (incorporates information defined in Enhanced Music CD Specification)

5. National Committee for Information Technology Standards (NCITS):

RBC Draft Proposal T10/97-260r0: ftp://ftp.t10.org/t10/drafts/rbc/rbc-r10a.pdf



NCITS SBP-2 transport protocols [ANSI NCITS 3.25-1998]

6. Small Computer Interface (SCSI-2) [X3T9.2-375R] standardSmall Computer Interface (SCSI-3) Parallel Interface [X3T9.2/91-10] standardGlobal Engineering Documents

7. Compaq-Intel-Phoenix BIOS Boot Specification, v.1.01;El Torito—Bootable CD-ROM Format Specification, v.1.0http://www.ptltd.com/techs/specs.html (PC99a:3.5.2)

8. Media Status Notification Support Specification, Version 1.03 http://www.microsoft.com/hwdev/respec/ (PC99a:18.2; see FAQ B10.1.5.4)

9. IEEE 1394 storage class devices: conform to the ANSI standards for SBP-2 (Serial Bus Protocol) with the appropriate command set: RBC (Reduced Block Commands) or MMC-2 (PC99a:8.6, 8.19)

10. Universal Serial Bus Mass Storage Class Specification Overview, Revision 1.0 (PC99a:18.7; see FAQ B10.1.5.5)

B10.1.3 Quality1. Windows 2000/Windows Me: Pass all required HCT tests

Windows 98: Pass all required BKIT tests

2. Windows installation requirements:

Operating system installs properly with drive attached

Current Service Pack installs properly

Any drivers provided with the controller or device install properly

Pass clean installation and upgrade tests (for appropriate operating systems):

Windows 98/Me Clean Installation Test (FAT16)Windows NT 4.0 > Windows 2000 Upgrade TestWindows 98/Me > Windows 2000 Upgrade Test (FAT16 > FAT32 upgrade;

FAT32 > NTFS conversion)Windows 2000 Clean Installation Test (NTFS)

3. Windows 2000: Support Crashdump for any storage controller that can be configured as the boot device

B10.1.4 Windows Experience1. Configuring or adding the device to the system must not require changing

jumpers or switches on either the device or the system board

2. Bootable controller supports El Torito No Emulation mode; option ROM supports Int 13h Extensions (PC99a:10.2, 10.3)

3. Removable media devices support media status notification (PC99a:18.3; see FAQ

B10.1.5.4)

4. Dynamic resource configuration is supported for all devices (PC99a:18.12, 18.33)



5. Device driver for partitioned media supports all Windows and Windows 2000 partition types (PC99a:18.42)

6. Controller, hard drive, and CD/DVD devices support bus mastering and UDMA/DMA (PC99a:18.1; see FAQ B10.1.5.3)

Design Guidelines:

PC 99 System Design Guide: Chapter 18

Server Design Guide 2.0: Chapter 5

B10.1.5 FAQs1. Current storage FAQ items are collected at

http://www.microsoft.com/winlogo/storage/

2. Server Design Guide Version 2.0 FAQ:

On 32- and 64-bit platforms that provide support for more than 4 GB of system memory, all PCI adapters, including 32-bit PCI adapters, must be able to 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 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. FAQ Date: July 2, 1999

3. ATA Ultra DMA and bus master requirements [Correction]: ATA and ATAPI devices must meet the following support requirements and recommendations for Ultra DMA and IDE Bus Master DMA.Support for Ultra DMA:

Required for ATA controllers and ATA devices

Recommended for ATAPI peripherals (required with the release of Windows Whistler)However, ATAPI devices might be connected to the ATA bus (which is required to support UDMA). Therefore, to ensure that ATAPI devices will tolerate Ultra DMA, ATAPI devices must support the termination scheme as defined in ATA/ATAPI-4.

4. Support for IDE 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 drivesFAQ Date: March 5, 1999 (PC99a:18.1)

5. Media status notification [Correction]: 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.FAQ Date: March 19, 1999 (PC99a:18.2)

Device type Media status notification implementation

All CD or DVD devices (independent of interconnect)

Required. Comply with ANSI NCITS T10 Multi-Media Command Set-2 (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. See Chapter 18 section 24.

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 NCITS Reduced Block Commands standard is recommended.

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 Future RequirementsAnnouncement of additional future requirements will be published at http://www.microsoft.com/winlogo/storage/


1. Advances to industry standards:

SPI-3 or later standard (PC2001:STOR–346)

ATA/ATAPI-5 (PC2001:STOR–347)

2. Support is required for the READ CD-DA command as defined in the MMC-2 standard (PC2001:STOR–354)



3. Mobile Note: Discrete PCI ATA controllers in mobile docking stations implement in PCI Native-Mode ATA (PC2001:STOR–351)

4. DELETED

5. Programmed I/O (PIO)support is allowed only for Compact Flash memory 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.) (PC2001:STOR–341)

B10.2 IDE ATA/ATAPI Controllers/DevicesAll 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 IDE controllers are submitted as reference motherboard implementations—two different motherboard implementations are required for Windows Logo qualification.

B10.2.1 Windows Compatibility1. Windows 98/Me: Enabling IDE DMA on Windows-based Systems:

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

B10.2.2 Industry Standards1. ATA/ATAPI-4 Revision 17 Working Draft Standard (ATA/ATAPI-4):

Global Engineering Documents (PC99a:10.1)

B10.2.3 Quality1. Function testing with devices connected:

ATA hard drive and CD-ROM drive attached and pass all required HCT and BKIT tests

CD-Record(able) (CD-R) or CD-ReWrite(able) (CD-RW) drive attached, functionality tested, and passes all required HCT and BKIT tests

Tape drive attached and passes all required tape drive tests

Removable media drive attached and passes all required removable media drive tests

DVD drive attached and functionality tested (movie playback)

Test controller in “loaded bus” configuration (devices connected to all positions)

Controller functions properly with devices in device 0, device 1, and cable-select configurations

Partitions are created and formatted with prescribed file systems on attached hard drives both during Setup and after installation is complete



Hard disk drive can be converted from FAT16 to FAT32, FAT to NTFS; removable media drive media can be converted from FAT16 to FAT32:removable media with MTBF similar to hard drives also can be converted to NTFS

2. Windows 2000: Disk mirror created across two identical IDE hard drives; passes all required HCT tests

B10.2.4 Windows Experience1. Windows 98/Me: Runs in 32-bit protected mode after installation (PC99a:18.40)

2. Windows 2000/Windows Me: Large partition support (>8 GB) and ability to boot from loader

3. NEW: Hibernation support [new for Windows Me]

4. Windows 2000/Windows Me: ATA controllers and devices support Ultra DMA, do not claim 3F7h and 377h (PC99a:10.7, 10.16, 18.6)

5. Dual ATA adapters use single FIFO with asynchronous access or dual FIFOs and channels; ATA disk drive supports (PC99a:10.4, 10.5)

6. Controller and peripheral connections include Pin 1 cable designation with keyed and shrouded connectors (PC99a:10.8)

7. Peripherals comply with ATA/ATAPI-4 (replaces SFF 8020i v.2.5) (PC99a:10.9)

8. ATAPI devices support DEVICE RESET command (PC99a:10.12)

9. ATA device supports ATA STANDBY command (PC99a:10.18)

B10.2.5 FAQsSee B10.1.5


10.3 SCSI Controllers/DevicesAll 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 Windows Compatibility1. SCSI Configured Automatically (SCAM) support is disabled by default

(PC99a:11.18)



B10.3.2 Industry Standards1. Small Computer Interface (SCSI-2) [X3T9.2-375R] standard

Small Computer Interface (SCSI-3) Parallel Interface [X3T9.2/91-10] standardGlobal Engineering Documents

B10.3.3 Quality1. Function testing with devices connected:

CD-ROM and hard drives attached, functionality tested, and pass all required HCT and BKIT tests

CD-R or CD-RW drive attached and passes all required functionality tests

Tape drive is attached and passes all required tape drive tests

Removable media drive is attached and passes all required removable media drive tests

Attached hard drives can be low-level formatted; partitions are created and formatted with prescribed file systems on attached hard drives during Setup and after installation is complete

Duplicate adapter installed, hard drive and CD-ROM drive connected to duplicate adapter; passes all required HCT tests against both adapters in system

Functionality as secondary, non-boot adapter

Hard disk drive can be converted from FAT16 to FAT32, FAT to NTFS; removable media drive media can be converted from FAT16 to FAT32removable media with MTBF similar to hard drives also can be converted to NTFS

Windows 2000: Create disk mirror across two identical SCSI hard drives and pass all required HCT tests

Windows 2000: Adapter is set to asynchronous negotiation and passes all required HCT tests

If device supports WIDE SCSI, verify this support with WIDE SCSI hard drive set to WIDE SCSI ID (8 through 15) and pass all required HCT tests


2. NEW: Windows 2000: Hibernation support Windows Me: Hibernate is not supported for SCSI


4. Adapter is capable of sharing IRQ and works behind a PCI-PCI bridge

5. Connector and terminator requirements:

Bus type is clearly indicated on connectors for all adapters, peripherals, cables, and terminators (PC99a:11.5)



Differential devices support DIFFSENS as defined in SPI standard (PC99a:11.6)

Automatic termination circuit and SCSI terminators meet SCSI-3 standard (PC99a:11.7)

Terminator power is supplied to the SCSI bus with overcurrent protection (PC99a:11.8)

External connector meets SCSI-2 or later standard (PC99a:11.9)

Controller and peripheral connections include Pin 1 cable designation; shielded device connector meets SCSI-2 or later standard (PC99a:11.11, 11.13)

External devices use automatic termination or an accessible on-board termination switch (PC99a:11.12)

Note: Not required for Fault-Tolerant RAID devices where the terminators are considered to be a Field Repalceable Unit (FRU).

Hot-pluggable SCSI uses connectors defined in SPI-3, Annex C (SCA)

6. Controller and peripherals implement SCSI bus data protection signal (PC99a:11.10)

7. Hardware supports the SCSI-3 STOP/START UNIT command to decrease power consumption (PC99a:11.22, 11.23)

8. Option ROM supports virtual DMA services (PC99a:11.4)

9. SCSI erasable drive supports SCSI commands (SDG2:163)

10. SCSI controller provides multi-initiator support if the controller provides external device connection capability for use as a cluster node (SDG2:135)

B10.3.5 FAQsSee B10.1.5


B10.4 Hard Disk DrivesAll 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 IDE/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.2 Industry Standards1. SMART IOCTL API Specification, v.1.1:

http://www.microsoft.com/hwdev/respec/storspec.htm (if SMART drive support is implemented)

B10.4.3 Quality1. Pass all required HCT Hard Drive tests on attached hard disk drives with

attached CD-ROM drive

2. Partitions created and formatted with prescribed file systems on attached hard drives, both during Setup and after installation is complete

3. Hard disk drive functions properly with WHQL-designated core controllers:

SCSI hard disk drive with WHQL-designated core SCSI controllers

IEEE 1394 hard drive with WHQL Logo–qualified IEEE 1394 controllers

USB hard disk drive functions on USB bus and passes USB Self-Test program

Fibre Channel hard disk drive functions properly with WHQL-designated core Fibre Channel controllers

IDE/ATAPI hard disk drive functions properly in device 0, device 1, and cable-select configurations

4. Hard disk drive can be converted from FAT16 to FAT32, FAT to NTFS

5. Windows 2000: Disk mirror created across two identical hard drives and passes all required HCT tests

B10.4.4 Windows Experience1. Hard disk supports bus mastering and UDMA/DMA (PC99a:18.1; see FAQ B10.1.5.3)


3. Device driver for block-mode device supports extended BIOS parameter blocks (BPBs) (PC99a:18.43)

B10.4.5 FAQsSee B10.1.5


B10.5 CD/DVD DrivesAll 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 IDE/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 Windows Compatibility1. DVD Multifunction Devices: Avoiding Multiple Logical Unit Devices:

http://www.microsoft.com/hwdev/dvd/multiLUN.htm

B10.5.2 Industry Standards1. ATA/ATAPI-4 Revision 17 Working Draft Standard (ATA/ATAPI-4)

(replaces PC 99 references to SFF 8020i)Other ATA standards: Global Engineering Documents (PC99a:18.19)

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

3. SFF 8070i (ATAPI Removable Rewritable Media Devices specification) for block rewritable optical ATAPI devices: ftp://fission.dt.wdc.com/pub/standards/SFF/specs/INF-8070.PDF (PC99a:18.24)

4. SFF 8090: ftp://fission.dt.wdc.com/pub/standards/SFF/specs/

5. Universal Disk Format Specification, v.1.5 and 2.0: http://www.osta.org/

6. ECMA Standards ECMA-267 (DVD-ROM), ECMA-274 (DVD+RW), and ECMA-273 (DVD-RAM): http://www.ecma.ch/

7. DVD Specifications for Rewritable Disc, Part 1: Physical Specifications: http://www.toshiba.com


CD-ROM Drives: CD-ROM drive functionality (Autostart, CD Player, Multiple-Session Photo CD, Multimedia CD, Soft Eject)

CD-R and CD-RW Drives: CD-ROM drive functionality, CD-R, and CD-RW drive functionality (Audio CD copy, Data CD copy, ISO Image CD Creation, and CD-RW full erase)

DVD-ROM Drives: CD-ROM drive functionality tests; DVD-ROM drive functionality (Encarta DVD suite: Encyclopedia Deluxe, Bookshelf, Virtual Globe); DVD-ROM drive movie playback verification (Movie Playback, Multi-language Audio Check, Multi-language Subtitle Check, Multi-angled DVD Disk Support); UDF file read testNote: For DVD capability, it is required to use Logo’d DVD decoder/video adapter combination or WHQL-designated Soft DVD application with sufficient system capability for movie playback testing

SCSI CD or DVD drive functions properly with WHQL-designated core SCSI controllers



IDE/ATAPI CD-ROM, CD-R/CD-RW, or DVD-ROM drive functions properly in device 0, device 1, and cable-select configurations

IEEE 1394 CD-ROM, CD-R/CD-RW, or DVD-ROM drive functions properly with Logo’d IEEE 1394 controllers

USB CD-ROM, CD-R/CD-RW, or DVD-ROM drive functions properly on USB bus and passes USB Self-Test program

2. Windows 98/Me: Media Player functionality with .AVI and .MPG files

B10.5.4 Windows Experience1. DMA capability on IDE/ATAPI CD-ROM, CD-R/CD-RW, and DVD-ROM

drives (PC99a:18.1; see FAQ B10.1.5.3)

2. CD device requirements:

Provides 8x minimum transfer rate or better performance (PC99a:18.16; see FAQ

B10.5.5.2)

CD-enhanced compatible (PC99a:18.17)

Supports specified logical and physical CD formats (PC99a:18.18, 18.20)

Supports digital audio detection and digital audio quality on CD-ROM drive: http://www.microsoft.com/hwdev/devdes/cddigital.htm (PC99a:18.22; see FAQ

B10.5.5.3)

3. DVD storage device requirements:

Provides 2 MB per second minimum transfer rate or better performance anywhere on the disc (PC99a:18.25; see FAQ B10.5.5.2)

Supports logical and physical CD formats, MMC-2, and defect management (PC99a:18.27, 18.28, 18.30; see FAQ B10.5.5.4)

B10.5.5 FAQs1. See B10.1.5

2. Minimum speed requirement for CD and DVD devices [Logo Program Clarification]: The minimum speed requirement for CD devices (8x) is needed for production-level CD reading on Windows platforms. The requirement applies to the minimum read speed on any production-level CD media, such as application or game software, at any location on the disc. This requirement does not apply to end-user recorded CD data discs, or to discs being read in error-correcting, defect management mode. It is expected that OEMs will continue to ship CD drives that produce an acceptable user experience and to conform to the required specifications.

DVD devices must provide 2 MB per second minimum transfer rate or better performance. 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. It is expected that OEMs will continue to ship DVD drives that produce an acceptable user experience and conform to the required specifications.FAQ Date: July 8, 1999 (PC99a:18.16, 18:25)

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 (PC99a:18.6)

4. CD Capabilities and CD Audio [Correction]: 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. FAQ Date: October 7, 1998 (PC99a:18.22)

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 (PC99a:18.30)

6. CSS copyright protection [Logo Program Clarification]: 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 (PC99a:18.31)


B10.6 Removable Media DrivesAll 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 IDE/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 Windows Compatibility1. Windows 2000: Removable Storage Management and Windows 2000:

http://www.microsoft.com/hwdev/storage/RSM.htm


B10.6.3 Quality1. Removable media drive functions properly with WHQL-designated controllers:

SCSI removable media drive with WHQL-designated core SCSI controllers

IEEE 1394 removable media drive with WHQL-Logo qualified 1394 controllers

USB removable media drive functions on USB bus and passes USB Self-Test program

IDE/ATAPI removable media drive functions properly in device 0, device 1, and cable-select configurations

Floppy capability of drive, if drive is dual-function removable media drive/floppy drive

2. Partitions are created and formatted with prescribed file systems on removable media drive

3. Removable media drive media can be converted from FAT16 to FAT32:removable media with MTBF similar to hard drives also can be converted to NTFS


2. To tolerate Ultra DMA, ATAPI devices must support the termination scheme defined in ATA/ATAPI-4 (See FAQ B10.1.5.3)

B10.6.5 FAQsSee B10.1.5


B10.7 Tape DrivesAll 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 IDE/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.2 Industry Standards1. Tape-related standards (SDG2:183):

Cartridge drives: QIC 157 Revision D, “Common SCSI/ATAPI Command Set For Streaming Tape”: http://www2.qic.org/qic/html/standards/15x.x/qic157d.pdf

ATA tape drive complies with packet passing protocol in ATA/ATAPI-4 Revision 17 Working Draft Standard (ATA/ATAPI-4)(replaces PC99 references to SFF 8020i)

SCSI tape drive complies with SCSI tape command set (SDG2:184)

B10.7.3 Quality1. Tape drive functions properly with WHQL-designated controllers:

IDE/ATAPI tape drive functions properly in device 0, device 1, and cable-select configurations

SCSI tape drive functions properly with WHQL-designated core SCSI controllers

USB tape drive functions on USB bus and passes USB Self-Test program

IEEE 1394 tape drive with Logo’d IEEE 1394 controllers

2. Pass WHQL tests, including Tape Drive Backup/Restore

B10.7.4 Windows Experience1. To tolerate Ultra DMA, ATAPI devices must support the termination scheme

defined in ATA/ATAPI-4 (See FAQ B10.1.5.3)

2. Win32-based backup solution provided with device (SDG2:185)

B10.7.5 FAQsSee B10.1.5


B10.8 Media Changer DevicesAll 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.3 Quality1. Driver passes Driver Verifier test and Pooltag testing

2. Pass WHQL testing:

Controller and driver pass testing on all OS-supported file systems with current Service Pack installed

MCStress test (general stress testing)

MCTest (API level testing, uses Windows 2000 RSM layer)

Basic functionality testing for any failure notification or system management software

3. Any features or capabilities documented must pass functional testing based on the general requirements for storage devices, device drivers, and provided supporting software, including testing that is not explicitly described in the Test Kit procedures

B10.8.4 Windows Experience1. If CD changer device supports 7 discs or less, comply with MMC-2 (SDG2:186;

PC99a:18.21)

2. SCSI tape changer and drive support auto-configuration (SDG2:187)

3. SCSI tape and optical disk changer support auto-configuration (SDG2:188)

Design Guidelines:

Hardware Design Guide Version 2.0 for Windows NT Server: Chapter 5

B10.8.5 FAQsSee B10.1.5


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: This guide focuses solely on requirements for client systems. If this device is implemented on a client system, compatibility testing is required for Windows 2000 and, optionally, Windows NT 4.0+SP 6a or later.



B10.9.1 Windows Compatibility1. SCAM is disabled by default, if SCSI device

B10.9.2 Industry StandardsSee B10.1.2 and B10.3.2

B10.9.3 Quality1. Functionality testing:

Controller, device, and drivers pass testing on all operating system–supported file systems with current Service Pack installed

Controller passes all related testing with these devices installed (multimedia testing for CD-ROM, Backup/Restore, and Tape I/O testing for tape drives)—unless tape and/or CD-ROM devices are listed as “unsupported” by the manufacturer

RAID-JBOD device pass testing on all operating system–supported file systems with current Service Pack installedIf RAID-JBOD includes a SAF-TE device, it too must pass all testing

Controller/device and driver (if applicable) can install Windows 2000 to a drive and/or array controlled by the controller, boot to a >9 GB partition, and successfully create a crashdump file

2. Drivers pass Driver Verifier test and Pooltag testing

3. RAID cluster device:

Cluster device is Logo qualified in its device type category

Product passes low-level hardware testing to verify support of key SCSI/disk mechanisms and commands necessary for MSCS to complete failover and failback operations on disks and, therefore, on shares created on those disks (Clisrv test)

Product passes 8-hour failover test run during which each server node will be crashed repeatedly and the shared disk resources will be transferred between crashed and live servers (CrashNNode test)

4. RAID multi-cluster device:

Product passes low-level hardware testing to verify support of key SCSI/disk mechanisms and commands necessary for MSCS to complete failover and failback operations on disks and therefore on shares created on those disks (Nodesim test)

Note: The 3-day stress test run specified for “Designed for Windows 2000 Server” testing is not required for client testing.

5. Pass WHQL testing:

Stress testing against supported RAID hardware array types



Stress testing against all operating system–supported software array types including arrays striped across multiple controller types (SCSI and Fibre Channel)

Dynamic device failure testing for all redundant FRUs (Field Replaceable Units)

Static device failure testing for all redundant FRUs

Hot Spare support testing, if supported

Basic functionality testing for any failure notification or system management software

RAID-JBOD device: all tests except testing for RAID hardware array types

B10.9.4 Windows Experience1. All external connectors are labeled with icon for bus type

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

3. RAID support include notification of failed drive (SDG2:206)

4. RAID subsystem supports automatic replacement of failed drive (SDG2:207)

Design Guidelines:


B10.9.5 FAQs1. Option ROM requirements: Option ROMs for RAID controllers implemented

on systems or as add-in controller cards must fully support Int 13. FAQ Date: March 19, 1999 (PC99a:11.3)


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: This guide focuses solely on requirements for client systems. If this component is implemented on a client system, compatibility testing is required for Windows 2000 and, optionally, Windows NT 4.0+SP 6a or later.

B10.10.1 Windows CompatibilitySee B10.1.1 and B10.3.1



B10.10.2 Industry Standards1. Fibre Channel Physical (FC-PH), Revision 4.3: http://www.fibrechannel.com

B10.10.3 Quality1. FC adapter and hard:

Note: The 3-day stress test run specified for “Designed for Windows 2000 Server” testing is not required for client testing.

2. FC adapter - pass WHQL testing:

Stress testing against supported RAID hardware array types

3. FC hard drive - pass WHQL testing:

On all operating system–supported file systems with current Service Pack installed

FC hard drive can install Windows 2000

B10.10.4 Windows Experience1. Option ROMs for FC bootable controllers support extended Int 13 functions;

El Torito support is not required

2. Use X3T11 Private Loop Direct Attach profile as storage base to use native operating system support (SDG2:162)

Design Guidelines:


B10.10.5 FAQsSee B10.1.5


B11.0 Streaming Media and Broadcast

B11.1 General StreamingAll general requirements in B1.0 are included by reference.All bus-specific requirements in B2.0 are included by reference.

B11.1.1 Windows Compatibility1. Device support is based on DirectX foundation class and WDM stream class

(PC99a:15.17)

WDM support: “Kernel Streaming Drivers Design Guide” in the Windows 2000 DDK



All video input sources and capture devices must implement driver support as defined for WDM Stream class in “Kernel Streaming Drivers Design Guide” in the Windows 2000 DDK

Minidriver implementation for subpicture decoder: Microsoft DirectX SDK in the Windows 2000 DDK

2. Windows compatibility and implementation notes—streaming: http://www.microsoft.com/hwdev/stream/

B11.1.2 Industry Standards1. ANSI/SMPTE standards:

http://www.smpte.org/stds/stsubj.html

2. DVB/DAVIC (Digital Video Broadcasting/Digital Audio-Visual Council): http://www.davic.org; http://www.dvb.org

3. IEC 61883 Digital Interface for Consumer Electronic Audio/Video Equipment: https://domino.iec.ch/webstore/webstore.nsf/Welcome?ReadForm

B11.1.3 Quality1. Synchronized audio and video, no tearing or other artifacts (macroblocking,

jaggies, and so on) (PC99a:15.21.2, 21.3)

B11.1.4 Windows Experience1. Interoperability with operating system and Microsoft DirectShow (PC99a:15.16,

15.27)

2. Support subpicture compositing and closed captioning (PC99a:15.25)

3. Device installation requirements:

Dependent video device is not independently enumerated (PC99a:15.51)

Software drivers are installed during hardware driver installation (PC99a:15.53)

4. MPEG and video component requirements:

Separate MPEG-2 hardware decoder for high-definition video does not cause PCI bus contention (PC99a:15.12)

PCI-based sources of uncompressed standard-definition digital video support bus mastering with scatter/gather DMA (PC99a:15.13)

All MPEG-2 decoders can accept an MPEG-2 elementary stream (PC99a:15.14)

All MPEG transport stream information is available to the central host processor (PC99a:15.15)

Background tasks do not interfere with MPEG-2 playback (PC99a:15.16)

De-interlacing of standard-definition video meets requirements (PC99a:15.22)

Mobile Note: MPEG sources support bus mastering; MPEG-2 MP@ML playback and video decode implementations meet requirements, with exceptions for mobile PCs (PC99a:15.11, 15.19, 15.21)




B11.1.5 FAQsCurrent video-related FAQ items are collected at http://www.microsoft.com/winlogo/video/

B11.1.R Future RequirementsNo additional requirements are currently identified. Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/video/


1. All graphics and video capabilities must be fully supported at 1024 × 768, 32 bpp mode or better (PC2001:VID–209)

2. Mobile Note: Mobile system meets standard video requirements for appropriate display panel resolution if resolution is 1024 × 768 × 24 bpp or higher (PC2001:MOBL–230)

TV-style MPEG-2 video stream playback consumes less than an average of 60 percent of CPU measured during any given minute.

There is no bus bandwidth restriction for consumption of memory, PCI, or AGP bandwidth in TV-style MPEG-2 video stream playback.

3. Mobile Note: Mobile system meets basic video requirements for appropriate display panel resolution if resolution is lower than 1024 × 768 × 24 bpp (PC2001:

MOBL–231)

There is no CPU utilization limitation and no 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.

B11.2 DVD PlaybackAll 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.2.1 Windows Compatibility1. “DirectShow and DVD Support” in the Windows 2000 DDK

2. Windows compatibility and implementation notes—DVD Playback: http://www.microsoft.com/hwdev/dvd/

B11.2.2 Industry Standards1. DVD Specification, Version 1.0: http://www.toshiba.com

2. DVD physical format documents: Global Engineering Documents: http://global.his.com



B11.2.3 Quality1. MPEG-2 MP@ML playback (720 × 480 @ 60 fields/second, 720 × 576 @ 50

fields/second) with smooth motion portrayal (PC99a:15.19.1)

2. Alpha blending of subpicture content on static menus (PC99a:15.25)

B11.2.4 Windows Experience1. Experience should be the same or better than with a stand-alone player

2. Multiple aspect ratio content is displayed correctly, with the default being the information in the MPEG header (PC99a:15.21.4)

3. DVD decoder requirements:

Driver correctly handles media types, time discontinuity, and decode-rate adjustment (PC99a:15.24)

All DVD video decoders must support Line21 closed-caption data (PC99a:15.28; see FAQ 11.2.5.2)

4. Support seamless DVD-Video 1.0 navigation (PC99a:15.27)


B11.2.5 FAQs1. Current DVD-Video FAQ items are collected at

http://www.microsoft.com/winlogo/video/

Video-related FAQs are at http://www.microsoft.com/winlogo/video/

2. DVD-Video navigation requirement: [Logo Program Clarification]: If non-Microsoft-provided DirectShow filters replace any filters included with the operaitng system, replacements provide a functional and qualitative superset of the replace modules. Any replacement DirectShow filter must be able to accept the exact same input and output formats provided by the operaitng system version of the DirectShow filter.

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.

On systems that do not run Windows Me, 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 or a private interface.



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

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 (PC99a:15.29)



1. Hardware supports video overlay surface with scalingSize increase to 1280 × 720 or larger; screen resolution color depth increase to 16 bpp and 32 bpp; scaling engine accepts input at a rate of 720p60 (1280 horizontal pixels) and 540p60 (bobbed from 1080i) (1280 horizontal pixels) (PC2001:GRPH–207)

2. DVD video playback meets colorspace conversion defined in ITU-R [BT.601-5] (PC2001:GRPH–208)

3. DVD-Video players must navigate chapter breaks seamlessly, even if the underlying elementary streams were created as separate program chain (PGC) objects (PC2001:VID–222)

B11.3 TV TunerAll 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 Windows Compatibility1. Microsoft TV platform: http://www.microsoft.com/tv/

2. Windows 2000/Windows Me and Windows 98: NDIS 5.0 miniport driver model: “Network Drivers – Design Guide and Reference” in the Windows 2000 DDK (PC99a:20.7; 20.59)

B11.3.2 Industry Standards1. ATSC DTV Specification: http://www.atsc.org/Standards/stan_rps.html



B11.3.3 Quality1. No tearing or other artifacts (macroblocking, jaggies, and so on) (PC99a:15.35)

2. Output video data at 3.7 MB/second, minimum (PC99a:15.31)

3. Playback (720 × 480 @ 60 fields/second, 720 × 576 @ 50 fields/second) with smooth motion portrayal (PC99a:15.35)

4. Video input provides VBI data, and VBI capture makes VBI data available to the CPU; close captioning doesn’t cause frame dropping or high CPU usage (PC99a:15.33, 15.38)

B11.3.4 Windows Experience1. VBI capture oversamples VBI data at least four times (PC99a:15.37)

2. Digital broadcast module can receive:

All streams contained in the particular transport stream (PC99a:15.39)

Full bandwidth from each frequency (PC99a:15.40)

A minimum of 16 simultaneous elementary streams (PC99a:15.41)

3. Digital broadcast module provides signal quality and other diagnostic information (PC99a:15.44)

4. Advanced Television Systems Committee (ATSC) DTV tuner/demodulator is fully implemented (PC99a:15.47)

5. NDIS 5.0 miniport driver provided for digital broadcast receiver (PC99a:15.55)


B11.3.5 FAQsCurrent video-related FAQ items are collected at http://www.microsoft.com/winlogo/video/



1. TV video playback meets colorspace conversion defined in ITU-R [BT.601-5] (PC2001:GRPH–208)

2. VBI capture samples VBI data exactly 4.7 or 5 times (PC2001:VID–225)

3. Video input devices must use WDM device drivers (PC2001:VID–210)

4. Digital broadcast module can receive a minimum of 32 simultaneous elementary streams (PC2001:VID–228)



B11.4 Video Input/CaptureAll 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 Windows Compatibility1. Windows compatibility and implementation notes—Video Capture:

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

2. Digital Video Camcorder Support in Windows 98 and Windows 2000: http://www.microsoft.com/hwdev/vidcap/DVCam.htm

3. WDM Video Capture Overview: http://www.microsoft.com/hwdev/desinit/vidcap.htm

B11.4.2 Industry Standards1. ATSC DTV Specification: http://www.atsc.org/Standards/stan_rps.html

2. AV/C Digital Interface Command Set VCR Subunit Specification, Version 2.0.1 (from http://www.1394TA.org)

B11.4.3 Quality1. No tearing or other artifacts (macroblocking, jaggies, and so on) (PC99a:15.35)

2. Output video data at 3.7 MB/sec, minimum (PC99a:15.31)

3. NEW: IEEE 1394 digital video (DV) camcorders implements mandatory VCR subunit commands. 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.

4. Analog input supports 720 × 480 decode to 4:2:2

5. Frame rate is within 0.2 percent of PAL 25.0fps or NTSC 29.97fps standard

B11.4.4 Windows Experience1. Analog video decoder such as NTSC/PAL/SECAM meets quality requirements

(PC99a:15.30)

2. Video input or capture device provides raw sampled VBI data (PC99a:15.32)

3. Digital video camera uses external bus support (PC99a:15.33)

4. Video input image orientation identification meets requirements (PC99a:15.34)

5. NEW: 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.5 FAQs1. Current video-related FAQ items are collected at

http://www.microsoft.com/winlogo/video/

2. Test Clarification: 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 (PC99a:15.30)



1. Video implementations meet basic video quality requirements; Video implementation must preserve source quality during playback, storage, or processing of the video streams and not adversely affect overall PC performance

(PC2001:VID–215)

2. VBI data must not be affected by any type of video operation, (cropping, scaling, or frame dropping), that the hardware or the driver is performing on the related video frames (PC2001:VID–224)

B12.0 Miscellaneous

B12.1 Multifunction DevicesAll 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 Windows Compatibility1. Device drivers comply with DDK requirements for its operating system

(Windows 2000 DDK or Windows 98 DDK), and third-party applications comply with Platform SDK requirements

2. Windows compatibility and implementation notes—multi-function: http://www.microsoft.com/hwdev/mf/

3. Windows compatibility and implementation notes per bus and device class: http://www.microsoft.com/hwdev/

4. Designing Multifunction Devices for Windows Operating Systems: http://www.microsoft.com/hwdev/mf/download/mfdesign.zip



B12.1.2 Industry Standards1. See related industry standards for each device class implemented on the multi-

function device

B12.1.3 Quality1. Functional units on a multifunction device must not have start-order

dependencies

2. Resource requirements of one functional unit must not be expressed in terms of another functional unit

3. Operation of one functional unit must not affect or interfere with the operation of another functional unit on the multifunction device or on the system as a whole

4. Each functional unit must be enumerated and its resource requirements communicated to the operating system so the system can load the necessary drivers and assign resources to the different units in any order

B12.1.4 Windows Experience1. Separate drivers are required for separate functions (PC99:3.21.4)

2. MFP devices correctly implement multi-function include Driver support, INF requirements, device ID, resource allocation, and other Plug and Play capabilities comply with “Multifunction Print Device Design Guidelines” at http://www.microsoft.com/hwdev/mf/mfp.htm

Design Guidelines: PC 99 System Design Guide: PC99a:3.21

B12.1.5 FAQs1. Current general FAQ items are collected at


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



3. The following do not require individual IDs:

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 2000, Mf.sys must be used to enumerate the dependent devices.FAQ Date: May 28, 1999

B12.1.R Future RequirementsNo additional requirements are currently identified. Announcement of additional future requirements will be published at http://www.microsoft.com/winlogo/system/


1. There are no start order dependencies between separate function drivers. 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.

2. Each independent function can be used concurrently, with no hidden dependencies. Separate functional units must be able to operate concurrently, without interfering with each other or with other devices on the system.

3. Each function can be power managed independently. 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 D3cold to D0) without losing functionality and without requiring user intervention to restore functionality. All functional units that support wakeup capabilities must correctly support wake from D3cold.


129

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 99 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 to arrange design reviews. If you are not working with a program manager, please send mail to [email protected] with “Program Contact Request” in the Subject line. Note that Microsoft cannot guarantee that it can schedule reviews for all manufacturer requests.

Participate in Developing Standards Attend Microsoft design review events, the Windows Hardware Engineering

Conference (WinHEC), and other Microsoft conferences to ensure your new designs are in sync with Windows system and component architectures.

Review draft versions of the Windows Logo Program requirements: http://www.microsoft.com/winlogo/

Participate in industry groups, forums, and committees developing strategic specifications and interfaces.

Participate in developing design guidelines in PC and server design guides by providing feedback on review drafts.

Register as a system design guide reviewer and obtain drafts at: http://www.pcdesguide.org/

Register as a server design guide reviewer by writing to [email protected]

Participate in the System Test Implementers Forum at: http://www.systemtest.org/

Subscribe to Microsoft Hardware Newsletter for information about Windows platform technologies, and check the Hardware Developer’s web site for design and driver tips:http://www.microsoft.com/hwdev/

Apply the Requirements in Your Design 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: http://www.microsoft.com/winlogo/

Ensure that the system’s ACPI BIOS is correctly implemented and passes the Microsoft ACPI HCT.The OEM must make sure to increase the OEMRevision field in the ACPI FACP to ensure that the system will run in ACPI mode under Windows 2000. To ensure that Windows 2000 does not mistake the BIOS for one entered on the Windows Non-compliant ACPI list, always update this field whenever the BIOS is revised.

Properly implement Plug and Play support for all devices—in particular, ensure that all PCI components properly implement unique SIDs and SVIDs, as described at:http://www.microsoft.com/hwdev/devdes/pciids.htm

Design and implement a Fast POST in the BIOS, and minimize the preloading of utilities and applications based on the guidelines provided at:http://www.microsoft.com/hwdev/NewPC/fast-boot.htm

Provide software that does not rely on real mode.

Provide system utilities, emergency repair software, and upgrades on non-floppy media such as CD or DVD disc.

Design and build legacy-free systems based on the guidelines provided at:http://www.microsoft.com/hwdev/NewPC/LF.htm

For OEMs, migrate all bundled devices to nonlegacy interfaces, such as USB and IEEE 1394.

For IHVs, build HID-compliant input devices, and implement nonlegacy interfaces for other device classes.

Request Early Technical Design Reviews Contact your Microsoft program manager to request a technical review for new

chipset, component, and system designs, so Microsoft architects can work with your architects in early phases to identify issues and to ensure that both designs and related software support are optimized.

If you are not currently working with a Microsoft program manager, send e-mail to [email protected] with “Program Contact Request” in the Subject line. Please be sure to include your name, title, company name, company type (IHV, ISV, or OEM), and phone and fax numbers, plus the principal devices or systems you manufacture.

Submit Hardware to Microsoft for Testing Submit prototypes to Microsoft early and often. Prototype testing in Windows

labs is strongly encouraged to identify design issues early. For information, send e-mail to [email protected].

Any new or revised systems, devices, and drivers should be submitted to WHQL for Windows Logo testing.



Participate in Microsoft Plugfests, Meltdown compatibility testing, and industry test events, such as USB Implementers Forum Plugfests. These events help identify firmware and driver issues before production-rate development.

Attend driver development labs at Microsoft, whenever invited.

Develop Drivers Based on Current DDKs Receive the DDK as part of MSDN Professional Subscription (you must

specifically request the DDK), or download the current DDK from the web at no charge: http://www.microsoft.com/ddk/

Use the DDK samples and documentation. For most WDM drivers, use the Windows 2000 DDK.

Test Beta Releases and Test for Upgrade Beta releases of Windows are distributed as part of MSDN Professional

Subscriptions. Submit bugs you find using the mechanism defined in the beta release package.

Test to ensure that customers have a smooth upgrade path to Windows 2000 operating systems.

After Windows Millennium Edition, the next version of Consumer Windows will be based on the Windows 2000 code base. For systems where Windows Millennium Edition will be preinstalled (or with Windows NT 4.0 and earlier versions of Windows 95/98), your test matrix should include upgrading new systems to Windows 2000, to identify hardware or BIOS constraints that might prevent smooth transition for your customers.

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.

APCI HCT http://www.microsoft.com/hwdev/acpihct.htm

Legacy-free HCT and OEM Test Kits for Windowshttp://www.microsoft.com/oemtest/index.htm

Windows HCTshttp://www.microsoft.com/hwtest/testkits/

DDK test tools, including Driver Verifierhttp://www.microsoft.com/ddk/

Sign All Drivers and Get the Windows Logo Make sure all drivers have digital signatures for both Windows Millennium

Edition and Windows 2000 operating systems: http://www.microsoft.com/hwdev/supportability/

Submit hardware and drivers with INF files to WHQL for testing. Submission guidelines are defined on:http://www.microsoft.com/hwtest/sysdocs/



Ensure Users Can Get BIOS and Driver Updates Make updated ACPI BIOSes available on the web. See:

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

Submit drivers for inclusion on Windows Update. Drivers must be tested and digitally signed by WHQL to be published on the Windows Update web site, as described at: http://www.microsoft.com/hwdev/supportability/
