<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">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").&nbsp; The root cause of this problem is that the app attempts to use a cursor after it already destroyed it.&nbsp; At first, this just causes the cursor to be blank.&nbsp; Then, it would appear that the handle is re-used for a different type of resource, which leads to the gibberish image &amp; subsequent hang.&nbsp; 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).&nbsp; 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.<br><br>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.&nbsp; However, I've been reading up and considering how to implement a solution.&nbsp; I presume that this problem affects every user32 handle &amp; 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!).&nbsp; There was a quaint MSDN&nbsp; 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).&nbsp; Although this only covers gdi32, I'm getting the idea that what needs to happen in user32 isn't too much different.<br><br>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.&nbsp; However, I need to gain a better understanding of the nuisances of user32 objects.&nbsp; 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.&nbsp; 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).&nbsp; Thus, if you create a thread, it can never have the same handle value as a cursor, icon, etc.<br><br>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.&nbsp; If anybody
 has any feedback, corrections to anything I've said, etc. please do reply.<br><br>Daniel<br></td></tr></table><br>