August 2026 - Wine-Bugs - list.winehq.org

[Bug 60068] wminet_utils: implement GetErrorInfo()

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60068 Louis Lenders <xerox.xerox2000x(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox.xerox2000x(a)gmail.com --- Comment #1 from Louis Lenders <xerox.xerox2000x(a)gmail.com> --- Hi, thanks for the patch. Patches are not picked up here, so could you please open a merge request for it at https://gitlab.winehq.org/wine to have a review on it? Thanks -- 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.

Aug. 3, 2026

[Bug 59775] German umlauts won't be handled correctly by typing

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59775 --- Comment #36 from AndyF <andreas.franz(a)arcor.de> --- I'm using this one: https://download.mailstore.com/dont-link-this/36B44217-2BF0-4603-8160-35DF2… To reproduce I'm using: - Linux Mint 22.3 - .NET4.8 installed (with Mono, no crash with "ö", but no keycodes on "keypressed"-event. -- 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.

Aug. 3, 2026

[Bug 55775] game made from unity is not play in-game video.

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=55775 --- Comment #39 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Zeb Figura from comment #38) > Therefore I'd appreciate leaving off the passive-aggressive comments. Which part is passive aggressive and should be left off? > As I've told you before, Wine lags behind DXVK because we have had at most > one developer working on Direct3D, often less than full time, for the past > several years. Thanks for clarifying d3d lags due to limited resources. I'm trying to fix the lags. Forgive me if my guess that limited resource allocation may due to business strategy is considered offensive to you. It seems a legitimate decision to be made given potential steam partnerships and resource allocations there. Perhaps I misunderstood your reply that "priorities are difficult" as these d3d bugs are considered lower priority. > I'm fully aware that the situation is not ideal, but there's nothing I can do to fix it. I'm doing what I'm able to fix/workaround bugs as a newcomer/outsider. Perhaps not auto rejecting other's fixes/workarounds may satisfy some level of what may be considered fixes especially when otherwise harmless and provide clarity. Haven video bugs are long standing with much confusion and speculation around the cause and I've spent considerable time testing, clarifying, relating duplicates, and submitting patches/merge requests to fix. That effort is not passive but very active. Forgive me if I consider my free time spent toward fixing these bugs important which may come off as a bit aggressive regarding achieving the goal of actually fixing them. -- 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.

Aug. 3, 2026

[Bug 60117] Evolution: The Game of Intelligent Life demo fails to start

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60117 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #5 from Zeb Figura <z.figura12(a)gmail.com> --- Probably hooking nonsense? -- 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.

Aug. 3, 2026

[Bug 55775] game made from unity is not play in-game video.

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=55775 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #38 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Stian Low from comment #36) > WineHQ constantly corrects reporters not to report DXVK tests/bugs but these > types of video bugs are the very cause that drives users/reporters to use > DXVK vs wine. > > If keeping wine behind DXVK is a business strategy then perhaps its > considered a waste of time to try to fix these bugs. As I've told you before, Wine lags behind DXVK because we have had at most one developer working on Direct3D, often less than full time, for the past several years. I'm fully aware that the situation is not ideal, but there's nothing I can do to fix it. Therefore I'd appreciate leaving off the passive-aggressive comments. We ask users to test with upstream Wine rather than DXVK because this is a Wine bug tracker. We have nothing to fix when DXVK bugs are reported. For what it's worth, I only bother asking things like that when it looks like a graphics bug. I'm not about to throw the book at someone who files a sound-related bug while using DXVK. > Perhaps dxvk exists because the dev also had difficulty getting these bugs > fixed and decided splitting dxvk as separate effort was more worthwhile > which steam also considered worth funding independently. Must be nice to be > fed for such hard effort. No, DXVK exists because Philip wanted to write his own Direct3D implementation. He never had intention of working with upstream. -- 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.

Aug. 3, 2026

[Bug 59775] German umlauts won't be handled correctly by typing

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59775 --- Comment #35 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- I'm not asked for an IP address. Are you using this as part of the TeamViewer package? I tried the standalone app as messing about with TeamViewer is a pain. If not, can you provide a direct URL to the version you are using? -- 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.

Aug. 3, 2026

[Bug 59775] German umlauts won't be handled correctly by typing

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59775 --- Comment #34 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to AndyF from comment #33) > Linux Mint: Crash > Debian: Works fine. I'll test for Linux Mint soon. Until I can reproduce the crash I won't be able to debug effectively. -- 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.

Aug. 3, 2026

[Bug 60110] AiCube-ISP v6.96Z: crashes (stack overflow) when selecting MCU type from dropdown

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60110 --- Comment #9 from nong24(a)qq.com --- (In reply to Ken Sharp from comment #7) Thanks for looking into this. To address your points: **1. hang vs crash** You're right — the app hangs, it doesn't crash/exit. The process stays alive (pgrep finds it, pkill kills it). The "Unhandled stack overflow" in the terminal output from the original report is a Wine-internal log event; the process itself doesn't terminate. So your observation of a hang matches mine. **2. ODBC** The "err:winediag:load_odbc failed to open library libodbc.so" message is a red herring. I checked: - The app's own import table does NOT import odbc32.dll. Its imports are: MFC42, MSVCRT, KERNEL32, USER32, GDI32, comdlg32, ADVAPI32, SHELL32, COMCTL32, ole32, OLEPRO32, OLEAUT32, VERSION, SETUPAPI, HID, SHLWAPI, iphlpapi, gdiplus, WS2_32. - The native mfc42.dll (required by the app) statically imports odbc32.dll. This is what causes odbc32.dll to be loaded and the winediag message to appear. - A WINEDEBUG=+loaddll,+odbc run shows odbc32.dll loaded once at startup (DllMain only), then zero SQL* function calls throughout the entire session — including at the point where the hang occurs. Installing ODBC (unixODBC or via winetricks mdac28) would only silence the winediag message; it should not change the hang. **3. Root cause: confirmed via winedbg backtrace** I ran the app under winedbg with BreakOnFirstChance enabled and caught the EXCEPTION_STACK_OVERFLOW (0xc00000fd) at first chance, before mfc42's SEH handler could intercept it. The backtrace (attached) shows unbounded re-entrant recursion through the comctl32 subclassing chain. The repeating cycle is: SetWindowTextA(hwnd, "0000") -> SendMessageA(hwnd, WM_SETTEXT) [msg=0xc] -> COMCTL32_SubclassProc -> DefSubclassProc -> TOOLTIPS_SubclassProc -> DefSubclassProc -> CallWindowProcW -> EDIT_WindowProc -> EDIT_WM_SetText -> notify_parent(EN_UPDATE) [msg=0x111] -> mfc42 WndProc -> SetWindowTextA(...) [re-enter] This cycle repeats ~140 times (each cycle consumes 7392 bytes of stack; 1MB stack exhausted at ESP=0x231ee8). The overflow triggers in WINPROC_CallProcWtoA (user32/winproc.c). The full winedbg session is attached as "winedbg_backtrace_60110.txt". Key frames from the backtrace: frame 58: SetWindowTextA(hwnd=000100C0, lpString="0000") frame 48: DefSubclassProc(uMsg=0xc) [WM_SETTEXT] frame 51: COMCTL32_SubclassProc(uMsg=0xc) frame 31: EDIT_WM_SetText frame 30: notify_parent -> SendMessageW(msg=0x111) [EN_UPDATE] frame 103: SetWindowTextA(hwnd=000100C0, lpString="0000") [re-enter] ... (repeats to frame 193, then stack overflow) **4. Conformance test (attachment 81666) — request for verification** The attached conformance test (attachment 81666) reproduces the same class of WM_SETTEXT re-entrancy without needing the app, mfc42, or ODBC. I ran it on both Wine and Windows: - Wine 11.14: recursion reaches the test's guard (depth 50) - Windows: recursion is bounded (depth ~15) I would appreciate it if you could verify the test on your Windows setup to confirm the Windows behavior independently. A note on scope: the test is a *simplified* reproduction. It triggers re-entrancy via a WndProc that re-enters SetWindowText on WM_SETTEXT, with a passive subclass in the chain. The real app's cycle (shown in the backtrace above) is more involved — it goes through EDIT_WM_SetText -> notify_parent(EN_UPDATE) -> WM_COMMAND -> mfc42 -> SetWindowText, with the comctl32 subclassing chain (TOOLTIPS_SubclassProc) in between. But both expose the same underlying gap: Wine does not bound WM_SETTEXT re-entrancy the way Windows does. The test isolates the core issue; the backtrace confirms it manifests in the real app. Notably, Wine already defines MAX_WINPROC_RECURSION (64) in dlls/win32u/message.c, but this limit did not prevent the recursion from reaching ~140 levels in the app — the re-entrancy appears to bypass the existing guard. This may warrant investigation as the potential fix site. -- 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.

Aug. 3, 2026

[Bug 60117] Evolution: The Game of Intelligent Life demo fails to start

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60117 --- Comment #4 from Alex Henrie <alexhenrie24(a)gmail.com> --- (In reply to Bernhard Übelacker from comment #3) > Maybe explicitly linking to kernel32 before kernelbase could help too, > like in this commit? > > https://gitlab.winehq.org/wine/wine/-/commit/ > db6c25fa7281fd6e62cd88b3ce52519c0bd6f1ed That worked! How the heck??? I understand why linking to kernel32 first would make a difference for tests that need to run on multiple Windows versions, but why it helps this game is a mystery to me. -- 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.

Aug. 3, 2026

[Bug 60110] AiCube-ISP v6.96Z: crashes (stack overflow) when selecting MCU type from dropdown

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60110 --- Comment #8 from nong24(a)qq.com --- Created attachment 81680 --> http://bugs.winehq.org/attachment.cgi?id=81680 winedbg first-chance backtrace showing unbounded WM_SETTEXT/DefSubclassProc recursion (140+ levels) -- 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.

Aug. 3, 2026