http://bugs.winehq.org/show_bug.cgi?id=14842
--- Comment #4 from Michael Karcher wine@mkarcher.dialup.fu-berlin.de 2008-08-13 03:12:32 --- Status report.
The bug seems to hit quite early in program startup. There are CreateCursor calls, and both the AND mask as well as the XOR mask are completely filled with zeroes, resulting in creation of a black square cursor. Directly before, a call sequence like this happens:
hBmpXor = CreateBitmap(32,32,1,1,XorData) hDCXor = CreateCompatibleDC(ScreenDC) oldBmpXor = SelectObject(hDCXor,hBmpXor) GetDIBits(ScreenDC,hBmpXor,0,32,XorBits,XorBitmapInfo,0) DeleteObject(SelectObject(hDCXor,oldBmpXor)); DeleteDC(hDCXor)
and the same for the AND mask. I currently don't have any more time to spare to trace it further (as I am just a hobbyist regarding to wine hacking) until weekend, but I suspect that XorData in the call to CreateBitmap is still correct, but the XorBits we get out of GetDIBits is wrong, especially as my commit that caused the regression is about GetDIBits.
If somebody else wants to track it, I would a) Check that XorData is correct b) Check that the pixmap created really contains two different colors c) Check that XorBits on the output is correct.
One of these step should fail, probably c). It is a bit difficult to reason about dataflow though, as the program seems to be copying data from one temporary heap buffer to other temporary heap buffers like mad, so you won't find the pointers like XorData or XorBits in any other API calls in the log except for HeapAlloc and HeapFree.