http://bugs.winehq.org/show_bug.cgi?id=16281
--- Comment #20 from Erich Hoover ehoover@mines.edu 2010-01-01 23:02:15 --- (In reply to comment #19)
...
Hello. I briefly looked over your patches. I could be wrong, but I don't think AJ will go for wine-specific extensions. eg. WINE_CursorIcon32To16(), WINE_get_cursoricon_ptr, LR_WINE16BIT, etc. As far as the .ani struct goes, it might be better to allocate only one piece of memory, but that is not all that important.
What exactly do you mean WRT to the animated cursors here? There's only one allocation for the entire animated cursor...
When I talked to AJ most recently, the idea was to pass a handle to winex11.drv's create_cursor() and have separate handles and structs for 16-bit and 32-bit icons/cursors. I didn't get time to ask for details on how he would want that done. It seems that with this approach we will either have to duplicate some code or make a 32->16 conversion function so that we can use eg. 32-bit LoadImageA() to implement the 16-bit loading functions. Of course, with this idea, conversion will only need to happen once.
At least from what I saw, you'll need some sort of wine-specific extensions to allow the conversion of icons in places where a non-cursor 16-bit function calls a non-cursor 32-bit function (like OleMetafilePictFromIconAndLabel16). Unless, of course, you wanted to copy over the code in these functions. A bunch of the extensions I created were mostly for book-keeping purposes or to make sure there would be an assertion if a 16-bit cursor snuck its way into a 32-bit function (this helped me to track down issues with SetClassLong/SetClassWord).
In other words, I think I've done a relatively decent job of doing what you describe. I don't believe it's all the way there yet, but you'd have to duplicate quite a bit of code in order to completely separate out the 16-bit icons.