[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

[Eric Pouech]

[e-mail] 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+

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

[Eric Pouech]

[e-mail] 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