http://bugs.winehq.org/show_bug.cgi?id=16281
Andrew Riedi andrewriedi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrewriedi@gmail.com
--- Comment #13 from Andrew Riedi andrewriedi@gmail.com 2009-11-05 21:55:15 ---
At least when I was poking around a while back (and still true today) I didn't get anything when I tried to visit the link in your comment. Was there any reasoning given on why the previous patches have not been accepted?
Just looked over your patch briefly. The main difficulty is not to break any 16-bit applications, such as Paint, that like to modify the cursor data directly. A true CURSORICONINFO followed by the (single) frame *must* be passed to at least the 16-bit cursor functions. The 16-bit cursor(/icon) handles *must* not have any change in the cursor struct, which obviously complicates things.
So, maybe work should be focused on unwrapping the 16/32-bit mess we have now with cursors. Currently, cursor code uses the old 16-bit memory alloc functions. It would be better to use them only when needed, and have the main 32-bit version of the cursor be whatever struct we want. We could make a table to convert between 16<->32 bit cursors. We would then convert 16->32 right before a draw, just in case the 16-bit form had been altered, and 32->16 whenever we need to alter a cursor. We would then be able to make Wine use a struct like your WINECURSORICONINFO internally, since the 16-bit application would have its own regular CURSORICONINFO to alter. But that work must be done first.
I suppose that placing .ani info right after the first frame might also work, but that is just hacky. The only thing real fix I can think of is to make a table to convert between 16<->32 bit cursors and have 2 versions for the 16-bit case, and ignore 16-bit stuff in the 32-bit (and 64-bit) case. What do you guys think?
Note: Another potential issue is how Windows acts when one process decides to use a cursor handle that another process made. Since Wine isn't correct here now (see user32 cursoricon tests), this shouldn't be of immediate concern.