Hi,
Michael Stefaniuc wrote:
static HRESULT WINAPI IDirectSoundCaptureImpl_CreateCaptureBuffer
+ if (pUnk) { + WARN("invalid parameter: pUnk != NULL\n"); + /* *lplpDSCaptureBuffer = NULL; Not done by native dsound */ + return DSERR_NOAGGREGATION; + }
What's your rationale for doing so? Bug compatibility with native is fine, however not setting NULL is problematic before you've reached 100% compatibility, have you?
What I mean is that if there's a situation where Wine's CreateCaptureBuffer returns some DSERR such as NOTIMPL where native does not, then that's an unexpected situation for the app which it may not be well prepared to handle, as it is untestable on native. Now not zeroing output pointers may make it even harder for the app to remain in sane state. Then blame the app or Wine for a crash?
If OTOH you know that the Wine module *always* returns the exact same values as native, then I've no objection in not zeroing output pointers when native does neither. Yet you'll have to consider that native may do so in the future, witness a growing number of MSDN documents covering later APIs that specifically mention zeroing pointers in case of failure.
IIRC, AJ removed from my mmdevapi tests one snippet that showed that native's GetService does not zero an output pointer even though MSDN says so -- Wine zeroes. Yet perhaps I got confused, messed up with patches and submitted the one that did not contain that test so maybe AJ never had a chance to see it. I'll have to check that.
Regards, Jörg Höhle