However, I still think it's VERY strange to expect success from an invalid call. You are describing it as an "invalid argument" yourself. Why should we expect a call with an "invalid argument" to succeed? And again, the test does NOT pass on all Microsoft versions; it fails on Terminal Servers.
If size wasn't relevant, it wouldn't be passed.
The size is used for determining which kind of WAVEOUTCAPS structure you pass.
There are only two options: only pass the number of bytes requested or return an error for unreasonable sizes. What is Terminal Server doing?
It's returning an error.
If the point is to verify that waveOutGetDevCaps doesn't write more than the size supplied, this should be verified. I'd also like to point out that the Wine implementation also doesn't handle this correctly: Only waveOutGetDevCapsA does a memcpy() using the size argument; waveOutGetDevCapsW does not.
waveOutGetDevCapsW lets the driver do the copy (just like old versions of windows). The driver should be checking the size and only copying that much. If it doesn't, then it broken.
Any references for this claim?
You are saying that the driver "should only copy that much", but *what* should it copy? In other words: If the size doesn't match the size of any known structure (WAVEOUTCAPSA/WAVEOUTCAPSW/WAVEOUTCAPS2A/WAVEOUTCAPS2W), should the driver then just *assume* some structure? Which one? As far as I know, there's no guarantee that, for example, the first sizeof(WAVEOUTCAPSW) bytes of WAVEOUTCAPSW are the same as WAVEOUTCAPS2W.
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