In the process of working on this bug (http://bugs.winehq.org/show_bug.cgi?id=18371), I have discovered that user32's SetCursor function does not ensure that the the handle passed is valid or that it is even a handle to a cursor object (and it seems that the lingo for user32 objects is "resources"). The root cause of this problem is that the app attempts to use a cursor after it already destroyed it. At first, this just causes the cursor to be blank. Then, it would appear that the handle is re-used for a different type of resource, which leads to the gibberish image & subsequent hang. When this app runs on windows, I presume that the SetCursor calls just fail and the app resumes harmlessly ignoring the failure (or correcting it, either way). In general, this flaw will affect applications which use the user32 api irresponsibly, and I'm certain that a great number of windows apps out there, to some extent, do.
My 1st step is to write some tests that illustrate/prove this problem (and that it works on windows) and I'm building the tests now so I can start on that. However, I've been reading up and considering how to implement a solution. I presume that this problem affects every user32 handle & function related to them, but I have only thoroughly examined mousecursor.c, so please forgive any incorrect assumptions I still have at this point (and let me know if I'm way off!). There was a quaint MSDN article on how the windows GDI32 dll manages GDI objects that even gave the internal structure, etc. (http://msdn.microsoft.com/en-us/magazine/cc188782.aspx).%C2%A0 Although this only covers gdi32, I'm getting the idea that what needs to happen in user32 isn't too much different.
Essentially, it would seem that user32 needs to associate a handle with a type and it would *appear* at this point that would be sufficient. However, I need to gain a better understanding of the nuisances of user32 objects.. From reading this ms kb article (http://support.microsoft.com/kb/184802), it seems that the windows user32 maintains 3 different types of heaps, a global one, one for each desktop and a different (differently sized?) one for non-interactive desktops. Windows' "global heap" is where user32 stores it's handle table, presumably which, simply associates a kernel32 handle with appropriate information for user32 objects, similar to the way GDI does (as illustrated in the above referenced MSDN article). Thus, if you create a thread, it can never have the same handle value as a cursor, icon, etc.
So I'm going to write my tests on my windows machine, starting with only the mousecursor.c stuff because there appears to be quite a lot of ground to cover. If anybody has any feedback, corrections to anything I've said, etc. please do reply.
Daniel