https://bugs.winehq.org/show_bug.cgi?id=50968
--- Comment #3 from pokeyprogrammer@yahoo.com --- I dug into the app to figure out what it's doing, and the load dialog that's messed up is calling GetOpenFileNameA() to create an explorer-style load dialog (OFN_EXPLORER) that includes custom child dialog template (OFN_ENABLETEMPLATE) and hook (OFN_ENABLEHOOK). It also uses an older version of the struct (OPENFILENAME_SIZE_VERSION_400) which hides the places bar.
The custom child dialog template uses a static stc32 control to put the controls to the right of the standard controls rather than underneath, and has a few additional controls to display a level preview along with a static "film" icon.
The hook procedure has a bunch of code to set a custom font (Times New Roman) and resize/move controls (both custom and built-in) when handling WM_INITDIALOG and CDN_INITDONE, but I think the crux of the problem is that at the end of CDN_INITDONE, the hook procedure makes a SetWindowPos(hChildDlgWnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_SHOWWINDOW | SWP_NOMOVE | SWP_NOSIZE) call that places the custom child dialog above the other dialog windows, which prevents them from responding to messages (paint/mouse/etc.).
If I modify the binary to make that SetWindowPos() call set the SWP_NOZORDER flag in addition to the other flags, the dialog appears and behaves correctly (at least as far as I can tell).
I created a stripped-down Visual Studio 2019 project w/o SWP_NOZORDER that reproduces the issue (I will attach this shortly). Under Wine (7.3 is latest tested), I can see that the HWND for the child dialog gets put to the top of the Z order after the SetWindowPos() call. However, Win10 apparently ignores the HWND_TOPMOST flag and leaves the HWND for the child dialog at the bottom of the Z-order.
I suspect this has to do with the remarks about SWP_NOZORDER and HWND_TOPMOST discussed on https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwin..., though the behavior specified by remarks isn't entirely clear to me.