[Bug 54233] New: Harry Potter and the Chamber of Secrets: launcher doesn't display properly, can't launch the game
https://bugs.winehq.org/show_bug.cgi?id=54233
Bug ID: 54233 Summary: Harry Potter and the Chamber of Secrets: launcher doesn't display properly, can't launch the game Product: Wine Version: 8.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs@winehq.org Reporter: info@fdossena.com Distribution: ---
Created attachment 73779 --> https://bugs.winehq.org/attachment.cgi?id=73779 HP2 launcher showing the bug
The 2002 UE1 game Harry Potter and the Chamber of Secrets has a launcher from where you can configure the game, launch a new game or load a saved game.
From my testing, this happens in all versions of Wine: stable, development, staging, proton and I even tried some older stable builds.
The launcher doesn't work properly in Wine making it impossible to launch the game. I tracked down the cause to the game's attempt to center the launcher window which somehow ends up moving the contents of the window instead of the window itself.
The call to SetWindowPos seems to be done correctly and the calculations are also correct. I wasn't able to find the bug in Wine itself, but I was able to find a workaround by modifying the game exe and simply removing the offending code.
I wrote an article explaining what I did in detail, maybe someone more experienced in the inner workings of Wine can help: https://fdossena.com/?p=hp2wine/i.md
I've attached screenshots of how the launcher looks when launched normally in Wine.
https://bugs.winehq.org/show_bug.cgi?id=54233
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- That article could be made significantly better with just a brief look at https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwi....
While I can't tell what went wrong, that pair of calls is to induce a particular Z-order of the windows (first it makes it a topmost window to move it above all non-topmost, then switches it back to non-topmost status, which effectively makes it the upper most window among not-topmost).
I'm not really proficient at reading decompiled pseudocode, but it looks mildly suspicious that some values are hard-coded (0x1e6 and 0x236)...(probably an artifact of the design tools...)
https://bugs.winehq.org/show_bug.cgi?id=54233
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl --- ...also, while 'relay' might be a bit over the top, 'win' log might be useful for the discussion.
https://bugs.winehq.org/show_bug.cgi?id=54233
--- Comment #3 from Federico Dossena info@fdossena.com --- Created attachment 73781 --> https://bugs.winehq.org/attachment.cgi?id=73781 Output with WINEDEBUG=+win
https://bugs.winehq.org/show_bug.cgi?id=54233
--- Comment #4 from Rafał Mużyło galtgendo@o2.pl --- ...an idea for the devs: it would be nice if in WIN_CreateWindowEx right before final return there was something along the lines of 'TRACE("Created hwnd %p\n", hwnd);', just so it's both clear window creation has been successful and the value of new hwnd is on the same debug channel.
https://bugs.winehq.org/show_bug.cgi?id=54233
--- Comment #5 from Rafał Mużyło galtgendo@o2.pl --- So, the hierarchy seems to be as such:
trace:win:WIN_CreateWindowEx L"" #8002 ex=00010000 style=80ca0a4c 1037,429 486x581 parent=00000000 menu=00000000 inst=11000000 params=00000000 trace:win:WIN_CreateWindowEx L"" L"Static" ex=00000024 style=50000007 0,0 479x410 parent=00010080 menu=00000425 inst=11000000 params=00000000 trace:win:WIN_CreateWindowEx L"" #8002 ex=00040020 style=4000004c 0,0 480x431 parent=00010086 menu=00000000 inst=11000000 params=00000000
(side note: would be nice if the debug function printed 'WC_DIALOG' or 'Dialog' for #8002)
First one is DS_CENTER dialog. Third is the push button container.
That suggests the mentioned calls should be redundant/ignored, yet they come from the app, not wine...
Does Windows special cases dialogs within dialogs in SetWindowPos ? Cause that's one of the few ways the above would make sense...
https://bugs.winehq.org/show_bug.cgi?id=54233
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |galtgendo@o2.pl
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl --- So, given that no progress is being made, it's time to hypothesize:
given that the hierarchy looks sane, there's a chance that the function is correct, but its inputs are wrong; that is perhaps that whole function is supposed to get the toplevel window as its input, not the child dialog.
That screenshot is suspect - the only googleable references to Unreal Engine derivates are about WDialog::OnInitDialog(void). Pity that there's no open access to the original thing...
Perhaps figuring out which type param1 actually is could get things moving along ?
https://bugs.winehq.org/show_bug.cgi?id=54233
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl --- To have a note in both places: recently a bug has been filed that sounded somewhat similar to the conditions of this one; it was marked as a duplicate of bug 20190, which has recently (well, relatively to that bug creation date) gained mr667, which while got stale, the fix proposed looks pretty much like addressing the problem here, if you combine the info from the ghidra snapshot and the window hierarchy from the log.
-
WineHQ Bugzilla