reactos-kernel

RE: [ros-kernel]ROS and Wine

[Mike S. <Mi...@qf...>]

> 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.

RE: [ros-kernel]ROS and Wine

[Mike S. <Mi...@qf...>]

> > 	- The current (incomplete) user32.dll code calls
> > 	  into win32k.sys which then allocates ATOMs and
> > 	  Window structures in NonPagedPool (and are thus
> > 	  inaccessible from user mode).
> 
> An atom is just an integer which specifies an index into a 
> string table.
> So they are accessible from user-mode; that is, the ATOMs are, but the
> strings they represent are not. But then again, they don't need to
> because only win32k.sys uses the strings. ntdll.dll has a 
> user-mode atom
> implementation for user-mode applications.

My mistake.

> > 
> > 	- Wine uses a per-process user_handles array (global array
> > 	  above 200K???) and allocates all ATOMs and Windows
> > 	  on the local heap.  It allocates all handles via
> > 	  RPC-like calls to the wineserver via Unix domain sockets.
> > 
> > 	- Wine's implementation of most Window classes relies on
> > 	  dereferencing the Window structure allocated (using their
> > 	  WIN_GetPtr function)
> > 
> > 	- Message queue functions like PostMessage use RPC calls to
> > 	  wineserver to allow for handles from other processes.
> 
> WINE is different because it is mostly (fully?) implemented in
> user-mode. The ReactOS window manager implementation should be in
> kernel-mode to have better performance. The Windows NT team made this
> mistake - we don't have to. Also using RPC here sounds much more
> expensive than two kernel-mode/user-mode transitions. E.g. you have to
> marshal/unmarshal parameters.

Yeah, I'd much rather duplicate what NT does but it just looked like
a much bigger job.  Having looked at the code more extensively I can
see that there's more there than I had thought.  Hopefully you
appreciate that as a newbie poster it's useful to hear why design
decisions made before my involvement were made!

> > 
> > Implementation ideas :-
> > 
> > 	- Remove the current user32.dll code and associated code in
> > 	  win32k.sys etc. and replace with the relevant code from
> > 	  Wine.
> 
> This is not just a copy/paste job, so why bother? Using WINE for
> something as low-level as the window manager puts restrictions on the
> design of the ReactOS window manager. If I had to choose, I would much
> rather spend the time needed for adapting the WINE code for 
> ReactOS, on
> designing the window manager code properly - even if it takes longer.
> Sure we can learn from the WINE implementation, but using its 
> design is
> IMO not worth it.

Fair enough.  I think the Wine USER code could be ported fairly quickly
but I do agree that an NT like implementation would be more efficient
and probably the longer term solution.

> > 
> > 	- Implement the wineserver using LPC as an extension to 
> CSRSS.exe
> > 	  (or does this belong in WinLogon.exe?).  Obviously 
> only a small
> > 	  subset of the wineserver messages are needed (most are for
> > 	  synchronisation primitives that ROS implements anyway).
> 
> Who would communicate with the wineserver then? What is the point of
> having wineserver messages in ReactOS?

Just ease of porting.  I'm not claiming that it's a better solution.
I guess that, since I'm clearly not as comfortable with Kernel mode
issues as you (the networking code looks excellent BTW), I was trying
to find a way to turn it into a user mode solution!

> We can use WINE modules that only use the Win32 API without 
> any need to
> make changes specific to ReactOS. If we can agree with the 
> WINE project
> to use the same headers, ReactOS developers can develop on the shared
> modules with less of a risk of breaking something for the WINE
> developers (and vice-versa).

Definitely.  It does look like things like comctl32.dll could be
taken almost directly from Wine (assuming, as you say, uniform use
of header files).

> If we want to share lower-level user-mode modules we have to make the
> kernel-mode APIs the same, which would mean having equal
> ntdll/win32k.sys APIs. I'm not sure this is a good idea.

Agreed.  I was just talking about user32.dll code really.

> > 	- Presumably WinLogon or CSRSS need to do something 
> like creation
> > 	  of the Desktop and Desktop Window and monitor for Mouse and
> > 	  Keyboard events and translate into Windows messages.
> > 
> 
> In Windows NT, WinLogon creates the interactive windowstation and
> desktops. Win32k.sys connects to mouse and keyboard.

I've found that code now.  Didn't realise it was implemented.  Case of
RTFC!

> No, because this puts more load on the mailing list servers. A decent
> mail program has a reply-to-list funtion.

Fair enough.  Unfortunately I've got Outlook! :>)

Mike.

RE: [ros-kernel]ROS and Wine

[Casper H. <ch...@us...>]

tir, 2002-04-23 kl. 19:28 skrev Mike Shepherd:
> Yeah, I'd much rather duplicate what NT does but it just looked like
> a much bigger job.  Having looked at the code more extensively I can
> see that there's more there than I had thought.  Hopefully you
> appreciate that as a newbie poster it's useful to hear why design
> decisions made before my involvement were made!

Yes, we should be writing more docs about such issues ;o)

> 
> > > 
> > > Implementation ideas :-
> > > 
> > > 	- Remove the current user32.dll code and associated code in
> > > 	  win32k.sys etc. and replace with the relevant code from
> > > 	  Wine.
> > 
> > This is not just a copy/paste job, so why bother? Using WINE for
> > something as low-level as the window manager puts restrictions on the
> > design of the ReactOS window manager. If I had to choose, I would much
> > rather spend the time needed for adapting the WINE code for 
> > ReactOS, on
> > designing the window manager code properly - even if it takes longer.
> > Sure we can learn from the WINE implementation, but using its 
> > design is
> > IMO not worth it.
> 
> Fair enough.  I think the Wine USER code could be ported fairly quickly
> but I do agree that an NT like implementation would be more efficient
> and probably the longer term solution.

I guess that some of the WINE code that use GDI APIs (but not WINE
specific APIs) could be easily modified for ReactOS.

> 
> > We can use WINE modules that only use the Win32 API without 
> > any need to
> > make changes specific to ReactOS. If we can agree with the 
> > WINE project
> > to use the same headers, ReactOS developers can develop on the shared
> > modules with less of a risk of breaking something for the WINE
> > developers (and vice-versa).
> 
> Definitely.  It does look like things like comctl32.dll could be
> taken almost directly from Wine (assuming, as you say, uniform use
> of header files).

Yes, comctl32.dll is one of the many DLLs that can be written to
exclusively use the Win32 API.

[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.

RE: [ros-kernel]RE: ROS and Wine

[Mark de W. <de...@a-...>]

> From: rea...@li...
> [mailto:rea...@li...]On Behalf Of Phillip
> Susi
>
> 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.

An MSDN magazine article from some time last year did exactly this.  The
author supplied a framework for detecting GDI resource leaks, and the
viewing of GDI resources from the global GDI table (although I believe that
this latter feature only works on Win9x, as the win2k architecture deals
with GDI resources differently from win9x).

Mark