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). 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:

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?

Thanks for reading!