Cursor & Icon patches

[Daniel Santos]

Hello everybody!

Attached is my current cursor icon patches based upon work by Henri Verbeet and Andrew Riedi for review and comment.  I finished the actual code about 3 weeks ago, but it's been a lot of work for me to split it out into smaller pieces, especially being new to git.  Here is a break-down of what these patches do and the theory.

* Adds real 32-bit handles (instead of converting 16-bit handles to 32
  bit).
* Cursors & icons stored in non-moveable memory block (a.k.a., "32 bit
  data") in addition to existing 16-bit moveable block.
* A new 'struct cursor_header' (include/wine/winuser16.h) is pre-pended
  to the 32-bit cursor/icon data (16-bit data format is untouched).
* A new 'struct cursor_map_entry' (dlls/user32/cursoricon.c) is used to
  manage a cursor's association with its handles and data.
* Adds more complete .ani support (I think nearly 100% complete).
* Adds themed icon support (from your X-windows theme).
* Fixes a lot of bugs.
* And finally, moves cursors to the server.

The server opaquely stores the raw 32-bit cursor/icon data.  Since the client does all interaction with winex11.drv, the server doesn't really need to understand it.  The client caches all objects locally, but attempts to retrieve from the server any handle it doesn't know about.  Locally, the client uses a pair of rbtrees to associate cursor objects (actually struct cursor_map_entry) with their respective 16 & 32 bit handles.  The 16 bit cursor data is automatically generated on the client and can still be directly manipulated from 16 bit programs; in such cases, the 32-bit cursor data will be updated from the modified 16 bit data.  The CRITICAL_SECTION IconCrst is used to synchronize access to the rbtrees and ensure that data is unmodified once an operation on that data begins (in database terms, IconCrst is used to lock the entire "table" and there's no "row-level" locking).

There are several new functions to query and manipulate the rbtrees:

add_cursor_entry   : (self-explanatory)
remove_cursor_entry: (self-explanatory)
get_cursor_handle16: retrieves a 16-bit handle from a 32-bit one
get_cursor_handle  : visa-versa

Layered on top of that are a basic set of functions for higher level management of cursor/icon objects:

alloc_cursor_data   : allocate & initialize cursor data & header
create_cursor       : creates cursor and auto-generates 16-bit data
destroy_cursor      : destroys cursor and associated 16-bit data
get_cursor_entry    : will look both locally and on the server
get_cursor_object   : returns the cursor's data
update_cursor_data16: creates or updates the 16-bit data from 32-bit data
CURSORICON_refresh_cursor16: updates the 32-bit data from 16-bit data

The functions add_cursor_entry and get_cursor_entry directly return a pointer to the struct cursor_map_entry and therefore require locking IconCrst in advance of calling (or will fail an assertion).  Having direct access to the cursor_map_entry reduces complexity in some circumstances.

One of the oddest fixes is the fake_cursor() function, which is used to accommodate deleting the active cursor, which windows doesn't mind.  This isn't the only way to go about it, but the alternative was to make the cursor empty and I'm not certain that that is the visual behavior of windows when deleting the active cursor, so I'm more than open to feedback on that as well as anything else in these patches.

Thanks!
Daniel