March 2025 - Wine-Bugs - list.winehq.org

[Bug 57386] New: Attempting to run The Sims 1 Complete Collection results in a loop in dbghelp.
by WineHQ Bugzilla March 3, 2025

March 3, 2025

https://bugs.winehq.org/show_bug.cgi?id=57386 Bug ID: 57386 Summary: Attempting to run The Sims 1 Complete Collection results in a loop in dbghelp. Product: Wine Version: 9.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dbghelp Assignee: wine-bugs(a)winehq.org Reporter: hibbsncc1701(a)gmail.com Distribution: --- I'm assuming the game crashed for some reason, but attempting to run The Sims 1 Complete Collection results in no game window being made, and the following message echoed to the console indefinitely until the game process is killed: fixme:dbghelp:elf_search_auxv can't find symbol in module Running with WINEDEBUG=+dbghelp shows that it's trying to load debugging symbols but fails when it tries to load the symbol for ntdll.so!main_envp: 0120:trace:dbghelp:SymFromName (FFFFFFFF, "ntdll.so!main_envp", 0080E378) 0120:trace:dbghelp:image_locate_build_id_target checking L"/usr/lib/debug/.build-id/90/0892727821433d4332b9bd84b5d49ad3e0735b.debug" 0120:trace:dbghelp:image_locate_build_id_target checking \??\Z:\home\ADS.CODENET\codebase\.cache\debuginfod_client\900892727821433d4332b9bd84b5d49ad3e0735b\debuginfo 0120:trace:dbghelp:image_locate_build_id_target not found 0120:trace:dbghelp:image_load_debugaltlink No .gnu_debugaltlink section found for L"ntdll.so" 0120:fixme:dbghelp:elf_search_auxv can't find symbol in module -- 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.

1 8

[Bug 57902] New: The Sims 1 Complete Collection crashes when trying to show the EA logo.
by WineHQ Bugzilla March 3, 2025

March 3, 2025

https://bugs.winehq.org/show_bug.cgi?id=57902 Bug ID: 57902 Summary: The Sims 1 Complete Collection crashes when trying to show the EA logo. Product: Wine Version: 10.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: quartz Assignee: wine-bugs(a)winehq.org Reporter: hibbsncc1701(a)gmail.com Distribution: --- Under Wine-10.2 attempting to run The Sims 1 Complete Collection in a clean prefix will crash the game due to a quartz bug. Attempting to use a native quartz.dll via winetricks will fail, as will setting quartz.dll to native only in winecfg, or attempting to use ffdshow. Renaming the quartz.dll in Windows\System32, (or Windows\Syswow64 for those running 64bit prefixes), will bypass the issue and allow the game to start. As will removing the gstreamer plugin for MSVIDEO / AVI. Relevant output from the console is attached. (Ignore the "can't find symbol in module" bits. That's Bug #57386.) -- 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.

1 2

[Bug 57901] New: Menu UI elements are positioned incorrectly in some cases with winewayland
by WineHQ Bugzilla March 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=57901 Bug ID: 57901 Summary: Menu UI elements are positioned incorrectly in some cases with winewayland Product: Wine Version: 10.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)winehq.org Reporter: shtetldik(a)gmail.com Distribution: --- Created attachment 78142 --> https://bugs.winehq.org/attachment.cgi?id=78142 treflex binary This doesn't happen with every application, but I noticed that with one particular old one (Typing Reflex) when using winewayland, the menu positioning is incorrect. Attaching the example binary if you want to test - it's enough to expose the issue with the menu. Originally here: https://rapidtyping.com/best-typing-tutors/typing-reflex.html It must be doing something uncommon with win32 API that winewayland doesn't handle properly. -- 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.

1 1

[Bug 57900] New: ML Sound Labs Amped Flagship: Audio not working within Amp simulator programs since the 10.0 update
by WineHQ Bugzilla March 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=57900 Bug ID: 57900 Summary: ML Sound Labs Amped Flagship: Audio not working within Amp simulator programs since the 10.0 update Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: wjm146(a)gmail.com Distribution: --- Created attachment 78141 --> https://bugs.winehq.org/attachment.cgi?id=78141 settings menu for the applications detailing pulseaudio I use WINE previously to use software guitar amps sims. Specifically Amped plugins from ML Sound Lab worked the best in my environment. Ever since the 10.0 update I have had issues. All of the Apps seemingly work fine other than it does not process audio using Pulseaudio. It recognizes my Focusrite interfaces as both an input and output as seen here. The only way that it outputs sound is the 'test' output button. Even before if I was having with outputs It would at least give static, but my output is dead silent. Out of curiosity I tried other guitar amp sim programs with similar problems. I assumed it was a bug that would have been fixed in 10.0-1 and -2, but the problem remains. This bug is present on multiple systems (arch and opensuse). This is seemingly not exclusive to the amp sims made by ML Sound Lab as I downloaded an unrelated amp sim to test. -- 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.

1 0

[Bug 57834] New: Regression: Cyberpunk 2077 doesn't load with CyberEngine Tweaks
by WineHQ Bugzilla March 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=57834 Bug ID: 57834 Summary: Regression: Cyberpunk 2077 doesn't load with CyberEngine Tweaks Product: Wine Version: 10.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: shtetldik(a)gmail.com Distribution: --- Between Wine 10.0 and 10.1 some regression occurred that causes Cyberpunk 2077 with cyber engine tweaks plugin not to load (without CET it works fine in 10.1 too). CET is loaded in general by overriding version.dll as native, builtin. The only suspicious error in the log that I see is this: 0184:fixme:graphics:ShutdownBlockReasonCreate (0000000000030056, L"Generating error report"): stub I'm running the game with usual things like * esync from staging * dxvk / vkd3d-proton -- 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.

1 17

[Bug 40495] New: Impossible to function at 64 bit on FreeBSD
by wine-bugs＠winehq.org March 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=40495 Bug ID: 40495 Summary: Impossible to function at 64 bit on FreeBSD Product: Wine Version: 1.7.46 Hardware: x86-64 OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alexandrosperdikomatis(a)gmail.com Created attachment 54269 --> https://bugs.winehq.org/attachment.cgi?id=54269 the regular backtrace report I've compiled wine64 several times in many ways at FreeBSD. 32 bit version always works fine. This is the port emulators/wine-devel from RELEASE ports collection at FreeBSD 10.2 Application tried was Wow-64.exe I am really disappointed with wine64 at FreeBSD. On Linux it flies. -- 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.

2 2

[Bug 57788] New: "You have been unsubscribed from the wine-bugs mailing list"
by WineHQ Bugzilla March 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=57788 Bug ID: 57788 Summary: "You have been unsubscribed from the wine-bugs mailing list" Product: WineHQ Bugzilla Version: 3.2.3 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: bugzilla-unknown Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com CC: austinenglish(a)gmail.com, jnewman(a)codeweavers.com Distribution: --- Twice now, I've gotten an email that I've been unsubscribed from the wine-bugs mailing list (I've been subscribed for years without issue). The first time was January 22, and again just now. @Newman, is this related to recent site upgrades? -- 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.

1 12

[Bug 3930] HOMM/Deadlock shows black screen (game DLL calls SuspendThread inside WOM_OPEN winmm callback)
by WineHQ Bugzilla March 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=3930 --- Comment #88 from zebra2745(a)vibzi.net --- > That doesn't work, because GetCurrentThread() only returns a pseudo handle, > "a special constant that is interpreted as the current thread handle" > (MSDN). I think we have to compare the globally unique thread IDs to be sure: https://www.codeproject.com/Tips/5350589/The-Current-Thread-Handle says: > What to do when you want to use the current thread handle > This tip shows a side effect of GetCurrentThread and explains what to do when you need to avoid that. > Introduction > When you need to get a handle to the current thread, you can use > GetCurrentThread which gives you a pseudo handle which you don't need to close > because it is not a real reference counted handle. This is mentioned clearly in > the documentation. However, I recently bumped my head against this. I wanted to > share it so that others can avoid having to chase this down. > My Headbump > Consider the following example: > ------------------------------ snip ------------------------------ DWORD worker(void* ctx) { std::cout << "Thread id: " << GetThreadId((HANDLE)ctx) << std::endl; return 0; } int main() { HANDLE hMainThread = GetCurrentThread(); std::cout << "Thread id: " << GetThreadId(hMainThread) << std::endl; HANDLE hThread = CreateThread(NULL, 0, worker, hMainThread, 0, NULL); WaitForSingleObject(hThread, INFINITE); } > ------------------------------ snip ------------------------------ > This is what happens: > Thread id: 44068 > Thread id: 36376 > Without thinking, I had assumed that the pseudo handle was just a weak copy of > the actual handle (a non reference counted copy of the current handle), and I > could reference it in a worker thread. Instead, it is a special constant that > literally means 'when this handle value is supplied, use the current thread'. > And if you pass that special value to another thread, then that value will > translate to the thread handle of 'that' thread. > If you read the documentation, then this is exactly what it says. Only I > didn't stop to think about what that actually meant. > Getting the Real Thread Handle > If you want to get a real handle that you can pass to another thread, do this: > ------------------------------ snip ------------------------------ HANDLE hMainThread = NULL; if (!DuplicateHandle( GetCurrentProcess(), GetCurrentThread(), GetCurrentProcess(), &hMainThread, 0, FALSE, DUPLICATE_SAME_ACCESS)) { cout << "Error " << GetLastError() << " cannot duplicate main handle." << endl; return GetLastError(); } > ------------------------------ snip ------------------------------ > Of course, when you do this, you get a HANDLE value that you do need to close > when you no longer need it. -- 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.

1 0

[Bug 3930] HOMM/Deadlock shows black screen (game DLL calls SuspendThread inside WOM_OPEN winmm callback)
by WineHQ Bugzilla March 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=3930 --- Comment #87 from Damjan Jovanovic <damjan.jov(a)gmail.com> --- (In reply to Dmitry Timoshkov from comment #86) > Created attachment 78138 [details] > patch > > Something like this may work. That doesn't work, because GetCurrentThread() only returns a pseudo handle, "a special constant that is interpreted as the current thread handle" (MSDN). I think we have to compare the globally unique thread IDs to be sure: ---snip--- if (GetCurrentThreadId() == GetThreadId(thread) && (GetVersion() & 0x80000000)) return 0; ---snip--- That fixes all the tests, but doesn't fully fix the game: it no longer deadlocks and even plays music (it was silently frozen before), but shows badly corrupted video (bottom ~2/3 of the screen are black, and the top 1/3 has randomly colored pixels), which makes it completely unplayable. Running it with "wine HEROES.EXE /s0" (which disables all sound) gets the graphics fully functional. This however, seems to be a separate issue, probably a regression as this WINMM fix was enough in earlier Wine versions, but now isn't. -- 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.

1 0

[Bug 3930] HOMM/Deadlock shows black screen (game DLL calls SuspendThread inside WOM_OPEN winmm callback)
by WineHQ Bugzilla March 2, 2025

March 2, 2025

https://bugs.winehq.org/show_bug.cgi?id=3930 --- Comment #86 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- Created attachment 78138 --> https://bugs.winehq.org/attachment.cgi?id=78138 patch Something like this may work. -- 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.

1 0