desktop mode again

[Robert Shearman]

I apologise in advance if this message is poorly formatted. Blame webmail for that.

Alex Pasadyn wrote:
> ChangeLog:
> - Make a separate process for the Wine desktop window
> - In desktop mode, all applications share one desktop  window

> - Ensure system metrics are accurate for all processes after resolution 
> changes

I suggest you put the system metrics stuff in a separate patch. It is a lot more tested and more likely to get in than the other code, which is quite a big change.

[snip]

> While several applications work fine, there are 
> some issues I have not been able to resolve.  The problems have to do 
> with trying to call WIN_FindWndPtr across processes, especially from the 
> windows/painting.c file.

As you rightly say, we need to move a lot of the window code into wineserver. ReactOS probably has a head start on us in this area, although we won't be able to borrow anything more than ideas because of the license.

[snip]

>   I am hoping someone with more knowledge of the painting and region 
> code could spot some obvious way to get around the issue.  Otherwise it 
> will be tough.  I had tried replacing some of the WND* uses with server 
> calls to get rectangles and style flags, but that does not handle 
> everything that's being read out of those structures.  Unless there's 
> some shortcut I don't see how to do it without moving more of that data 
> into the server.  The other problem related to this is that some 
> functions are supposed to fail if the window is in another process, 
> while others would work better if they got the data from the server, and 
> it's not always obvious which way a particular function should work.

I guess we need test cases for those then.
The way I see it the only way around the problem of inter-process graphics operations is for us to have our own DIB engine and move functions calling WIN_FindWndPtr into the server. X doesn't allow inter-process operations right?

> @@ -128,7 +129,14 @@
>   */
>  BOOL WINAPI PaintDesktop(HDC hdc)
>  {
> -    HWND hwnd = GetDesktopWindow();
> +    HWND hwnd;
> +    SERVER_START_REQ( set_desktop_window )
> +    {
> +        req->handle       = 0;
> +        wine_server_call( req );
> +        hwnd = reply->cur_handle;
> +    }
> +    SERVER_END_REQ;
>  
>      /* check for an owning thread; otherwise don't paint anything (non-desktop mode) */
>      if (GetWindowThreadProcessId( hwnd, NULL ))

Is there some reason for replacing GetDesktopWindow with this server call?

[snip]

> +/***********************************************************************
> + *           BecomeDesktop
> + *
> + * Tell the server to make our window the desktop.  
> + */
> +static BOOL BecomeDesktop()
> +{
> +    BOOL res = TRUE;
> +    SERVER_START_REQ( set_desktop_window )

This is bad. There shouldn't be a direct server call in a normal wine program. We should try and find the right Windows API to do this, or create our own export from user32. Only user32, gdi32, ntdll and x11drv should need to use server calls (and kernel32 out of convenience).

[snip]

> +/***********************************************************************
> + *           WrapperWndProc
> + *
> + * Window procedure
> + */
> +static LRESULT WINAPI WrapperWndProc( HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam )

[snip]

> +/***********************************************************************
> + *           DesktopWndProc
> + *
> + * Window procedure
> + */
> +static LRESULT WINAPI DesktopWndProc( HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam )

Why do you need two windows procedures? If you're sure you do need both of them, a comment in the code explaining why would be good. It's not at all obvious to the casual observer (i.e. me) otherwise.


It appears you don't launch winedesktop anywhere and you don't remove any options from the config file. It will be a bit confusing for people who do use the wine desktop when it doesn't do anything after applying your patch (until they launch winedesktop). Do you plan to launch winedesktop at startup (possibly just after wineserver is launched) if the desktop setting is enabled?

Rob