http://bugs.winehq.org/show_bug.cgi?id=16281
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #24527|0 |1 is obsolete| |
--- Comment #15 from Erich Hoover ehoover@mines.edu 2009-11-11 18:35:52 --- Created an attachment (id=24681) --> (http://bugs.winehq.org/attachment.cgi?id=24681) A different take on animated cursors [v2]
(In reply to comment #13)
... The main difficulty is not to break any 16-bit applications, such as Paint, that like to modify the cursor data directly. ...
I managed to find a copy of the ol' Paint and you are quite correct (* insert frustration here *).
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've attached a new version that does this to an extent. I learned from exploring LockResource that we know which pointers are created using a 32-bit alloc and which are created using a 16-bit alloc, so a table is not necessary. The attached approach keeps the 16-bit icons as 16-bit icons but then it creates a 32-bit "wrapper" around them for anywhere that they are used internally (to keep things nice and neat).