Having a problem building with win32ada

Having a problem building with win32ada

[John McCabe]

Hi Guys

Further to my message the other day, I've downloaded the GPL 2009
version of GNAT with the Win32Ada bindings and I'm trying to do
something really simple at the moment, namely, get the number of input
and output midi devices on my system through Win32.Mmsystem.

The code I'm using is at the bottom of this message.

I've created a project in GPS (and other things) but so far have been
unsuccessful in building it and I can't see any obvious reason why.

I've set the project in GPR to reference the [known] win32ada library
and, as far as I can see, there's nothing much different to the
example "connect" application that comes with win32ada however when I
try to build it, I get this (compilation is fine, just linking doesn't
work):

gnatmake -d -PC:\\AdaProjects\\TestMidiDevs\\testmididevs.gpr
MidiDevs.adb
gnatbind -I- -x C:\AdaProjects\TestMidiDevs\mididevs.ali
gnatlink C:\AdaProjects\TestMidiDevs\mididevs.ali
-LC:\GNAT\2009\lib\win32ada\ -lwin32ada -o
C:\AdaProjects\TestMidiDevs\mididevs.exe
c:\adaprojects\testmididevs\MidiDevs.o:MidiDevs.adb:(.text+0x2d):
undefined reference to `_midiInGetNumDevs@0'
c:\adaprojects\testmididevs\MidiDevs.o:MidiDevs.adb:(.text+0x7d):
undefined reference to `_midiOutGetNumDevs@0'
collect2: ld returned 1 exit status
gnatlink: error when calling C:\GNAT\2009\bin\gcc.exe
gnatmake: *** link failed.

[2010-03-05 11:36:33] process exited with status 4 (elapsed time:
02.98s)

Now that says to me that those functions don't exist in the bunch of
libraries that are being linked in. Is there something I need to do to
rebuils the libwin32ada.a? When I installed it I went for the
automatic configuration option and it looked like it was being built
there.

Sorry if this seems like a stupid question but does anyone know what
I've done wrong or what's missing? As I mentioned, it's been a while
since I used Ada in anger so while I'm ok with syntax and semantics,
the subtleties of building something using GPS (tried it in Gnatbench
on Eclipse too) against an existing library are a bit beyond me and
it's difficult to track down much information on that.

Thanks
John

===========
testmididevs.gpr
===========
with "win32ada.gpr";

project TestMidiDevs is

   for Source_Dirs use (".");

   package Compiler is
      for Default_Switches ("ada") use ("-gnat05");
   end Compiler;

   for Main use ("MidiDevs.adb");

end TestMidiDevs;

==========
MidiDevs.adb
==========
with Ada.Text_IO;

with Win32;
with Win32.Mmsystem;

procedure MidiDevs is

   package UINTText_IO is new Ada.Text_IO.Modular_IO(Win32.UINT);

begin
   Ada.Text_IO.Put("There are ");
   UINTText_IO.Put(Win32.Mmsystem.midiInGetNumDevs);
   Ada.Text_IO.Put_Line(" input devices");

   Ada.Text_IO.Put("There are ");
   UINTText_IO.Put(Win32.Mmsystem.midiOutGetNumDevs);
   Ada.Text_IO.Put_Line(" output devices");
end MidiDevs;

Re: Having a problem building with win32ada

[Dmitry A. Kazakov]

On Fri, 05 Mar 2010 11:41:56 +0000, John McCabe wrote:

> gnatmake -d -PC:\\AdaProjects\\TestMidiDevs\\testmididevs.gpr
> MidiDevs.adb
> gnatbind -I- -x C:\AdaProjects\TestMidiDevs\mididevs.ali
> gnatlink C:\AdaProjects\TestMidiDevs\mididevs.ali
> -LC:\GNAT\2009\lib\win32ada\ -lwin32ada -o
> C:\AdaProjects\TestMidiDevs\mididevs.exe
> c:\adaprojects\testmididevs\MidiDevs.o:MidiDevs.adb:(.text+0x2d):
> undefined reference to `_midiInGetNumDevs@0'
> c:\adaprojects\testmididevs\MidiDevs.o:MidiDevs.adb:(.text+0x7d):
> undefined reference to `_midiOutGetNumDevs@0'
> collect2: ld returned 1 exit status
> gnatlink: error when calling C:\GNAT\2009\bin\gcc.exe
> gnatmake: *** link failed.

You have to link against Winmm.lib change the gpr file as follows:

with "win32ada.gpr";
 
project TestMidiDevs is
 
    for Source_Dirs use (".");
    for Source_Files use ("MidiDevs.adb");
    for Main use ("MidiDevs.adb");
 
    package Compiler is
       for Default_Switches ("ada") use ("-gnat05");
    end Compiler;
 
    package Linker is
       for Default_Switches ("ada") use ("-lwinmm");
    end Linker;
 
end TestMidiDevs;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Having a problem building with win32ada

[John McCabe]

On Fri, 5 Mar 2010 14:12:52 +0100, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

<..snip..>

>You have to link against Winmm.lib change the gpr file as follows:
>
>with "win32ada.gpr";
> 
>project TestMidiDevs is
> 
>    for Source_Dirs use (".");
>    for Source_Files use ("MidiDevs.adb");
>    for Main use ("MidiDevs.adb");
> 
>    package Compiler is
>       for Default_Switches ("ada") use ("-gnat05");
>    end Compiler;
> 
>    package Linker is
>       for Default_Switches ("ada") use ("-lwinmm");
>    end Linker;
> 
>end TestMidiDevs;

Dmitry, you're a star. Thanks for that.

As an aside, now that I've done that, and it works nicely thank you, I
looked at my project properties in GPS and can see no difference to
any of the settings in there. Do you know if there's a way to add that
sort of thing in GPS?

Alternatively, I couldn't see any obvious way to add that sort of
thing in Gnatbench 2.3.x (GPL). Any ideas on that too? I've
importedthe Win32Ada project in to Eclipse and se it as referenced by
the MidiDevs one, but I get Win32 is undefined etc so it's not even
seeing win32.ads!

Re: Having a problem building with win32ada

[John McCabe]

On Fri, 05 Mar 2010 14:03:31 +0000, John McCabe
<john@nospam.assen.demon.co.uk> wrote:

>As an aside, now that I've done that, and it works nicely thank you, I
>looked at my project properties in GPS and can see no difference to
>any of the settings in there. Do you know if there's a way to add that
>sort of thing in GPS?

Ah - I've just found it now. It's in a little tiny edit box at the
bottom of the "Ada Linker" tab of the "Switches" page on the project
properties. A completely unlabelled edit box that gives no hint of its
purpose!

Is it just me or is GPS really crap?

Re: Having a problem building with win32ada

[J-P. Rosen]

John McCabe a �crit :
> On Fri, 05 Mar 2010 14:03:31 +0000, John McCabe
> <john@nospam.assen.demon.co.uk> wrote:
> 
>> As an aside, now that I've done that, and it works nicely thank you, I
>> looked at my project properties in GPS and can see no difference to
>> any of the settings in there. Do you know if there's a way to add that
>> sort of thing in GPS?
> 
> Ah - I've just found it now. It's in a little tiny edit box at the
> bottom of the "Ada Linker" tab of the "Switches" page on the project
> properties. A completely unlabelled edit box that gives no hint of its
> purpose!
> 
> Is it just me or is GPS really crap?
> 
The GUI is just sugar for building the command line. That little box
shows you the options that will be selected according to the boxes you
ticked above. In addition (and it is a nice escape for unusual options),
you can edit that string to add whatever options are not available from
the GUI.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Having a problem building with win32ada

[John McCabe]

Hi J-P

>The GUI is just sugar for building the command line. That little box
>shows you the options that will be selected according to the boxes you
>ticked above. In addition (and it is a nice escape for unusual options),
>you can edit that string to add whatever options are not available from
>the GUI.

Yes, I understand that, but I'm used to IDEs where the little boxes
like that have some label that actually explains what they're there
for. It takes the guesswork out of things :-)

Re: Having a problem building with win32ada

[Simon Wright]

John McCabe <john@nospam.assen.demon.co.uk> writes:

> Is it just me or is GPS really crap?

GPS is a work in progress, I guess.

A colleague had exactly the same problem, it took a moment or two for
inspiration to strike.

Personally I prefer Emacs ada-mode except for debugging, when GPS is
pretty neat.

Re: Having a problem building with win32ada

[John McCabe]

On Fri, 05 Mar 2010 20:24:17 +0000, Simon Wright <simon@pushface.org>
wrote:

>John McCabe <john@nospam.assen.demon.co.uk> writes:
>
>> Is it just me or is GPS really crap?
>
>GPS is a work in progress, I guess.

LOL - very diplomatic :-)

>A colleague had exactly the same problem, it took a moment or two for
>inspiration to strike.

>Personally I prefer Emacs ada-mode except for debugging, when GPS is
>pretty neat.

Yes - well, mmm. I might look at using Emacs again, but I think I
might just try GNATBench in Eclipse, now I'm aware that sometimes it's
worth changing the gpr file to get things to work!

Re: Having a problem building with win32ada

[Dmitry A. Kazakov]

On Mon, 08 Mar 2010 11:30:29 +0000, John McCabe wrote:

> On Fri, 05 Mar 2010 20:24:17 +0000, Simon Wright <simon@pushface.org>
> wrote:
> 
>>John McCabe <john@nospam.assen.demon.co.uk> writes:
>>
>>> Is it just me or is GPS really crap?
>>
>>GPS is a work in progress, I guess.
> 
> LOL - very diplomatic :-)

You didn't see the first versions of GPS! Presently GPS is quite good. OK,
the debugger is a total crap, but it is not GPS's fault, but the gdb's one.
Project setting dialog is unusable, but nobody would create gpr files using
it anyway. I would just throw it away in AdaCore's place. GPS also has some
problems, which are rather to addressed to GTK.

>>A colleague had exactly the same problem, it took a moment or two for
>>inspiration to strike.
> 
>>Personally I prefer Emacs ada-mode except for debugging, when GPS is
>>pretty neat.
> 
> Yes - well, mmm. I might look at using Emacs again, but I think I
> might just try GNATBench in Eclipse, now I'm aware that sometimes it's
> worth changing the gpr file to get things to work!

Eclipse is certainly much worse than GPS, slow, ugly, unstable. I hope
AdaCore will abandon GNATBench and concentrate all efforts on GPS.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Having a problem building with win32ada

[John McCabe]

On Mon, 8 Mar 2010 12:52:28 +0100, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>>>> Is it just me or is GPS really crap?
>>>
>>>GPS is a work in progress, I guess.
>> 
>> LOL - very diplomatic :-)
>
>You didn't see the first versions of GPS! Presently GPS is quite good.

Oh!

>>>Personally I prefer Emacs ada-mode except for debugging, when GPS is
>>>pretty neat.

>> Yes - well, mmm. I might look at using Emacs again, but I think I
>> might just try GNATBench in Eclipse, now I'm aware that sometimes it's
>> worth changing the gpr file to get things to work!

>Eclipse is certainly much worse than GPS, slow, ugly, unstable. I hope
>AdaCore will abandon GNATBench and concentrate all efforts on GPS.

I would tend towards the opposite. I think they'd be better off
spending their time building good quality plug-ins for more mature and
more widely used IDEs (e.g. Eclipse, Microsoft Visual Studio) than
developing their own proprietary one. It's going to take a lot of
effort to get GPS to the point where someone says "wow" when they see
it. I know it has some great features, but....

Anyway - this isn't really the place to discuss the IDE but thanks for
your comments.

Re: Having a problem building with win32ada

[John McCabe]

On Fri, 05 Mar 2010 14:03:31 +0000, John McCabe
<john@nospam.assen.demon.co.uk> wrote:

>Alternatively, I couldn't see any obvious way to add that sort of
>thing in Gnatbench 2.3.x (GPL). Any ideas on that too? I've
>importedthe Win32Ada project in to Eclipse and se it as referenced by
>the MidiDevs one, but I get Win32 is undefined etc so it's not even
>seeing win32.ads!

Ok - using the same technique (editing the GPR file) I've now managed
to get the same project working in Eclipse/GNATBench.

Now to see if I can get anywhere with Netbeans!

Re: Having a problem building with win32ada

[Gautier write-only]

Oh, I see in the bindings:
   pragma Import (Stdcall, midiInGetNumDevs, "midiInGetNumDevs");
The linking of Stdcall functions is broken in GNAT 2009, use 2008
instead!
Cheers
______________________________________________________________
Gautier's Ada programming -- http://gautiersblog.blogspot.com/

Re: Having a problem building with win32ada

[John McCabe]

Guys

Thought I might as well add it to this thread, but I'm now having a
slight problem running with Win32Ada.

The basis of the code I'm using is in my "please review my code"
thread.

Essentially I've got the code shown below the double dashed line
(well, that's most of it).

When I run it, the Read_And_Print_Patches call _before_ outputting the
output device information is fine, but the same call _after_
outputting the output device information fails. Sometimes it just
prints the "1" prior to the Ada.Text_IO.Open call, and sometimes I get
PROGRAM_ERROR EXCEPTION_ACCESS_VIOLATION.

Now, if I change the declarations of Midi_In_Caps and Midi_Out_Caps
to:

   Midi_In_Caps  : aliased Win32.Mmsystem.MIDIINCAPS;
   Midi_Out_Caps : aliased Win32.Mmsystem.MIDIOUTCAPS;

and use 'Unchecked_Access in the calls to midiInGetDevCaps and
midiOutGetDevCaps for those objects (and dispose of the Free calls) it
seems to work ok. That sounds like some memory isn't being allocated
properly somehow. I can't see that I'm doing anything wrong but if you
can please let me know.

One thing I noticed though is that in mmsystem.h (in the
i686-pc-mingw32 folder) the declaration of MIDIINCAPS (well,
MIDIINCAPSA as it's non-Unicode) is:

   typedef struct tagMIDIINCAPSA {
       WORD wMid;
       WORD wPid;
       MMVERSION vDriverVersion;
       CHAR szPname[MAXPNAMELEN];
       DWORD dwSupport;
   } MIDIINCAPSA,*PMIDIINCAPSA,*LPMIDIINCAPSA;

However in win32-mmsystem.ads, the corresponding definition is:

   type MIDIINCAPSA is                          --  mmsystem.h:835
      record
         wMid : Win32.WORD;                     --  mmsystem.h:836
         wPid : Win32.WORD;                     --  mmsystem.h:837
         vDriverVersion : MMVERSION;            --  mmsystem.h:838
         szPname : Win32.CHAR_Array (0 .. 31);  --  mmsystem.h:839
      end record;

Now call me stupid if you like, but does it not look like there's
something missing there? (i.e. the dwSupport field).

If anyone can be bothered to check this out and see what they think
your comments would be appreciated, especially if you can spot that
I've done something stupid.

Do you think this is a bug that AdaCore should know about if they
don't already?

Obviously I could go down the route of not using dynamic memory
because, as I mentioned, it seems to work that way, but I don't like
not knowing why it didn't work the other way!

=================================
-- File: MidiDevs.adb
with Ada.Text_IO;
with Ada.Unchecked_Deallocation;

with Interfaces.C;
use type Interfaces.C.Unsigned;

with Win32.Mmsystem;
use type Win32.Mmsystem.MMRESULT;

with TestFileRead;

procedure MidiDevs is
   Num_Input_Devices  : Win32.UINT;
   Num_Output_Devices : Win32.UINT;

   res           : Win32.Mmsystem.MMRESULT;
   Midi_In_Caps  : Win32.Mmsystem.LPMIDIINCAPS;
   Midi_Out_Caps : Win32.Mmsystem.LPMIDIOUTCAPS;

   procedure Free is new
      Ada.Unchecked_Conversion(Win32.Mmsystem.LPMIDIINCAPS,
                               Win32.Mmsystem.MIDIINCAPS);
   procedure Free is new
      Ada.Unchecked_Conversion(Win32.Mmsystem.LPMIDIOUTCAPS,
                               Win32.Mmsystem.MIDIOUTCAPS);

   package UINT_Text_IO is new
      Ada.Text_IO.Modular_IO(Win32.UINT);
   package MM_Text_IO is new
      Ada.Text_IO.Modular_IO(Win32.Mmsystem.MMRESULT);

begin
   Num_Input_Devices := Win32.Mmsystem.midiInGetNumDevs;
   Num_Output_Devices := Win32.Mmsystem.midiOutGetNumDevs;

   Ada.Text_IO.Put("There are ");
   UINT_Text_IO.Put(Num_Input_Devices, 0);
   Ada.Text_IO.Put(" input devices available, and ");
   UINT_Text_IO.Put(Num_Output_Devices, 0);
   Ada.Text_IO.Put_Line(" output devices available.");

   Midi_In_Caps  := new Win32.Mmsystem.MIDIINCAPS;
   Midi_Out_Caps := new Win32.Mmsystem.MIDIOUTCAPS;

   if Num_Input_Devices > 0
   then
      Ada.Text_IO.New_Line;
      Ada.Text_IO.Put("The ");
      UINT_Text_IO.Put(Num_Input_Devices, 0);
      Ada.Text_IO.Put_Line(" input devices are:");
      Ada.Text_IO.New_Line;

      for Device_ID in Win32.UINT range 0..(Num_Input_Devices - 1)
      loop
         res := Win32.Mmsystem.midiInGetDevCaps(Device_ID,
                                                Midi_In_Caps,

Win32.Mmsystem.MIDIINCAPS'size
                                                   * Win32.BYTE'size);
         UINT_Text_IO.Put(Device_ID, 0);
         Ada.Text_IO.Put(") ");
         if res = Win32.Mmsystem.MMSYSERR_NOERROR
         then
            Ada.Text_IO.Put("szPname = ");

Ada.Text_IO.Put_Line(Interfaces.C.To_Ada(Win32.To_C(Midi_In_Caps.szPname)));
         else
            Ada.Text_IO.Put("Query Failed. Returned ");
            MM_Text_IO.Put(res, 0);
         end if;
         Ada.Text_IO.New_Line;
      end loop;
   end if;

   -- Try reading in the file
   TestFileRead.Read_And_Print_Patches;
   Ada.Text_IO.New_Line;

   if Num_Output_Devices > 0
   then
      Ada.Text_IO.New_Line;
      Ada.Text_IO.Put("The ");
      UINT_Text_IO.Put(Num_Output_Devices, 0);
      Ada.Text_IO.Put_Line(" output devices are:");
      Ada.Text_IO.New_Line;

      for Device_ID in Win32.UINT range 0..(Num_Output_Devices - 1)
      loop
         res := Win32.Mmsystem.midiOutGetDevCaps(Device_ID,
                                                 Midi_Out_Caps,

Win32.Mmsystem.MIDIOUTCAPS'size
                                                   * Win32.BYTE'size);
         UINT_Text_IO.Put(Device_ID, 0);
         Ada.Text_IO.Put(") ");
         if res = Win32.Mmsystem.MMSYSERR_NOERROR
         then
            Ada.Text_IO.Put("szPname = ");

Ada.Text_IO.Put_Line(Interfaces.C.To_Ada(Win32.To_C(Midi_Out_Caps.szPname)));
         else
            Ada.Text_IO.Put("Query Failed. Returned ");
            MM_Text_IO.Put(res, 0);
         end if;
         Ada.Text_IO.New_Line;
      end loop;
   end if;

   -- Try reading in the file
   TestFileRead.Read_And_Print_Patches;
   Ada.Text_IO.New_Line;

   Free(Midi_In_Caps);
   Free(Midi_Out_Caps);

end MidiDevs;
===================
=================================
-- File: TestFileRead.ads
package TestFileRead is
   procedure Read_And_Print_Patches;
end TestFileRead;
===================
=================================
-- File: TestFileRead.adb
with Ada.Text_IO;

package body TestFileRead is
   ----------------------------
   -- Read_And_Print_Patches --
   ----------------------------
   procedure Read_And_Print_Patches is
      Input_File : Ada.Text_IO.File_Type;
   begin
      Ada.Text_IO.Put_Line("1");
      -- Note: You need a file that exists
      Ada.Text_IO.Open(SysEx_File,
                       Ada.Text_IO.In_File,
                       "FILENAME.TXT");
      Ada.Text_IO.Put_Line("2");
      Ada.Text_IO.Close(Input_File);
      Ada.Text_IO.Put_Line("3");
   end Read_And_Print_Patches;

end TestFileRead;
===========

Re: Having a problem building with win32ada

[John McCabe]

John McCabe <john@nospam.assen.demon.co.uk.nospam> wrote:

Couple of corrections....

1) I've put Unchecked_Conversion where it should be
Unchecked_Deallocation. Replace:

>   procedure Free is new
>      Ada.Unchecked_Conversion(Win32.Mmsystem.LPMIDIINCAPS,
>                               Win32.Mmsystem.MIDIINCAPS);
>   procedure Free is new
>      Ada.Unchecked_Conversion(Win32.Mmsystem.LPMIDIOUTCAPS,
>                               Win32.Mmsystem.MIDIOUTCAPS);

With

   procedure Free is new
      Ada.Unchecked_Deallocation(Win32.Mmsystem.MIDIINCAPS,
                                 Win32.Mmsystem.LPMIDIINCAPS);

   procedure Free is new
      Ada.Unchecked_Deallocation(Win32.Mmsystem.MIDIOUTCAPS,
                                 Win32.Mmsystem.LPMIDIOUTCAPS);


2) In face, the replacing with aliased Win32.Mmsystem.MIDIINCAPS etc
and use of Unchecked_Access DOESN'T WORK. It stops the file open from
failing, but the calls to midiIn/OutGetDevCaps return MMRESULT value
11 whish is Invalid Parameter.

Ah well.

I've done some more searching, and it looks to me like basically the
Win32Ada binding that AdaCore are allowing people to download are a
minimum of 11 years old. Apparently the last intermetrics version
(3.0) was released in 1999. The win32-mmsystem.ads has an Intermetrics
copyright date of 1995.

This is rather unfortunate. I'd hope this would be very useful for
what I wanted to do but, to be honest, it looks like the idea is
doomed as I really don't want to have to re-create a whole set of
Win32 Ada bindings based on the existing MinGW versions of these files
(that also appear to be out of date compared to the definitions of the
types you can find on Microsoft's website).

Disappointing.
John

Re: Having a problem building with win32ada

[tmoran]

> One thing I noticed though is that in mmsystem.h (in the
> i686-pc-mingw32 folder) the declaration of MIDIINCAPS (well,
> MIDIINCAPSA as it's non-Unicode) is:
>
>    typedef struct tagMIDIINCAPSA {
>        WORD wMid;
>        WORD wPid;
>        MMVERSION vDriverVersion;
>        CHAR szPname[MAXPNAMELEN];
>        DWORD dwSupport;
>    } MIDIINCAPSA,*PMIDIINCAPSA,*LPMIDIINCAPSA;
>
> However in win32-mmsystem.ads, the corresponding definition is:
>
>    type MIDIINCAPSA is                          --  mmsystem.h:835
>       record
>          wMid : Win32.WORD;                     --  mmsystem.h:836
>          wPid : Win32.WORD;                     --  mmsystem.h:837
>          vDriverVersion : MMVERSION;            --  mmsystem.h:838
>          szPname : Win32.CHAR_Array (0 .. 31);  --  mmsystem.h:839
>       end record;

> I've done some more searching, and it looks to me like basically the
> Win32Ada binding that AdaCore are allowing people to download are a
> minimum of 11 years old. Apparently the last intermetrics version
> (3.0) was released in 1999. The win32-mmsystem.ads has an Intermetrics
> copyright date of 1995.

Looking at an mmsystem.h dated 8/21/96 I see

typedef struct tagMIDIINCAPSA {
    WORD        wMid;                   /* manufacturer ID */
    WORD        wPid;                   /* product ID */
    MMVERSION   vDriverVersion;         /* version of the driver */
    CHAR        szPname[MAXPNAMELEN];   /* product name (NULL terminated string) */
#if (WINVER >= 0x0400)
    DWORD   dwSupport;             /* functionality supported by driver */
#endif
   } MIDIINCAPSA,*PMIDIINCAPSA,*LPMIDIINCAPSA;

Do you need to access dwSupport?  If not, do you need to allocate space for
a record of this type, or do you just use pointers to a record allocated
by mmsystem?

Re: Having a problem building with win32ada

[John McCabe]

John McCabe <john@nospam.assen.demon.co.uk.nospam> wrote:

>Guys

<..snip..>

>Now call me stupid if you like, <..snip..>

You're stupid - glad it was me who spotted it though :-) Sudden flash
of inspiration at ~6:00am....

>         res := Win32.Mmsystem.midiInGetDevCaps(Device_ID,
>                                                Midi_In_Caps,
>
>Win32.Mmsystem.MIDIINCAPS'size
>                                                   * Win32.BYTE'size);

It would probably help if I wasn't asking for the Midi_In_Caps
structure to be filled in with 64x the amount it should be. I should
be dividing by Win32.BYTE'Size here, not multiplying.

Still doesn't get round the issue with win32-mmsystem,h but, in answer
to Tom (later), I don't need the dwSupport field on the IN side as
it's always zero.

John