search

Earlz / midi-dot-net

Automatically exported from code.google.com/p/midi-dot-net
0 stars 0 forks source link

Midi-dot-net doesn't work on Windows 8 #6

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. run the SimpleExamples input 
2. AccessViolation when StartReceiving

Original issue reported on code.google.com by bart.de....@gmail.com on 22 Dec 2013 at 10:01

GoogleCodeExporter commented 9 years ago 
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)

Original comment by bart.de....@gmail.com on 23 Dec 2013 at 7:44

GoogleCodeExporter commented 9 years ago 
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?

Original comment by goo...@davidcday.co.uk on 17 Jul 2014 at 8:57

GoogleCodeExporter commented 9 years ago 
NOTE - My reference to UINT16 and INT above are fictional, simply to illustrate 
a point.

Original comment by goo...@davidcday.co.uk on 17 Jul 2014 at 9:12

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

Original comment by ales.ra...@gmail.com on 22 Oct 2014 at 1:26