0.3.4 release

[Aleksey Bragin]

Hi,
the only critical blocker left on the release is the keyboard/mouse  
detection problem in qemu. There are a couple of other major issues  
related to the installation in qemu, but if they aren't solved by  
january, I'm ok to release with them.

LiveCD is going to be partly broken too, because hardly any  
application starts in it, but I don't have time to fix this issue (if  
anyone volunteers - feel free to).

The CursorIcon problem would be fun to have solved too (hint:  
janderwald & shell32).

With the best regards,
Aleksey Bragin.

[Colin Finck]

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

[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 [e-mail] 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 :-) )

[Ged Murphy]

Colin Finck wrote:
> 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.

I doubt it's this change directly, it's probably just triggered something
elsewhere.
I do have the remaining code to go with this change in my local tree which
will make our cursor/icon object more compatible with windows, but I haven't
had time to test it yet, so I haven't committed it.

I'll try and find some away from the pub .... but it is Christmas .....

Ged