http://bugs.winehq.org/show_bug.cgi?id=16281
--- Comment #14 from Erich Hoover ehoover@mines.edu 2009-11-07 20:22:31 --- (In reply to comment #13)
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.
Is this actually the case? I would have assumed these applications are playing with the pointers returned by DumpIcon. Do you have an obtainable example of such an application? I don't have any Win 3.1 disks anymore and I'd assume newer versions of Paint no-longer work this way. I'm thinking it's likely that even if these applications expect the icon pointer to start with CURSORICONINFO that they then grab the pointer to the actual data with DumpIcon. If this is the case then just placing the CURSORICONINFO at the beginning of the structure would satisfy these applications.
... 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? ...
I'd have to take a deeper look into how LockResource and GlobalLock work to form an opinion here. I'm hoping that this isn't really necessary and can be avoided using the technique discussed above.