winmm: For MCI parsing, use 64bit compatible structures.

Joerg-Cyril.Hoehle at Joerg-Cyril.Hoehle at
Tue Mar 30 09:54:48 CDT 2010


Eric Pouech wrote:
>this patch is ugly as hell...
Please qualify.  To me,
-	    data[3] = (DWORD_PTR)dev;
+ = dev;
looks more robust than before:
 - no magic offsets,
 - no casts that may silence warnings.

The one #ifdef WIN64 is a pure performance optimization on Win32.
The other one with the TRACE() is indeed ugly, but I don't feel
it's safe to call debugstr_w() on misaligned data in Wine64. Even
if it were, printing data[3] as string may be wrong, because it
may be data[4] (+5) that holds a pointer, not (3+4).  Therefore I
decided to renounce to print string contents on 64bit, despite
their value in the logs.

> and it still believe we can do the MCI 
>parser without knowing about MCI structures internals
What do you mean?
Quite to the contrary, the parser depends on knowing the internals
of some commands (like MCI_OPEN) as well as the convention about the
return value as 2nd (+3rd) slot after the callback.

The parser bridges the gap between the resource definition files
winmm_res.rc that are now in git and are known to work well with
32bit and the mixed DWORD/DWORD_PTR MCI_..._PARMS definitions whose
correctness has been (partially) validated by tests.

What we don't know is whether Win64 introduced a different winmm_res.rc.
I'd sure would be pleased if somebody could describe whether there
have been changes to the resources to accommodate 64bit pointers in MS-Windows.

Everybody, please visit bug #22146 if you can contribute such knowledge.
(Part of) my patch is needed even if there were (thanks to lack of magic offsets).

 Jörg Höhle

More information about the wine-devel mailing list