Technologies

A key to successful advancement of audio in the PC is Windows Driver Model (WDM) Audio class support under Microsoft« Windows« 98 and Windows 2000. The new, more complete architecture performs all audio processing in kernel mode, which significantly improves latency. Code common to all audio hardware on a given bus is now part of the operating system, making for faster driver development with more consistent results.

Microsoft is encouraging implementation of external digital audio. USB and IEEE 1394 provide excellent mechanisms for delivering digital audio to external peripherals for high-quality conversion (greater than 85 dB dynamic range) to and from analog. In the near term, the popularity of USB makes it a natural choice. In the long term, the consumer-electronics industry envisions IEEE 1394 transporting audio and video among many devices in a simple, high-performance manner.

BPC (Broadcast Architecture) Technology
Microsoft« Windows« 98 includes built-in support for PCs that can receive and display broadband digital and analog broadcasts, blending television with new forms of information and entertainment. Broadcast client programming can include TV signal, audio, Internet information, and computer data content.

Important: All components must use a WDM minidriver instead of a Video for Windows (VfW) driver. Drivers for hardware decoders and for audio and video subsystems must be implemented as described in the Windows 98 DDK in order to support DirectShow, DirectDraw VPE, and WDM.

The digital broadcast receiver must use an NDIS 5.0 miniport driver. IP data carried in a transport stream, either encapsulated in the MPEG-2 private section format or PES, is made available through the Windows IP stack by the NDIS driver. See the Broadcast Architecture DDK for information about the related NDIS extensions, network adapter miniport, Broadcast Architecture transport, and other components.

CardBus Technology
Microsoft« Windows« 95/98 and Windows 2000 operating systems support PC Card socket controllers, 16-bit PC Card I/O cards (sometimes referred to as PCMCIA cards), and CardBus I/O cards. Memory 16-bit PC Card cards are supported only as legacy devices.

For any PC Card device to work effectively with Windows operating systems, the manufacturer must implement a minimum set of tuples documented in the PC Card standard. The operating system uses these tuples to identify and configure any 16-bit PC Card card, and it might also use these tuples for CardBus cards.

Display/Video Technology

Microsoft« Windows« 98 and Windows 2000 have different architectures for their graphics subsystems. Consequently, driver developers must create separate drivers for each operating system.

Driver support for hardware acceleration of 2-D and 3-D graphics is provided through Microsoft DirectDraw« and Direct3D«. For information about implementing driver support, see the Microsoft DirectX« DDK.

Other new capabilities under Windows 98 and Windows 2000 include support for multiple monitors and multiple adapters, plus support for AGP and other new technologies for the graphics subsystem. The DDKs provide the information developers need to ensure that their drivers take advantage of these capabilities.

To ensure high-quality support for Plug and Play under Windows 98 and Windows 2000, it is important that PCI-based adapters implement the Subsystem ID and Subsystem Vendor ID fields defined in the Subsystem ID ECN to PCI 2.1 or PCI 2.2. For information about implementing these fields for use under Microsoft operating systems, see PCI Device Subsystem IDs for Windows.

IEEE 1394 Technology
The IEEE 1394 high-speed serial bus complements USB by providing enhanced PC connectivity for a wide range of devices, including consumer electronics audio/video (A/V) appliances , storage peripherals, other PCs, and portable devices.

IEEE 1394 has been adopted by the consumer electronics industry and is expected to provide a volume, Plug and Play-compatible expansion interface for the PC. The 100-MB/sec, 200-MB/sec, and 400-MB/sec transfer rates currently specified in IEEE P1394.a and the proposed enhancements in IEEE P1394.b are well suited to multi-streaming I/O requirements.

Microsoft provides built-in support for IEEE 1394 in Windows« 98 and Windows 2000, with drivers compliant with the new Windows Driver Model (WDM).

These are the design concerns for PCs running Windows 98 and Windows 2000:

Compliance with IEEE 1394 standards, specifically IEEE 1394-1995 and IEEE P1394.a. Support for the 1394 Open Host Controller Interface (OpenHCI) specification, specifically OHCI Revision 1.0.
Plug and Play support for device configuration, control and status registers (CSRs), connectors and cabling, and connection fault handling.
Cable power distribution, including requirements for source devices, sink devices, self-powered devices, and supporting CSRs.
Device power management, CSRs, and soft-power protocols.
Device command protocols for audio, video imaging, still imaging, and storage device classes.

Infrared and Wireless Technology

Infrared support in Microsoft« Windows« 2000 and Windows 98 is based on standards developed by the Infrared Data Association (IrDA). Both operating systems include support for the IrDA Data standards, including Fast Infrared (FIR) and Serial Infrared (SIR). Windows 2000 also supports the IrTran-P image exchange protocol, and the IrLPT printing protocol.

Drivers for IrDA devices are implemented as NDIS 5.0 miniports

Input and HID Technology

Microsoft« Windows« 98 and Windows 2000 include support for USB and for legacy implementations such as PS/2 type connections for input devices. USB is the recommended connection for input devices on new PC systems.

Note: All input devices that do not use drivers that are built into the operating system should support Microsoft« DirectInput«, which provides a low-level, high-performance input device API to support a keyboard, mouse, joystick, and so on. Input devices should also be able to correctly provide simultaneous input so that no input device is disabled when another input device is in use. For information about implementing drivers that support simultaneous use of devices, see the Microsoft« DirectX« DDK.

Human Interface Devices

Microsoft Windows 98 and Windows 2000 support a uniform way for code to access input devices while providing extensible, adaptable interfaces to new devices, based on USB Device Class Definition for Human Interface Devices (HID), developed by the USB Implementers Forum. The HID specification unifies input devices by providing flexible data reporting, typeless data, and arrayed and variable input and output.

HID controls are defined for the following:

Vehicle simulation devices (autos, planes, tanks, spaceships, submarines, and so on)
Virtual reality devices (belts, body suits, gloves, head trackers, head mounted displays, oculometers, and so on)
Sports equipment devices (golf clubs, baseball bats, rowing machines, treadmills, and so on)
About 250 consumer appliance controls
2-D and 3-D game control devices

Windows 98 provides an interface plus power management and Plug and Play support for USB/HID-compliant devices. Windows 2000 includes HID support for devices connected using legacy input ports. Also, IHV/ISV-supplied HID class minidrivers can extend HID support on both operating systems for devices connecting using IEEE 1394 and legacy ports. IHVs can also extend the functionality of devices by adding filter drivers to the Windows Driver Model (WDM) layered architecture.

Modem Technology
Microsoft« Windows« 98 and Windows 2000 support communications devices such as modems, fax modems, voice modems, voice/data modems, wireless and cellular modems, and serial Integrated Service Digital Network (ISDN) adapters.

Network Technology
Networking under Microsoft« Windows« 98 and Windows 2000 is based on Network Driver Interface Specification (NDIS) 5.0, which consists of all functionality defined in NDIS 4.0, plus the following extensions:

Power management, Plug and Play, and WMI-based hardware instrumentation support.
Mechanisms for off-loading tasks such as TCP/IP checksum, IP Security, TCP message segmentation, and Fast Packet Forwarding to intelligent hardware.
Broadcast media extension, required for Broadcast Architecture components.
Deserialized miniport for improved performance on Windows 2000 multi-processor systems.
Connection-oriented NDIS to support native access to connection-oriented media such as ISDN and ATM, including ATM/ADSL, ATM/cable modem, and so on, plus support for Quality of Service (QoS) when supported by the media.

Parallel and Serial (COMM) Technology

The recommended implementation for I/O connections on new PCs is to use USB or IEEE 1394.

However, Microsoft« Windows« 98 and Windows 2000 continue to support legacy serial and parallel port connections. Note that under Windows 2000, the serial driver supports both Plug and Play and power management through a new architecture and driver model, requiring several changes in order to migrate a serial device driver from Windows NT« 4.0.

PCI
The Peripheral Component Interconnect (PCI) architecture has become the most common method used to extend PCs for add-on adapters. Microsoft« Windows« 32-bit operating systems use the basic PCI infrastructure to gain information about devices attached to the PCI bus. The ability of PCI to supply such information makes it an integral part of the Plug and Play architecture in Windows.

All cards, bridges, and devices that use PCI should meet the requirements defined in PCI Local Bus Specification, Revision 2.1 (PCI 2.1), and also comply with the Engineering Change Notices (ECNs) available from the PCI Special Interest Group (SIG) at http://www.pcisig.com .

In addition, to ensure that Plug and Play works correctly, devices should implement the Subsystem ID and Subsystem Vendor ID fields defined in the Subsystem ID ECN to PCI 2.1 or PCI 2.2. For information about implementing these fields for use under Windows, see PCI Device Subsystem IDs for Windows.

New Logo Program testing policy for Mini PCI. The Microsoft Windows Hardware Quality Labs (WHQL) has adopted a new testing policy for the developing Mini PCI specification. This policy has been posted on the WHQL web site at http://www.microsoft.com/hwtest/. This update applies to the 1998-1999 and 1999-2000 Logo Programs. The Windows Logo Program FAQ is available at http://www.microsoft.com/msdn/hwdev/msdn/winlogo/

Plug and Play Technology
Plug and Play is the technology that supports automatic configuration of PC hardware and attached devices. A user can just attach a new device such as sound or fax card ("plug it in") and start working ("begin playing") without having to configure the device manually. Plug and Play technology is implemented in hardware, in the operating system, and in supporting software such as drivers and BIOS.

First introduced with Microsoft« Windows« 95, true Plug and Play configuration capabilities are supported under Windows 2000. For Plug and Play and power management support under Windows 2000, the system and its BIOS must be compliant with Advanced Configuration and Power Interface Specification (ACPI). For information, see the OnNow home page .

Plug and Play technologies are defined for USB, IEEE 1394, PCI, ISA, SCSI, ATA, LPT, COM, and PC Card/CardBus. Each Plug and Play device must have all of the following capabilities:

It must be uniquely identified.
It must state the services it provides and the resources it requires.
It must identify the driver that supports it.
It must allow software to configure it.

PnP Vendor IDs: See Creating Plug and Play Device IDs for information about how to request a unique Vendor ID for a hardware company that implements legacy Plug and Play devices.

OnNow and Power Management
A comprehensive, system-wide approach to system configuration and device power control is built into Microsoft« Windows« 98 and Windows 2000, based on the ACPI system interface and other new bus and device specifications. This supports new capabilities that can be exploited by drivers and applications to improve the end-userÆs computing experience.

Print Technology
Microsoft provides a universal printer driver (unidriver) that is capable of carrying out requests on most printer types, such as printing text, rendering bitmaps, or advancing a page. To build a driver for a particular printer, a developer builds a minidriver that accepts requests from the Graphics Device Interface (GDI) and then, in most cases, passes the request to the unidriver along with information that describes the capabilities, commands, and resident fonts of the particular printer.

Because Microsoft« Windows« 2000 supports Plug and Play, manufacturers should provide complete Plug and Play support for all buses that a print device supports.

Windows 98 and Windows 2000 also support using color profiles that comply with the ICC Profile Format specification. The device either must create sRGB output or must embed the ICC profile for the newly acquired image into the image file to identify the color-space information for that image. The ICM APIs and functionality for Windows 98 and Windows 2000 are described in the Microsoft Platform SDK and the Windows 2000 DDK.

Digital Still Imaging Technology
Digital still image peripherals include digital cameras and scanning devices such as sheet-fed, flatbed, handheld, film, and fingerprint scanners. The recommended connector for all imaging peripherals is USB or IEEE 1394.

Under Microsoft« Windows« 98 and Windows 2000, driver support for acquisition of still images is implemented under the Still Image architecture (STI). The major benefit of STI is reduction of the software investment that must be made by an IHV. Under Windows 98 and Windows 2000, Microsoft-provided support includes:

Still image device driver interface, providing enumeration, device information, test activation, data and command I/O, notification/polling for device events, and retrieval of ICM color profiles and other device information.
Class installer for imaging devices, including an installation wizard for non-Plug and Play solutions.
Push-model event monitor and control center, detecting incoming events for the STI control center.
Still Image Control Center, supporting push model behavior with policies for distributing events to applications.
Still Image kernel-mode drivers, packaging commands and data for delivery on a specific bus type.
Bus drivers, including USB and SCSI driver stacks, plus serial, IR, and parallel port drivers.

Windows 32-bit operating systems support using color profiles that comply with the ICC Profile Format specification for Integrated Color Management (ICM). The device either must create sRGB output or must embed the ICC profile for the newly acquired image into the image file to identify the color-space information for that image. The ICM APIs and functionality are described in the Microsoft Platform SDK and the DDKS for Windows 98 and Windows 2000.

Storage Technology
For good performance under both Microsoft« Windows« 98 and Windows 2000, the host controller and storage devices should support bus mastering, and bus mastering should be enabled by default.

For end-user ease of use, removable media devices should implement media status notification.

Note: Device drivers that support partitioned media should support all Windows partition types, which include but are not limited to FAT16, FAT32, and NTFS, plus UDF 1.5 and 2.0 for CD and DVD.

Streaming Media Technology
The WDM Streaming environment in Microsoft« Windows« 98 and Windows 2000 is made up of clients running in nonkernel mode and components running in kernel mode; they work together to control and connect components, to stream and synchronize data passing between components, and to ensure quality management as components share limited resources.

Most multimedia drivers use the WDM stream class, which consists of several components that can be used to implement kernel-mode streaming, including:

WDM Streaming Library, which consists of the operating system components that enable the WDM to stream data. This is explained in the WDM Streaming Architecture Reference in the Windows 98 DDK documentation.
KsProxy, a Microsoft DirectShowÖ filter with COM interfaces, provides a generic method of presenting kernel streaming (KS) filters as DirectShow filters. The KsProxy is explained in the Kernel Streaming Proxy Reference of the Windows 98 DDK documentation. DirectShow is meant to be the primary client of kernel-mode filters. For more information about filters and user-mode interfaces for streaming video and audio, see the DirectX« Media SDK containing the DirectShow SDK.
Stream Class Driver, which is a generic class driver for streaming and time-stamped media. It is explained in the Stream Class Driver Reference in the Windows 98 DDK documentation.

Universal Serial Bus Technology

USB provides an expandable, hot-pluggable Plug and Play serial interface that ensures a standard, low-cost socket for adding external peripheral devices. These devices range from interactive HID devices such as joysticks and pointing devices to isochronous devices such as telephony, audio, and imaging devices. USB allows cascading hubs that can be integrated into desktop devices such as monitors and keyboards.

USB is supported under Microsoft« Windows« 98 and Windows 2000. Migration to USB is recommended for all I/O devices that use legacy ports.

A USB peripheral that fits into one of the USB device class definitions should comply with the related USB device class specification. USB class drivers and WDM support provided in Windows 98 and Windows 2000 support devices that comply with the particular device class specification. Devices can use the generic class drivers provided with the operating system, or manufacturers can create drivers or WDM minidrivers (depending on the device class) to exploit any additional unique hardware features.

Video Capture Technology
Under Microsoft« Windows« 98 and Windows 2000, all video components must use a Windows Driver Model (WDM) minidriver instead of a Video for Windows (VfW) driver. Drivers for hardware decoders and for the audio and video subsystems must be implemented as described in the Windows 98 DDK or Windows 2000 DDK in order to support DirectShowÖ, DirectDraw« 5.0 VPE, and WDM.

Windows Driver Model (WDM) Technology
Windows Driver Model (WDM) is a common set of services designed to allow driver writers for certain classes of devices to construct drivers with binary compatibility between the Microsoft« Windows« 98 and Windows 2000 operating systems. (Notice that binary compatibility is only possible on Intel Architecture-compatible processors.)

The WDM class driver support under Windows 98 and Windows 2000 includes:

Stream class driver to support kernel-mode streaming of data for video capture, MPEG decoders, audio, DVD, and broadcast architectures
HID class driver to support input devices
USB and IEEE 1394 bus class driver

Each WDM class abstracts many of the common details involved in controlling similar devices. For example, consider five separate devices attached to a USB bus. If each driver for each device separately contained all the code needed to talk to its device over the USB bus, there would be five very large drivers consisting mainly of code to deal with USB communications issues.

WDM, on the other hand, uses a layered approach, where the common tasks are implemented inside a WDM class driver. With WDM, driver writers write the generally smaller code pieces (miniports) that talk to their hardware directly and call the appropriate class driver to do the bulk of the common tasks.

There are some caveats:

WDM driver writers generally find their code executes somewhat differently on the different Windows platforms, because the WDM specification allows for significant architectural differences between Windows 98 and Windows 2000. Therefore, once you get a driver working on one platform, you need to thoroughly test your driver on the other platform, especially with multiprocessor systems.
WDM does not support all types of hardware. For example, WDM does not help if you are writing a printer driver--you still have to write separate drivers for Windows 98 and Windows 2000. To understand whether WDM helps you write drivers for a particular type of hardware, see the Windows 2000 DDK and the WDM-related technical papers listed below.
INF files must accommodate differences between Windows 98 and Windows 2000. In most cases, you are able to install your driver with a single INF file, but generally you need separate sections for Windows 98 and Windows 2000.
WDM 1.0 is not supported on Windows 95. OEM service release (OSR) version 2.1 does have limited WDM-like USB capabilities, but OSR 2.1 has significantly less support than the support available in Windows 98 and Windows 2000, which includes basic changes in the kernel to accommodate WDM.

If you're ready to begin writing a WDM driver, see Dr. Iver's advice for developers at http://www.microsoft.com/msdn/hwdev/driver/wdmtruth.htm.

WMI: Windows Management Instrumentation Technology
New Microsoft operating systems support Windows Management Instrumentation (WMI), which was formerly known as WBEM. However, WMI requires vendors to create well-instrumented software and hardware components. New guidelines are being developed for hardware instrumentation and drivers.

Effective management of PC and server systems in an enterprise network benefits from well-instrumented computer software and hardware, which allow system components to be monitored and controlled, both locally and remotely. Microsoft is committed to simplifying instrumentation of hardware and software for the Microsoft« Windows« environment. Microsoft is also committed to providing consistent access to this instrumentation for both Windows-based management systems and legacy management systems that are hosted in other environments.

The foundations for manageability in Windows 2000 and Windows 98 are WMI and WMI extensions for WDM.

The Web-Based Enterprise Management (WBEM) initiative was begun by BMC Software Inc., Cisco Systems Inc., Compaq Computer Corporation, Intel Corporation, and Microsoft Corporation. The Desktop Management Task Force (DMTF) announced in early June that it is accepting a transfer of the WBEM initiative so that the DMTF will provide an organizational framework for broader industry participation in the development of WBEM/WMI-related technologies and standards.

The purpose of WMI is to define a non-proprietary set of environment-independent specifications. These specifications allow management information to be shared between management applications that run in both similar and dissimilar operating system environments. WMI prescribes enterprise management standards and related technologies that work with existing management standards, such as Desktop Management Interface (DMI) and SNMP. WMI complements these other standards by providing a uniform model. This model represents the managed environment through which management data from any source can be accessed in a common way.

WMI uses the Common Information Model (CIM) and Internet protocols for providing management data. The DMTF will use current WMI technologies as it continues to develop its standards, including development of the CIM event model, query mechanisms to CIM, and XML encodings for CIM objects.

WMI and Microsoft Operating Systems. WMI provides fully integrated operating system support for uniform system and applications management, based on the Common Information Model (CIM) adopted by the DMTF. WMI provides a consistent and richly descriptive model of the configuration, status, and operational aspects of Windows operating systems, assisting management applications in creating solutions that reduce the maintenance and life cycle costs of managing Windows.

Used in conjunction with other management services provided in Windows 2000, such as the Microsoft Management Console (MMC), WMI helps simplify the task of developing well integrated management applications, allowing vendors to provide Windows customers with best-of-breed, enterprise-scalable management solutions. Local and remote events combined with a rich query language for the information model provide the means to create solutions to complex management problems. The ability to easily script these solutions in Visual Basic« or using Windows Scripting Host (WSH) adds an often-requested dimension to Windows management.

WMI and WMI Extensions for Windows Driver Model (WDM). WMI is the kernel-level instrumentation technology for Windows 98 and Windows 2000. Close coupling of WMI extensions for WDM with services developed to conform to the WMI initiative simplifies instrumentation and provides consistent, open access to management data.

WMI extensions for WDM facilitate these capabilities:

Publishing kernel instrumentation
Configuring device settings
Providing kernel-side event notification
Publishing custom data
Allowing administrators to set data security
Accessing instrumentation by way of WMI

WMI and WMI extensions for WDM share a unified schema, with data made available to management applications by way of WMI. Instrumented hardware data is provided by way of drivers instrumented for WMI extensions for WDM. WMI extensions for WDM provide a set of Windows DDIs for instrumenting data within the driver models native to Windows, so OEMs and IHVs can easily extend the instrumented data set.

Windows 98 includes core support for WMI extensions for WDM, plus NDIS class driver support. The Windows NT« 5.0 Beta 1 release included NDIS class and SCSI class driver support, and more drivers will be instrumented in subsequent beta releases. The Windows NT 5.0 Beta 2 DDK includes WMI extensions for WDM documentation and sample code. The WMI SDK is available as part of the MSDN Platform SDK.

Name Changes for WMI and WBEM

The Desktop Management Task Force (DMTF) has recently taken ownership of Web-Based Enterprise Management (WBEM) and the associated marketing initiative. This article clarifies the use of the WBEM and WMI acronyms in the Microsoft« Windows« operating system platforms.

Microsoft is using the term Windows Management Instrumentation (WMI) to describe how Microsoft implements WBEM for Windows. It is fully compliant with the DMTF Common Information Model (CIM) and WBEM specifications. WMI is now used by Microsoft where the terms "WBEM" and "WBEM for Windows" were used previously, and WMI will remain conformant to future DMTF WBEM specifications.

The kernel side/device driver interface to WBEM, previously referred to as WMI, is now called the WMI extensions for WDM. Similarly, the provider that surfaces this device-driver based information to the management infrastructure is now called the WDM provider instead of the WMI provider.

The following table summarizes the changes.

Old Name    New Name

WBEM and WBEM for Windows    Windows Management Instrumentation (WMI)

WMI    WMI extensions for WDM

WMI provider    WDM provider

Windows 2000 and IPMI

Recently, Intel Corporation, Hewlett Packard Company, NEC Corporation, and Dell Computer announced the availability of Intelligent Platform Management Interface (IPMI) version 1.0 specifications. These specifications define common interfaces to hardware used to monitor server characteristics such as temperature, voltage, fans, power supplies, and chassis.

For Microsoft« Windows« 2000, Microsoft is providing a device driver and manageability infrastructure for developers to use to write hardware device drivers. This infrastructure allows management data to be obtained from hardware interfaces that might not have direct, native support in Windows 2000. By using WMI and WDM, hardware interfaces such as IPMI version 1.0 can be supported in systems. This can be accomplished by OEMs who write and provide custom device drivers, allowing access to management information through WMI.

Microsoft and Intel are working together on a future version of IPMI that will be accessible under ACPI and through native support in a future version of Windows 2000.