http://bugs.winehq.org/show_bug.cgi?id=16281 Erich Hoover <ehoover(a)mines.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #24527|0 |1 is obsolete| | --- Comment #15 from Erich Hoover <ehoover(a)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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.