Joerg-Cyril.Hoehle@t-systems.com a écrit :
Hi,
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