https://bugs.winehq.org/show_bug.cgi?id=28884
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://csillagpor.org/progr | |amok/sculptris.exe
--- Comment #8 from Sebastian Lackner sebastian@fds-team.de --- Thanks for providing the download url. Actually the following (very bad) hack is sufficient to make the app working fine here (well, at least what I tested):
--- snip --- diff --git a/dlls/user32/message.c b/dlls/user32/message.c index eac4e4d..27a4988 100644 --- a/dlls/user32/message.c +++ b/dlls/user32/message.c @@ -3908,6 +3908,7 @@ BOOL WINAPI TranslateMessage( const MSG *msg ) message = (msg->message == WM_KEYDOWN) ? WM_CHAR : WM_SYSCHAR; TRACE_(key)("%d -> PostMessageW(%p,%s,<x>,%08lx) for <x> in %s\n", len, msg->hwnd, SPY_GetMsgName(message, msg->hwnd), msg->lParam, debugstr_wn(wp, len)); + return TRUE; for (i = 0; i < len; i++) PostMessageW( msg->hwnd, message, wp[i], msg->lParam ); } --- snip ---
The app calls PeekMessage and afterwards GetMessage in a loop. When the app receives the first WM_KEYDOWN message, Wine translates this to a WM_CHAR message. When the app tries to remvoe the WM_KEYDOWN message, it gets the WM_CHAR message instead. Since the WM_KEYDOWN message is never removed new WM_CHAR messages are generated all the time, which causes the app to hang. Excerpt from the log, only relevant lines:
--- snip --- 371956.632:0009:Call user32.PeekMessageA(0033fd6c,00000000,00000000,00000000,00000000) ret=0045b98e 371956.632:0009:trace:msg:peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x20050 wp 41 lp 1e0001 371956.632:0009:Ret user32.PeekMessageA() retval=00000001 ret=0045b98e 371956.632:0009:Call user32.TranslateMessage(0033fd6c) ret=0045b966 371956.632:0009:trace:key:TranslateMessage 1 -> PostMessageW(0x20050,WM_CHAR,<x>,001e0001) for <x> in L"a" 371956.632:0009:Ret user32.TranslateMessage() retval=00000001 ret=0045b966 371956.632:0009:Call user32.GetMessageA(0033fd6c,00000000,00000000,00000000) ret=0045b972 371956.632:0009:trace:msg:peek_message got type 6 msg 102 (WM_CHAR) hwnd 0x20050 wp 61 lp 1e0001 371956.632:0009:Ret user32.GetMessageA() retval=00000001 ret=0045b972 371956.632:0009:Call user32.DispatchMessageA(0033fd6c) ret=0045b980 0009:Call window proc 0x45ae90 (hwnd=0x20050,msg=WM_CHAR,wp=00000061,lp=001e0001) 0009:Ret window proc 0x45ae90 (hwnd=0x20050,msg=WM_CHAR,wp=00000061,lp=001e0001) retval=00000000 371956.632:0009:Ret user32.DispatchMessageA() retval=00000000 ret=0045b980
(now the same starts again, until PeekMessageA finally gets something else than WM_KEYDOWN)
371956.633:0009:Call user32.PeekMessageA(0033fd6c,00000000,00000000,00000000,00000000) ret=0045b98e ... --- snip ---
Will have to take a closer look whats the difference to Windows here. Either TranslateMessage() should behave differently, depending on if the message was already translated before - or, more likely, messages are dequeued with different priorities, which has the effect that WM_KEYDOWN is removed earlier.
Component is either user32 or wineserver.