Hi! The problem could be shell32,, the abuse is there with cache icons. Always assume "wine is not enough!"
Now with patch 31301, I noticed the use of GDIOBJ_SetOwnership. It is set with null and makes it inaccessible to all PID's until it is set to an owner from kernel space. This could be what is locking in the handles since any other process could not access or remove them after an exception failure.
I hate GDIOBJ_SetOwnership and I'm in the process of rewriting it. I would like to create a memory pool where we can use as share memory w/o the need of re/allocating virtual memory everytime we change ownership with Gdi Attr Objects. When ReactOS sets ownership null, the code frees the _Attr memory and there is a hole. Windows, ownership was made "Public" sets the Object and Attr to read only. The plus side would be, after a ReleaseDC "Cache DC" the user application could still read the Dc_Attr space and fix many of the User32_winetest results.
Based on tests, there are three modes, None aka NULL, Public and pOwned. Every time ownership changed there is a freeing and allocating of Attribute "VM". I assume there is a NULL Pid (inaccessible, no need to have _Attr) and Public Pid (reallocate VM read only _Attr).
I'm open to any ideas! James
On Dec 26, 2007 2:13 PM, Colin Finck mail@colinfinck.de wrote:
Aleksey Bragin wrote:
The CursorIcon problem would be fun to have solved too (hint: janderwald & shell32).
I don't think the CursorIcon problem is related to shell32. I did some regress-testing today and found that the guilty revision is Ged's NtUserSetCursorIconData rewrite in r31301. In r31300 it works without any problems.
If you want to verify this yourself, you also need to apply the header change in r31303 and the change from lines 271 to 279 in "bitmap.c" in r31302. Otherwise you won't get r31301 to build. To reproduce the problem, click on the "Start" button and then move the mouse up and down many times to open the submenus of the root-level start menu. When I do this fast enough, I can reproduce the bug in less than 30 seconds :-)
I hope someone with some experience in win32k can look into this bug, now that we have the guilty revision.
Best regards,
Colin (who is on vacation for real now :-) )