winmm/tests: waveOutGetDevCaps called with invalid size

[Robert Reif]

Robert Reif wrote:
> 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.
>
>
>
>   
Another solution to this problem would be to add the equivlent of 
todo_windows.
That way we wouldn't have to throw out valid tests just because some random
driver in windows does the wrong thing.  That would ensure that wine works
properly even if windows doesn't.  I have seen the trend lately to throw out
valid tests that fail on windows due to driver dependent behavior and that
disturbs me.  I would like to see wine held up to a higher standard than 
typical
windows drivers.