Fog Creek Software
Discussion Board




Learning windows device drivers

Any advice on learning how to write a windows device driver?  I've got lots of experience in writing them for pSos, VRTX, VxWorks, Rexx, and Linux, but this will be my first Windows driver.  What do I need, VC++?  What's a good book to buy (The Windows equivalent to Linux Device Drivers)?  Target OS is XP.

snotnose
Friday, August 15, 2003

Not sure of any good books on the subject.

You need the Microsoft DDK (there are many example drivers).  You'll find that the architecture is very similar to what you know.  There are tools/wizards to make things easier.  Check out NuMega/Compuware and the DriverStudio product or (can't remember who did this one)the product WinDK.

MikeG
Friday, August 15, 2003

At the very least, you'll need Visual Studio and the Windows DDK.  I think MS pulled it from their web site as a free download.  You now need to be an MSDN subscriber to get it.

Writing Windows Device Drivers is a lot of work.  A "hello world" driver in Windows is about 2000 lines.  Longhorn is supposed to include a higher-level Windows driver framework to make life easier.

The DDK comes with a lot of examples, but they are pretty scary.

If this is a one-off driver, and the driver doesn't have to be high-performance (network drivers, video drivers), maybe you should look at Jungo WinDriver.  http://www.jungo.com 

WinDriver will help you get a good driver working in a few days, but for more serious driver development, maybe you should at Compuware's driver products.  Basically, they offer a set of C++ classes to hide some of the raw DDK code.  I haven't really used it though.

Good site for getting started:
http://www.osronline.com/


Good Books:
"Programming the Microsoft Windows Driver Manual"
by Walter Oney
"Windows NT Device Driver Development"
by Viscarola and Mason
"Inside Windows 2000"
by David A. Solomon and Mark Russinovich


Bad Books:
Anything by Chris Kant

Myron A. Semack
Friday, August 15, 2003

Oh, btw WinDK became WinRT.  I think BSquare bought it.

WinRT was a product that worked similar to Jungo Windriver.  I've written several drivers with WinRT.  It has it's share of bugs.

WinRT has been discontinued, so don't use it for new projects.

Myron A. Semack
Friday, August 15, 2003

Buy one of the device driver writing tools.  Cost is ~$2K and up, but they're worth it.  (I use Jungo's WinDriver, but pick whichever one suits your needs.)  Most of the tool sellers will let you download a free 30-day demo version before you buy.  Also download and read the documentation.  If you can't understand the manual, that's a hint :-)

__Inside Windows 2000__ by Solomon and Russinovitch has been more useful for me than any of the books specifically about device driver writing. 

__Windows NT/2000 Native API Reference__ by Gary Nebbett has some advanced material I haven't found in any of the other books, but it is not an introductory text.

Good luck,

Bob Smith
Friday, August 15, 2003

Get the DDK first. You don't need the Visual Studio since DDK comes with the compiler and you typically use "build.exe" and makefiles to actually compile the driver. VS is pretty pointless for driver development, you can find much better text editors.

Walter Oney's book is pretty good. The docs that come with DDK are really good, IMHO. You can write the driver directly to WDM API's. It's not that hard, especially starting with a sample.

Absolutely get a kernel debugger running. You can use MS debugger or, better yet, get NuMega's SoftICE debugger. It rocks! If you want to write drivers in C++ (yes it's possible and it works really well) get NuMega's DriverWorks product (You can get both softice and dw in DriverStudio package). It's worth the money.

igor
Friday, August 15, 2003

Thanks for the replies.  Is 'hello world' really a 2,000 line driver?  What's in that thing, a chess playing easter egg?

snotnose
Friday, August 15, 2003

Yeah, BSQUARE bought WinDK/WinRT from Bluewater systems, then ran that group into the ground, following the great BSQUARE tradition of killing any products that actually produced revenue ...

Beensquared`
Friday, August 15, 2003

Most of those 2000 lines of code are WDM boilerplate, for handling things like Plug-n-Play and Power Management.

See my weblog article on the subject:
http://www.semack.net/Articles/HelloWorldin2000LinesorLe.html

BTW, one warning about WinDriver, you may want to consider a "floating" license instead of a node-lock, even though it costs more.  I ended up fighting with having to re-register the product every time I made a hardware change to the system (a BIOS update triggers a re-register).  IMHO, their node-lock system really sucks.

WinDriver and WinRT drivers run in user mode, not kernel mode.  With their toolkits, all you do is make a user-mode DLL which uses a generic set of IOCTLs to talk to the "real" driver, which is a generic driver they created.  Writing drivers is easier, but the performance is not as good.

For something simple like a digital I/O board, or low-speed data aquisition, WinRT worked fine.  When we started developing higher speed data aquisition products (>1MSample/sec), we hit the limits of WinRT.

Myron A. Semack
Friday, August 15, 2003

One or two years ago, I tried to write a device driver myself. This was only to see how it basically worked and was not supposed to do something meaningful. I have then put sort of a summary on my web page:
http://www.adp-gmbh.ch/win/misc/writing_devicedriver.html

I don't know if this is of any help or not, I still hope it gets you going.

Rene

Rene Nyffenegger
Saturday, August 16, 2003

I'll add my two €urocents...

---- Writing Windows Device Drivers is a lot of work.  A "hello world" driver in Windows is about 2000 lines

What? no way, at most a hundred lines

---- __Windows NT/2000 Native API Reference__ by Gary Nebbett has some advanced material I haven't found in any of the other books, but it is not an introductory text

Definitely *not* a driver programmer's book. In fact, the vast majority of the system calls that the book documents aren't even available in kernel mode (not through an import library, at least, but you can use some horrible hacks to retrieve the function addresses at runtime)

---- If you want to write drivers in C++ (yes it's possible and it works really well) get NuMega's DriverWorks product

No need for DriverWorks, you can use C++ for drivers without problems -- as long as you don't use C++ exceptions and RTTI. If you absolutely can't do without exceptions or RTTI, you can still link statically to the compiler's C++ support libraries and write some glue code to make them work. It's all described in an Usenet post by Gary Nebbet:

<http://groups.google.com/groups?q=msgid:%3C3976f1b3@guardhouse.chbs%3E>

In general, you should be *very* careful and conservative about using C++ in a driver, limiting yourself to worker threads, because you need the guarantee that your code runs in a non-arbitrary context. All in all, it's a hairy matter

Finally, I suggest an exercise for "snotnose". As your first driver, try to write a "/dev/port" driver work-alike for Windows. It's a very simple device (found in many UNIX and UNIX-like systems) that gives user-mode applications access to the I/O address space, and it could actually come in handy. Hints:
- the Windows kernel APIs to read/write to I/O ports are READ_PORT_UCHAR, WRITE_PORT_UCHAR and family
- /dev/port uses the current file position (the value set by SetFilePointer - and, indirectly, by ReadFile and WriteFile) as the port address

KJK::Hyperion
Saturday, August 16, 2003

KJK::Hyperion,

I'm talking about a "proper" driver, with PnP and Power Management support.  One that might actually pass WHQL.

There's no way on earh you can fit that into 100 lines or so.

Myron A. Semack
Sunday, August 17, 2003

---- I'm talking about a "proper" driver, with PnP and Power Management support.  One that might actually pass WHQL.

not exactly the best choice for a first driver :-) I've found making sense out of the baroque I/O system alone hard enough

KJK::Hyperion
Monday, August 18, 2003

*  Recent Topics

*  Fog Creek Home