Re: [PATCH] ole32: OleGetClipboard(): zero output interface pointer on error

[Paul Gofman]

I managed to make Windows OleGetClipboard to fail by pre-locking the
clipboard by OpenClipboard and verified that output pointer is zeroed. I
should note that Wine OleGetClipboard does not fail in this case. Should
I add such a test to this patch (with todo_wine on OleGetClipboard
returning CLIPBRD_E_CANT_OPEN)?

On 01/13/2016 02:18 PM, Paul Gofman wrote:
> Hi Nikolay,
> I came through this while testing COM/OLE init stuff and tried to
>
> use OleGetClipboard to probe actual OLE state in Windows. The fact is
> that on Windows OleGetClipboard succeeds for me even if Ole is not
> initialized (and this is not the case in Wine). So straightforward test
> will be failing on Windows (returning S_OK when I expect and error in
> Wine). It is probably some separate compatibility issue. My test used to
> assign 0xdeadbeef to the interface pointer and release any non-null
> interface after the call regardless of status (as I saw as a common
> practice in ole tests), so it crashed under wine. I just thought it is
> appropriate to zero pointer on output as long it is a standard convention.
>     I could possibly search for some conditions when OleGetClipboard
> fails on Windows to make a valid test like this. Does it make sense or
> better leave it as is for now?
>
> Thanks,
>     Paul.