Cluebat-man to the rescue : Driver programming

My latest article in NTInsider

vanDooren — Fri, 26 Sep 2008 06:00:00 GMT

A bit late perhaps, but my latest article on API development got published in the NTInsider (owned by OSR Online).

The online version can be found here. It requires free registration.

I know that at least 2 people have read it completely, because that is the number of mails I got to tell me I missed something.

In the code example at the bottom, I acidentally switched the names of fooA and fooB in the declaration. Doh!
That same code, compiled for a 64 bit platform, gives a linker warning. I don't know how I missed that. This code was made using VS2005, so one of two things could have happened: VC2005 didn't report the warning (unlikely), or I only checked the compilation in detail, and then only checked if the function was exported without checking if there were linker warnings. It's probably the latter.

I'll see if I can get these errata published. But at least now I know that people actually read my articles and use the code. Well, at least one person is using the code :) I'll have to make an extra effort next time to verify that a) I didn't make a stupid type, and b) There are no warnings anywhere.

It’s a small world after all

vanDooren — Sat, 10 Mar 2007 10:51:31 GMT

Yesterday I was searching for some information on FireWire and the User Mode Driver Foundation (UMDF) and I ended up on the blog of Ilias Tsigkogiannis.

I scanned the page and lo and behold: He links to my articles on driver development using the KMDF, which are hosted on codeproject.

2 Microsoft KMDF developers and one independent driver developer (Don Burn) were kind enough to proofread them before publication, but I didn't know that someone from Microsoft linked to them as tutorials. J

That's one of the 'advantages' of being active in a niche domain were very little information is easily available: it's a small world.

My first article on API development in the NT Insider

vanDooren — Thu, 01 Mar 2007 11:45:00 GMT

It is with some pride that I can announce my first publication that is printed on processed dead trees, a.k.a. paper.

It is titled ‘Designing a Device API: Part 1 - What It Means, and Why You Should Do It’ and it is published in the ‘NT Insider’; a journal for systems programmers that is published by OSR (www.osronline.com).

It is the first article in a series that will explain the issues in developing a user mode API on top of a device driver. Each follow-up article will focus on a specific topic that is relevant for API development; explaining techniques, best practices, and common pitfalls. The tool I use for creating the user mode API is Visual C++.

The article itself can be viewed online on their website.

http://www.osronline.com/article.cfm?id=482

Free registration is required.

Source code for the user mode part of my USB tutorial driver

vanDooren — Wed, 03 Jan 2007 21:52:00 GMT

Sometime ago I wrote 2 length articles on writing device drivers, using the new Kernel Mode Driver Framework that is the bees-knees when it comes to kernel mode programming.

Of course, I had to have a demo application to interact with the device drivers to control and monitor the USB device through the driver. I whipped together an MFC dialog application and a user mode API.

Since those were not the main point of my articles, I took some shortcuts to get working demo ASAP. Within the context of my demo, these shortcuts are safe enough. However, they are not an example of how to write user mode APIs.

In fact, they might encourage bad programming style if you would not understand that some things are only valid in a particular context. That is why I have not released the source code of the application and the API.

The problem is that every month, I get at least one and sometimes more requests for the code because there are very few examples on how to interact with device drivers.

I still don’t want to release the code because it is not an example of good programming.

I am writing a series of articles on how to write user mode APIs, but that is far from finished. That is why I extracted that portion of the code, since it is clean enough. It is available for download under the MIT license.

If there is anything you can learn for this, is that you should not take shortcuts if you create tutorial articles. Even it some piece of code is only there for support purposes, some people will need it to understand the whole picture.

Now then, when you look at those sources, you’ll see that all the win32 functions have a __ prefix. Those functions are wrappers around the true win32 function that throw exceptions instead of returning an error status. I have not included those wrappers because they contain macro magic that made my life easier, but is not how I would program production code.

This means that you cannot directly compile it, but it should be easy enough to adapt it and use it for interacting with my demo USB driver.

Good luck, and let me know if you have specific questions.

Is it possible to create (USB) device drivers with Visual C++?

vanDooren — Thu, 15 Jun 2006 09:20:00 GMT

This question pops up in the Visual C++ newsgroups from time to time.

You can’t. At least, you cannot directly perform USB communications. USB simply doesn’t work that way. They same is true for PCI, Firewire, SCSI, ...

All USB IO has to be performed by a USB device driver. User space applications send IO requests to the device driver. The device driver will then perform some processing and complete the request.

The first possibility is that your USB device is of a standard device class in which case it doesn’t need a special device driver, or it needs its own device driver, but exports a standardized device interface.

A good example of this is a USB to serial converter. The device driver registers a standardized serial interface with the system.

Any user mode application can then use the normal .NET or win32 APIs for serial communications without having to care about the fact that the serial line is in fact connected to a USB port instead of being soldered to the motherboard.

The next possibility of course is that the device is a non-standard device. In that case you cannot access it through a standard windows high level API. Normally the device manufacturer will ship a high level API (e.g. a dll or ActiveX object) with the device driver to allow you to interact with the devices.

If no API is available, you will have to use the CreateFile, DeviceIoControl, ReadFile, WriteFile and CloseHandle functions (among others) to directly communicate with the device driver.

Lastly, it is possible that you have a custom device of which you only have the interface documentation, but no device driver or API. In that case you need to create your own device driver. For more information on writing device drivers you can read my articles (and others on www.codeproject.com) as a starting point:

http://www.codeproject.com/system/wdf_kmdf_basic.asp

http://www.codeproject.com/system/kmdf_osr_usb_fx2.asp

The first article explains all the steps involved in actually creating a device driver. The second article explains all the issues in programming a fully functional USB device driver. Both articles use the Microsoft’s new KMDF framework. It is relatively easy to learn if you have C/C++ experience.

There are some other toolkits available from 3d parties, but they cost money, and a bigger problem is that they are non-standard so you cannot ask other developers for support unless they use the same toolkit. Another problem is that the vendor might discontinue the toolkit, and leave you with nothing but unsupported software.

In any case, as soon as you need to develop a device driver you should not use VC++. Use the DDK build tools instead. They are the standard when it comes to building device drivers, and you can get good support on microsoft.public.development.device.drivers.

You can download the latest KMDF DDK here:

http://www.microsoft.com/whdc/driver/wdf/KMDF.mspx