Reader to Reader - May 1997

Writing a Windows NT 4.0 device driver is no easy task, even for an experienced programmer. I found a book, The Windows NT Device Driver Book, by Art Baker, that can make this job practical, if not simple. This new book thoroughly covers the environment, concepts, tools, and techniques you need to write many types of device drivers. Because NT 4.0 device drivers run in kernel mode, which is a higher privilege level than ordinary user programs, they use special operating system interfaces and require special programming techniques; the drivers typically use C and avoid assembly language code.

The experienced programmer will find this book critical for developing any device driver. The key topics include the special requirements of code that uses shared resources and executes on multiple CPUs; the hardware and software environments of a device driver; the objects NT uses to manage devices and drivers; how a driver communicates with the hardware; special operating system calls; the components of a device driver; how to build, install, and debug a device driver; how to instrument and gain maximum performance from a device driver; how to synchronize access to shared objects from multiple execution threads; and how to extend WINDBG for your device driver.

I'd prefer more illustrations. However, the book offers enough code examples to make coding and design principles clear, including a parallel port driver, a full-duplex 16550 Universal Asynchronous Receiver Transmitter (UART) driver, and examples of lower-level routines. The book includes a floppy with the code examples in machine-readable form. Besides this book, the only tools you need are the NT Device Driver Kit, the Win32 Software Development Kit, and documentation about the specific hardware device the driver will use.

No other book covers this subject for NT 4.0 with as much clarity and detail. I consider The Windows NT Device Driver Book an indispensable resource for any NT device driver developer.

—Mike Maddox

Email Auto Responders
Recently, someone sent email to my auto responder (email account that automatically performs tasks on an email message; e.g., reading the From or Reply-To address of an incoming email and responding with a stock text answer). The message's return address was an auto responder. What happened next was the creation of more than 10,000 separate emails.

How did this message proliferation happen? The email query to me resulted in a response to the sender, which in turn generated a post to me, which required a response to the original sender. The cycle of these constant replies created a loop between two email servers.

You can imagine the effect all this auto-responding had on my server. Because of the volume of messages the loop caused, my server began to close down. It was processing 1 message every 20 seconds. One message becomes three files as it moves through my email server (from the incoming message queue to the outgoing message queue).

All these messages caused several problems: The server could not properly route or accept email because the server was so busy parsing and sending messages in the loop. My poor mailbox grew from a usual 200KB to a whopping 25MB (I get a copy of every message that goes to the auto responder address--a nice option of my email server). I was never able to successfully read the file, so I just deleted it and lost any and all email--possibly forever. More and more of my computer's resources went to cycling the email server so it could deal with the onslaught of activity. This load made getting into or accessing other services on the computer difficult. Bandwidth usage shot up, which made downloading pages from the Web server difficult. On my server, disk space was at a premium. Besides the increased space my mailbox was using, the files awaiting processing added another 25MB.

Stop the Madness
To stop the auto-response loop, I not only had to bring down my email server, but I also had to locate the instigator's server. Fortunately, I was able to read the interim email files, and after reading 50 or 60 of them, I learned that bob@foo.com (the name is changed) was the culprit.

Now the question was how to find bob@foo.com. I could have sent him email--but his address was an auto responder! Luckily, I understand Domain Name System (DNS) and how domain names are recorded.

Whois, the facility for reading the information in InterNIC's database of domain names, told me the technical contact's phone number. This ISP was able to turn off the link to foo.com. All in all, this little nightmare took most of my morning to solve and a whole day to put to bed.

What if this situation happens to multiple auto responders on different servers? Keep adding servers to this equation because the problem can affect two servers: sender and recipient. Now add the load of large numbers of unnecessary email messages floating back and forth on the Internet backbone. What do you have? A disaster!

Can you prevent this disaster? Yes, depending on your platform (Windows NT, UNIX, or Mac). You can mitigate the problems.

1. If you use a mailbot, a list, or anything else that generates email automatically, make sure every mail header that it sends includes a Reply-To line. A Reply-To supersedes the From address when the receiving mail client wants to send a reply.

2. In a Reply-To line, never put the address of something that automatically generates data. Always make sure replies come to an account that a person has to read first.

3. Use a mailbot that caches messages before sending them. Even a delay of a minute between the incoming and outgoing messages will dramatically reduce the amount of spam.

—Wayne Spivak

The Windows NT Device Driver Book: A Guide for Programmers
Author: Arthur H. Baker
Publisher: Prentice Hall PTR
Upper Saddle River, NJ, 1997
ISBN 0-13-184474-1
Price: $44.95; 522 pages

End of Article