[Bug 47817] Gameforge Client: Cannot launch TERA

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47817

Paul Gofman <gofmanp at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gofmanp at gmail.com

--- Comment #17 from Paul Gofman <gofmanp at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.