[PATCH 1/5] winmm: Improve MCI's Sysinfo command.
eric.pouech at orange.fr
Thu Apr 1 14:36:31 CDT 2010
Joerg-Cyril.Hoehle at t-systems.com a écrit :
> Eric Pouech wrote:
>> did you test the 16 => 32 bit conversion for the MCI_ALL_DEVICE ?
> Which ones do you have in mind? There are tests involving MCI_ALL_DEVICE_ID
> that pass on both win9x and later (also in patch #5). I wrote a few
> more MCI tests privately. Generally, I added (UINT16) casts in Wine
> when I saw test failures on Win9x platforms, then kept doing so (i.e.
> I'm not sure I've tested SYSINFO with a 0000FFFF deviceID on Win9x in
> particular or whether I simply use that pattern everywhere now after
> having been burnt once). There are a few patches already in
> git that fix a few MCI_ALL_DEVICE_ID here and there, but as you wrote
> yourself in the TODO header long ago, support for it is incomplete.
> Making "close all", "play all" etc. work is on my private TODO list, but
> I never started working on this particular item.
>> actually, I'd say it belongs to the 16=>32 mci message mapper, not in
>> generic 32bit code
> Do you mean dlls/mmsystem.dll16? I never looked at it but I
> don't think that's the correct place, see below.
> Do you mean the A/W (un)mapping? That's distinct, because it deals
> with string conversions only, as the name suggests, and it does
> not mogrify dwParam1.
> Current test results suggest that MCI_ALL_DEVICE_ID is not only a 16/32
> issue -- at least when I equate 16 with MS-Windows 3.x -- Have a look
> at the mciGetDeviceID("all") test case, which returns a 16bit FFFF on Win9x,
> not FFFFFFFF. Therefore I believe Wine must be prepared for receiving
> 0000FFFF as ALL_ID from old Win9X apps or drivers -- possibly regardless
> of them using the A or W function entry points.
that's the point I wanted to be clarified
did you check what mciGetDeviceID("all") returns on Vista or XP ?
if it's 0xFFFF in all cases, the real answer is then that device ID are
internally UINT16 and we shouldn't care at all about 32 bit extension
it it's 0xFFFFFFFF in latest windows, then likely the device ID has been
extended internally, and we should cope with both 0xFFFF and 0xFFFFFFFF
values in winmm
"The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
More information about the wine-devel