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
1
About the Microsoft Windows Logo ................................................................................................. 1
“Designed for Windows” Logo Options ............................................................................................ 2
Windows Logo Program Dates ........................................................................................................ 3
What’s New in This Version ............................................................................................................ 4
How to Use These Guidelines ......................................................................................................... 5
Chapter 2 PC Hardware Requirements for Windows Logo
Chapter 3 Recommendations and Future Requirements
7
15
Recommended System Capabilities.............................................................................................. 16
Recommended End-user Experience ............................................................................................ 17
Recommended Device and Driver Capabilities ............................................................................. 18
“Best Practices” Recommendations .............................................................................................. 20
Chapter 4 Getting the Windows Logo for Hardware
21
Appendix A PC System Requirement Details
23
How to Use This Appendix ............................................................................................................ 23
A1.0 General PC System Requirements ....................................................................................... 24
A2.0 Desktop Client Requirements ............................................................................................... 34
A3.0 Mobile Client Requirements .................................................................................................. 35
A4.0 Legacy-Free System Requirements ...................................................................................... 41
Appendix B Device Requirement Details
45
How to Use This Appendix ............................................................................................................ 45
B1.0 General Device and Driver Quality ........................................................................................ 46
B2.0 Bus/Device Controllers ......................................................................................................... 49
B2.1 CardBus/PCMCIA Controllers and Devices ...................................................................... 49
B2.2 IEEE 1394 Controllers and Devices .................................................................................. 51
B2.3 Infrared/Wireless .............................................................................................................. 53
B2.4 Parallel/Serial Devices ...................................................................................................... 54
B2.5 PCI Controllers and Devices ............................................................................................. 56
B2.6 USB Controllers and Devices ........................................................................................... 60
B3.0 Audio Devices ....................................................................................................................... 61
B3.1 General Audio .................................................................................................................. 61
B4.0 Display .................................................................................................................................. 68
B4.1 Display Adapters/Chipsets ............................................................................................... 68
B4.2 Monitors ........................................................................................................................... 75
B5.0 Input and HID........................................................................................................................ 78
B5.1 General Input.................................................................................................................... 78
B5.2 Keyboard .......................................................................................................................... 80
B5.3 Input/Pointing ................................................................................................................... 81
B5.4 Input/Game ...................................................................................................................... 82
B5.5 Input/Keyboard-Video-Mouse ........................................................................................... 83
B5.6 Smart Card Readers......................................................................................................... 84
B6.0 Modems ................................................................................................................................ 86
B6.1 General Modem ................................................................................................................ 86
B7.0 Network Devices ................................................................................................................... 90
B7.1 General Network............................................................................................................... 90
B7.2 Cable Modem ................................................................................................................... 94
B7.3 DSL Device ...................................................................................................................... 94
B7.4 ISDN Net Device .............................................................................................................. 95
B7.5 ATM Device ...................................................................................................................... 96
B8.0 Printers ................................................................................................................................. 97
B8.1 General Printers ............................................................................................................... 97
B9.0 Still Image Devices ............................................................................................................... 99
B9.1 General Still Image Devices ............................................................................................. 99
B10.0 Storage Controllers and Devices ....................................................................................... 102
B10.1 General Storage ........................................................................................................... 102
B10.2 IDE ATA/ATAPI Controllers/Devices ............................................................................ 106
10.3 SCSI Controllers/Devices ............................................................................................... 107
© 1999-2000, Microsoft Corporation. All rights reserved.
iv
B10.4 Hard Disk Drives .......................................................................................................... 109
B10.5 CD/DVD Drives ............................................................................................................ 110
B10.6 Removable Media Drives .............................................................................................. 113
B10.7 Tape Drives .................................................................................................................. 114
B10.8 Media Changer Devices ............................................................................................... 115
B10.9 RAID ............................................................................................................................ 116
B10.10 Fibre Channel ............................................................................................................. 118
B11.0 Streaming Media and Broadcast ....................................................................................... 119
B11.1 General Streaming ....................................................................................................... 119
B11.2 DVD Playback .............................................................................................................. 121
B11.3 TV Tuner ...................................................................................................................... 123
B11.4 Video Input/Capture...................................................................................................... 125
B12.0 Miscellaneous ................................................................................................................... 126
B12.1 Multifunction Devices .................................................................................................... 126
Appendix C Designing for Success
© 1999-2000, Microsoft Corporation. All rights reserved.
129
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 serverspecific components. For information, see
http://www.microsoft.com/winlogo/Server/.
About the Microsoft Windows Logo
Microsoft offers the Windows Logo Program to help customers identify systems and
peripherals that meet a baseline definition of platform features and quality goals that
ensure a good Windows experience for the end user. The Windows Logo is not
intended to communicate the specific technical capabilities of any particular 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 1
Introduction to Windows Logo Program for Hardware
2
Customer Benefits
Windows Logo Program requirements are intended to support a good user experience
with the Windows operating system. In this context, a “good user experience” means
a reliable, consistent experience with system hardware, firmware, 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 Options
Microsoft 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:
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 1
Introduction to Windows Logo Program for Hardware
3

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 Dates
Dates 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 1
Introduction to Windows Logo Program for Hardware
4
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 availability 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 Version
This 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 1
Introduction to Windows Logo Program for Hardware
5
How to Use These Guidelines
This 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 1
Introduction to Windows Logo Program for Hardware
6
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 requirements
and 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]
http://www.microsoft.com/msdn/subscribe/
© 1999-2000, Microsoft Corporation. All rights reserved.
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 Requirements
The 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 Requirements
WL-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 enduser experience
WL-8
System components migrate correctly upon upgrade to a later operating
system
Rationale
For minimum memory and processor performance: These minimum requirements
ensure that the system will provide an adequate user experience when running
applications designed for the targeted platform.
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 2
PC Hardware Requirements for Windows Logo
8
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 systems
At 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
experience
Because 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 2
PC Hardware Requirements for Windows Logo
9
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 devices
The 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 guidelines
The 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 Requirements
These 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,
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 2
PC Hardware Requirements for Windows Logo
10
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” Requirements
For new or other technologies where specific compatibility tests have not been
defined under the Windows Logo Program (as provided in the HCTs from WHQL),
or where design guidelines have not been provided in a PC Design Guide, the
following requirements apply:
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 2
PC Hardware Requirements for Windows Logo
11

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 goals
Hardware 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).
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 2
PC Hardware Requirements for Windows Logo

Operating system detection software does not report the presence of Super I/Odependent 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 devices
The goal for this requirement is correct support for complete operating system
management of system configuration and behavior. This requirement applies for all
BIOS, bus, and device components in a system. In particular, this includes:

Windows 2000–ready, ACPI-compliant BIOS.

Correct implementation of Plug and Play and power management.
This requirement is based on fundamental operating system requirements, industry
specifications, and 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 experience
The 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
12
Chapter 2
PC Hardware Requirements for Windows Logo
13
WL-8. System components migrate correctly upon upgrade to later operating
system
A 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 2
PC Hardware Requirements for Windows Logo
14

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 OEMprovided 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 2000
These 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 3
Recommendations and Future Requirements
16
Windows Logo Program Recommendations and Future Requirements
R1.
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 Capabilities
R1. System meets “legacy free” design requirements
Windows 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 device
This 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 system
All 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 3
Recommendations and Future Requirements
17
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 states
At 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 Experience
R5. System and component design practices follow accessibility guidelines
At 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 3
Recommendations and Future Requirements
18
Recommended Device and Driver Capabilities
R6. Graphics adapter supports 3-D features for the next-generation Windows
GDI
GDI+ 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 guidelines
On 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 3
Recommendations and Future Requirements
19
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 environment
The 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 guidelines
Several types of devices can be designed to migrate functions from peripheral
hardware to Windows drivers, saving bill-of-materials costs at the expense of CPU
resources. Examples of such devices include soft audio, soft Public Switched
Telephone Network (PSTN) modems (V.34, V.90)and soft asymmetric digital
subscriber line (ADSL) modems (G.992.2). There are several risks:

Any soft device may undermine the system, depending on how it uses CPU and
system resources.

Any soft device may be vulnerable to failures or performance issues created by
other parts of the system, depending on how other device drivers compete with it
for CPU and system resources.

A combination of soft devices may be much less stable than either device alone.
Requirements for soft modems are in development. These requirements will reference
absolute CPU consumption rather than percentages of the available CPU.
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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 3
Recommendations and Future Requirements
20
Guidelines are in development for soft audio and soft digital subscriber line (DSL)
modems.
“Best Practices” Recommendations
R11. Installed software meets guidelines for globalization
These guidelines include the following:

Use Unicode as the character encoding to represent text.

Consider using a multilingual user interface: launch the application in the default
user interface language, and offer the option to change to other languages.

Use the Win32 application programming interface (API) National Language
Support functions to handle locale-sensitive data.

Watch for Windows messages that indicate changes in the input language, and
use that information for the spell checker, selecting fonts, and so on.

Use the Script APIs (Uniscribe) to lay out formatted text on a page, to allow
display of multilingual text and complex scripts such as Arabic, Hebrew, Hindi,
Tamil, and Thai.

Test applications in multiple configurations, mixing the system locale, user
locale, input locale, and user interface (UI) language.
Design Guidelines: Developing International Software for Windows 95 and
Windows NT, by Nadine Kano, available online at
http://msdn.microsoft.com/library/books/devintl/s24ac.htm.
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.
© 1999-2000, Microsoft Corporation. All rights reserved.
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 Testing
To submit a system for Logo Program testing

Follow the submission rules at http://www.microsoft.com/hwtest/systems/
Submitting Devices for Windows Logo Program Testing
To 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 Submission
WHQL 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Chapter 4
Getting the Windows Logo for Hardware
Information Contacts for Windows Logo Testing
The up-to-date list of contacts is provided at
http://www.microsoft.com/hwtest/support/ (including additional contacts for serverrelated submissions).
© 1999-2000, Microsoft Corporation. All rights reserved.
22
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 2000
Windows Me
Windows 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 Appendix
PC System Sections and Subsections
In 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
24
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 References
The 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" Items
In 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 Compatibility
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
25

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 CompaqIntel-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. C
If 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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
26

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 stepping
See 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 Standards
1. 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.01
El 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
27
A1.3 Quality
1. 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 Experience
1. 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 adapter
Note: 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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
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 FAQs
1. 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.htm
For 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
29
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 systemboard devices, so the PCI SID must reflect that of the system-board manufacturer.
If an OEM chooses a riser card and driver from any riser card driver
manufacturer, the BIOS must populate the fields as follows:

The PCI SVID must reflect the Vendor ID assigned by the PCI special
interest group (SIG) to that OEM.

The SID must be unique for each AC ‘97 device configuration. For example,
for a modem-on-motherboard (MoM), modem riser (MR), or audio modem
riser (AMR) device, each SID must be unique.
If an OEM chooses a system board from a manufacturer that works with one or
more codecs, the following applies:

The SVID must reflect the Vendor ID assigned by the PCI SIG to that
system-board manufacturer.

The SID must be unique for each AC ‘97 codec/device configuration. For
example, for a MoM, MR, or AMR device, each SID must be unique.
For an AMR riser, the system BIOS must properly implement the detection
algorithm from Intel to verify that the hardware on an AMR/MR riser extension is
actually present. The detection algorithm is available at
ftp://download.intel.com/ial/scalableplatforms/audio/ac97bios.pdf
Similar provisions exist in the CNR and ACR specifications.
For information about WHQL testing for riser cards, see
http://www.microsoft.com/hwtest/.
See 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 mid1999, 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details

30
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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
31
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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
32
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 Requirements
Announcement 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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details

33
Windows 2000 Professional/Windows Whistler Professional:
128 MB RAM minimum, 128 KB of cache (enabled)
2. Uniprocessor desktop: S1, S3, S4, S5
Desktop 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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
34
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 32bit 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 Requirements
This section describes additional requirements or exceptions to the requirements
defined earlier in Section A1.0.
A2.1 Windows Compatibility
See A1.1
A2.2 Industry Standards
1. USB specifications, and other USB requirements as defined in Section B2.6 in
Appendix B, “Device Requirement Details”
A2.3 Quality
1. 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 time
See FAQ A2.5.2
A2.4 Windows Experience
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
35
A2.5 FAQs
1. Current general FAQ items are collected at
http://www.microsoft.com/winlogo/system/
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)
A2.R Future Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/system/
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 Requirements
This section describes additional requirements or exceptions to the requirements
defined earlier in Section A1.0.
A3.1 Windows Compatibility
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
36
A3.2 Industry Standards
1. 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 Quality
See A1.3
A3.4 Windows Experience
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
37
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
Design Guidelines: PC 99 System Design Guide: Chapter 6
A3.5 FAQs
1. Current general FAQ items are collected at
http://www.microsoft.com/winlogo/system/
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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
38
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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
39
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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
40
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)
A3.R Future Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/system/
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 ACPIbased 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
41
_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 Requirements
This section describes additional requirements or exceptions to the requirements
defined earlier in Section A1.0.
A4.1 Windows Compatibility
1. 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
42

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. Legacyfree 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 Standards
1. “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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
43
A4.3 Quality
1. 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 Experience
1. No external serial, parallel, or PS/2-compatible ports, and no ISA-based game
ports or MPU-401 (MIDI) ports available for external connection or detected by
the operating system
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.
A4.5 FAQs
1. Current general FAQ items are collected at
http://www.microsoft.com/winlogo/system/
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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix A
PC System Requirement Details
44
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 Requirements
No future legacy-free requirements are identified at this time. Announcement of
additional future requirements will be published at
http://www.microsoft.com/winlogo/system/
© 1999-2000, Microsoft Corporation. All rights reserved.
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 2000
Windows Me
Windows 98/Me
How to Use This Appendix
Device Class Sections and Subsections
In 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
46
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 References
The 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" Items
In 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 Quality
All devices must comply with these general device and driver compatibility and
quality requirements.
B1.1 Windows Compatibility
1. 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/
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
47
B1.2 Industry Standards
1. 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 Quality
1. Product is submitted to the appropriate WHQL test program and passes pretesting (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.exe
Windows 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 Experience
1. 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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
48

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 32bit) 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 FAQs
1. Current general FAQ items are collected at
http://www.microsoft.com/winlogo/system/
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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
49
B1.R Future Requirements
1. Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/system/
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 Devices
All general requirements in B1.0 are included by reference.
B2.1.1 Windows Compatibility
1. 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 Standards
1. 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.pccard.com/bookstore.htm
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
50
B2.1.3 Quality
1. Pass WHQL tests: Pcmcia.exe, Refresh.exe, Whqltest.vxd, plus relevant device
class tests for devices
B2.1.4 Windows Experience
1. 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)
Design Guidelines: PC 99 System Design Guide: Chapter 12
B2.1.5 FAQs
1. 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 16bit 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
51
ensures compatibility with the power management capabilities of Windows 2000.
FAQ date: October 7, 1998 (PC99a:12:19)
B2.1.R Future Requirements
No 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 Devices
All general requirements in B1.0 are included by reference.
B2.2.1 Windows Compatibility
1. 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 Standards
1. 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 1212r
Global 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)]
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
52

National Committee for Information Technology Standards (NCITS) T10,
Reduced Block Commands (RBC)

National Committee for Information Technology Standards (NCITS) T10
Multimedia Command Set 2 (MMC-2)

Storage class devices must conform to the ANSI standards for SBP-2 with
the appropriate command set: RBC or MMC-2

Printing devices using the SBP-2 protocol must conform to the guidelines set
in “SBP-2 Support and Windows 2000,” available at
http://www.microsoft.com/hwdev/print/sbp2_w2000.htm
FAQ date: March 19, 1999 (PC99a:8.6, 8.19)
B2.2.3 Quality
1. 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 1394a1999 (PC99a:8.34) See FAQ B2.2.5.2
Design Guidelines: PC 99 System Design Guide: Chapter 8
B2.2.5 FAQs
1. 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, 38
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
53
Devices 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 Requirements
Announcement 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/Wireless
All general requirements in B1.0 are included by reference.
B2.3.1 Windows Compatibility
1. 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 Standards
1. IrDA documents at http://www.irda.org/: Serial Infrared Physical Layer
Specification; Control IR Specification (PC99a:13.28)
B2.3.3 Quality
1. Pass WHQL tests: IrDA enumeration (PC99a:13.29, 13.30)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
54
B2.3.4 Windows Experience
1. 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)
Design Guidelines: PC 99 System Design Guide: Chapter 13
B2.3.5 FAQs
1. Current IR/wireless FAQ items are collected at
http://www.microsoft.com/winlogo/input/
B2.3.R Future Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/wireless/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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 Devices
All general requirements in B1.0 are included by reference.
B2.4.1 Windows Compatibility
1. Windows 2000: “Serial and Parallel Drivers” in the Windows 2000 DDK
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
55
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 Standards
1. Standard Signaling Method for a Bi-directional Parallel Peripheral Interface for
Personal Computers (IEEE 1284 specification): Global Engineering Documents
B2.4.3 Quality
1. Pass WHQL tests: COM PnP Enum, LPT PnP Enum
B2.4.4 Windows Experience
1. 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)
Design Guidelines: PC 99 System Design Guide: Chapter 13
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
B2.4.5 FAQs
1. Current legacy ports FAQ items are collected at
http://www.microsoft.com/winlogo/input/
B2.4.R Future Requirements
No 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 Devices
All general requirements in B1.0 are included by reference.
B2.5.1 Windows Compatibility
1. 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 Standards
1. 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/pcix_v10.pdf
6. Mini PCI specification
B2.5.3 Quality
1. Pass WHQL tests: PCItest.exe; INFCatReady
© 1999-2000, Microsoft Corporation. All rights reserved.
56
Appendix B
Device Requirement Details
57
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 Experience
1. 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)
Design Guidelines: PC 99 System Design Guide: Chapter 9
B2.5.5 FAQs
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
58
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 nonDAC 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
FAQ 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
59
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 Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/pci/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
60
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 Devices
All general requirements in B1.0 are included by reference.
Note that related BIOS and system-level requirements are included with the Windows
Logo Program requirements for systems (Appendix A).
B2.6.1 Windows Compatibility
1. 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 Standards
1. 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 Quality
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
61
B2.6.4 Windows Experience
1. 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)
Design Guidelines: PC 99 System Design Guide: Chapter 7
B2.6.5 FAQs
1. 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 Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/usb/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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 Audio
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
B3.1.1 Windows Compatibility
1. 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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
62
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.htm
DirectSound 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 Standards
1. 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 Quality
1. 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 Experience
1. 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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
63
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.
Design Guidelines: PC 99 System Design Guide: Chapter 17
B3.1.5 FAQs
1. 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
64

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
2.0 Vrms
FSIP (A-D-PC) microphone input
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)
30 Hz to 20.0 kHz4
80 dB FS A4
–65 dB FS4
Microphone input to line output
Frequency response (-3 dB)
Dynamic range (SNR)
THD+N (-3 dB FS)
100 Hz to 12.0 kHz
70 dB FS A4
–60 dB FS4
Line input to speaker output with 8-ohm
load2
30 Hz to 20.0 kHz4
Frequency response (-3 dB)
70 dB FS A4
Dynamic range (SNR)
–55 dB FS4
THD+N (-3 dB FS)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
65
Requirement
Value
Digital playback (PC-D-A)
for line output:
Frequency response (-3 dB)
44.1 kHz source material
48.0 kHz source material
30 Hz to 17.6 kHz4
30 Hz to 19.2 kHz4
Dynamic range (SNR)
80 dB FS A3, 4
THD+N (-3 dB FS)
–65 dB FS4
Digital recording (A-D-PC) for line input:
Frequency response
44.1 kHz destination
48.0 kHz destination
20 Hz to 17.6 kHz4
20 Hz to 19.2 kHz4
Dynamic range (SNR)
70 dB FS A4
THD+N (-3 dB FS)
–60 dB FS4
Digital recording (A-D-PC) for microphone input:
Frequency response (-3 dB)
22.05 kHz destination
100 Hz to 8.8 kHz
Dynamic range (SNR)
70 dB FS A4
THD+N (-3 dB FS)
–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
0.1%
Record
0.1%
1
For mobile PCs with 3.3 V audio subsystems, the required Full Scale Output Voltage for
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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
66
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:
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
67
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/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
68
B4.0 Display
B4.1 Display Adapters/Chipsets
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
B4.1.1 Windows Compatibility
1. Windows 2000: “Display and Video Miniport Drivers” and “Multiple Monitor
Support in the Display Driver” in the Windows 2000 DDK
Software 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 Standards
1. 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) Specification
http://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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
69
B4.1.3 Quality
1. 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 Experience
1. 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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
70
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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
71

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
Design Guidelines: PC 99 System Design Guide: Chapter 14
B4.1.5 FAQs
1. 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
72
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_BOTHINVSRCALPH
A
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 Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/display/
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
73
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
74
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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
75

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 required
Support 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 Monitors
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
B4.2.1 Windows Compatibility
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
76
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 Standards
1. EDID Standard, V. 3.0:
VESA Display Data Channel Standard
VESA and Industry Standards and Guidelines for Computer Display Monitor
Timing
http://www.vesa.org/standards.html
2. ICC Profile Format Specification, Spec ICC.1:1988-09 and Addendum 2,
ICC.1A:1999-04: http://www.color.org/profiles.html
3. USB Monitor Control Class Specification, Revision 1.0
4. DVI Revision 1.0: http://www.ddwg.org/
B4.2.3 Quality
1. Pass WHQL tests:

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
Design Guidelines: PC 99 System Design Guide: Chapter 16
B4.2.5 FAQs
1. Current Monitor FAQ items are collected at
http://www.microsoft.com/winlogo/display/
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
77
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 Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/display/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
1. Advance required standards:

VESA Enhanced Extended Display Identification Data Standard (E-EDID),
Release A
DDC2B (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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
78

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 Compatibility
1. 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 Standards
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
79
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 Quality
1. Pass WHQL tests: Winkey
2. All keys/buttons are functional at an end-user level after an INF installation
B5.1.4 Windows Experience
1. 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)
Design Guidelines: PC 99 System Design Guide: Chapter 13
B5.1.5 FAQs
1. Current input device FAQ items are collected at
http://www.microsoft.com/winlogo/input/
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 Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/input/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
80
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 Compatibility
1. 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
3. Windows compatibility and implementation notes (general):
http://www.microsoft.com/hwdev/input/
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 Standards
1. Keyboard Scan Code Specification:
http://www.microsoft.com/hwdev/desinit/scancode.htm
B5.2.3 Quality
1. 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 Experience
1. Any power management buttons implemented are ACPI compliant (PC99a:3.3)
2. Hot-plugging does not damage system or device
USB 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)
Design Guidelines: PC 99 System Design Guide: Chapter 13
B5.2.5 FAQs
1. Current keyboard FAQ items are collected at
http://www.microsoft.com/winlogo/input/
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
81
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)
B5.2.R Future Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/input/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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/Pointing
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general input requirements in B5.1 are included by reference.
B5.3.1 Windows Compatibility
1. 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
3. Windows compatibility and implementation notes (general):
http://www.microsoft.com/hwdev/input/
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 Standards
See B5.1.5
B5.3.3 Quality
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
82
B5.3.4 Windows Experience
1. Device functions correctly:

Wheel support (scroll, auto-scroll, pan, and zoom) in Microsoft® Office
2000 and Windows Explorer

In multimedia applications that require mouse support, such as Microsoft
Encarta® 99 and MS-DOS-based applications

When switching on-the-fly from MS-DOS-based applications to Windows
Design Guidelines: PC 99 System Design Guide: Chapter 13
B5.3.5 FAQs
Current pointing-device FAQ items are collected at
http://www.microsoft.com/winlogo/input/
B5.3.R Future Requirements
No new requirements are planned at this time. Announcement of additional future
requirements will be published at http://www.microsoft.com/winlogo/input/
B5.4 Input/Game
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general input requirements in B5.1 are included by reference.
B5.4.1 Windows Compatibility
1. 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
3. Windows compatibility and implementation notes (general):
http://www.microsoft.com/hwdev/input/
4. Designing HID Game Controllers for DirectInput:
http://www.microsoft.com/hwdev/devdes/hidgame.htm
B5.4.2 Industry Standards
See B5.1.5
B5.4.3 Quality
1. Installation meets dynamic miniport and user notification requirements
2. Pass WHQL tests: Game (Joydrv.exe)
B5.4.4 Windows Experience
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
83
Design Guidelines: PC 99 System Design Guide: Chapter 13
B5.4.5 FAQs
1. Current game port FAQ items are collected at
http://www.microsoft.com/winlogo/input/
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.4.R Future Requirements
No new requirements are planned at this time. Announcement of additional future
requirements will be published at http://www.microsoft.com/winlogo/input/
B5.5 Input/Keyboard-Video-Mouse
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general input requirements in B5.1, B5.2, and B5.3 are included by reference.
B5.5.1 Windows Compatibility
1. 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
3. Windows compatibility and implementation notes:
http://www.microsoft.com/hwdev/input/
B5.5.2 Industry Standards
See B5.1.5
B5.5.3 Quality
1. 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 Experience
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
84
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)
Design Guidelines: PC 99 System Design Guide: Chapter 13
B5.5.5 FAQs
Current KVM FAQ items are collected at http://www.microsoft.com/winlogo/input/
B5.5.R Future Requirements
No new requirements are planned at this time. Announcement of additional future
requirements will be published at http://www.microsoft.com/winlogo/input/
B5.6 Smart Card Readers
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general input requirements in B5.1 are included by reference.
B5.6.1 Windows Compatibility
1. 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 Standards
1. ISO/IEC DIS 7816 Identification Cards—Integrated circuit(s) cards with
contacts—Part 1: Physical characteristics: http://www.iso.ch/cate/d29257.html
Part 2: Dimensions and location of the contacts:
http://www.iso.ch/cate/d26536.html
Part 3: Electronic signals and transmission protocols:
http://www.iso.ch/cate/d14735.html
(PC99a:13.38, 13.39)
2. Interoperability Specification for ICCs and Personal Computer Systems:
http://www.pcscworkgroup.com/
B5.6.3 Quality
1. 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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
85
B5.6.4 Windows Experience
1. 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
state
Note: 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 FAQs
1. Current smart card FAQ items are collected at
http://www.microsoft.com/winlogo/input/
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)
B5.6.R Future Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/input/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
1. New industry standards required: (PC2001:SMRT–0153)
ISO/IEC 7811
Part 1: Embossing
Part 3: Location of embossed characters on ID-1 cards
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
86
ISO/IEC 7813:1995 Identification Cards—Financial transaction cards
ISO/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 Compatibility
1. 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 Standards
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
87
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 Experience
1. 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 ringing
ATD – dial
ATE - echo setting
ATH – hangup
ATI - get modem information
S0 - S0 register(0 value is to disable to accept ringing)
ATV - response code style
ATZ - reset
- - Initialize
- - Hard/Soft flow control
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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
88
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)
Design Guidelines: PC 99 System Design Guide: Chapter 19
B6.1.5 FAQs
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
89
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 500microsecond 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.htm
FAQ 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 powermanaged 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 Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/modem/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
90

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 Devices
Requirements 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 Network
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
B7.1.1 Windows Compatibility
1. 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
91
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 Standards
1. 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 Quality
1. 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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
92
B7.1.4 Windows Experiences
1. 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
capabilities
Windows 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)
Design Guidelines: PC 99 System Design Guide: Chapter 20
B7.1.5 FAQs
1. 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
93

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 Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/network/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
94
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 Modem
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general network device requirements in B7.1 are included by reference, except for
requirements specific to connection-less or LAN devices.
B7.2.1 Windows Compatibility
1. Windows compatibility and implementation notes (general):
http://www.microsoft.com/hwdev/network/cable/
B7.2.2 Industry Standards
1. Cablelans DOCSIS Data-Over-Cable Service Interface Specifications:
http://www.cablemodem.com/
B7.2.3 Quality
1. Run 1-card NDIS tests and 2-machine TDI tests
B7.2.4 Windows Experiences
1. 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 FAQs
See B7.1.5
B7.2.R Future Requirements
See B7.1.R
B7.3 DSL Device
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general network device requirements in B7.1 are included by reference, except for
requirements specific to connection-less or LAN devices.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
95
B7.3.1 Windows Compatibility
1. 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 Standards
1. 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 Quality
1. 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 Experiences
1. 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 FAQs
1. 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.3.R Future Requirements
See B7.1.R
B7.4 ISDN Net Device
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
96
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 Compatibility
See B7.1.1
B7.4.2 Industry Standards
See B7.1.2
B7.4.3 Quality
See B7.1.3
B7.4.4 Windows Experiences
1. 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.4.5 FAQs
See B7.1.5
B7.4.R Future Requirements
See B7.1.R
B7.5 ATM Device
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general network device requirements in B7.1 are included by reference, except for
requirements specific to connection-less or LAN devices.
B7.5.1 Windows Compatibility
See B7.1.1
B7.5.2 Industry Standards
See B7.1.2
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
97
B7.5.3 Quality
1. See B7.1.3
2. Run ATM Dial Up and FTP stress tests
B7.5.4 Windows Experiences
1. ATM adapter supports essential connections and connection management
(PC99a:20.31-39)
B7.5.5 FAQs
See B7.1.5
B7.5.R Future Requirements
See B7.1.R
B8.0 Printers
B8.1 General Printers
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
B8.1.1 Windows Compatibility
1. 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.htm
March 19, 1999 (PC99a:8.6, 8.19)
B8.1.2 Industry Standards
1. 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)
3. ICC Profile Format Specification, Spec ICC.1:1988-09 and Addendum 2,
ICC.1A:1999-04: http://www.color.org/profiles.html
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
98
B8.1.3 Quality
1. 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 Experience
1. 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)
Design Guidelines: PC 99 System Design Guide: Chapter 21
B8.1.5 FAQs
1. 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 Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/printer/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
99
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 Devices
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
B9.1.1 Windows Compatibility
1. 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 Standards
1. 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)
4. ICC Profile Format Specification, Spec ICC.1:1988-09 and Addendum 2,
ICC.1A:1999-04: http://www.color.org/profiles.html
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
100
B9.1.3 Quality
1. 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 Experience
1. 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 FAQs
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
101
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 Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/stillimage/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
102
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 Storage
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
BIOS support for boot devices: see System Requirement Details item A1.1.4.
B10.1.1 Windows Compatibility
1. 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
DDK
Windows 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 Standards
1. 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.0
http://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/rbcr10a.pdf

NCITS SBP-2 transport protocols [ANSI NCITS 3.25-1998]
6. Small Computer Interface (SCSI-2) [X3T9.2-375R] standard
Small Computer Interface (SCSI-3) Parallel Interface [X3T9.2/91-10] standard
Global Engineering Documents
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
103
7. Compaq-Intel-Phoenix BIOS Boot Specification, v.1.01;
El Torito—Bootable CD-ROM Format Specification, v.1.0
http://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 Quality
1. 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 Test
Windows 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 Experience
1. 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:
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
104

PC 99 System Design Guide: Chapter 18

Server Design Guide 2.0: Chapter 5
B10.1.5 FAQs
1. 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 drives
FAQ 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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
105
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
Required. Comply with either MMC-2
standard or SFF 8070i Version 1.1.
See Chapter 18 section 24.
(PD, MO, removable
magnetic floppy or rigid
based, and so on.)
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 Requirements
Announcement of additional future requirements will be published at
http://www.microsoft.com/winlogo/storage/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
106
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/Devices
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.
Note: Most IDE controllers are submitted as reference motherboard
implementations—two different motherboard implementations are required for
Windows Logo qualification.
B10.2.1 Windows Compatibility
1. Windows 98/Me: Enabling IDE DMA on Windows-based Systems:
http://www.microsoft.com/hwdev/devdes/idedma.htm
B10.2.2 Industry Standards
1. ATA/ATAPI-4 Revision 17 Working Draft Standard (ATA/ATAPI-4):
Global Engineering Documents (PC99a:10.1)
B10.2.3 Quality
1. 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 cableselect 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
107
2. Windows 2000: Disk mirror created across two identical IDE hard drives; passes
all required HCT tests
B10.2.4 Windows Experience
1. 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 FAQs
See B10.1.5
B10.2.R Future Requirements
See B10.1.R
10.3 SCSI Controllers/Devices
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.
Note: Most SCSI controllers submitted as reference motherboard implementations
can be submitted on a plug-in adapter card. However, if the reference motherboard
implementation must be submitted on a motherboard, two different motherboard
implementations are required for Windows Logo qualification.
B10.3.1 Windows Compatibility
1. SCSI Configured Automatically (SCAM) support is disabled by default
(PC99a:11.18)
B10.3.2 Industry Standards
1. Small Computer Interface (SCSI-2) [X3T9.2-375R] standard
Small Computer Interface (SCSI-3) Parallel Interface [X3T9.2/91-10] standard
Global Engineering Documents
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
108
B10.3.3 Quality
1. 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 FAT32
removable 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
B10.3.4 Windows Experience
1. Windows 98/Me: Runs in 32-bit protected mode after installation (PC99a:18.40)
2. NEW: Windows 2000: Hibernation support
Windows Me: Hibernate is not supported for SCSI
3. Windows 2000/Windows Me: Large partition support (>8 GB) and ability to
boot from loader
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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
109

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 FAQs
See B10.1.5
B10.3.R Future Requirements
See B10.1.R
B10.4 Hard Disk Drives
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.
All 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.1 Windows Compatibility
See B10.1.1
B10.4.2 Industry Standards
1. SMART IOCTL API Specification, v.1.1:
http://www.microsoft.com/hwdev/respec/storspec.htm (if SMART drive support
is implemented)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
110
B10.4.3 Quality
1. 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 Experience
1. Hard disk supports bus mastering and UDMA/DMA (PC99a:18.1; see FAQ B10.1.5.3)
2. Windows 2000/Windows Me: Large partition support (>8 GB) and ability to
boot from loader
3. Device driver for block-mode device supports extended BIOS parameter blocks
(BPBs) (PC99a:18.43)
B10.4.5 FAQs
See B10.1.5
B10.4.R Future Requirements
See B10.1.R
B10.5 CD/DVD Drives
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.
All 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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
111
B10.5.1 Windows Compatibility
1. DVD Multifunction Devices: Avoiding Multiple Logical Unit Devices:
http://www.microsoft.com/hwdev/dvd/multiLUN.htm
B10.5.2 Industry Standards
1. 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
B10.5.3 Quality
1. Pass WHQL tests:

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 CDRW 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 test
Note: 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
112

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 Experience
1. 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 FAQs
1. 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 errorcorrecting, 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
113
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.5.R Future Requirements
See B10.1.R
B10.6 Removable Media Drives
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.
All 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 Compatibility
1. Windows 2000: Removable Storage Management and Windows 2000:
http://www.microsoft.com/hwdev/storage/RSM.htm
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
114
B10.6.2 Industry Standards
See B10.1.2
B10.6.3 Quality
1. 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
B10.6.4 Windows Experience
1. Windows 98/Me: Runs in 32-bit protected mode after installation (PC99a:18.40)
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 FAQs
See B10.1.5
B10.6.R Future Requirements
See B10.1.R
B10.7 Tape Drives
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.
All 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.1 Windows Compatibility
See B10.1.1
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
115
B10.7.2 Industry Standards
1. 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 Quality
1. Tape drive functions properly with WHQL-designated controllers:

IDE/ATAPI tape drive functions properly in device 0, device 1, and cableselect 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 Experience
1. 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 FAQs
See B10.1.5
B10.7.R Future Requirements
See B10.1.R
B10.8 Media Changer Devices
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.
B10.8.1 Windows Compatibility
See B10.1.1
B10.8.2 Industry Standards
See B10.1.2
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
116
B10.8.3 Quality
1. 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 Experience
1. 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 FAQs
See B10.1.5
B10.8.R Future Requirements
See B10.1.R
B10.9 RAID
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general storage requirements in B10.1 are included by reference.
Note: 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 Compatibility
1. SCAM is disabled by default, if SCSI device
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
117
B10.9.2 Industry Standards
See B10.1.2 and B10.3.2
B10.9.3 Quality
1. 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 installed
If 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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
118

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 Experience
1. 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:

Hardware Design Guide Version 2.0 for Windows NT Server: Chapter 7
B10.9.5 FAQs
1. 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.9.R Future Requirements
See B10.1.R
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 Compatibility
See B10.1.1 and B10.3.1
B10.10.2 Industry Standards
1. Fibre Channel Physical (FC-PH), Revision 4.3: http://www.fibrechannel.com
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
119
B10.10.3 Quality
1. 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 Experience
1. 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:

Hardware Design Guide Version 2.0 for Windows NT Server: Chapter 5
B10.10.5 FAQs
See B10.1.5
B10.10.R Future Requirements
See B10.1.R
B11.0 Streaming Media and Broadcast
B11.1 General Streaming
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
B11.1.1 Windows Compatibility
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
120

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 Standards
1. 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 Quality
1. Synchronized audio and video, no tearing or other artifacts (macroblocking,
jaggies, and so on) (PC99a:15.21.2, 21.3)
B11.1.4 Windows Experience
1. 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)
Design Guidelines: PC 99 System Design Guide: Chapter 15
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
121
B11.1.5 FAQs
Current video-related FAQ items are collected at
http://www.microsoft.com/winlogo/video/
B11.1.R Future Requirements
No additional requirements are currently identified. Announcement of additional
future requirements will be published at http://www.microsoft.com/winlogo/video/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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 Playback
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general requirements in B11.1 are included by reference.
B11.2.1 Windows Compatibility
1. “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 Standards
1. DVD Specification, Version 1.0: http://www.toshiba.com
2. DVD physical format documents: Global Engineering Documents:
http://global.his.com
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
122
B11.2.3 Quality
1. 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 Experience
1. 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)
Design Guidelines: PC 99 System Design Guide: Chapter 15
B11.2.5 FAQs
1. 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 nonMicrosoft-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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
123
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)
B11.2.R Future Requirements
No additional requirements are currently identified. Announcement of additional
future requirements will be published at http://www.microsoft.com/winlogo/video/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
1. Hardware supports video overlay surface with scaling
Size 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 Tuner
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general requirements in B11.1 are included by reference.
B11.3.1 Windows Compatibility
1. 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 Standards
1. ATSC DTV Specification: http://www.atsc.org/Standards/stan_rps.html
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
124
B11.3.3 Quality
1. 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 Experience
1. 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)
Design Guidelines: PC 99 System Design Guide: Chapter 15
B11.3.5 FAQs
Current video-related FAQ items are collected at
http://www.microsoft.com/winlogo/video/
B11.3.R Future Requirements
No additional requirements are currently identified. Announcement of additional
future requirements will be published at http://www.microsoft.com/winlogo/video/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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)
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
125
B11.4 Video Input/Capture
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All general requirements in B11.1 are included by reference.
B11.4.1 Windows Compatibility
1. 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 Standards
1. 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 Quality
1. 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 Experience
1. 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.
Design Guidelines: PC 99 System Design Guide: Chapter 15
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
126
B11.4.5 FAQs
1. 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)
B11.4.R Future Requirements
No additional requirements are currently identified. Announcement of additional
future requirements will be published at http://www.microsoft.com/winlogo/video/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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 Devices
All general requirements in B1.0 are included by reference.
All bus-specific requirements in B2.0 are included by reference.
All requirements for each specific device class implemented in the multifunction
device are included by reference.
B12.1.1 Windows Compatibility
1. 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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
127
B12.1.2 Industry Standards
1. See related industry standards for each device class implemented on the multifunction device
B12.1.3 Quality
1. 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 Experience
1. 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 FAQs
1. Current general FAQ items are collected at
http://www.microsoft.com/winlogo/system/
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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix B
Device Requirement Details
128
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 Requirements
No additional requirements are currently identified. Announcement of additional
future requirements will be published at http://www.microsoft.com/winlogo/system/
New requirements for the Windows Logo Program, expected to take effect with the
release of Windows Whistler:
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.
© 1999-2000, Microsoft Corporation. All rights reserved.
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
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix C
Designing for Success
130
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.
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix C
Designing for Success
131

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 Windows
http://www.microsoft.com/oemtest/index.htm

Windows HCTs
http://www.microsoft.com/hwtest/testkits/

DDK test tools, including Driver Verifier
http://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/
© 1999-2000, Microsoft Corporation. All rights reserved.
Appendix C
Designing for Success
132
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/
© 1999-2000, Microsoft Corporation. All rights reserved.