GetMessage related Jagged Alliance 2 regression

[Alexander Dorofeyev]

Hello.

I get freezes in Jagged Alliance 2 (seems to be tied to moving the mouse). It
used to work in older versions. The game doesn't lock up totally (the music and
sounds continue to play normally, for example), but the screen doesn't redraw
and it doesn't respond to input. Activating some other window than the game
window (if it's not full screen) usually unfreezes it.

Bisect pointed to this change:

http://source.winehq.org/git/wine.git/?a=commitdiff;h=2896540a34a18b8aff848d...

server: Set the queue mask directly in get_message to avoid an extra server call.

I did a bit of debugging and it looks like the game is getting stuck within a
GetMessageW call. It stays in that while loop in GetMessage, mostly in
MsgWaitForMultipleObjectsEx. If the mouse is moved, then it awakes, gets to
PeekMessageW, from there it goes to peek_message which returns false and so
PeekMessageW returns false and the game goes back to waiting within GetMessageW.

peek_message returns false, because in a first call to server it gets a 
MSG_HARDWARE (mouse) message which it drops for some reason, then it clears 
PM_QS_ flags and so in a next call to server it can't get a WM_TIMER message 
despite an expired timer seems to be ready in the queue.

I'm not sure what would be a proper fix, although I did find out that commenting 
out this line in peek_message()

if (HIWORD(flags)) flags = PM_QS_SENDMESSAGE | LOWORD(flags);

makes the game playable. Maybe this clearing of PM_QS_* flags shouldn't be done 
in case when the message gets dropped? Before that commit nothing was passed in 
flags high word, which is probably why this problem wasn't happening.

[Alexandre Julliard]

Alexander Dorofeyev  writes:
> I'm not sure what would be a proper fix, although I did find out that commenting 
> out this line in peek_message()
>
> if (HIWORD(flags)) flags = PM_QS_SENDMESSAGE | LOWORD(flags);
>
> makes the game playable. Maybe this clearing of PM_QS_* flags shouldn't be done 
> in case when the message gets dropped? Before that commit nothing was passed in 
> flags high word, which is probably why this problem wasn't happening.

Does this help?

diff --git a/dlls/user32/message.c b/dlls/user32/message.c
index 53d1c1d..d3f4a3a 100644
--- a/dlls/user32/message.c
+++ b/dlls/user32/message.c
@@ -2173,11 +2173,11 @@ static BOOL peek_message( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags
                                    WMCHAR_MAP_RECVMESSAGE );
         reply_message( &info, result, TRUE );
         thread_info->receive_info = old_info;
-    next:
-        HeapFree( GetProcessHeap(), 0, buffer );

/* if some PM_QS* flags were specified, only handle sent messages from now on */
         if (HIWORD(flags)) flags = PM_QS_SENDMESSAGE | LOWORD(flags);
+    next:
+        HeapFree( GetProcessHeap(), 0, buffer );
     }
 }

[Alexander Dorofeyev]

Hello.

Is there a reason this fix you sent didn't make it to git yet? I think I 
accidentally replied to author only when previously answering, so in case it was 
something unexpected and got lost somehow I'm resending to wine-devel too.

The patch works fine for me, I've played JA2 with this patch applied for a 
substantial time, no problems noticed. Sorry for the noise, if you've already 
seen it.

Alexandre Julliard wrote:
> Alexander Dorofeyev  writes:
> > I'm not sure what would be a proper fix, although I did find out that commenting 
> > out this line in peek_message()
> >
> > if (HIWORD(flags)) flags = PM_QS_SENDMESSAGE | LOWORD(flags);
> >
> > makes the game playable. Maybe this clearing of PM_QS_* flags shouldn't be done 
> > in case when the message gets dropped? Before that commit nothing was passed in 
> > flags high word, which is probably why this problem wasn't happening.
>
> Does this help?
>
> diff --git a/dlls/user32/message.c b/dlls/user32/message.c
> index 53d1c1d..d3f4a3a 100644
> --- a/dlls/user32/message.c
> +++ b/dlls/user32/message.c
> @@ -2173,11 +2173,11 @@ static BOOL peek_message( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags
>                                     WMCHAR_MAP_RECVMESSAGE );
>          reply_message( &info, result, TRUE );
>          thread_info->receive_info = old_info;
> -
>
> next:
> -
>    HeapFree( GetProcessHeap(), 0, buffer );
>
>    /* if some PM_QS* flags were specified, only handle sent messages from now on */
>    if (HIWORD(flags)) flags = PM_QS_SENDMESSAGE | LOWORD(flags);
> - next:
> -
>    HeapFree( GetProcessHeap(), 0, buffer );
> }
>
> }

[Martin Bosner]

On Friday 07 December 2007 05:49:26 Alexander Dorofeyev wrote:
> Hello.
>
> I get freezes in Jagged Alliance 2 (seems to be tied to moving the mouse).
> It used to work in older versions. The game doesn't lock up totally (the
> music and sounds continue to play normally, for example), but the screen
> doesn't redraw and it doesn't respond to input. Activating some other
> window than the game window (if it's not full screen) usually unfreezes it.
>
> Bisect pointed to this change:
>
> http://source.winehq.org/git/wine.git/?a=commitdiff;h=2896540a34a18b8aff848
> d728308c5811cdd122a
>
> server: Set the queue mask directly in get_message to avoid an extra server
> call.
>
> I did a bit of debugging and it looks like the game is getting stuck within
> a GetMessageW call. It stays in that while loop in GetMessage, mostly in
> MsgWaitForMultipleObjectsEx. If the mouse is moved, then it awakes, gets to
> PeekMessageW, from there it goes to peek_message which returns false and so
> PeekMessageW returns false and the game goes back to waiting within
> GetMessageW.
>
> peek_message returns false, because in a first call to server it gets a
> MSG_HARDWARE (mouse) message which it drops for some reason, then it clears
> PM_QS_ flags and so in a next call to server it can't get a WM_TIMER
> message despite an expired timer seems to be ready in the queue.
>
> I'm not sure what would be a proper fix, although I did find out that
> commenting out this line in peek_message()
>
> if (HIWORD(flags)) flags = PM_QS_SENDMESSAGE | LOWORD(flags);
>
> makes the game playable. Maybe this clearing of PM_QS_* flags shouldn't be
> done in case when the message gets dropped? Before that commit nothing was
> passed in flags high word, which is probably why this problem wasn't
> happening.

I just wanted to say that that JA2 is the most unstable windows game i ever 
played (on windows XP!). JA2 crashing is a 100% natural Windows behaviour. 
Most times it just became unresponsive and the music was still playing in the 
background...

Martin