Printer Drivers
In Windows NT, hardcopy devices are considered to be just another kind of graphical output hardware. Unlike display devices, however, there can be more than one printer on the system, and these printers may not all use the same kind of physical connection. Some of them may even be located somewhere else on the network. The Windows NT printing architecture (pictured in Figure 1.8) is an attempt to deal with all this variety.
Printer drivers — A printer driver is very much like a display driver in that it runs in kernel mode and helps the GDI engine convert Win32 API graphics calls into rendering commands. The difference is that a printer driver sends its output to the spooler (described below) rather than to a video device.
A printer driver is responsible for supporting a particular printer or family of printers. The Windows NT DDK contains sample drivers for raster-based printers, PostScript printers, and plotters. Most printers available today fall into one of these categories. Unless your printer uses some completely alien technology, it’s unlikely that you’d need to write an entire driver from scratch.
For raster-based printers, most of the rendering operation is simply a matter of converting a specific drawing command into the proper set of printer escape codes. Because this is such a well-defined problem, you can use a Microsoft-supplied framework called the Unidriver to do most of the work. In this case, you only need to write the device-specific pieces of code in the form of a miniprint driver. Adding support for printers based on a page description language like PostScript is a more complicated task.
Configuration DLL — To support a printer under Windows NT, it’s not enough to write a printer driver. You also have to supply a user-mode configuration DLL. The job of this DLL is to display the property-sheet dialog box that changes the printer’s settings. Application programs use the configuration DLL to set up the printing environment for specific documents. It also appears when you select one of the icons in the Windows NT shell’s Printers folder.
Spooler — The spooler is the central component of Windows NT’s printing mechanism. It takes the output generated by a printer driver and either sends it to the appropriate printer or stores it in a temporary file for later printing. The spooler works either with local or networked printers.
The spooler is one of the integral subsystem processes that starts when the operating system loads. Its architecture is very modular so that it can accommodate a wide variety of printing devices and environments. Printer vendors can customize the spooler by supplying three different kinds of components: print processors, language monitors, and port monitors.
Print processor DLL — A print processor is a DLL that reads the spooled data produced by a specific printer driver and converts it into actual output. At its upper edge, the print processor DLL exposes a standard set of functions to the spooler. It generates output using the services provided by a language or port monitor.
The standard printer drivers can spool their output as text, as raw data (already rendered by the GDI engine), or as a series of enhanced metafile (EMF) commands to be rendered by the spooler. Microsoft supplies a print processor that can interpret any of these three data formats. If you write a printer driver that uses a proprietary format for spooled data, you’ll also have to write a print processor for it.
Language monitor DLL — In workgroup situations, it’s very common for several users to be sharing a single printer or print server. Consequently, it’s important to keep their jobs clearly separated and to be able to determine the status of a particular job at any point in time. It also may be necessary to set up a different printing environment for each job being output.
To meet these kinds of needs, many vendors offer smart, bidirectional printers that accept commands and report status over the same connection on which they receive output data. Normally, these command and status messages are in some kind of control language defined by the printer’s manufacturer. For example, Hewlett Packard LaserJet printers use something called the Printer Job Language (PJL).
A language monitor is a DLL that allows the spooler to communicate with a bidirectional printer in a standardized way. It exposes a well-defined set of functions that the spooler can call to control and monitor a job on one of these printers. The language monitor then converts these requests into the proper stream of job-language commands and uses the port monitor (described below) to send them to the printer.
Windows NT comes with a language monitor for the Hewlett Packard PJL language. If your printer uses some home-brew set of commands, you’ll need to write a language monitor for it.
Port monitor DLL — A port monitor is a DLL that manages a particular kind of output channel on behalf of the spooler subsystem. The monitor exposes a standard set of functions, which the spooler invokes in order to generate output. The port monitor then converts these calls into the appropriate set of Win32 I/O requests.
Allowing the spooler to work with an abstraction of the output device makes it easier to add support for a variety of printer connections. Microsoft supplies the following port monitors with Windows NT:
The local port monitor that communicates with the parallel and serial ports as well as printing data to a file.
The LPR monitor that manages LPD printers and print-servers using a TCP/IP network connection.
Port monitors from Hewlett Packard, Apple, and Digital Equipment Corporation that control network-based printers and print-servers from these vendors.
Normally, you won’t need to write a port monitor unless you’ve developed some new and strange way to link a printer to a computer. For example, an output device connected to a SCSI controller would need a new port monitor.
Multimedia Drivers
Multimedia is going to change our lives one day — if only someone can figure out how. For those who’d like to try, Windows NT supports a wide range of multimedia devices, including:
Waveform audio hardware that samples and reconstructs analog audio signals
MIDI ports that connect to external musical devices like keyboards, synthesizers, and drum machines
Onboard MIDI synthesizers that are part of the computer itself
Video capture devices that digitize either single frame or continuous video signals
Related devices like CD players, video-disk players, and joysticks
Most application programs don’t interact with multimedia hardware by calling such functions as CreateFile or DeviceIoControl. Instead they use some of the special-purpose multimedia functions provided by Win32. This indirect approach reduces their dependency on hardware from a specific vendor. Figure 1.9 shows the components involved in multimedia operations.
WINMM — To meet the requirements of different kinds of software, Win32 actually contains two separate multimedia APIs. The media control interface (MCI) functions provide high-level access to a wide variety of multimedia devices while hiding many of the details from the programmer. MCI is the interface used by most applications. For software needing more direct hardware control, Win32 also provides a group of low-level audio functions. Programs such as MIDI sequencers or waveform editors are more likely to use this low-level interface.
Support for both sets of multimedia functions comes from the WINMM system component. WINMM is a user-mode DLL that acts as a translation layer between the application and the vendor-supplied drivers that actually control the multimedia hardware. To do its job, WINMM relies on three kinds of drivers.
MCI drivers — An MCI driver is just a user-mode DLL that WINMM loads at runtime to process MCI commands for a specific device. In response to calls from a multimedia application, WINMM sends various messages to the proper MCI driver. Depending on the device, the MCI driver then uses either the low-level audio interface (described below) or Win32 I/O functions to control the hardware.
Low-level audio drivers — When an application calls a low-level audio function, WINMM loads a vendor-supplied user-mode DLL (the low-level audio driver) and sends it various messages. The low-level audio driver then uses Win32 I/O functions to communicate with the audio hardware. This is very similar to the operation of the MCI drivers described previously.
Kernel-mode device drivers — Management of the multimedia hardware itself comes from a kernel-mode device driver. This includes data transfer operations, handling interrupts, processing errors, and so on.
Drivers for Legacy 16-bit Applications
When Microsoft first introduced Windows NT, a vast amount of software already existed for MS-DOS and 16-bit Windows. Any new operating system hoping to be a commercial success would have to be able to run the majority of this code without modification. At the same time, it would be necessary to protect system integrity by denying these 16-bit programs the kind of unlimited hardware access they enjoyed under MS-DOS and Windows. As you saw earlier in this chapter, Microsoft’s solution was to run 16-bit code in the context of one or more virtual DOS machine (VDM) processes.
To meet the challenge of allowing VDMs to perform I/O without giving them direct access to any hardware, Windows NT uses a piece of software called a virtual DOS driver (VDD). Figure 1.10 shows the relationship of such a VDD to the other parts of the operating system.
The VDD essentially acts as a translation layer between a 16-bit application and some custom piece of hardware. Whenever the application tries to touch the hardware directly, the VDD intercepts the request and turns it into a series of Win32 calls. These Win32 calls are then processed by a standard Windows NT kernel-mode driver.
A VDD can intercept a 16-bit program’s attempts to access I/O ports and specific ranges of memory. It also has the ability to perform DMA transfers on behalf of the application, read and set the contents of CPU registers, and simulate the arrival of interrupts. All this makes it possible to fool the 16-bit application into thinking it’s still running under MS-DOS or Windows.
The advantage of this approach is that the original 16-bit executable doesn’t need to be modified to run under Windows NT. The disadvantage is that the extra layer of software can add significant amounts of processing overhead. Since you have to write a kernel-mode driver to support the underlying hardware, the real solution is to port the application to the Win32 environment.
One other point to make here: This technique supports the execution of MS-DOS programs that touch hardware directly. It also supports 16-bit DLLs that play with hardware (a common form of driver in the 16-bit Windows environment). It does not allow you to run Windows or Windows 95 VxDs under Windows NT.
SUMMARY
As you can see, Windows NT’s rich architecture and multiple API environments add a certain amount of complexity to I/O processing. In particular, Windows NT uses a much broader definition of what constitutes a driver than many other operating systems. If you’re in the process of adding support for a specific piece of hardware, you should have a good idea at this point of just what kind of driver(s) you’ll need to write.
In the next chapter we’ll start our descent into kernel-mode driver development by examining some of the hardware issues facing NT driver writers.
Critical Challenges of ESI & Email Retention Are you storing too much electronic information? Get expert legal advice and better understanding of what you are required to do as an IT professional.
Rev Up Your IT Know-How with Our Recharged Magazine! The improved Windows IT Pro provides trusted IT content with an enhanced new look and functionality! Get comprehensive coverage of industry topics, expert advice, and real-world solutions—PLUS access to over 10,000 articles online. Order today!
Get It All with Windows IT Pro VIP Stock your IT toolbox with every solution ever printed in Windows IT Pro and SQL Server Magazine plus bonus Web-exclusive content on hot topics. Subscribe to receive the VIP CD and a subscription to your choice of Windows IT Pro or SQL Server Magazine!
Order Your Fundamentals CD Today! Gain an introduction to Exchange, learn server security requirements, and understand how unified communications can play a role in your messaging strategies with this free Exchange CD.
Windows IT Pro
Register
