[ros-dev] 0.3.4 release

[James Tabor]

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 at 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 :-) )
>
>