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

[Bug 60537] New: Final Fantasy XI Online: Window manager rules not applying as usual, and window decorations misbehaving.
by WineHQ Bugzilla Oct. 23, 2026

Oct. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60537 Bug ID: 60537 Summary: Final Fantasy XI Online: Window manager rules not applying as usual, and window decorations misbehaving. Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Keywords: regression Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: chiitoo(a)gentoo.org Target Milestone: --- Regression SHA1: 6cfa941df3f385ab025aa2c458753c017aa49ccc Distribution: Gentoo Created attachment 82404 --> http://bugs.winehq.org/attachment.cgi?id=82404 terminal output during application start After 6cfa941df3f [1], at least some states of the PlayOnline Viewer (as well as Final Fantasy XI Online when running in windowed mode) application window is no longer remembered via kwin-x11 window/application rules. I tend to have KWin remember "No Title Bar and Frame", or "apply initially", but neither seems to no longer be working with the aforementioned commit. Using 'force' instead of 'remember' or 'apply initially' does still work. Another oddity starting with this change can be seen when exiting Final Fantasy XI Online, and going back to the PlayOnline Viewer, where there is a brief moment where the window decorations appear to be something like the Wine window decorations, and after a moment the desktop theme-style decorations take over again. While there are some new'ish fixmes to be seen with the application output, they do start before this commit, but I wonder if they could hint towards something here. fixme:wgl:win32u_context_create Unknown WGL_CONTEXT_FLAGS_ARB 0x1 Thank you! 1. 6cfa941df3f385ab025aa2c458753c017aa49ccc -- 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 60533] New: partially implemented stub .. finds the adapter, but cannot open it
by WineHQ Bugzilla Oct. 23, 2026

Oct. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60533 Bug ID: 60533 Summary: partially implemented stub .. finds the adapter, but cannot open it Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wpcap Assignee: wine-bugs(a)list.winehq.org Reporter: rens.groenewegen(a)xs4all.nl Target Milestone: --- Distribution: --- I am trying to get an 32 bit packet capturing app to work. ( function: it checks for a checksum send by the client game, and validates it for the game server ) everything goes pretty well (as in: it recognizes what I have in the box ... ) but still fails to open the adapter. apparently blaming it on a partial stub ( i believe thats a incomplete implementation ?? ) NIC List: 1. \Device\NPF_{00000002-0000-0000-0000-4E6574446576} (eth3) 2. \Device\NPF_{00000003-0000-0000-0000-4E6574446576} (br0) 3. \Device\NPF_{00000004-0000-0000-0000-4E6574446576} (vnet0) 4. \Device\NPF_{00000005-0000-0000-0000-4E6574446576} (vnet1) 5. \Device\NPF_{00000001-0000-0000-0000-4E6574446576} (lo) 6. \Device\NPF_{00000006-0000-0000-0000-4E6574446576} (virbr0) 0164:fixme:wpcap:pcap_open "\\Device\\NPF_{00000002-0000-0000-0000-4E6574446576}", 65536, 1, 100, 00000000, 0012FC84: partial stub Unable to open the adapter. (null) is not supported by WinPcap itsme:vmhost3.fritz.box:[/home/itsme/.wine/drive_c/serv0-46800] = wine -V Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: File not found. itsme:vmhost3.fritz.box:[/home/itsme/.wine/drive_c/serv0-46800] = wine --help Usage: wine PROGRAM [ARGUMENTS...] Run the specified program wine --help Display this help and exit wine --version Output version information and exit itsme:vmhost3.fritz.box:[/home/itsme/.wine/drive_c/serv0-46800] = wine --version wine-10.10 -- 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 60558] New: configure reports "Wayland development files not found" when xkbregistry (or xkbcommon) is missing
by WineHQ Bugzilla Oct. 23, 2026

Oct. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60558 Bug ID: 60558 Summary: configure reports "Wayland development files not found" when xkbregistry (or xkbcommon) is missing Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: build-env Assignee: wine-bugs(a)list.winehq.org Reporter: truiken(a)gmail.com Target Milestone: --- Distribution: --- https://gitlab.winehq.org/wine/wine/-/blob/840a939ee526137639665ff5f587224d… The check for Wayland includes five dependencies: WAYLAND_CLIENT_LIBS, WAYLAND_SCANNER, XKBCOMMON_LIBS, XKBREGISTRY_LIBS, linux_input.h. If any of these are missing, configure outputs "Wayland development files not found". It may be surprising to some that installing libwayland-dev (or equivalent) does not fully satisfy this dependency, and reading configure.ac is required to know what to install. This can be fixed by using separate WINE_NOTICE_WITH checks for each dependency using the same enable_wayland_drv parameter (as is done with other components like Kerberos). -- 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 4

[Bug 60553] New: .NET Framework 4.8 : Rounding error when casting a nullable float variable (0.001) to a decimal
by WineHQ Bugzilla Oct. 23, 2026

Oct. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60553 Bug ID: 60553 Summary: .NET Framework 4.8 : Rounding error when casting a nullable float variable (0.001) to a decimal Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: godonnell(a)curtisswright.com Target Milestone: --- Distribution: --- float? Step = (float)0.001; Casting Step to a decimal yields a value of 0.0010000001 Example Code: internal class Program { static void Main(string[] args) { float? Step = (float)0.001; Console.WriteLine($"Step.Value = {Step.Value}"); Console.WriteLine($"(decimal)Step = {(decimal)Step}"); double? DoubleStep = (double)0.001; Console.WriteLine($"DoubleStep.Value = {DoubleStep.Value}"); Console.WriteLine($"(decimal) DoubleStep = {(decimal)DoubleStep}"); } } Output: Windows 11 Step.Value = 0.001 (decimal)Step = 0.001 DoubleStep.Value = 0.001 (decimal) DoubleStep = 0.001 debian trixie running wine 11.0 Step.Value = 0.001 (decimal)Step = 0.0010000001 DoubleStep.Value = 0.001 (decimal) DoubleStep = 0.001 -- 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 60562] New: winhttp silently truncates response header lines longer than 1459 bytes (breaks pre-signed S3 redirects)
by WineHQ Bugzilla Oct. 23, 2026

Oct. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60562 Bug ID: 60562 Summary: winhttp silently truncates response header lines longer than 1459 bytes (breaks pre-signed S3 redirects) Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winhttp Assignee: wine-bugs(a)list.winehq.org Reporter: jesper(a)jespersandstrom.se Target Milestone: --- Distribution: --- read_reply() in dlls/winhttp/request.c reads the status line and each response header line into a fixed stack buffer of MAX_REPLY_LEN (1460) bytes. read_line() copies at most that many bytes and discards the rest of the line, so a response header line longer than 1459 bytes is silently truncated. No error is returned to the caller. This is still the case in master as of 840a939ee5. Native WinHTTP accepts much longer header lines. The documented default for WINHTTP_OPTION_MAX_RESPONSE_HEADER_SIZE is 64 KB for all headers combined, and WinHTTP defines ERROR_WINHTTP_HEADER_SIZE_OVERFLOW for responses that exceed it. Real-world impact: services that redirect to pre-signed AWS S3 / CloudFront URLs. When the signing credentials are temporary, the URL carries an X-Amz-Security-Token of about 1 KB, so the Location header goes over 1460 bytes. Signature parameters come last in these URLs, so the truncated Location loses X-Amz-SignedHeaders and X-Amz-Signature. After the redirect, S3 answers "400 Bad Request" with error code AuthorizationQueryParametersError ("Query- string authentication version 4 requires the X-Amz-Algorithm, X-Amz-Credential, X-Amz-Signature, X-Amz-Date, X-Amz-SignedHeaders, and X-Amz-Expires parameters"). Affected application: Adobe Lightroom Classic 15.6. Its Camera Raw engine downloads AI models from photos.adobe.io, which 302-redirects to such URLs. The People / Object / Reflection masking models fail with "some AI models failed to download", while the same version downloads them fine on Windows. Because the cut-off depends on the token length, some downloads in a session succeed and others fail. Steps to reproduce (no Adobe software needed): 1. Start a local HTTP server that answers GET / with status 200 and a Location header whose value is 2999 characters long. 2. From a Windows program running under wine, use WinHTTP to GET that URL (WinHttpOpen / WinHttpConnect / WinHttpOpenRequest / WinHttpSendRequest / WinHttpReceiveResponse), then read the header with WinHttpQueryHeaders(WINHTTP_QUERY_LOCATION) and print the returned length. Expected: 2999 characters Actual: 1449 characters. The 10-byte "Location: " prefix plus the 1449-byte value fill the 1460-byte buffer, including its terminating NUL. Raising the line limit in read_reply() to the native 64 KB makes the reproduction return the full value. With that change, Lightroom's model downloads succeed and the files are byte-identical to the same files downloaded on Windows. Disclosure: the root-cause analysis and the local test were done with the help of an AI assistant. Per the Clean Room Guidelines, no AI-written code is attached; the description above is meant to let a developer write the fix and the test independently. -- 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 60561] New: Regression in 11.20: wine segfaults in ntdll.so at startup, even winecfg on a fresh prefix
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60561 Bug ID: 60561 Summary: Regression in 11.20: wine segfaults in ntdll.so at startup, even winecfg on a fresh prefix Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: hadoerdo1991(a)gmail.com Target Milestone: --- Distribution: --- Since Wine 11.20, every Wine process crashes immediately at startup with SIGSEGV (exit code 139). This happens even with `winecfg` on a brand-new prefix, so it is not application-specific. Wine 11.19 works fine on the same system. Tested (Kron4ek builds): - wine-11.20-amd64 -> crash - wine-11.20-amd64-wow64 -> crash - wine-11.20-staging-amd64-wow64 -> crash - wine-11.20-staging-tkg-amd64 / -wow64 -> crash - wine-11.19-staging-tkg-amd64-wow64 -> works Steps: WINEPREFIX=$HOME/test1120 wine winecfg dmesg: wine64[33896]: segfault at 0 ip 000079249e879589 sp 00007ffe70302d70 error 4 in ntdll.so[79589,79249e800000+a7000] gdb backtrace (no symbols) crashes at ntdll.so+0x79589; stack contains 0x7ffe0000 / 0x7ffe1000 (KUSER_SHARED_DATA region), suggesting the crash happens during early virtual memory setup. System: - Xubuntu 24.04, kernel 7.0.0-38-generic - MacBook Air 2012, Intel i5-3427U (Ivy Bridge), Intel HD 4000, 8 GB RAM - /dev/ntsync present Also reproduced on a second machine: - MacBook Pro Early 2015, Intel Core i5-5257U (Broadwell), 8 GB RAM - Ubuntu 24.04, Xorg, kernel 7.0.0-38-generic - wine-11.19-staging-tkg-amd64-wow64 -> works - wine-11.20-staging-tkg-amd64-wow64 -> crash I have not bisected yet, since building Wine on this machine is very slow, but I can test patches or specific builds if needed. -- 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 60540] New: imgburn can't access Blu-ray writer anymore
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60540 Bug ID: 60540 Summary: imgburn can't access Blu-ray writer anymore Product: Wine-staging Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: bastiaan.stougie(a)telenet.be CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Target Milestone: --- Distribution: --- Verbatim Blu-ray writer connected to USB. Imgburn works with with wine-staging 11.19, can burn blu-ray discs and DVDs. To reproduce the issue: - install winehq-staging 11.20. - install imgburn with SetupImgBurn_2.5.8.0.exe - Start imgburn - Go to Tools > Settings > I/O and select SPTI. - Go to Tools > Search for SCSI/ATAPI devices Expected result: imgburn reports that it has found a BD-RE drive and it becomes available to write to. Actual result with win 11.20: Imgburn produces an error popup: {{{ I/O Error! Device: [2:0:0] (D:) CDB: 12 00 00 00 60 00 Interpretation: Inquiry Reason: No access to memory location. }}} The drive does not become available. -- 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 4

[Bug 60429] New: Anno 1800: Closes immediately after launch since Wine 11.17
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60429 Bug ID: 60429 Summary: Anno 1800: Closes immediately after launch since Wine 11.17 Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: philipp.kloke(a)web.de Target Milestone: --- Distribution: --- Created attachment 82238 --> http://bugs.winehq.org/attachment.cgi?id=82238 Log with Wine 11.16 - Anno 1800 works Anno 1800 used to work very well with Wine 11.16. Since 11.17, also tested with 11.18 and 11.19, it does no longer start. The game successfully launches Ubisoft Connect. It even opens the games main window, switches to fullscreen and shows the cursor on a black screen. After a while, the game window closes and only Ubisoft connect remains open. Log files with working 11.16 and not working 11.19 are attached. -- 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 4

[Bug 60559] New: dinput: Acquire() dispatches messages sent from other threads (Sudden Strike Gold crashes)
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60559 Bug ID: 60559 Summary: dinput: Acquire() dispatches messages sent from other threads (Sudden Strike Gold crashes) Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dinput Assignee: wine-bugs(a)list.winehq.org Reporter: winehqbmw(a)lsmod.de Target Milestone: --- Distribution: --- Created attachment 82424 --> http://bugs.winehq.org/attachment.cgi?id=82424 reproducer source Sudden Strike Gold (Steam 612300) crashes at startup with Proton 8.0 and later, with a NULL pointer read in Menu_Dll.dll. Proton 7.0 works a bit better, but has random crashes later. The crash happens when another process sends a message to the game window while the game is inside IDirectInputDevice::Acquire. Proton 8+ runs tabtip.exe, which sends WM_GETOBJECT to the focused window. In Wine, Acquire sends a message to dinput's internal input thread and waits for the reply. While it waits, it dispatches messages sent to the calling thread, so the game's window procedure runs from inside Acquire. The game doesn't expect that, and its startup ends up in a broken state. Unacquire behaves the same way. Native dinput doesn't do this. I checked on Windows XP SP3 with dinput versions 3, 5, 7 and 8, keyboard and mouse, foreground and background. The attached repro.c (produces repro.exe) sends WM_USER to its window from a second thread, calls Acquire, and prints how many times the window procedure ran during the call: Windows XP SP3: messages dispatched inside Acquire: 0 Wine 11.20 / Proton 10: messages dispatched inside Acquire: 1 The crash can be reproduced in plain Wine without tabtip.exe by running any program that repeatedly sends WM_GETOBJECT to the game window while it starts. -- 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 55405] New: FreeCommander crashing immediately after it starts, when Windows version is set above Windows XP
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

https://bugs.winehq.org/show_bug.cgi?id=55405 Bug ID: 55405 Summary: FreeCommander crashing immediately after it starts, when Windows version is set above Windows XP Product: Wine Version: 8.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mywine(a)schiermeier-it.de Distribution: --- Created attachment 74965 --> https://bugs.winehq.org/attachment.cgi?id=74965 Console log from start of FreeCommander with Windows version set to v10 Installation of FreeCommander 32bit is working without any error. When it should start it crashes. Depending on the version Windows is set to, it behaves like this: Windows XP: works Windows 7: crash at the start with a stack overflow error, show in a message box Windows 10: a window came up and disappears immediately without any message (box) Console output for Windows 10 is attached. -- 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 5