[Bug 16281] Wine lacks support for fully animated cursors

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=16281





--- Comment #14 from Erich Hoover <ehoover at 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.

-- 
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.