Updating MS Windows NT 4.0 Serial Device Drivers for Windows 2000

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

White Paper

Abstract

In Microsoft® Windows 2000, the serial driver will support both Plug and Play and Power Management. This white paper provides a brief overview of the architecture and design of the new Windows 2000 serial driver model, and is intended to assist the driver writer in determining which changes need to be made to a serial device driver so that it can migrate from Windows NT 4.0 to Windows 2000. This paper is targeted toward developers who are writing drivers for serial devices that will run on Windows 2000.

Introduction

The Microsoft® Windows 2000 serial bus model has been updated to support Plug and Play and Power Management. The Windows 2000 serial bus driver, Serial.sys, is now Plug and Play-enabled, and a serial device enumeration driver, Serenum.sys, has been added to support serial device enumeration from the RS-232 port. To support this new functionality, all Windows NT 4.0 serial device drivers should be updated to work with the new serial driver model in Windows 2000.

This white paper describes the changes to the serial device driver for Windows 2000, and the reasons behind those changes. For more information on Plug and Play architecture in Windows 2000, please refer to the Windows 2000 Beta 1 Driver Developer Kit (DDK) documentation.

Why Must Serial Device Drivers be Modified for Windows 2000?

In Windows NT 4.0, there was a specific order for loading serial device drivers. This load order allowed independent hardware vendors (IHVs) to use the Windows NT serial bus driver, Serial.sys, to connect hardware to the PC and to Windows NT 4.0. This load ordering structure is not included in the Windows 2000 serial driver. Instead, Windows 2000 relies on the Plug and Play Manager to start devices. In addition, serial device enumeration for devices connected to the RS-232 port is now provided in a separate driver, Serenum.sys. This separation allows serial bus drivers other than Serial.sys to use Serenum.sys to enumerate RS-232 port devices. For example, a multiport RS-232 device driver can use Serenum.sys to enumerate RS-232 devices.

For these reasons, Windows NT 4.0 serial device drivers that depend on the Windows NT 4.0 serial.sys load order cannot function in Windows 2000 without some modification. The next section discusses the architectural changes in greater detail.

The Plug and Play Layered Driver Architecture

The Windows 2000 I/O system with Plug and Play support provides a layered architecture for serial device drivers, consisting of the Plug and Play drivers and their corresponding device objects. This architecture is explained in the following paragraphs.

Plug and Play Drivers

Plug and Play supports three types of drivers:

Bus drivers, which drive I/O buses and include any per-slot functionality that is device-independent.
Function drivers, which drive individual devices.
Filter drivers, which filter I/O requests for a device, a class of devices, or a bus.

Note that from the Plug and Play perspective, a bus is any device to which other physical, logical, or virtual devices are attached. A Plug and Play bus can be a traditional bus—such as a SCSI or PCI—or a parallel port, or an RS-232 port.

Device Objects

A driver creates a device object (DO) for each device it controls. The device object represents the device to the driver. Plug and Play recognizes three types of device objects:

Physical Device Objects (PDOs), which represent individual devices on a bus to a bus driver.
Functional Device Objects (FDOs), which represent individual devices to a function driver.
Filter Device Objects (filter DOs), each of which represent individual devices to a filter driver.

Figure 1 shows the possible types of device objects that can be attached in a device stack (the stack shows drivers that handle I/O requests for a device).

Figure 1: Device Objects in a Device Stack

Figure 1: Device Objects in a Device Stack

The device stack includes a device object for each driver that is involved in handling I/O to a particular device: there is a PDO for the underlying bus driver, an FDO for the function driver, and filter DOs for any optional filter drivers.

Device objects are created as follows (starting at the bottom of Figure 1):

A bus driver creates a PDO for each device that it enumerates on its bus.
The PDO represents the device to the bus driver. Other drivers for a device attach device objects on top of the PDO—the PDO is always at the bottom of the device stack.
Optional bus filter drivers create filter DOs for each device they filter.
Bus filter drivers are not part of serial device driver support discussed in this paper.
Optional lower-level filter drivers create filter DOs for each device they filter.
If an optional lower-level filter driver exists for a particular device, it is loaded after the bus driver and any bus filter drivers. A lower-level filter driver creates a device object for the device and attaches it to the device stack.
The function driver creates an FDO for the device.
The Plug and Play Manager loads a function driver for the device. The function driver creates an FDO and attaches it to the device stack.
Optional upper-level filter drivers create filter DOs for each device they filter.
If any optional upper-level filter drivers exist for the device, the Plug and Play Manager loads them after the function driver and each such filter driver attaches its device object above the FDO.

RS-232 Device Enumeration in Windows 2000 – SerEnum.sys

As stated earlier, serial device enumeration for devices connected to the RS-232 port is now provided in a separate driver, Serenum.sys. Serenum.sys detects enumerable hardware connected to an RS-232 port. Enumerable hardware is hardware that conforms to the PC 98 System Design Guide. Note that these requirements have been in the System Design Guide since the PC 95 version. In addition, Serenum.sys detects pointer devices that comply with legacy mouse detection in Windows NT 4.0.

Rather than having each RS-232 hardware vendor implement the detection protocol and be responsible for providing a bus driver, the upper-level filter driver, Serenum.sys, provides this functionality. If Serenum.sys finds hardware, Serenum.sys creates a PDO for the device. Serenum.sys serves as both the bus driver on the RS-232 port, enumerating devices, and an upper-level filter driver for the RS-232 device stack.

I/O requests that are not handled by Serenum.sys pass through the RS-232 device stack to the driver immediately below Serenum.sys. Non-I/O requests may follow a different path. Serenum.sys actively decides which I/O request packets (IRPs) to pass through and which to service.

RS-232 Device Models and Serial Driver Design

There are four possible hardware configurations for serial hardware devices, all of which use Serial.sys:

A Plug and Play device connected to the computer's RS-232 port; for example, a modem.
A non-Plug and Play device connected to the computer's RS-232 port; for example, a legacy non-Plug and Play graphics tablet.
A serial device containing a 16550 universal asynchronous receiver-transmitter (UART); for example, a PC Card modem.
A multifunction device with a serial device containing a 16550 UART; for example, a multifunction PC Card device with Ethernet and Modem.

The following sections explain these configurations, and illustrate their respective hardware device connections, device stacks, and corresponding device objects. It's important to note that the hardware design dictates which configuration should be used. Therefore, before writing a hardware driver, the developer must understand which device configuration best describes the hardware involved.

Plug and Play Serial Device Connected to the RS-232 Port

Figure 2 shows a hardware connection diagram and a Plug and Play device stack for a serial device enumerated by Serenum.sys. This type of architecture can be used with Plug and Play serial-compliant devices, such as mice, pointing devices, graphics tablets, modems, and digital cameras.

Figure 2: Plug and Play Serial Device (Toaster) Enumerated by Serenum.sys on the RS-232 Port

In this configuration, an upper-level filter DO is added to the RS-232 device stack, allowing Serenum.sys to enumerate Plug and Play devices. The Plug and Play Manager directs the Serial.sys to start its device, and then queries Serenum.sys for its children. In response, Serenum.sys enumerates the devices on the RS-232 port. The arrow in the figure indicates that the "Toaster" serial device is a child of the RS-232 device stack. In this configuration, Serenum.sys finds a serial Plug and Play device (in this case, Toaster), creates a PDO for the child device, and adds the appropriate filter DOs and function DOs to the serial device stack by combining the serial device .inf file and the class installer.

Note that the PDO created by the underlying Serenum.sys is always at the bottom of the device stack for the particular serial device. When a serial device driver handles a Plug and Play IRP, it must pass the IRP all the way down the device stack to the PDO and to Serenum.sys.

Non-Plug and Play Serial Device Connected to the RS-232 Port

Figure 3 shows a non-Plug and Play serial device connected to the RS-232 port.

Figure 3: Non-Plug and Play Serial Device (Toaster) on the RS-232 Port (Serenum.sys not used)

In this case, the RS-232 device stack does not use Serenum.sys. Instead, the serial Toaster device stack is manually installed, and Toaster.sys opens a COM port by making a call to Serial.sys in the RS-232 stack. This type of serial device model is used when the serial device would not be recognized by Serenum.sys, and a manual installation is required. It is still important for the Toaster.sys serial device driver to handle Plug and Play IRPs and Power Management IRPs, even though the device is not Plug and Play. Otherwise, the operating system will have limited Plug and Play functionality and no Power Management capabilities.

Serial Device Containing a 16550 UART Inserted in PC Card Slot

Figure 4 shows a serial device containing a 16550 UART inserted in a PC Card slot.

Figure 4: Plug and Play Serial Device (Toaster) Enumerated by Pcmcia.sys in a PC Card Slot (SerEnum.sys not used)

Serenum.sys is not required in this configuration because Pcmcia.sys enumerates the child device in the PC Card device, and creates the PDO for the device. (Pcmcia.sys is both a function driver and a bus driver.) This configuration has a serial device with a 16550 UART in the PC Card slot, and Serial.sys is required for the serial device. The .inf file and class installer for the PC Card Toaster device installs Serial.sys as a lower-level filter DO as part of the Toaster device stack, and Serial.sys exposes a COM port to the device. Note that the PDO created by the underlying Pcmcia.sys is always at the bottom of the device stack for the particular serial device. When a serial device driver handles a Plug and Play IRP, it must pass the IRP all the way down the device stack to the PDO and to Pcmcia.sys.

Multifunction Device Inserted in a PC Card Slot

Figure 5 shows a multfunction device (which includes both a serial device and another device) inserted in a PC Card slot.

Figure 5: Multifunction Device with a Serial Device Enumerated by Mf.sys Inserted in a PC Card Slot (Serenum.sys not used)

In this example, Serenum.sys is not required to detect the child device. Instead, Mf.sys is required to enumerate multiple children in the single multifunction device. (Mf.sys is a function driver and a bus driver.) Mf.sys enumerates and creates a PDO for each of the child devices (Toaster and Blender). The Toaster device in the Multifunction device is a serial device with a 16550 UART. Note that the Toaster device stack shown in Figure 5 is the same as the Toaster device stack in Figure 4. The only difference is that one stack was enumerated by Mf.sys and the other by Pcmcia.sys. Mf.sys is the recommended Plug and Play bus driver for detecting multifunction devices, such as network/modem cards, sound/ joystick cards, and multifunction printers.

Serial Device Installation and .Inf Files

To be installed, any Windows 2000 device driver must have an .inf file. Windows 2000 device driver .inf files do not contain installation scripts. Instead, installation procedures are part of a Win32® installer application, such as a Control Panel application or system-supplied, device-type specific class installer, with each device driver's .inf file acting as a resource. The .inf file contains all necessary information about the file(s) and device(s) to be installed, such as file names, registry information, version information, and so on to be used by the installer.

Requirements and procedures for creating .inf files are documented in the Windows NT DDK. The .inf reference documentation is being expanded for the Beta 2 DDK.

Testing, Logo Program, and Hardware Support

PC 98 requirements specify that serial device drivers are required by July 1, 1998.

The compatibility tests are available from Windows Hardware Quality Labs (WHQL). For more information, go to https://www.microsoft.com/hwtest .

Call to Action

In summary, Microsoft recommends that you follow these guidelines when writing serial device drivers for Windows 2000 or when updating existing Windows NT 4.0 drivers:

Update your serial device drivers for Windows 2000 Plug and Play serial model.
Make all Windows 2000 drivers support Plug and Play and Power Management, even those designed for non-Plug and Play hardware.
Submit your new or updated serial driver to WHQL.

For More Information

The Windows 2000 Beta 1 DDK is now available. Additional documentation and code samples will be provided in a future Windows 2000 Beta DDK.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

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

0X98