October 2022 - Wine-Bugs - list.winehq.org

[Bug 53814] TMUnlimiter 1.2.0.0 unable to find configuration INI

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53814 Qwerty Chouskie <asdfghrbljzmkd(a)outlook.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://trackmania-unlimite | |r.software.informer.com/dow | |nload/ -- 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.

Oct. 23, 2022

[Bug 53826] Attempting to install / update battle.net fails with Qt error

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53826 --- Comment #2 from Adrian Demarais <adwinebug(a)adrn.no-spam-allowed.com> --- Turns out that replacing the current battle.net plugin (/home/whoever/.wine/drive_c/Program Files (x86)/Battle.net/Battle.net.13763/platforms/qwindows.dll with a qwindows.dll from a previous battle.net folder will allow an already-installed battle.net to run. I expect anyone attempting a first install would be out of luck, having no previous qwindows.dll to fall back on. -- 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.

Oct. 23, 2022

[Bug 53814] TMUnlimiter 1.2.0.0 unable to find configuration INI

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53814 --- Comment #4 from Qwerty Chouskie <asdfghrbljzmkd(a)outlook.com> --- (In reply to Rafał Mużyło from comment #3) > By the log, the file "C:\\Program Files > (x86)\\TmNationsForever\\TMUnlimiter.ini" is found and read with no problem > reported. What other logs should I provide to help debug the issue then? Perhaps it's an issue with Wine's INI decoder? -- 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.

Oct. 23, 2022

[Bug 53826] Attempting to install / update battle.net fails with Qt error

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53826 --- Comment #1 from Adrian Demarais <adwinebug(a)adrn.no-spam-allowed.com> --- It should be noted that at least World of Warcraft will still run if launched separately, ie wine wow.exe. WoW will therefore remain playable until the 25th, when the next expansion's changes kick in, making the game unplayable for anyone who didn't download all the patches yet. -- 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.

Oct. 23, 2022

[Bug 53826] New: Attempting to install / update battle.net fails with Qt error

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53826 Bug ID: 53826 Summary: Attempting to install / update battle.net fails with Qt error Product: Wine Version: 7.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: adwinebug(a)adrn.no-spam-allowed.com Distribution: --- The install program Battle.net-Setup.exe runs for a while, then fails with a pop-up error message of " This application failed to start because it could not find or load the Qt platform plugin "windows" in "". " Multiple reports of this are in as of Oct 22: https://eu.forums.blizzard.com/en/wow/t/battlenet-client-doesnt-start-on-li… This was apparently triggered by Blizzard doing something to Battle.net. -- 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.

Oct. 23, 2022

[Bug 52619] Dungeon Fighter Online: Launcher crash when accepting Terms of Service

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52619 LB <wannabetheguy(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|7.12 |7.18 -- 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.

Oct. 23, 2022

[Bug 52619] Dungeon Fighter Online: Launcher crash when accepting Terms of Service

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=52619 LB <wannabetheguy(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #72740|0 |1 is obsolete| | --- Comment #13 from LB <wannabetheguy(a)gmail.com> --- Created attachment 73354 --> https://bugs.winehq.org/attachment.cgi?id=73354 Log from Wine 7.18 Staging Fedora updated to Wine 7.18 Staging. The launcher works as expected again. It still hung for a minute on "Make Download file list" starting again after it patched, but after that it quickly progresses to the login page. CPU usage on the launcher is much better now, but still seemed a little higher than it should be. Clicking Agree in the Terms of Service after logging in with my Neople account still crashes the launcher. -- 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.

Oct. 23, 2022

[Bug 53617] Imaris fails at exit with error, and keeps a process running.

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53617 --- Comment #4 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Created attachment 73353 --> https://bugs.winehq.org/attachment.cgi?id=73353 patch that would prevent keeping ImarisArenaFileMonitor running after closing imaris The attaced patch addresses the issue of the process "ImarisArenaFileMonitor" keeps running after the Imaris/ImarisViewer application has been closed. -- 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.

Oct. 22, 2022

[Bug 53682] wineboot shows "user_check_not_lock BUG: holding USER lock" on aarch64 since wine-7.14

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53682 --- Comment #15 from Martin Storsjö <martin(a)martin.st> --- Created attachment 73352 --> https://bugs.winehq.org/attachment.cgi?id=73352 Patch storing a separate syscall stack pointer separate from the syscall frame itself -- 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.

Oct. 22, 2022

[Bug 53682] wineboot shows "user_check_not_lock BUG: holding USER lock" on aarch64 since wine-7.14

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53682 --- Comment #14 from Martin Storsjö <martin(a)martin.st> --- (In reply to Kevin Puetz from comment #13) > > The attached patch, with the separate "DECLSPEC_NORETURN __attribute__((noinline)) call_user_mode_callback", there's a much greater chance of this still holding up (with a noreturn function, there's little point for the compiler to store anything else on the stack. > > No it's stronger than that. It's noinline that's controlling the compiler, > noreturn is just descriptive. In that patch, the setjmp(&jmpbuf) is in > KeUserModeCallback. But the callback_frame is in > call_user_exception_dispatcher, which, always gets its *own* stack frame > (because of noinline). We still smash up the stack of > call_user_exception_dispatcher, just like it used to for KeUserModeCallback. > But since the longjmp points to KeUserModeCallback, the epilogue of > call_user_exception_dispatcher will never get a chance to care. Oh, right, that's true. Indeed, that variant should be fairly safe. It's mildly ugly that we're expecting to maybe clobber this stack frame a bit, but it shouldn't have any practical effect. > > When setting up a new syscall_frame on the current stack, and calling __wine_syscall_dispatcher_return, we'd need to make sure that the new syscall_frame is at the very exact bottom of the stack. > > Yes (given the current __wine_syscall_dispatcher_return). zf and I weren't > sure whether that is just convenience, or if there was an actual reason why > the stack and syscall_frame needed to be contiguous. If you think it's OK to > just add an arbitrary gap, then it would seem more robust for asm code in > __wine_syscall_dispatcher_return to simply preserve its own $sp value (which > was properly set up by its caller), rather than overwriting it with $sp = > syscall_frame. Then it's just going to naturally be the correct stack, > rather than an arbitrary 0x100 offset. > > (maybe this would mean we need a __wine_syscall_dispatcher_return_callback > that differs from __wine_syscall_dispatcher_return, if the usage in > handle_syscall_fault and call_init_thunk need to do this). Oh, yes, that would work too. I tried making such a patch too, and that seems to work for me. I changed the unused align field in syscall_frame into syscall_stack. I made __wine_syscall_dispatcher_callback set this up, and likewise have signal_init_process set it up. But despite this, __wine_syscall_dispatcher does run into a case where this field is zero, early on in the startup. I fixed this by just using the syscall_frame itself as stack pointer, if it was null, but I wonder where I'm missing an initialization of it. The patch for doing this is fairly small too, but the end of __wine_syscall_dispatcher_callback which restores the original user mode registers still uses sp pointing at syscall_frame. I can rewrite it not to do that (there's a slight risk of clobbering the stack below sp at that point I believe), but I'd leave that to a second separate patch for clarity. -- 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.

Oct. 22, 2022