Installable MIDI driver on new OS's

NTDEV
1

My client wants to expose a two way non-audio MIDI channel as a MIDI device. The MIDI stream needs to interact with a user mode API, so for purposes of the kernel space, there’s effectively no hardware behind it. After a lot of digging over the last few days it looks like I can create a kernel driver based on dmusuart/mpu401/msvad and come up with a non-hardware kernel driver to provide the virtual MIDI interface.

However, it seems a lot more sensible based on the requirements to create a user mode driver. It looks like I can create a DLL and register it as an “Installable Driver” per the following:

http://msdn.microsoft.com/en-us/library/dd756990(VS.85).aspx
http://www.winvistatips.com/do-create-new-midi-device-t181672.html

My questions about a MIDI “Installable Driver” user mode DLL are:

  1. Is there any reason why I really should go the kernel route instead (performance is not an issue, as these are non-audio MIDI note-on / note-off’s)?

  2. Will the “Installable Driver” approach work with x64, Windows Vista, and Win7?

  3. Will the “Installable Driver” approach result in a MIDI device accessible via the midiIn* / midiOut* device enumeration, opening/closing, and I/O functions?

There seems to be little in the way of documentation, examples or visible internet activity related to this, which makes me wonder if it’s an approach that’s obsolete and on its way out?

2

xxxxx@yahoo.com wrote:

My client wants to expose a two way non-audio MIDI channel as a MIDI device. The MIDI stream needs to interact with a user mode API, so for purposes of the kernel space, there’s effectively no hardware behind it. After a lot of digging over the last few days it looks like I can create a kernel driver based on dmusuart/mpu401/msvad and come up with a non-hardware kernel driver to provide the virtual MIDI interface.

However, it seems a lot more sensible based on the requirements to create a user mode driver. It looks like I can create a DLL and register it as an “Installable Driver” per the following:

http://msdn.microsoft.com/en-us/library/dd756990(VS.85).aspx
http://www.winvistatips.com/do-create-new-midi-device-t181672.html

My questions about a MIDI “Installable Driver” user mode DLL are:

  1. Is there any reason why I really should go the kernel route instead (performance is not an issue, as these are non-audio MIDI note-on / note-off’s)?

It depends on your comfort level. Officially, the whole “installable
driver” concept is no longer supported. If some future service pack
introduces an accidental or intentional regression that breaks all
installable drivers, Microsoft no longer promises to fix it. Now, in
practical terms, this is not an issue. The installable driver layer is
very simple, and they aren’t making any changes here, so it’s unlikely
this will ever break. One client actually asked me to build a
replacement for mmsystem.dll specifically for waveIn and waveOut because
of this issue, and it took very little code to implement.

  1. Will the “Installable Driver” approach work with x64, Windows Vista, and Win7?

Yes.

  1. Will the “Installable Driver” approach result in a MIDI device accessible via the midiIn* / midiOut* device enumeration, opening/closing, and I/O functions?

Yes. There is virtually a 1-to-1 mapping between the midiIn/midiOut
APIs and the installable driver messages. Mmsystem.dll merely provides
a little plumbing.

There seems to be little in the way of documentation, examples or visible internet activity related to this, which makes me wonder if it’s an approach that’s obsolete and on its way out?

Technically, it’s obsolete, but it still works, and in my opinion it’s a
reasonable approach. The mechanism is fairly simple and has low
overhead. I’m not sure there ever were very many MIDI installable
drivers, although there were a lot of waveIn and waveOut drivers.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Thanks for the detailed response, Tim.

I like the idea of keeping it simple; and even if the “Installable Drivers” concept is unsupported, keeping it in user mode is in the spirit of Microsoft’s push for UMDF and focusing/restricting driver execution permissions as much as possible.

I’m pretty sure my client is going to go for this. If it breaks in “Windows 8” we can go the WDM route.

4

> 2. Will the “Installable Driver” approach work with x64, Windows Vista, and Win7?

To write a WINMM driver you will at least need some obsolete DDK I think.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

5

Maxim S. Shatskih wrote:

> 2. Will the “Installable Driver” approach work with x64, Windows Vista, and Win7?
To write a WINMM driver you will at least need some obsolete DDK I think.

No. In fact, except for mmddk.h (which is still in the 7600 WDK), I
believe you can do it all with the SDK.

He’ll have to figure out how to install it, and that might require an
older DDK.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

Just as a follow up note – I have acquired the NT4 DDK, and it looks like the relevant sample is \ddk\src\mmedia\mmdrv. This sample DLL exports the following entry points:

wodMessage
widMessage
modMessage
midMessage
auxMessage
DriverProc

My understanding is that this example code was dropped from the DDK after NT4.