[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    winmm: For MCI parsing, use 64bit compatible structures.
From:       <Joerg-Cyril.Hoehle () t-systems ! com>
Date:       2010-03-30 14:54:48
Message-ID: 47CC5ABB01651443A88DB8EC5B4D657B740303 () S4DE8PSAANK ! mitte ! t-com ! de
[Download RAW message or body]

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




[prev in list] [next in list] [prev in thread] [next in thread]