Management Overview and Checklist

If you re a development manager, or if you re otherwise responsible for delivering a hardware device to market, there are a few things you need to know about device drivers. You need to decide, first of all, whether you need a customized driver and, if so, what kind. The preceding section should help you with that decision, but you might want to hire an expert consultant for the limited purpose of advising you on that score.

If your evaluation leads you to believe you need a custom driver, you then need to locate an appropriate programmer. The sad truth is that WDM driver programming is pretty hard, and only experienced (and expensive!) programmers are capable of doing it well. Some companies have cadres of driver programmers, but most can t afford to. If you re in the latter situation, your basic choice is between training someone who s already on your staff, hiring a programmer who already has the necessary skills, engaging a consultant or contract programmer, or outsourcing the development to a company that specializes in driver programming. All of these alternatives have pluses and minuses, and you will have to weigh them based on your own unique needs.

Driver programming should start as soon as there is a reasonably firm specification for how the hardware will work. You should expect to modify the specification in light of unpleasant discoveries during driver development, and you should also expect to iterate your hardware/firmware and driver design several times. Flexibility and a willingness to start over will really help you.

You should also expect driver programming to last longer and cost more than you initially imagine. All software is subject to time and cost overruns. Additional overruns in this kind of programming stem from communication difficulties between the hardware and software people, from ambiguity in specifications and in the DDK documentation, from bugs in all the components, and from delays in engineering and production.

In most cases, you ll want to submit your hardware and software to the Windows Hardware Quality Lab (WHQL) in order to obtain a digital certificate that will streamline installation and provide an entr e to one of Microsoft s logo programs. You ll do most of the testing yourself, and you ll need specific computer setups to do it, so find out early what the testing requirements are for your class of device to avoid being caught short at the end of your project. (Just as an example, testing a USB device requires you to have a variety of audio hardware in a specific topology, even if your device has nothing to do with audio or any other kind of streaming media.)

Also prepare your business infrastructure for working with WHQL. At a minimum, this will require obtaining a Data Universal Numbering System (DUNS) number from Dun and Bradstreet (or providing equivalent proof of business organization) and a digital signature certificate from Verisign. As of this writing, the DUNS number was free, but the Verisign certificate was not. And working through all the processes of multiple companies will take time.

Pay attention early on to how end users will install the driver software. Most vendors of add-on hardware prefer to ship a custom installation program on a CD-ROM, and writing the installer is a lengthy process that can consume an experienced programmer for several weeks. Web-based driver repositories are quite common and require special attention to installation issues.

Drivers can provide statistical and other management information in two ways. The Windows Management Instrumentation (WMI) subsystem provides a language- and transport-independent pathway for various sorts of binary data. Microsoft has established standard WMI classes for certain types of device, and your own industry subgroup may have established other standards to which your driver should conform. Chapter 10 contains information on how to conform to the Microsoft standards, but finding out how to fit in with the rest of the industry may be a job for your company s trade group representatives.

The second way of providing management information is by means of the system event log, which has been part of Windows NT since the beginning and which gives administrators a quick way of learning about exceptional conditions that have arisen in the recent past. Your driver should report events that an administrator would be interested in and can do something about. Whoever programs your driver should consult with an experienced system administrator to decide which events to log, so as to avoid cluttering the log with routine and unexceptional information. Your driver executable file will also probably include the text of messages in a special multilingual message resource, and it would be a good idea to have a trained writer compose that text. (I m not saying your driver programmer can t do this, but he or she may not be the best choice.)

In addition to a driver, you may need control panel or other configuration software. The driver programmer and a specialist in user interaction should work together to build these components. Since they ll be installed along with the driver, they ll be part of the package that WHQL digitally signs, so they need to be finished at the same time as the driver.

Finally, don t treat your drivers as unimportant details. Having a good driver with a smooth installation is at least as important as the exterior appearance of the product. To put it simply, if your driver crashes the operating system, reviewers will alert the public, and anyone who doesn t read the reviews will be irately returning your product to the stores. You won t have any repeat business from people whose systems have crashed, even once, because of your driver. So a myopic decision to short-fund driver development could easily have a dramatic, negative effect on your bottom line for years to come. This advice is especially important for hardware manufacturers in developing countries, where managers have a tendency to look for every possible way to cut costs. I suggest that driver development is one place where cost-based decision making is inappropriate.

To summarize, plan your project with the following milestones in mind:

Evaluation of required driver and selection of programming talent
Programming specification for hardware complete enough for driver work to begin
Prototype hardware available for driver testing
Driver and hardware/firmware working together as originally intended
Installation (INF) file tested on all operating systems
Control panels and other ancillary software done
WMI and event log functionality done and tested
WHQL self-tests passed and submission made
Custom installation program done (not part of WHQL submission)
Ready to burn discs and ship product!