winmm/tests: waveOutGetDevCaps called with invalid size
Robert Reif
reif at earthlink.net
Tue Apr 29 06:47:19 CDT 2008
Peter Åstrand wrote:
> On Mon, 28 Apr 2008, Robert Reif wrote:
>
>
>>> However, the waveOutGetDevCapsW fails as well on WTS, also returning
>>> MMSYSERR_INVALPARAM.
>>>
>
>
>> Let me get this straight, your company's product doesn't pass this wine
>> regression test so you want to remove the test?
>>
>
> No. Quoting from my intial post:
>
> "The CapsW test fails with our sound driver (tlsnd) as well as Microsofts
> Terminal Services driver (rdpsnd)."
>
> We can of course change our driver to accept invalid structure sizes, but
> "plain" Terminal Servers would still fail.
>
> Of course, if you add MMSYSERR_INVALPARAM as accepted return code, as you
> suggest, the problem would go away, but then again, the test is mostly
> pointless, since it succeeds regardless of if the API call succeeds or
> not.
>
>
> Rgds,
> ---
> Peter Åstrand ThinLinc Chief Developer
> Cendio AB http://www.cendio.se
> Wallenbergs gata 4
> 583 30 Linköping Phone: +46-13-21 46 00
First of all, requesting 4 bytes is not invalid but a perfectly
reasonable thing to do.
It is just reading the manufactures id and product id. However this
behavior
is not documented in MSDN so at best it's just unspecified behavior.
The reason
most hardware drivers get this right is because Microsoft does check this
behavior in their hardware compatibility test so manufactures can get
certification that their hardware and drivers are working properly. Now
the
two drivers that are behaving differently happen to be software drivers and
have probably never had the hardware driver tests run on them. Technically,
this behavior is not wrong because it's not specified but Microsoft
would expect
that the drivers do the short copy without error if they wanted
certification.
The tests in wine are valid but incomplete because they don't check for
the possible buffer overrun that could occur if the driver just ignores
the requested
size. A black list should be added for Terminal Server and your product
because they behave differently than most hardware drivers. This would
ensure that regressions don't slip into wine when drivers are added or
changed
and that wine behaves like Microsoft expects a hardware driver to behave.
More information about the wine-devel
mailing list