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
