[PATCH] user32: Call driver's DestroyWindow in destroy_thread_windows().

[Rémi Bernon]

On 10/13/21 12:39 PM, Paul Gofman wrote:
> index 5e89f4c2c97..bafd0a3a7f0 100644
> --- a/dlls/user32/win.c
> +++ b/dlls/user32/win.c
> @@ -1218,7 +1218,6 @@ void destroy_thread_windows(void)
>       while ((wndPtr = next_thread_window( &hwnd )))
>       {
>           /* destroy the client-side storage */
> -
>           list = WIN_ListChildren( hwnd );
>           menu = ((wndPtr->dwStyle & (WS_CHILD | WS_POPUP)) != WS_CHILD) ? (HMENU)wndPtr->wIDmenu : 0;
>           sys_menu = wndPtr->hSysMenu;
> @@ -1235,6 +1234,8 @@ void destroy_thread_windows(void)
>               window_surface_release( surface );
>           }
>   
> +        USER_Driver->pDestroyWindow( hwnd );
> +
>           /* free child windows */
>   
>           if (!list) continue;
> 

One thing I wondered was whether we should call the driver only after 
releasing the child windows, and what would happen if these child 
windows are owned by a different thread.

If the windows are owned by the current thread, we'll maybe destroy the 
child window driver data (ie: client windows I think) after the parent. 
I'm not sure if it's a problem, but WIN_DestroyWindow does it the other 
way around.

In the other case I believe there's already a pre-existing race 
condition (and I have a test exhibiting it), so maybe we don't need to 
worry too much about it:

   We send the WM_WINE_DESTROYWINDOW to the child windows, and expect 
their owning thread to peek their message and destroy them.

   These thread may not be peeking their messages, and we may terminate 
the current thread before, which will make wineserver detach the child 
windows from their owning thread, losing the message forever.
-- 
Rémi Bernon <rbernon at codeweavers.com>