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.