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