On Thu May 8 16:51:45 2025 +0000, Stefan Dösinger wrote:
The recursive reset() is just one of the ways some applications depend on the message sequence. It wouldn't be a good replacement for the existing tests, although it would certainly be worth adding to explicitly test one of the ways a known [0] application fails. Some of the other pickiness I came across while implementing the alt-tab handling: Again this is from memory, I don't remember any more which application did what, but maybe we can figure it out from the archives:
- Some application insists that WM_SYSCOMMAND(SC_RESTORE) is delivered
after all the focus gain, screen res change, window size change messages. WM_SYSCOMMAND is actually the first thing that gets sent on task bar click, and only because the rest of the stuff gets sent by d3d9's WM_SYSCOMMAND handler is it the last one delivered to the application
- Some application (I think Command & Conquer 3) sets the focus window
to something else and then back to the main application while not processing messages on the window's thread. user32 is cancelling out the two WM_ACTIVATEAPP messages
- Some other game (I think Warcraft 3) hides the device window with
ShowWindow(SW_HIDE) and crashes when a WM_WINDOWPOSCHANGING message arrives. That's where the weirdo special !WS_VISIBLE checks come from. It has focus window != device window.
- Deus Ex (ddraw) destroys the ddraw device in WM_KILLFOCUS and expects
it to work. wined3d and ddraw are therefore very careful not to access device->xxx after a certain point. Fullscreen focus switching on Windows always had a reputation of being fragile, and sadly Wine and the many, many window managers it runs on is no different. But the picky (and fragile) tests were built over time for good reason. [0]: I don't know which application prompted the original test_wndproc(). Henri did that work and I couldn't figure out from the archives and bug tracker which application motivated that.
Yeah, I'm not proposing to replace the entire tests, just that we should replace that specific test (was WM_WINDOWPOSCHANGED received) with a more direct test (does Reset() recurse forever).