[ros-kernel]RE: ROS and Wine

[Phillip S. <ps...@cf...>]

USER objects are shared between processes, within a desktop or window 
station I think.  GDI objects are (mostly) process specific.  I met a guy 
on irc a few weeks ago who is working on a really kickass program that digs 
through the user/gdi handle table and lets you view the objects such as 
bitmaps and whatnot.  I think the deal was that both types of handles come 
from a global handle table ( global to the desktop I think ) and the 
handles have an associated owning process id.  Global objects such as all 
user objects, and some gdi objects have an owning pid of 0, and thus are 
accessible from all processes.  The handle value itself is part index into 
the table, and part uniqueness value that is incremented every time the 
handle index is reused, to prevent accidental reuse of handles after the 
object has been deleted and the handle slot reused.  The objects also have 
parts that can exist in both paged pool, and the user address space of the 
owning process.  This allows user mode code to do things like 
GetWindowLong() w/o switching to kernel mode.

At 05:47 PM 4/23/2002 +0100, you wrote:
> > I'm working on it though I haven't actually done anything
> > since January. My
> > general approach was to rewrite code from WINE to work in
> > win32k.sys. What
> > advantage would be gained by moving to wineserver? I thought that all
> > USER objects were unique to a process.
>
>The wineserver stuff is just to make sure that the handles can be
>used between different processes.  The ROS win32k.sys code probably
>should use a handle table stored against the process desktop
>rather than the process itself (it might do this - I haven't
>looked extensively).
>
>The nice thing about using the Wine approach is that all the USER
>objects are allocated on the process heap so that you don't need
>to go to ring0 just to call GetWindowLong (which will obviously
>happen a lot).
>
>I was just thinking that porting Wine rather than reworking it would
>be a quicker (time wise) way to go.  I can see ways in which the
>win32k.sys could be more efficient.
>
>Mike.