[PATCH 1/5] winmm: Improve MCI's Sysinfo command.
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. Of course, a single (or few) central place(s) to convert wDeviceID=(MCIDEVICEID)(WORD)wDeviceID or wDeviceID= wDeviceID==0xFFFF ? MCI_DEVICE_ALL_ID : wDeviceID is a nice idea. That could be a distinct patch. I'm convinced this handle is truly a 16 bit entity, even after it has been upgraded to a UINT/DWORD type at some time in the past. Still, SYSINFO is a special case, as it receives a device ID not only as function argument but also in its PARMS structure. Regards, Jörg Höhle.
Hi, Eric Pouech wrote:
did you test the 16 => 32 bit conversion for the MCI_ALL_DEVICE ?
It's good you asked. Upon closer inspection, MCI_Sysinfo appears to behave differently. I'd say it's even a bug in MS that setting SYSINFO_PARMS.wDeviceType = MCI_ALL_DEVICE_ID is not recognized! Only sendCommand(MCI_ALL_DEVICE_ID, MCI_SYSINFO ...) appears usable to obtain the functionality of "sysinfo all ..." :-( I'll supersede the patch ASAP. Grr, that's not going to simplify the parser. Regards, Jögr Höhle
Joerg-Cyril.Hoehle(a)t-systems.com a écrit :
Hi,
Eric Pouech wrote:
did you test the 16 => 32 bit conversion for the MCI_ALL_DEVICE ?
It's good you asked. Upon closer inspection, MCI_Sysinfo appears to behave differently. I'd say it's even a bug in MS that setting SYSINFO_PARMS.wDeviceType = MCI_ALL_DEVICE_ID is not recognized! Only sendCommand(MCI_ALL_DEVICE_ID, MCI_SYSINFO ...) appears usable to obtain the functionality of "sysinfo all ..." :-(
I'll supersede the patch ASAP. Grr, that's not going to simplify the parser.
Regards, Jögr Höhle
but does SYSINFO_PARMS.wDeviceType = (WORD)(DWORD)MCI_ALL_DEVICE_ID; work better ? if yes, I'd be convinced for a bug in native winmm, missing a (WORD) cast somewhere... A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Hi, Eric Pouech wrote:
SYSINFO_PARMS.wDeviceType = (WORD)(DWORD)MCI_ALL_DEVICE_ID; work better ? I tested ... = (WORD)MCI_ALL_DEVICE_ID which should do the same. It does not yield the "all" functionality.
did you check what mciGetDeviceID("all") returns on Vista or XP ? Yes, and it is in the tests. Alas, you'll have to believe my comment therein that Win9x returns a 16bit FFFF and the others a 32bit FFFFFFFF, because the testsuite never works like ok((iswin9x && MCI_ALL_DEVICE_ID==err) || !iswin9x && (WORD)MCI_ALL_DEVICE_ID==err))
While we know that 1. mciDeviceID "all" yields 0000FFFF in Win9x and that 2. mciCommand(0000FFFF, MCI_SYSINFO ...) yield "all" only in Win9x sadly we don't know if some Win9x app out there uses 0000FFFF as MCIDEVICEID. My opinion is that MCIDEVICEID has to be treated in Wine like a 16bit entity because compatibility with Win9x requires it and the question whether >65535 handles can be opened is not interesting in practice -- or we'll have to start writing version-dependent code. Regards, Jörg Höhle
Joerg-Cyril.Hoehle(a)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 -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
participants (2)
-
Eric Pouech -
Joerg-Cyril.Hoehle＠t-systems.com