Hi,
I forgot to mention that this patch was rebased against 1.1.42, supersedes the former "Fix A/W mapping for 64bit Wine" patch and is not dependent on prior 64bit patches.
Currently, I can't think of a fully general solution to the A/W mapping problem. In theory, an unknown driver with new unknown commands and keywords could be registered. We have little idea how large the structure is and which flags controls the validity of the nth slot, e.g. when to call strdupAtoW().
One could think about parsing the command table to obtain this information. However, a) I see no guarantee that there's a unique MCI_STRING value for a given bit that is set in the flags parameter. b) This does not help with baroque commands like SYSINFO which sometimes put a string, sometimes a DWORD into the result buffer or which are documented to count buffer sizes in bytes, unlike other commands.
This latter example reveals that calling MCI_Cleanup() before unwrapping is unfortunate, as valuable type information is lost. It is currently encapsulated inside mciSendCommandW.
Open questions: - Does Wine actually support hooking in a new native MCI driver? (beside DLL overrides)
- Why does Wine copy dwCallback only when MCI_NOTIFY is set? It is not wrong, but why care? To prevent a Valgrind message when that slot was not filled by the caller?
BTW, my (unpublished) testing reveals that unlike what MSDN says, dwRetSize is counted in characters in MCI_SYSINFO_PARMSW, not bytes (at least on w2k with SYSINFO_NAME [OPEN]). But that shall be the subject of another patch.
Regards, Jörg Höhle