Does wine send window messages without waiting apps to reenter userdll?

[Sebastian Lackner]

On 25.08.2015 22:09, Javier Pimás wrote:
> Hi! this is a very low-level technical question and my first one to this
> list so please take with a grain of salt. I'm debugging a 32 bit app in
> wine 1.6.2, on ubuntu 15.04 64 bits.

As Stefan Dösinger already suggested, upgrading to the latest development
version definitely wouldn't hurt. Maybe your issue was already fixed in the
meantime.

> 
> The app I'm debugging is a smalltalk vm, so it is very possessive with the
> native stack, synchronization, callbacks and things like that. I'm having a
> problem that happens in wine and not in windows, and the following thing I
> describe might be the cause, it's very subtle.
> 
> The problem is related with non-queued messages, in a loop that calls
> WaitMessage and does something more if there's a message. When running on
> windows, WaitMessage blocks the thread until there's something (queued or
> non-queued). If the message is non-queued, it is not immediately delivered
> (adding frames to the stack by hand), but windows just awakes the thread
> and waits it to reenter the OS (or userdll, I guess).

If you are concerned that WaitMessage immediately dispatches the messages,
Wine doesn't do that. Processing of window messages is only done in the
context of GetMessage and PeekMessage, no matter if its a "queued" or
"non-queued" message. In fact Wine doesn't really make a difference between
the two, it just assigns specific internal message numbers for non-queued
messages. To identify those the the highest bit (0x80000000) is set.

> I'm not sure if i can
> trust wine to do the same, or if it awakes the process with a bunch of
> frames pushed in the stack so that the non-queued message is delivered as
> if WaitMessage never returned.
> 
> Here is a small idea of the subtle stack variations:
> 
> always in windows:
> 
> |        VM Callback        | <--- stack top
> |      WndProc context      |
> |           ....            |
> | Next userdll call context | <- WaitMessage already returned
> |         VM Callout        |
> |           ....            |
> 
> ------------------
> 
> never happens in windows (*i think*), possible in Wine?:
> 
> |        VM Callback        | <--- stack top
> |      WndProc context      |
> |           ....            |
> |    WaitMessage context    | <--- never returned
> |         VM Callout        |
> |           ....            |
> 
> As I said, this is very low-level and subtle. Most apps wouldn't notice the
> difference, but this is a VM. Is the second layout possible in wine?

That cannot happen in Wine.

However, that doesn't mean that handling of non-queued messages is already
implemented completely correct. Dmitry was working on this some time ago,
when you go back in the mailing list to April 2015 for example:
"user32: After handling an internal message give a chance to real message to arrive."

Regards,
Sebastian