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

Octavian Voicu octavian.voicu at gmail.com
Fri Aug 27 09:30:24 CDT 2010


On Fri, Aug 27, 2010 at 4:25 PM, Eric Pouech <eric.pouech at orange.fr> wrote:
> 2010/8/27 Octavian Voicu octavian.voicu at gmail.com
>> I didn't think it was necessary to test on native systems. The command
>> parsing looks like internal winmm stuff, which makes no difference to
>> the exported interfaces, as long as the command string is parsed into
>> the corresponding MCI_ structures correctly.
>
> no the format of MCI string tables is public, and Wine aims at supporting
> native MCI drivers (which can come with their own tables)
> 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, and the MCI_DEVTYPE_ constants for the
rest; can't figure what device is 524 though, last device is
MCI_DEVTYPE_SEQUENCER which is 523).

Wine currently uses string ids, with a table to map device ids to
device name strings.

Also, winmm_res.rc and others looks really bad because they use
numeric constants (eg. 0x00000803L instead of MCI_OPEN, 0).

>>In any case, using the MCI_XYZ_PARMS union looks much better :) Maybe
>>also stick MCI_GENERIC_PARMS in there.
> I don't agree here. IMO the parser should be the most agnostic possibly
> against the real data structures (the MCI string table shall contain the
> definition of the structures including type of data). so, using unions and
> structures is going into the right direction (even if I agree that current
> parser doesn't fully comply with that goal)

Not sure if I understand exactly what you mean here. Bottom line is
that unions & structures are the way to go, like in Joerg's patch, but
maybe try to make it look prettier?

Octavian


PS: found this really useful pdf documenting MCI:
http://mediaxw.sourceforge.net/files/tmp/Windows%20NT%20DDK%20-%20Multimedia%20Drivers.pdf



More information about the wine-devel mailing list