Midi-dot-net doesn't work on Windows 8 about midi-dot-net HOT 4 OPEN

Device handles should be declared as IntPtr, not Int32
(see in HMIDIOUT and HMIDIIN)

Note: structs HMIDIOUT and HMIDIIN are not really needed, could be replaced 
with IntPtr in pinvoke calls (eg midiOutOpen)

I would be very interested in finally seeing a mutually agreed 64bit compatible 
wrapper for these "winmm.dll" functions.  

For example:
// Notes here:
// 
http://msdn.microsoft.com/en-us/library/windows/desktop/dd798453%28v=vs.85%29.as
px
[DllImport("winmm.dll")]
private static extern int midiInGetDevCaps(
   int deviceID,     // UINT_PTR - can also be a properly cast device handle
   ref MidiInCaps caps,        // LPMIDIDINCAPS - I have seen OUT parameter used
   int sizeOfMidiInCaps);      // UINT

The simplest approach is to understand what symbols to use in place of the C++ 
definitions, for each platform separately.  So, on a 64bit system, UINT = ?? 
and DWORD = ??.   But on a 32bit system, UINT = ?? and DWORD = ??.  No harm in 
using a different wrapper depending on the width of UINTPTR in bytes.

Secondly, we need to differentiate where the casting between 32 and 64 bit 
types occurs.  Yes, we can return an INT - but is it better to return an UINT16 
from the wrapper to clarify?  Just because we can cast without an explicit 
statement does not make it right to do so - in fact with dll wrapping it is 
better to spell it out.  Hiding the width makes passing the value to another 
function more difficult.  So I propose the bit width limits are explicit in the 
return types in the wrappers.

Can we not create an open source group to write these wrappers as a reference 
for the community?

NOTE - My reference to UINT16 and INT above are fictional, simply to illustrate 
a point.

The workaround is to compile your .net application in 32bit mode only (Project 
properties > Build > Platform target > x86)