[PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.

Joerg-Cyril.Hoehle at t-systems.com Joerg-Cyril.Hoehle at t-systems.com
Fri Aug 27 11:36:52 CDT 2010


Octavian Voicu wrote:
>> so binary compatibility in RC files is required
>We don't have this right now. Native winmm.dll uses integer resource
>ids (id 200 for core commands, [...])
>Wine currently uses string ids
Could you please elaborate on that? I wasn't aware of an incompatibility.

>> I don't agree here. IMO the parser should be the most agnostic possibly
>> against the real data structures
>Not sure if I understand exactly what you mean here

I believe Eric envisions a parser that needs no MCI_*_PARMS at all
because everything lies in the resource (except that the first
DWORD_PTR is the callback).  Even MCI_RETURN need not be second (yet
there's no known case where that happens).  It would be a major change
from the current parser.

It could be sketched as follows:
 - get first token (verb)
 - get second token (beware of quoting) ("device")
 - find driver according to device
    - either name of an existing alias
    - or name of MCI driver ("waveaudio")
    - or waveaudio!foo.wav
    - or "all"
    - or something else
 - load driver's command table (may need loading driver!)
 - parse command options according to table

Now we know the command's numeric value and can act upon it.
That would be much more compatible than what is in place now.

Still, the devil lies in the details. E.g. a)
sound notify
are valid MCI commands. Look ma, no device!

b) Sysinfo cdaudio quantity open
need IMHO not load the cdaudio driver. It strictly operates at winmm's
level.  Perhaps first try to identify the verb via the core table, and
if it's a core command like MCI_SYSINFO, never load the driver?
MCI_SYSINFO_PARMS.wDeviceType needs special treatment anyway,
the parser is not enough.

c) When to unload the driver?

At some point one needs MCI_*_PARMS.  For instance, it's winmm's job
to detect MCIERR_DUPLICATE_ALIAS.  How is it going to access the alias
field if not via MCI_OPEN_PARMS and thus imposing that all
MCI_*_OPEN_PARMS are congruent?  (e.g. MCI_DGV|WAVE_OPEN_PARMS).

One could imagine backparsing the resource file to detect the position
of the slot that defines the MCI_ALIAS element... This is just crazy.

I've tests that prove (and a patch in my queue) that unlike the
mciSendCommand interface, the string parser always sets an alias.  So
at some point it must set the lpstrAlias slot.  How is it going to do
that if not via MCI_OPEN_PARMS?

 Jörg Höhle

More information about the wine-devel mailing list