|
From: Mike S. <Mi...@qf...> - 2002-04-23 14:39:14
|
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). - 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. Implementation ideas :- - Remove the current user32.dll code and associated code in win32k.sys etc. and replace with the relevant code from Wine. - 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). - Use existing ROS GDI infrastructure. - 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. 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?] |