1
votes

I'm starting to dive into some Windows 7 driver development. One thing that is not clear is how a managed code program can access information from the driver (communicating, for example with a digital I/O card).

For example, a driver (kernel- or user-mode) would manage access to registers on a PCI/PCIe card, but reads/writes of the register data must be available to a programmer writing managed code (C#, VB.NET) via a .NET class.

I do not want to have to resort to P/Invoke as in Win32API calls.

Is this a matter of memory sharing (IOCTL), do I use an intermediate managed DLL to "hide" the P/Invoke, or is there something simple that I'm missing?

Thanks!

1

1 Answers

1
votes

If you want to dive into Windows 7 driver development, don't use managed code at all. But if you mean that you want to call functionality of certain drivers, you can use various techniques and P/Invoke is probably the easiest of them.

The reason is simple: device drivers are by their nature unmanaged, hence you are required to use a technique like P/Invoke. Here's an example of how you can invoke device drivers. And here's how to talk to a USB device.

I understand your resentment against P/Invoke. But somehow you'll need to bridge the gap between managed and unmanaged. You can do it all by hand (using your own marshalers and everything), but I'd suggest you should only resort to that if normal P/Invoke doesn't suit the job. Of course, you can always hide the complexities by making a thin layer set of classes that does the gory details of the interface, and then you can call this self-made library freely from managed code.