Developing Windows NT Device Drivers: A Programmer's Handbook - Softcover

Dekker, Edward N.; Newcomer, Joseph M.

Softcover

ISBN 10: 0768682258 ISBN 13: 9780768682250

Publisher: Addison-Wesley Professional, 1999

Synopsis

Developing Windows NT Device Drivers: A Programmer's Handbook offers programmers a comprehensive and in-depth guide to building device drivers for Windows NT. Written by two experienced driver developers, Edward N. Dekker and Joseph M. Newcomer, this book provides detailed coverage of techniques, tools, methods, and pitfalls to help make the often complex and byzantine black art of driver development straightforward and accessible. This book is designed for anyone involved in the development of Windows NT Device Drivers, particularly those working on drivers for nonstandard devices that Microsoft has not specifically supported. Because Windows NT does not permit an application program to directly manipulate hardware, a customized kernel mode device driver must be created for these nonstandard devices. And since experience has clearly shown that superficial knowledge can be hazardous when developing device drivers, the authors have taken care to explore each relevant topic in depth. This book's coverage focuses on drivers for polled, programmed I/O, interrupt-driven, and DMA devices.The authors discuss the components of a kernel mode device driver for Windows NT, including background on the two primary bus interfaces used in today's computers: the ISA and PCI buses.Developers will learn the mechanics of compilation and linking, how the drivers register themselves with the system, experience-based techniques for debugging, and how to build robust, portable, multithread- and multiprocessor-safe device drivers that work as intended and won't crash the system. The authors also show how to call the Windows NT kernel for the many services required to support a device driver and demonstrate some specialized techniques, such as mapping device memory or kernel memory into user space. Thus developers will not only learn the specific mechanics of high-quality device driver development for Windows NT, but will gain a deeper understanding of the foundations of device driver design.

About this title

Review:

Developing Windows NT Device Drivers is an authoritative and clearly written resource on how to write device drivers for Windows NT. The book begins with an excellent high-level overview of how Windows NT device drivers work and how to create them. The text concentrates on "generic" device drivers written in C and excludes specialized drivers for graphics, file system, and network hardware.

Eventually, the book turns to device registers, device memory, and different PC busses (such as PCI). A section on I/O Request Packets (IRPs) and interrupt handling within Windows NT shows how to do asynchronous I/O. The authors offer a simple "Hello World" example for a device driver and present various debugging techniques.

Subsequent chapters deepen the reader's knowledge on topics such as device I/O, synchronization (including spin locks), device-driver initialization and cleanup, and direct memory access (DMA). These chapters also instruct you on how to access hardware ports and interrupt processing (a crucial topic) and how to move device memory into system memory (along with a working example). Discussion of more specialized topics--ISA and PCI busses, serialization, driver threads, and the advantages of the new "layered" driver model--follows.

Authors Edward Dekker and Joseph M. Newcomer offer plenty of excellent real-world advice. (Material on how to log device-driver events and manage the infamous Windows "Blue Screen of Death" is indispensable.) They present a "hardware simulator" that lets readers develop device drivers without an actual hardware device. The book closes with information on Windows 2000, universal serial bus (USB) devices, the Win32 driver model, and over 300 pages of reference material, including device-driver kernel functions. Overall, this comprehensive text provides a solid introduction to the way Windows NT device drivers interact with hardware; it gives you all you need to start building custom device drivers. --Richard Dragan

From the Inside Flap:

Welcome to the World of Device Drivers

This is a book on how to write Device Drivers. Device Drivers are those very specialized pieces of software that live inside the operating system and allow it, and thus your programs, to communicate to the outside world. Every communication NT makes to the outside world, including the keyboard, mouse, display, disks, CD-ROMS, and printers requires a Device Driver. Most of the key ones have been written by Microsoft, and NT supports all the "standard" devices.

But what about "nonstandard" devices? This doesn't mean the devices don't conform to a standard; what it means is that these are devices that are not found on "standard" PCs. Often they are specialized devices whose market is far too small for Microsoft to devote any energy to supporting. These could be devices such as drivers that support IEEE-488 communications (used for laboratory equipment and test equipment), analog-to-digital data input boards, digital-to-analog data output boards, specialized communications boards, and the like.

The core problem in Windows NT is that if you don't have a Device Driver you can't talk to a device. In Windows 3.x and Windows 9x you can cheat; you can write an application program that goes "for the bare metal" and directly manipulates the hardware interface to the device. But in Windows NT, because of the requirements for being certified at C2 Security (an important certification commercially and for government sales), an application program is simply not permitted to manipulate the hardware directly. So you are confronted with the problem of writing a device driver.

That's what this book is all about. How This Book Happened

One evening after a long day at Comdex, Ed and I (jmn) were sitting around discussing our Latest Adventures. Ed was telling me about all the really cool, largely non-obvious (not undocumented, but obscurely documented) things he'd learned about writing device drivers. I said to him, "Ed, you should write a book". (At this point I was well into the writing of Win32 Programming, so writing books was at the top of my consciousness). He looked at me and said "Joe, I don't know how to write a book". I immediately responded "Well, I don't know how to write a device driver!" The conclusion was obvious. So we wrote a proposal to Addison-Wesley, and you are holding the result. What We Cover

The purpose of this book is to allow you to write NT Device Drivers for a new device that you would want to connect to an NT machine. These include polled, programmed I/O, interrupt-driven, and DMA devices. Modern interrupt drivers add complexity, because interrupts may be shared by several devices. DMA has changed from the use of the PC's onboard DMA controller to external DMA controllers and Bus Mastering controllers. Many drivers for modern devices need access to onboard memory, and we show how to do that. In some cases, you might want to write a "user level" system that does most of the work, calling the I/O subsystem only to initiate certain input or output transactions, and using it to handle interrupts. We show how to construct these drivers.

We talk about how to build robust, portable, multithread- and multiprocessor-safe drivers. We talk about what you have to do to ensure that your driver won't bring the system crashing down around the user. We lay out the protocols you must use in communicating to the rest of the system; if you don't follow these fairly exactly, the system won't work as expected. It may crash, it may corrupt the disk, it may ignore the device, it may lose information on input or output, or it may misinterpret the intention of the application programmer who calls the services of the driver. Writing a Device Driver is fairly exacting. We try to capture much of the Art of building a device driver here, as well as the Technology.

In addition, we talk about how to actually build drivers, that is, the mechanics of compilation and linking; what they have to do to register themselves with the system, and most importantly, how to debug them. Most of the useful techniques for debugging device drivers is either undocumented or difficult to find; we've summarized our experiences in this book. What We Don't Cover

There is only so much that one book or set of books can cover. We've chosen our goals to cover what most device driver writers want or need. But there are several aspects we don't cover at all:

Graphics drivers. These include display drivers and printer driver. The Graphics Driver contains the code to render an image into the internal frame buffer of the Video Adapter or printer engine. Most of the effort goes into understanding the incredibly clever hacks needed to get optimal efficiency on a particular piece of hardware. Graphics drivers are in the range of tens of thousands of lines of code. Generally, unless you work for a display card vendor or printer vendor, you will never encounter a need to write one of these. And while there is often a desire to support some old printing or plotting device, frankly, the cost of developing one of these drivers would buy several modern equivalents of those old printers. Chapter 25 contains a very high-level overview of graphics drivers. To do them justice would take another book about this size.

File System Drivers would be worthy of an entire book on their own. In fact, this has already been done (see Further Reading). To write an entire file system is far more complex and is beyond the scope of this book. We've never written a file system, and are not now qualified to write about how to do it. Network Drivers. Network drivers are worthy of an entire book devoted just to that subject (there is a pattern here). The chances that most device writers will ever need to write a full network driver are fairly slim. At the lowest level (for example, the card driver) a network card driver bears a strong resemblance to most other devices, but there are some additional complications that require a deep understanding of network protocols. There is just not enough space available in this book to cover network drivers.

In addition, recognize that this is software. There are dozens of ways to do anything. We present the core methods, and possibly one or two interesting alternatives. We cannot tell you every possible way to do every possible thing (for one thing, we haven't done every possible thing in every possible way ourselves!) Many techniques are unique to particular devices, and in some cases our ability to talk about some of the more interesting advanced techniques is circumscribed by various Non-Disclosure Agreements we have signed. What we hope to give you here is a sound footing in basic driver technology and illustrate a few of the more interesting advanced techniques that you may need. But the coverage here is not "complete". If we started to write a "complete" book on version n of NT, we would not have delivered the manuscript before version n+1 was released. This wouldn't help anyone. The Physics Model for Software

No, not "Software Physics". That's something else entirely. The "Physics Model" refers to a comment by a physics professor, who said "We have an advantage in physics; we teach it by an ever more refined set of lies". What he was referring to is that when physics is first taught, you learn about Newtonian physics. In this model, we have phenomena such as the wave model of light, the particle model of light, and so on. Physical objects are real, and their masses interact according to specified laws of gravity or of energy transfer. But relativity theory tells us that Newtonian physics is really relative to a particular inertial frame, and what is really going on is something different. In Quantum Mechanics, you learn that at a certain scale, physical objects don't exist, and phenomena like the Heisenberg Uncertainty Principle come into play, and you get an explanation of what is really going on. Then there's Quantum Electrodynamics, in which the real model of what is going on is explained, and then...well, it's been too long since our physics courses and anyway you should have the idea by now.

We apply this same principle to teaching software. So don't be surprised if there are some apparent discrepancies between the illustrations and text on one page and the illustrations and text on a later page. We're trying to avoid giving you infinite detail too early and thus avoid being too confusing. Ideally, the earlier text or illustration is a subset of the later one. About URLs

While many people know about URLs, not everyone might be familiar. A URL is a Universal Resource Locator, a designator for a page of information on the World Wide Web. A URL has a form like mumble/here/and/there/and/everywhere.html mumble/here/and/there/and/everywhere.htm mumble

To access a Web page for which we give a URL, you must have a Web Browser, such as Microsoft Internet Explorer or NetScape (to name the two most popular browsers for Win32 platforms), and a connection to the Internet. We are not going to explain those details here, but if you don't have access, you want to find an Internet Service Provider (ISP) who can provide this service to you. We have investigated a number of interesting Web sites that provide useful information for Device Driver writers. We have included these URLs in various places in the book.

Once you have your Internet connection, you bring up your browser and you type the URL, and as if by magic, the Internet tells you it doesn't exist. Well, actually, if you typed it correctly, and the Web page wasn't removed, you will actually get the page. We can't guarantee that all of the URLs we give will continue to exist. We're giving you the best information we have as we went to press, but the Web changes daily, and it is impossible to be instantly current in a print publication. Documents on the Web

We often cite URLs as a source of documents. The Web page will usually give you a link, such as the name of the document or a button, that allows you to download the document. Documents come down in a variety of formats, but the most popular formats are Microsoft Word (.doc) files and Adobe Acrobat (.pdf) files. If you have Microsoft Word, it is easy to read the documents; if you don't, you will need to download the Microsoft Word Viewer. For Acrobat, you need an Acrobat Viewer. This is available as a download from Adobe. We give the URLs under Further Reading.

Documents on the Web are often compressed, usually using the PKZip utility from PKWare. We have uncompressed all the information we included on the CD-ROM, but if you download a document you will need the PKZip utility. This is available in both public-domain versions and registered versions. The folks at PKWare have done Good Things for the computing community. Support them by buying a licensed version. The licensed version is not that expensive; if you're a device driver writer, you can recover the cost very quickly. Icons for insertions

We have done a number of text insets. These elaborate on points that have specific audiences, and rather than put everything inline in the text, we have pulled some discussions out into these sidebar-like annotations. To clue you as to their relevance, we have a series of icons that we use to indicate the contents.

One indicates a potential bug. Sometimes it is a bug in the documentation, sometimes it is a bug in a particular release of the operating system.

Another indicates some informational aside.The information may be useful to you, but it is not as important as the main-line text.

Yet another indicates a potential pitfall. Often it is a compatibility issue, such as a Win16/Win32 difference that is otherwise undocumented, or obscurely documented, or a difference between two Win32 versions. Occasionally, we use it to indicate other possible failures that would otherwise be hard to discover. These failures include obscure or undocumented limitations, or places where you are likely to get into trouble In some cases, the behavior of a Windows operation is not "intuitively obvious", and if you do what you think is "right", it won't work as expected.

Another icon indicates that there is a potential hazard. You should take note of this when using the related material.

Finally, yet another icon indicates the authors are expressing a (usually controversial) opinion. We want you to know it is an opinion, rather than a statement of some fact. You may even disagree with the opinion, but one advantage of being an author is that we get to say, in public, how we feel about certain issues. A note on "Hungarian Notation"

This whole section should have one of the "flame" insets, but it is too long and too important to reduce to a mere sidebar.

The so-called "Hungarian Notation" (developed by a Hungarian programmer at Microsoft) is one of the worst ideas to have hit software development in many years. This is that horrid notation that tries to encode the data type in the name, for example, "nCount" indicating an integer count. This is a mistake; only two other popular languages in history ever encoded data type in a name, FORTRAN and BASIC, and both of them abandoned it as a fundamentally bad idea. Fortunately, the coders of the NT kernel had the good sense to avoid this notation. You will not find it used in any of our examples, except those user-level examples where we have to interface to Microsoft's data structures that use the convention, or when some published standard has fallen prey to this insidious notation.

Why is Hungarian Notation bad? Aesthetics aside (it is singularly ugly), it creates maintenance nightmares, which is a cardinal sin in our opinion. Software is hard enough to maintain without introducing artifices that make that more difficult. For example, you might declare a short signed integer counter and call it "nCount". But you may then discover that you need more than 32,767 values, but less than 65,535 values in the counter. So in a sane world, you would do the obvious: change the declaration from "short" to "unsigned short" or equivalently "WORD" (the declaration WORD always means "unsigned short"). But according to Microsoft's standards, you now need to change the name to "wCount". A global substitution won't work, because there may be other contexts in which the variable "nCount" is simply a short. If you don't change it, you'll wonder why you get a compiler warning if you compare what is "obviously" a signed number with another signed value. And if you need more than 64K values, you might want to redeclare it a "long" or "unsigned long" ("DWORD") in which case you need to change the name to "lCount" or "dwCount". If you don't change the name, you'll wonder why assigning a 16-bit variable wCount to another 16-bit variable wOldCount or passing it to a function that requires a 16-bit parameter generates a compiler warning about value truncation. If the names did not encode the type, you would not make this kind of error because you would have to refer to the declaration to find the type. You say that changing a single name is trivial? Not so. And the possibility of making an error and not changing the name, or perhaps changing the name in too many places, introduces a complication to maintenance that is unn...

About this edition

• Publisher: Addison-Wesley Professional
• Publication date: 1999
• ISBN 10: 0768682258
• ISBN 13: 9780768682250
• Binding: Paperback
• Edition number: 1
• Number of pages: 1280