September 2020 - Wine-Bugs - list.winehq.org

[Bug 49920] wine: could not load ntdll.so, and more

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49920 --- Comment #8 from Daniel Ribeiro da Silva <ferion11(a)hotmail.com> --- (In reply to Alexandre Julliard from comment #7) > It's hard to tell without seeing all the details of your setup, but a valid > WINEDLLPATH should work the same way before and after the change. Note that > you can put multiple directories in WINEDLLPATH, for instance both 32-bit > and 64-bit lib dirs. Well, even just adding lib/wine to WINEDLLPATH in versions already working, stops it from working. My setup is unified in an AppImage that includes all 32-bit dependencies (for users of no-multilib distributions): * All working: https://github.com/ferion11/Wine_Appimage * Still in stability tests: https://github.com/ferion11/Wine_Appimage_dev Made to be used to install LogosBible using the script: https://github.com/ferion11/LogosLinuxInstaller Of the versions with v5.18, the only one that still works is the tkg, since Tk-Glitch reversed the changes of this commit, as we can see here: https://raw.githubusercontent.com/Tk-Glitch/wine-tkg/master/loader/main.c * and I'm making preparations for the WoW64 version too -- 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.

Sept. 30, 2020

[Bug 48121] Unity games do not fire OnApplicationFocus/OnApplicationPause events on focus regain

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=48121 --- Comment #14 from w(a)zeroitlab.com --- > Well sure it's old but it's also been there for a while, not breaking other apps, and probably serves a purpose. Well, now it does break Unity apps so there's that > Maybe Windows doesn't let the application decide if it should be activated or not when Alt-Tab is used, but maybe it does when clicking on it. This is 100% true. > The code covers the former too, maybe incorrectly, but the latter may be important to support. It does not actually support the second. The reason in Windows for allowing the window to decide whether to activate or not is because windows with "holes" in them, think of like the winamp skins more than a decade ago (for illustration: https://cdn.fishki.net/upload/post/2017/04/15/2268689/tn/840be11454bc68b1a9…) A WM_HITTEST is sent to the window, to test what window element a click hit, then a WM_MOUSEACTIVATE with the hittest result to figure out if the window wants to activate itself. If the window was activated as a result, the same action is sent as the message belonging to it - for example a WM_NCLBUTTONDOWN. Wine on the other hand never does a HITTEST, and sends a WM_MOUSEACTIVATE on a HTMENU which often is impossible because the app does not have a menu. Then does not follow it up with the appropriate message - because it cannot, since we have no idea where a menu is, if it even exists in the first place, and that message requires a coordinate. As you can expect, click-through windows dont work in wine because this. > Also, I don't know if it's possible, but maybe it is possible for some windows to not appear in the Alt-Tab list, and so only the latter case applies for them. this is possible, for windows with WS_EX_TOOLWINDOW style. I haven't really investigated their behavior (yet). Worst case we can just keep the behavior if the window has this style. At the core, this problem is about that we receive a click on something (the caption) that doesn't exist to the win32 program, and thus we cannot fake / pass through a click on it. You could try to say "let's render the caption then, and cut it off when displaying", however windows apps are allowed to draw whatever in the caption, or move it anywhere by just implementing WM_HITTEST so we cannot possibly know where the - if any - caption is. Part of the issue can be solved perfectly however: As long as the click goes to the client area, we could properly implement it (hittesting and all that stuff) and gain support to windows with holes in them like winamp. This would also solve half of this issue, since as long as you clicked into the window and not on the caption, activation would work as expected. As for the other part, we only have 3 other choices: - wontfix (sounds like you're leaning towards this?) - simulate alt-tab instead (my suggestion) - just add some random hack that makes unity work and hopefully doenst break other stuff (pretty much David's poc, with maybe a little bit more throught put into which message we should fake) > If the check is removed, then we can remove all WM_TAKE_FOCUS related code altogether because of the mentioned TOOLWINDOW stuff we might want to keep this around, for tool windows at least. > Then this may require some investigation, UseTakeFocus=No should not change the focus loss behavior, only the focus gain on Wine windows. I'll check back on this, was a 2 minute check of running an unity test program, could've been that my test environment was dirty from some stuff I tried before. As for the remaining problem (Unity jumping in the middle after fixing the activation issue) I think it's a clear-cut case, we just need to have those two messages sent. -- 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.

Sept. 30, 2020

[Bug 49920] wine: could not load ntdll.so, and more

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49920 --- Comment #7 from Alexandre Julliard <julliard(a)winehq.org> --- It's hard to tell without seeing all the details of your setup, but a valid WINEDLLPATH should work the same way before and after the change. Note that you can put multiple directories in WINEDLLPATH, for instance both 32-bit and 64-bit lib dirs. -- 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.

Sept. 30, 2020

[Bug 49909] Win Toolkit v.1.4.37.20 (.NET 3.5 app) crashes with wine-mono

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49909 --- Comment #2 from Esme Povirk <madewokherd(a)gmail.com> --- It was looking for a version resource in dism.exe. Patch sent, but I doubt this program will actually function in Wine given what it does. -- 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.

Sept. 30, 2020

[Bug 49920] wine: could not load ntdll.so, and more

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49920 --- Comment #6 from Daniel Ribeiro da Silva <ferion11(a)hotmail.com> --- (In reply to Alexandre Julliard from comment #5) > That's not really a change, WINEDLLPATH should always have pointed to the > dlls. You maybe didn't notice the wrong path before because it wasn't used > when libwine was loaded first. > > For 32-bit you need to either pass the correct --libdir to configure, or add > the 32-bit lib dir to WINEDLLPATH. Well, I clearly see the intention for this to work this way, but I don't see it working that way in practice. Perhaps, you could point me out how to change all variables at run time (without fixed compilation paths, because "/my/path" is random), and that works for cases before commit and after it (in both 32-bit and 64-bit WoW64 versions). After changing the variable of a working version of wine v5.11, it stopped working with a similar error: /my/path/usr/lib32/wine: error while loading shared libraries: /my/path/usr/lib32/wine: cannot open shared object file: No such file or directory -- 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.

Sept. 30, 2020

[Bug 49923] New: [Wine 5.18] Wineconsole curses backend support was removed.

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49923 Bug ID: 49923 Summary: [Wine 5.18] Wineconsole curses backend support was removed. Product: Wine Version: 5.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P5 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ttallink(a)googlemail.com Distribution: ArchLinux Hello, Today, after an update of my ArchLinux based server I was saddened and frustrated to find out that in Wine 5.18, the curses backend was removed from the available command line options of 'wineconsole'. I personally rely on wineconsole and _ESPECIALLY_, the curses backend - wineconsole is spawned as a systemd service configured to attach a pseudo terminal (/dev/ptmx), in order to run a backend for a Windows application I wrote. However, in Wine 5.18, the curses backend was removed, quoting the changelog: wineconsole: Remove curses backend. This is a total no-go for me and many others running Windows binaries through wineconsole on servers, since we need to be able to run wineconsole without a display / using a terminal session. Can you please elucidate as for why the curses backend was removed in the first place? I now have to downgrade to downgrade to 5.17 in order to be able to host the service again. This is a HUGE loss of functionality for those using Wine / wineconsole on servers. PLEASE consider adding the curses backend again. Best Regards, William Kane -- 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.

Sept. 30, 2020

[Bug 49920] wine: could not load ntdll.so, and more

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49920 --- Comment #5 from Alexandre Julliard <julliard(a)winehq.org> --- That's not really a change, WINEDLLPATH should always have pointed to the dlls. You maybe didn't notice the wrong path before because it wasn't used when libwine was loaded first. For 32-bit you need to either pass the correct --libdir to configure, or add the 32-bit lib dir to WINEDLLPATH. -- 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.

Sept. 30, 2020

[Bug 49673] Backpacker 3:Americana:unhandled exception

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49673 --- Comment #6 from Chebanenko Igor <chebanenkoigor93(a)gmail.com> --- (In reply to joaopa from comment #3) > Is it that game? > https://www.myabandonware.com/game/backpacker-3-americana-dxd#download Backpacker 3 original game: https://www.myabandonware.com/game/backpacker-3-dxc Backpacker 3: Mediterraneo (first addon): https://www.myabandonware.com/game/backpacker-3-mediterraneo-dxe Backpacker 3: Americana (second addon): https://www.myabandonware.com/game/backpacker-3-americana-dxd -- 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.

Sept. 30, 2020

[Bug 49920] wine: could not load ntdll.so, and more

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49920 --- Comment #4 from Daniel Ribeiro da Silva <ferion11(a)hotmail.com> --- (In reply to Alexandre Julliard from comment #2) > WINEDLLPATH should point to lib/wine, not lib/wine/fakedlls. By the way, this change breaks the working of all my wine compilations, before the regression commit. -- 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.

Sept. 30, 2020

[Bug 49673] Backpacker 3:Americana:unhandled exception

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49673 --- Comment #5 from Chebanenko Igor <chebanenkoigor93(a)gmail.com> --- (In reply to joaopa from comment #4) > Created attachment 68259 [details] > console output with relay channel enabled > > Confirming. Yes,but Americana - addon for original game. You need to install original game,and after that you will install addon. -- 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.

Sept. 30, 2020