On 4/10/06, Alexandre Julliard julliard@winehq.org wrote:
Jesse Allen the3dfxdude@gmail.com writes:
There is a problem with explorer managing the desktop and the sending of PAINT messages. I've narrowed it down to the following area. In dlls/user/message.c wait_message_reply(), if QS_PAINT are the bits we get, and we call MsgWaitForMultipleObjectsEx, it seems to block the process indefinitely. Should another process be replying here? I decided to make the function return if we get QS_PAINT. Now my app doesn't hang and paints properly. Any ideas what I should be looking for or know?
If we are in wait_message_reply the other process is supposed to reply. You should check what message this is, and why it doesn't get replied to.
This is what the app, Warcraft III.exe is doing ----- Start of process 0x8:
Creates 16x16 window, WS_POPUP style in thread 0x9, 10024 (Root Window) ShowWindow 10024 In ShowWindow .... set_active_window Creates a new thread 0xc Starts process 0xe CreateEvent "WARCRAFT_III_OK" and waits on read pipe for event
In thread 0xc: Creates 500x400 window, WS_EX_TOOLWINDOW, 10026 (Splash Screen) ShowWindow, 10026 In ShowWindow....hits set_active_window. Previous active window is 10024, SendMessage WM_NCACTIVATE to 10024 (thread 0x9). Waits for reply.
In process 0xe using war3.exe: Executes some copy protection code Creates a window 10028 (Game Window -- Not visible) Waits for process 0x8 to close ----
Both thread 0x9 and thread 0xc are waiting for receiving something different from each other at the same time. This will never work. Before explorer managed the desktop, thread 0xc would not send WM_NCACTIVATE, and when it proceeded, it would cause the "WARCRAFT_III_OK" event and thread 0x9 would continue normally... painting etc. The purpose of 0x9 waiting for the event is to see whether the copy protection threads succeeds normally. If they do not, it will show a messagebox. But the copy protection threads do succeed, we are just not passing messages properly at this point.
I tried doing something in set_active_window when getting a window that is WS_POPUP. Like returning early with TRUE or FALSE, or just avoiding the server call or SendMessage WM_NCACTIVATE. For the most part the app would no longer hang, but one of three things would happen, the splash screen would not paint, or the game window would not paint, or both will paint but the game window would not get input focus.
The backtrace of thread 0xc at SendMessage is still at ftp://resnet.dnip.net/ShowWindowProblem.txt
Jesse