winmm: Improve MCI A/W mapping slightly.

[Joerg-Cyril.Hoehle at t-systems.com]

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