Re: winmm: For MCI parsing, use 64bit compatible structures.
joerg-cyril.hoe...@t-systems.com a écrit : 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. actually there are not magic offsets, but can be computed from the previous values written. the current parser can be better rewritten in a way were fields are written to in sequential order (currently, for example, return values are written at the end, which is not satisfactory) but I agree current that current parser can be improved 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. MCI_OPEN is kinda specific the others are not. it just uses that first parameter is callback, second is the returned type (which is described in the MCI table), then parameters, which are also described in the table. no nothing magic here 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. to me what works are test (and packing) of MCI structures on 64 windows (but with native DLLs, hence using native MCI tables) what doesn't work is MCI parser (with builtin winmm) and same MCI structures but we never validated builtin MCI tables on windows... 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. we just need a copy of 64bit winmm.dll. If someone could mail it to me privately, it would be rather easy to check. A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
winmm: For MCI parsing, use 64bit compatible structures.
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
Re: winmm: For MCI parsing, use 64bit compatible structures.
joerg-cyril.hoe...@t-systems.com a écrit : Hi, I believe this patch can stand on its own, regardless of whether we discover an MCI_INTEGER64 type or similar later (cf. bug 22146). It is not all about Wine64. I have two others in my queue: - One deals with HWND and the like in the MCI_XYZ_PARMS. - Another adds more tests that do not depend on sound being configured. These are not ready yet for submission. Yet this first patch is good enough to start gathering results on test.winehq. André's machine basically passed the MCI tests no worse than Wine32 with it. This patch depends on the Sysinfo patch from earlier today. Regards, Jörg Höhle this patch is ugly as hell... and it still believe we can do the MCI parser without knowing about MCI structures internals A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
