Menu
▾
▴
reactos-kernel
|
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?] |
|
From: <we...@cw...> - 2002-04-23 15:42:14
|
Quoting Mike Shepherd <Mi...@qf...>: > 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? > 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. |
|
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 > |
|
From: Steven E. <ste...@ya...> - 2002-04-23 18:50:51
|
> 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). I've been working with them off and on for a while also and they just seem to send any ideas to /dev/null. The header issue with wine/mingw/reactos was something Jason and I tried to really hit on at wineconf. The only way we will be able to get them to really jump on working hand in hand with us is if we get NT/2K driver support because they want to try and port it to linux. /me thinks what a ulgy fucking hack. Once we get our GUI kicking I think then we will have some real pull with the WINE team and can then start to work out a better intergration plan. Untill that time dont expect much help from them. Steven __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ |
|
From: Casper H. <ch...@us...> - 2002-04-23 19:27:01
|
tir, 2002-04-23 kl. 20:50 skrev Steven Edwards: > > 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). > > I've been working with them off and on for a while > also and they just seem to send any ideas to > /dev/null. The header issue with wine/mingw/reactos > was something Jason and I tried to really hit on at > wineconf. That does not sound nice. > > The only way we will be able to get them to really > jump on working hand in hand with us is if we get > NT/2K driver support because they want to try and port > it to linux. /me thinks what a ulgy fucking hack. > > Once we get our GUI kicking I think then we will have > some real pull with the WINE team and can then start > to work out a better intergration plan. Untill that > time dont expect much help from them. Have you asked if they would accept patches that would make the headers more similar to w32api. What about the new x11 fork? Maybe they are more willing to cooporate? |
|
From: James T. <jim...@ad...> - 2002-04-24 00:57:14
|
Hi, Casper Hornstrup wrote: > > tir, 2002-04-23 kl. 20:50 skrev Steven Edwards: > > > 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). > > > > I've been working with them off and on for a while > > also and they just seem to send any ideas to > > /dev/null. The header issue with wine/mingw/reactos > > was something Jason and I tried to really hit on at > > wineconf. > > That does not sound nice. > > > > > The only way we will be able to get them to really > > jump on working hand in hand with us is if we get > > NT/2K driver support because they want to try and port > > it to linux. /me thinks what a ulgy fucking hack. > > > > Once we get our GUI kicking I think then we will have > > some real pull with the WINE team and can then start > > to work out a better intergration plan. Untill that > > time dont expect much help from them. > > Have you asked if they would accept patches that would make the headers > more similar to w32api. What about the new x11 fork? Maybe they are more > willing to cooporate? > Yes, Steven has. Sometime ago Steven posted patches on the wine list and as I can tell no one did anything with them. James |
|
From: Steven E. <Ste...@ya...> - 2002-04-24 17:23:05
|
> Yes, Steven has. Sometime ago Steven posted patches on the > wine list and as I can tell no one did anything with them. James I understand why most of the patches were droped but no effort has been made on the wine projects part to try and really work together. I am very selective about how much time I am spending on wine untill our windowing is working. "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: Jason F. <jas...@ya...> - 2002-04-24 09:23:09
|
--- Casper Hornstrup <ch...@us...> wrote: > tir, 2002-04-23 kl. 20:50 skrev Steven Edwards: >>I've been working with them off and on for a while >>also and they just seem to send any ideas to >>/dev/null. The header issue with wine/mingw/reactos >>was something Jason and I tried to really hit on at >>wineconf. >That does not sound nice. The header issue is actually quite important... but it doesn't add any flashy functionality. However, I'm working on it when I have time. I noticed that some files (like defines.h) have a notice that they're automatically generated. I'm trying to contact the author (Scott Christley) but so far the mails are bouncing.. trying to get an email addy for him. Failing that I'm working on a database schema for the include file contents and structure. - Jason __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ |
|
From: Casper H. <ch...@us...> - 2002-04-23 20:53:06
|
The missing reply-to is confusing...The reply-to-all function in outlook will do the trick. Except that then the sender will get two copies, but I can live with that. Many other mailing lists do this tir, 2002-04-23 kl. 22:32 skrev Richard Campbell: > Ok this is ever so offtopic, but basic driver support and basic message > queue support should be one of the goals of the next version or the version > afterwards anyways, well I'm outta my territory, back to mulling. > > ----- Original Message ----- > From: "Casper Hornstrup" <ch...@us...> > To: <rea...@li...> > Sent: Tuesday, April 23, 2002 2:26 PM > Subject: Re: [ros-kernel]ROS and Wine > > > > tir, 2002-04-23 kl. 20:50 skrev Steven Edwards: > > > > 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). > > > > > > I've been working with them off and on for a while > > > also and they just seem to send any ideas to > > > /dev/null. The header issue with wine/mingw/reactos > > > was something Jason and I tried to really hit on at > > > wineconf. > > > > That does not sound nice. > > > > > > > > The only way we will be able to get them to really > > > jump on working hand in hand with us is if we get > > > NT/2K driver support because they want to try and port > > > it to linux. /me thinks what a ulgy fucking hack. > > > > > > Once we get our GUI kicking I think then we will have > > > some real pull with the WINE team and can then start > > > to work out a better intergration plan. Untill that > > > time dont expect much help from them. > > > > Have you asked if they would accept patches that would make the headers > > more similar to w32api. What about the new x11 fork? Maybe they are more > > willing to cooporate? > > > > > > > > _______________________________________________ > > reactos-kernel mailing list > > rea...@li... > > https://lists.sourceforge.net/lists/listinfo/reactos-kernel > > |
