[PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.

Octavian,

are you aware of bug http://bugs.winehq.org/show_bug.cgi?id=22146
and the partial patch and additional test cases there?
> winmm: Add MCI_INTEGER_PTR return type for DWORD_PTR return values.
> +#define MCI_INTEGER_PTR         13
> What kind of testing did you perform on native systems to derive the existence of this value?
> If such value does not exist, then I fear your patch set looses the ability to
> drop in native dlls for compatibility testing and validation.
> If it exists, then it's good news you found it.
> -static	DWORD	MCI_ParseOptArgs(DWORD_PTR* data, int _offset, LPCWSTR lpCmd,
> +static	DWORD	MCI_ParseOptArgs(BYTE* data, int _offset, LPCWSTR lpCmd,
> -		    if (!MCI_GetDWord(&(data[offset+0]), &args) ||
> -			!MCI_GetDWord(&(data[offset+1]), &args) ||
> -			!MCI_GetDWord(&(data[offset+2]), &args) ||
> -			!MCI_GetDWord(&(data[offset+3]), &args)) {
> +		    if (!MCI_GetDWord(data+offset+0*sizeof(DWORD), &args) ||
> +			!MCI_GetDWord(data+offset+1*sizeof(DWORD), &args) ||
> +			!MCI_GetDWord(data+offset+2*sizeof(DWORD), &args) ||
> +			!MCI_GetDWord(data+offset+3*sizeof(DWORD), &args)) {

The MCI_XYZ_PARMS structures are neither DWORD_PTR, not BYTE*,
they are DWORD with some DWORD_PTR in between.
Wouldn't using DWORD* data help avoid such pointer arithmetic
and eliminate several hunks of the patch ?

Regards,
 Jörg Höhle