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.