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

[Octavian Voicu]

On Fri, Aug 27, 2010 at 4:25 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote:
> 2010/8/27 Octavian Voicu octavian.voicu(a)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...