Menu
▾
▴
Re: [ros-kernel]ROS and Wine
|
From: Casper H. <ch...@us...> - 2002-04-23 16:10:21
|
tir, 2002-04-23 kl. 16:39 skrev Mike Shepherd: > Hi All, > > Just started playing with ROS and thought I'd have a look > at how Wine fits in. It looks like there is some initial > Wine code in the tree - I'm presuming that this is not > being worked on? > > Initial thoughts :- > > - 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. > > - 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. > > 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. > > - 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? 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). 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. > > - Use existing ROS GDI infrastructure. > This is required to have binary compatibility with Windows NT. > - 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. > Doesn't look *too* difficult. Does any of this sound at all sensible? > Presumably I wouldn't be duplicating work here? > > Mike. > > [BTW: Shouldn't the list be setup with Reply-To being the list?] No, because this puts more load on the mailing list servers. A decent mail program has a reply-to-list funtion. > > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel > |
