https://bugs.winehq.org/show_bug.cgi?id=47817
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #17 from Paul Gofman gofmanp@gmail.com --- Created attachment 65852 --> https://bugs.winehq.org/attachment.cgi?id=65852 POC patch
I've tested the issue with Metin2 (as it is probably the smallest thing to download for Gameforge client).
I could not reproduce any crash but no game window appeared after pressing 'Play' (while it was starting OK manually from game install directory). So maybe I am not reproducing all the issues which the others had but I tracked down an issue which is definitely there and prevents the game from showing up if run from current Gameforge client.
Before going to the main issue, I should also note that while running with winehq build binaries for Fedora I spotted the game complaining about not being able to hotpatch NtProtectVirtualMemory(). This did not affect anything in my case, i. e., it didn't work without the fix for the main issue, and did work with the main issue worked around without fixing the hotpatching. Still I am attaching the second patch to the PoC fix just in case.
The issue is triggered by the application setting up a new desktop. The application does it with user32.CreateDesktopW() (without WSF_VISIBLE flag, which is important here), sets it with SetThreadDesktop() and later changes its attributes with SetUserObjectInformationW(). After that it tries to initialize a d3d interface (d3d9, d3d8) with all the same result:
009a:warn:d3d:wined3d_init Failed to create adapter.
This is due to the following reverse sequence of unfortunate events: - by the time wined3d_init is called, the display driver was not yet initialized for the process; - dlls/user32/driver.c:load_desktop_driver() tried to load driver, but GetPropW( hwnd, display_device_guid_propW ) returns NULL string, so that results in creating a "null" display driver which is not good enough for rendering; - the latter happened because the window propery had never been set; normally explorer.exe creates the desktop window and sets that property, but not in this case; - the desktop window without required property was created in wineserver, upon processing get_desktop_window (server/window.c) request from first user32.GetDesktopWindow(); - that happened because the winstation did not have WSF_VISIBLE flag, and as winstation was not visible, server decided to avoid roundtrip. So the first call to user32.GetDesktopWindow() for the thread did not properly initialize desktop window by running explorer.exe because it received nonzero top_window from server right away.
The attached patch contains a quick fix for that, which allowed me to start the game from Gameforge client normally. I suppose a better fix would be to properly handle desktop attribute change.
There is still a bug when virtual desktop is used: - upon starting Gameforge client, the second virtual desktop is now created (with the patch applied), as probably expected; - the game then starts OK; - if I quit the game, the second desktop is closed, so that the attempt to start the game again from client fails.
But this looks like a separate issue.