I've been looking into the ole32:clipboard test failures (http://test.winehq.org/data/tests/ole32:clipboard.html) I'm now convinced that Windows simply doesn't handle FORMATETC.ptd correctly when retrieving an IDataObject via OleGetClipboard().
When looking at the test.winehq.org status page mentioned above, it appears that the tests succeed on at least a number of boxes. However, when doing a bit more testing on the retrieved ptd data (see attached diff) it's obvious that the retrieved ptd data contains garbage on all Windows versions >= Win2k (meaning with extra tests in attached diff applied I see failures on all my >= Win2k machines).
It appears that at some point Windows is using uninitialized memory. I verified that by hooking HeapAlloc() and filling the allocated memory with a 0x00000008 0x00000008 ... pattern (when the HEAP_ZERO_MEMORY flag was not set). This pattern then showed up in the retrieved ptd data (tdSize was 0x00000008, tdDriverNameOffset was 0x0008, tdDeviceNameOffset was 0x0000). Similarly, when I initialized the allocated memory with a 0x0000000c pattern that pattern showed up in the retrieved ptd data.
If Windows is really referencing some uninitialized block of memory then that means we can't just use broken() when comparing expected and actual ptd fields. The status page above indicates that the ole32:clipboard test crashes on a lot of machines. The crashes that I investigated on my machines all happen somewhere inside ole32.dll. This can be expected if uninitialized memory is used. I don't see a way to use broken() to work around this.
My proposed solution is to not set the ptd field in DataObjectImpl_CreateComplex() when the created IDataObject is going to be used for OleSetClipboard()/OleGetClipboard(). I don't really like that, so if anyone has ideas for a better solution I'd love to hear them.
Ge van Geldorp.