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

Joerg-Cyril.Hoehle at t-systems.com Joerg-Cyril.Hoehle at t-systems.com
Tue Mar 30 08:12:58 CDT 2010


Hi,

Eric Pouech wrote:
>this patch is ugly as hell...
Please qualify.  To me,
-	    data[3] = (DWORD_PTR)dev;
+	    parms.open.lpstrElementName = 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).

Regards,
 Jörg Höhle



More information about the wine-patches mailing list