Need Windows multimedia include file (mmsystem.inc)

[NoCforMe]

I want to fool around with some MIDI stuff, so I thought I'd put together a little testbed, but alas, MASM32 is missing the mmsystem.inc file.

Odd: I found this version of the file (from a German site, file was apparently created for TASM), but it doesn't have any function prototypes (I'm trying to use midiOutGetNumDevs() and midiOutGetDevCaps(). But looking at this version of mmsystem.h (from the Wine project), I see everything's there. Why would somebody go to all the trouble of creating a .inc file from the .h, but leave out essential stuff like prototypes?

In any case, does anyone know where I can get a working copy of this file? It looks as if MASM32 has the required library (winmm.lib).

Thanks in advance for any help!

[dedndave]

it is in the masm32 package, named winmm.inc/lib
Hutch puts all the constants in windows.inc (which includes winextra.inc)

the link you gave does have prototypes

Code Select Expand

1506 UINT            WINAPI  mixerGetNumDevs(void);
1507 UINT           WINAPI  mixerOpen(LPHMIXER,UINT,DWORD_PTR,DWORD_PTR,DWORD);
1508 UINT            WINAPI  mixerClose(HMIXER);
1509 DWORD           WINAPI  mixerMessage(HMIXER,UINT,DWORD_PTR,DWORD_PTR);
1510 UINT           WINAPI  mixerGetDevCapsA(UINT_PTR,LPMIXERCAPSA,UINT);
1511 UINT           WINAPI  mixerGetDevCapsW(UINT_PTR,LPMIXERCAPSW,UINT);
1512 #define                 mixerGetDevCaps WINELIB_NAME_AW(mixerGetDevCaps)
1513 UINT            WINAPI  mixerGetLineInfoA(HMIXEROBJ,LPMIXERLINEA,DWORD);
1514 UINT            WINAPI  mixerGetLineInfoW(HMIXEROBJ,LPMIXERLINEW,DWORD);
1515 #define                 mixerGetLineInfo WINELIB_NAME_AW(mixerGetLineInfo)
1516 UINT            WINAPI  mixerGetID(HMIXEROBJ,LPUINT,DWORD);
1517 UINT            WINAPI  mixerGetLineControlsA(HMIXEROBJ,LPMIXERLINECONTROLSA,DWORD);
1518 UINT            WINAPI  mixerGetLineControlsW(HMIXEROBJ,LPMIXERLINECONTROLSW,DWORD);
1519 #define                 mixerGetLineControls WINELIB_NAME_AW(mixerGetLineControls)
1520 UINT            WINAPI  mixerGetControlDetailsA(HMIXEROBJ,LPMIXERCONTROLDETAILS,DWORD);
1521 UINT            WINAPI  mixerGetControlDetailsW(HMIXEROBJ,LPMIXERCONTROLDETAILS,DWORD);
1522 #define                 mixerGetControlDetails WINELIB_NAME_AW(mixerGetControlDetails)
1523 UINT            WINAPI  mixerSetControlDetails(HMIXEROBJ,LPMIXERCONTROLDETAILS,DWORD);

[NoCforMe]

So why did he name the file "winmm.inc" when the C header file is "mmsystem.h" (according to MSDN)? Yes, I found the file after you pointed it out.

Yes, the .h file I linked to has prototypes, but the .inc file does not. (Hutch's file does, though.)

[dedndave]

i am guessing it was the name in an older version of the SDK

as for the missing prototypes - if it is for tasm, they may not be required

[hutch--]

NoCforMe,

The MASM32 SDK matches include file names with library file names, something it has done since 1997. What you are assuming is following the technique that Microsoft change from one SDK to another, the C header files which do not have a direct relationship with the library names.

[NoCforMe]

There's another .inc file I could use: since the Microsoft header file is mmreg.h, I guess it should be called mmreg.inc. Can't find it in the MASM package.

This file has a list of MIDI manufacturers and products (see this MSDN page for manufacturers). I found this version of the .h file, but I'd rather not have to reformat it by hand. Anyone know if there's an .inc version of this floating around out there?

[MichaelW]

I didn't check every constant in the MMReg.h from the SDK, but all of the 20 or so that I radomly selected were defined in the MASM32 winextra.inc.

For the structure definitions I was able to find only some of them in windows.inc.

[NoCforMe]

Aaaargh, what a mess!

Yes, the MM_ defines seem to all be there in winextra.inc. (Basically all the manufacturer and product identifiers from mmreg.h, including other stuff that I don't need at the moment, structures and the like.)

In fact, this list seems to be far more up-to-date than the product listing on MSDN. F'rinstance, MSDN lists nothing by Mark of the Unicorn (MOTU), while there are dozens of MOTU products listed in winextra.inc. (This seems to correspond to the MMreg.inc file I downloaded as part of the WinInc package from Japheth.de.)

To make matters worse, the product identifiers aren't even unique! What's up with that?

I had hoped to cobble together a little utility to display the MIDI devices installed in my system, showing such relevant details as the manufacturer and product identifier. Should be simple, right? I can see it would be a gigantic pain in the ass. Rather than simply enumerating products from one to infinity, they're all over the place:

Code Select Expand


MM_WORKBIT_MIXER                 equ 1
MM_WORKBIT_WAVEOUT               equ 2
MM_WORKBIT_WAVEIN                equ 3
MM_ADDX_PCTV_DIGITALMIX          equ 1
MM_ADDX_PCTV_WAVEIN              equ 2
MM_ADDX_PCTV_WAVEOUT             equ 3
MM_NVIDIA_WAVEOUT                equ 1
MM_NVIDIA_WAVEIN                 equ 2
MM_NVIDIA_MIDIOUT                equ 3

just to give you a small sample. So to display the product, you have to determine the manufacturer, then select a subset of all available products based on the manufacturer's ID. Requires lots of structures and fiddling.

Unless someone has any brilliant ideas how to deal with this ...

[hutch--]

As before, find out which LIBRARY the APIs are in and match the include file to the LIBRARY. Note as before that the MASM32 project has NEVER used the variable technique that Microsoft use from one SDK to another.

[dedndave]

Code Select Expand

MM_WORKBIT_MIXER                 equ 1
MM_ADDX_PCTV_DIGITALMIX          equ 1
MM_NVIDIA_WAVEOUT                equ 1

this would tend to indicate that the devices are compatible, as far as the internal API is concerned
any differences might be taken care of in the drivers

if you want a manufacturer name, WMI can probably do it - or look in the registry

[NoCforMe]

Code Select Expand

MM_WORKBIT_MIXER                 equ 1
MM_ADDX_PCTV_DIGITALMIX          equ 1
MM_NVIDIA_WAVEOUT                equ 1

this would tend to indicate that the devices are compatible, as far as the internal API is concerned
any differences might be taken care of in the drivers

I don't think so. Check these out:

Code Select Expand


MM_BTV_MIDIIN                    equ 3
MM_NVIDIA_MIDIOUT                equ 3


I don't think these can be compatible (one's an input device, the other an output device).

if you want a manufacturer name, WMI can probably do it - or look in the registry

The manufacturer's names are easy--they're unique, and easily gotten from the MIDIOUTCAPS structure delivered by midiOutGetDevCaps(). (Likewise for input capabilities.) The product name is likewise retrievable: it's just that you have to screw around with it and map it to the manufacturer's ID.

[dedndave]

Code Select Expand

MM_BTV_MIDIIN                    equ 3
MM_NVIDIA_MIDIOUT                equ 3

yes - and because one is an input and one is an output, they are used in different ways
i.e., they are not interchangable
whereas the others probably are

[NoCforMe]

So you're saying that devices with the same IDs are equivalent, unless they're not? Do I have that right?

(Sorry, I don't use smiley faces ...)

[dedndave]

it will probably make more sense to you after you have played with it for a while   :t

[NoCforMe]

It's always made sense to me.

It's just that it's a pain in the ass because of the way Micro$oft set up the whole system of mfgr. and product IDs (because of non-unique product IDs, etc.).

Here's what I've come up with (a representative sample of the entire gargantuan mass of data):

Code Select Expand


$mfrMap STRUCT
  ID DD ?
  prodPtr DD ?
  textPtr DD ?
$mfrMap ENDS

$c2t STRUCT
  cd DD ?
  txt DD ?
$c2t ENDS


ManufacturerList LABEL DWORD
$mfrMap <MM_INTEL, MM_INTELprods, MM_INTELstr>
$mfrMap <MM_VOCALTEC, MM_VOCALTECprods, MM_VOCALTECstr>
$mfrMap <MM_VOYETRA, NULL,MM_VOYETRAstr>
$mfrMap <MM_ANTEX, NULL, MM_ANTEXstr>

. . . . .
DD -1 ;End o'list.

MM_INTELprods LABEL DWORD

$c2t <MM_INTELOPD_WAVEIN, MM_INTELOPD_WAVEINstr>
$c2t <MM_INTELOPD_WAVEOUT, MM_INTELOPD_WAVEOUTstr>
$c2t <MM_INTELOPD_AUX, MM_INTELOPD_AUXstr>
$c2t <MM_INTEL_NSPMODEMLINE, MM_INTEL_NSPMODEMLINEstr>
DD -1 ;End o'list.

MM_VOCALTECprods LABEL DWORD

$c2t <MM_VOCALTEC_WAVEOUT, MM_VOCALTEC_WAVEOUTstr>
$c2t <MM_VOCALTEC_WAVEIN, MM_VOCALTEC_WAVEINstr>
DD -1 ;End o'list.

;===================================================
; Manufacturer & product ID strings
;===================================================

MM_INTELstr DB "INTEL", 0
MM_VOCALTECstr DB "VOCALTEC", 0
MM_VOYETRAstr DB "VOYETRA", 0
MM_ANTEXstr DB "ANTEX", 0

MM_INTELOPD_WAVEINstr DB "INTELOPD_WAVEIN", 0
MM_INTELOPD_WAVEOUTstr DB "INTELOPD_WAVEOUT", 0
MM_INTELOPD_AUXstr DB "INTELOPD_AUX", 0
MM_INTEL_NSPMODEMLINEstr DB "INTEL_NSPMODEMLINE", 0
MM_VOCALTEC_WAVEOUTstr DB "VOCALTEC_WAVEOUT", 0
MM_VOCALTEC_WAVEINstr DB "VOCALTEC_WAVEIN", 0


See how that works?

Extra credit question: why is there NULL in the middle field in the last 2 entries in the mfgr. list?