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

[Bug 60527] New: CUERipper does not work in Wine 11.20 - Drives not detected
by WineHQ Bugzilla Oct. 23, 2026

Oct. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60527 Bug ID: 60527 Summary: CUERipper does not work in Wine 11.20 - Drives not detected Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: toadking(a)toadking.com Target Milestone: --- Distribution: --- Created attachment 82390 --> http://bugs.winehq.org/attachment.cgi?id=82390 WINEDEBUG=+file wine CUERipper.exe Starting in Wine 11.20, CUERipper does not work. The list of drives just says "The mehtod or operation is not implemented" if no CD is inserted, and if one is it says "Error querying drive: IoctlFailed" instead. Trace with WINEDEBUG=+file attached. This may be related to Bug #60525 since I'm also seeing some c00000cb (STATUS_BAD_DEVICE_TYPE) logs around CD drives in this trace. -- 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 6

[Bug 60560] New: Initial WINEPREFIX setup hangs at "Updating, please wait..." dialog when the disk runs out of space
by WineHQ Bugzilla Oct. 23, 2026

Oct. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60560 Bug ID: 60560 Summary: Initial WINEPREFIX setup hangs at "Updating, please wait..." dialog when the disk runs out of space Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: truiken(a)gmail.com Target Milestone: --- Distribution: --- $ mkdir -p /tmp/winetest $ sudo mount -t tmpfs -o size=250M tmpfs /tmp/winetest $ WINEPREFIX=/tmp/winetest/prefix winecfg Unclear whether the expected behavior should be a dialog alerting the user or output on stderr. -- 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 60563] New: Kerberos (Negotiate) login to MS SQL Server fails since out-of-process lsass: second InitializeSecurityContext gets empty input token
by WineHQ Bugzilla Oct. 23, 2026

Oct. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60563 Bug ID: 60563 Summary: Kerberos (Negotiate) login to MS SQL Server fails since out-of-process lsass: second InitializeSecurityContext gets empty input token Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: secur32 Assignee: wine-bugs(a)list.winehq.org Reporter: w.janos(a)maciosoft.net Target Milestone: --- Distribution: --- 32-bit Delphi/ADO application connects to MS SQL Server 2017 using the Microsoft OLE DB Driver 18 for SQL Server (MSOLEDBSQL) with Integrated Security. Kerberos is configured correctly: valid TGT, SPN MSSQLSvc/<host>:<port> registered, and kvno resolves it. Wine 11.0 (stable): login succeeds. Wine 11.20 (staging, WoW64 prefix): login fails. The driver shows "SQL Server Network Interfaces: " with an empty description. The failure happens in the second leg of the Kerberos exchange. The first gss_init_sec_context runs inside lsass.exe and produces the AP-REQ (GSS_S_CONTINUE_NEEDED, ret_flags 0x4133). The server's reply token is then passed back by the driver in the second InitializeSecurityContextW call. But gss_init_sec_context inside lsass receives an EMPTY input token and fails: trace:kerberos:initialize_context gss_init_sec_context returned 0x1 minor status 0 ret_flags 0x4133 trace:kerberos:initialize_context gss_init_sec_context returned 0x90000 minor status 0x186a1 ret_flags 0 trace:kerberos:trace_gss_status_ex GSS-API error: 0x90000: "Invalid token was supplied" I confirmed the empty input with an LD_LIBRARY_PATH shim around libgssapi_krb5.so.2 that logs the input and output tokens of gss_init_sec_context: INPUT len=0 OUTPUT len=3415 (1st call, AP-REQ) INPUT len=0 OUTPUT len=0 (2nd call, should carry the server's AP-REP) On the client side, secur32 is called with a non-NULL input SecBufferDesc on the second call: trace:secur32:lsa_InitializeSecurityContextW 08514D50 08514D40 L"MSSQLSvc/mcsfs01.mcs.local:49829" 0x14003 0 16 0026EBCC 0 ... Suspected cause --------------- include/wine/lsass.idl (introduced with the out-of-process lsass) declares: typedef struct { ULONG ulVersion; ULONG cBuffers; SecBuffer *pBuffers; } SecBufferDesc; pBuffers has no [size_is(cBuffers)], so widl marshals only ONE SecBuffer. programs/lsass/lsass.c then iterates input->cBuffers / output->cBuffers elements. When the caller passes more than one buffer and the token is not buffer 0, the package never sees the token. Elements past index 0 are also read out of bounds of the unmarshalled array. Likely fix: [size_is(cBuffers)] SecBuffer *pBuffers; (I could not inspect MSOLEDBSQL's exact SecBufferDesc layout, for example token plus channel bindings or an extra empty buffer. That part is an inference from the IDL and the observed empty input.) Steps to reproduce ------------------ 1. WoW64 prefix, install msoledbsql (18.x, x64 installer, which includes the 32-bit driver). 2. kinit user@REALM; SQL Server with a registered MSSQLSvc SPN. 3. 32-bit client connecting via OLE DB: Provider=MSOLEDBSQL;Data Source=host\instance; Integrated Security=SSPI (any ADO test program). 4. Wine 11.0: works. Wine 11.20: fails as above. Environment ----------- Ubuntu 26.04 x86_64, MIT krb5 1.22.1, WineHQ packages wine-staging 11.20 and wine-stable 11.0, MS SQL Server 2017 (14.0.1000), Windows AD domain. -- 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 60552] New: RFE: Explicitly define linker segment option to override distro default
by WineHQ Bugzilla Oct. 23, 2026

Oct. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60552 Bug ID: 60552 Summary: RFE: Explicitly define linker segment option to override distro default Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: loader Assignee: wine-bugs(a)list.winehq.org Reporter: mike(a)cchtml.com Target Milestone: --- Distribution: --- Wine has relied on default linker behavior. Starting with Fedora 45 and binutils 2.47 the default linker option "--rosegment" is now set for all binary linking. The previous default linker option was "--no-rosegments" and other distros may or may not follow Fedora. The reasoning behind the option switch is to improve security of the resulting binary layout. May Wine explicitly define "--no-rosegments" to preserve the expected binary output? This should be a no-op for all distros except Fedora 45+ that now override the defaults. I have opened a binutils bug to discuss the change, too. https://sourceware.org/bugzilla/show_bug.cgi?id=34714 -- 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 60534] New: Skyrim SE: Assertion `view->protect & VPROT_SYSTEM' failed.
by WineHQ Bugzilla Oct. 23, 2026

Oct. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60534 Bug ID: 60534 Summary: Skyrim SE: Assertion `view->protect & VPROT_SYSTEM' failed. Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: winebugs(a)63bit.net Target Milestone: --- Distribution: --- Created attachment 82395 --> http://bugs.winehq.org/attachment.cgi?id=82395 Last N lines of +virtual log to fit under the file size limit A modded Skyrim SE setup worked fine until 11.20, so this is a regression. I have not yet bisected the commits for 11.20. If there is a suspected commit happy to try reverting it. The game launches fine, can click to continue or start new game. The game will load, and as it is trying to start rendering the first scene frame, the game crashes reliably with "../wine/dlls/ntdll/unix/virtual.c:1502: create_view: Assertion `view->protect & VPROT_SYSTEM' failed." The game is using dxvk and proton vkd3d, as well as community shaders. Other SKSE plugins installed. I've attached a +virtual log. -- 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 3

[Bug 60536] New: Clip Studio Paint 1.13.2 Drawing Tool Cursor (pen, brush, eraser, etc) stops responding after pressing tablet button. Prevent drawing with mouse or stylus.
by WineHQ Bugzilla Oct. 23, 2026

Oct. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=60536 Bug ID: 60536 Summary: Clip Studio Paint 1.13.2 Drawing Tool Cursor (pen, brush, eraser, etc) stops responding after pressing tablet button. Prevent drawing with mouse or stylus. Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: firstone1993(a)msn.com Target Milestone: --- Distribution: --- Created attachment 82403 --> http://bugs.winehq.org/attachment.cgi?id=82403 Video demonstrating the bug. After pressing a button on my graphics tablet, the cursor for drawing related tools (Pen, Brush, Eraser, etc) will suddenly freeze in place, independently from the mouse cursor. It will jump around when you zoom or pan, but you will be unable to actually draw anything at all. Clicking out of the program and back into it "fixes" the frozen cursor, but then Clip Studio will no longer detect pen pressure until I restart it. System info: OS Linux Mint 22.3 (Cinnamon version 6.6.9) Kernel: 7.0.0-38-generic Display Server: X11 Wine info: Wine running in Windows 8.1 mode Allow window manager to decorate the windows is enabled Allow the window manager to control the windows is enabled Tablet model: Wacom Intuos Pro (PTH-660) -- 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 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

[Bug 27559] New: ImgBurn crash at startup when Wine's 'Windows Version' is set to 'Vista' (or newer)
by wine-bugs＠winehq.org Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=27559 Summary: ImgBurn crash at startup when Wine's 'Windows Version' is set to 'Vista' (or newer) Product: Wine Version: 1.3.22 Platform: x86 URL: http://www.imgburn.com/ OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: lightning_uk(a)imgburn.com I've had a bunch of crash logs sent to me over the past year where ImgBurn crashes unrecoverably on startup when users are running it under Wine but was never able to reproduce the error until today. It turns out that if Wine's 'Windows Version' is set to 'XP' (default and what I'd always been using) everything works fine. The second it's changed to 'Vista' (or newer), the app crashes at startup. I've managed to get a crash call stack via madExcept / Eurekalog and have now traced the problem back to the 'Explorer' style component it uses in the 'Disc Layout Editor' window ('TVirtualExplorerTree' by MustangPeak). It looks like it's related to namespace stuff and therefore the shell? I've made/attached a Delphi demo app with a single form and single instance of 'TVirtualExplorerTree' to hopefully make testing and debugging this issue a little easier. Without fail, it'll crash when Wine's 'Windows Version' is set to 'Vista' but it's fine as 'XP'. I'm using Wine in Ubuntu 11.04 for testing. The programs (ImgBurn and demo app) work fine on a real Windows XP, Vista or 7 installation. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

3 35

[Bug 60281] New: 32-bit installer crashes with stack overflow due to infinite loop in RtlUnwindEx (SEH unwinding) on macOS WoW64 build
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60281 Bug ID: 60281 Summary: 32-bit installer crashes with stack overflow due to infinite loop in RtlUnwindEx (SEH unwinding) on macOS WoW64 build Product: Wine Version: 11.16 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: nileshkumbhar1604(a)gmail.com Target Milestone: --- Wine version: wine-11.16 (self-built from git, commit gcd22bd7383a) Build configuration: ./configure --enable-archs=i386,x86_64 --with-mingw Host: Mac mini M4 (Apple Silicon), running Wine under Rosetta 2 as x86_64. Steps to reproduce: 1. Build Wine from source with WoW64 support (`--enable-archs=i386,x86_64`). 2. Run a 32-bit Windows installer, for example: `./wine UltraViewer_setup_6.6.124_en.exe` 3. The installation starts and the "Installing UltraViewer" dialog appears. 4. The process then crashes with: `err:virtual:virtual_setup_exception stack overflow 1664 bytes addr 0x7bcfccd3 stack 0x130000-0x131000-0x230000` Running with `WINEDEBUG=+seh,+tid` shows that `RtlUnwindEx` is repeatedly called with the same `target_ip` (`00006FFFFDFB2E80`) and does not appear to make any progress. This continues until the thread stack overflows. I have attached the full trace. This initially looked similar to bug 58698, which also involved an infinite loop with the new WoW64 implementation. However, that issue was related to the `VirtualAlloc` size-probing logic and was fixed by commit `f4c5b04148db5fc4e5265beec461d3b7d9f4a789`. The problem described here still occurs with Wine 11.16, so it does not appear to be the same issue. A 64-bit-only build (`--enable-win64`, without WoW64) does not reproduce the problem, and 64-bit applications run normally. The issue therefore appears to be specific to the 32-bit-on-64-bit exception/unwinding path. It may also be related to the macOS/Apple Silicon environment, although I have not confirmed this 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.

1 7

[Bug 60262] New: winemac.drv: macOS title bar drawn on frameless windows that reclaim the caption via WM_NCCALCSIZE, displacing all mouse input
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60262 Bug ID: 60262 Summary: winemac.drv: macOS title bar drawn on frameless windows that reclaim the caption via WM_NCCALCSIZE, displacing all mouse input Product: Wine Version: 11.16 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs(a)list.winehq.org Reporter: winebugs(a)protonmail.ch Target Milestone: --- winemac.drv draws a macOS title bar on a window that reclaimed its caption area via `WM_NCCALCSIZE`, and the resulting geometry displaces all mouse input by the caption height. ## Reproducer 60 lines, no game or third-party app required: https://github.com/macgameport/cities-skylines-2-macos/blob/main/scripts/fr… ## Steps to reproduce 1. Build the attached 60-line reproducer: `x86_64-w64-mingw32-gcc -O2 -o frameless-repro.exe frameless-window-repro.c -lgdi32` 2. `wine frameless-repro.exe` It creates a `WS_OVERLAPPEDWINDOW` and, in `WM_NCCALCSIZE`, reserves a 5px border on the left, right and bottom and **zero** on the top — the frameless-but-resizable pattern used by Electron and CEF apps. `SWP_FRAMECHANGED` is applied after creation so the change takes effect. ## Expected `dx=5 dy=0` (border kept, caption reclaimed) and **no** title bar — the application declined the caption and draws its own chrome there. ## Actual The window reports `dx=5 dy=0` as expected, and winemac draws a macOS title bar with traffic lights anyway. Applications that draw their own title bar therefore show **two**. The knock-on effect is worse than cosmetic: the Cocoa content view ends up ~28pt shorter than the client rect Win32 reports, so `ScreenToClient` subtracts a window origin ~56px above where the NSWindow actually is. **Every control hit-tests below the visible pointer** — you must hold the cursor above a button to activate it. Measured on a real application (the Paradox launcher shipped with Cities: Skylines II): ``` Win32 window rect : 228,346 px = 114,173 pt Cocoa window drawn at : 232,402 px = 116,201 pt -> 56 px = 28 pt apart Cocoa window 1279 x 674 pt Cocoa content view 1279 x 642 pt -> a 32 pt title bar that should not exist Win32 client rect 1279 x 669.5 pt -> widths identical, heights 27.5 pt apart ``` Not a pointer-mapping bug — `GetCursorPos` agrees with macOS `CGEvent` to within truncation (`dx -0.4, dy -0.4 px`, pointer verified stationary by bracketing the reads). ## Analysis Two functions answer "does this window have a title bar" from different inputs, and nothing reconciles them: | caller | function | input | |---|---|---| | `macdrv_GetWindowStyleMasks` — win32u asks how much non-client space the window rect reserves | `get_window_features_for_style()` | **style bits only** | | window creation / style change — the actual Cocoa decoration | `get_cocoa_window_features()` | style bits **+ `data->rects`** | `get_cocoa_window_features()` already carries an evidence-based override — `EqualRect(&data->rects.window, &data->rects.visible)` — so the incompleteness of the style test was clearly known. But it never consults `rects.client`, which is precisely the record of what `WM_NCCALCSIZE` did, and `struct window_rects` carries it already. **That guard is also why this is not more widely noticed.** An application that reclaims the *entire* window rect gets `dx=0 dy=0`, `window == visible` fires, and the window is left undecorated — Steam's own client does exactly this and is unaffected. The bug needs a **border with no caption**, which is the more common Electron shape. ## What does not fix it Suppressing `title_bar` in `get_cocoa_window_features()` when `client.top == window.top` removes the doubled chrome but **not the offset**: `GetWindowStyleMasks` still reports caption masks, win32u keeps reserving the space, and the NSWindow simply moves down by it. Measured content-view vs client: 27.5pt apart before and after. A fix has to make both answers share one source of truth, and the ordering is the hard part — `GetWindowStyleMasks` is called *while* win32u is computing the very rects it would need to consult. ## Disclosure This was investigated with heavy AI assistance. I am filing a bug report rather than a patch, and the reproducer is deliberately small enough to confirm or dismiss in two minutes without taking my analysis on trust. -- 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 7

[Bug 60375] New: Regression: Sojourn hangs due to timeout in ntdll/loader.c
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60375 Bug ID: 60375 Summary: Regression: Sojourn hangs due to timeout in ntdll/loader.c 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: zerooneo(a)01101001.net Target Milestone: --- Distribution: --- Created attachment 82160 --> http://bugs.winehq.org/attachment.cgi?id=82160 A log showing the timeout in the last two lines The game Sojourn has started hanging when the user starts playing after the main menu. As the game hangs, the log shows: 0254:err:vulkan:vkEndCommandBuffer section 00006FFFFFC4C460 "../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 0254, blocked by 0124, retrying (60 sec) 0120:err:sync:RtlpWaitForCriticalSection section 00006FFFFFC4C460 "../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 0120, blocked by 0124, retrying (60 sec) This started happening after commit 68474011825a98e9710240209d15b024b1dc6978 , "faudio: Import upstream release 26.09." The game is running with DXVK 2.4.1. -- 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 5

[Bug 60304] New: Leverage deduplication for prefixes to reduce wasted storage space
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60304 Bug ID: 60304 Summary: Leverage deduplication for prefixes to reduce wasted storage space Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: bokorbalazs(a)gmail.com Target Milestone: --- Distribution: --- A gentleman created an issue/feature request six years ago for proton, and the concluson was that it is not proton specific, it belongs to wine. Aeikum from CodeWeavers and maybe others were working on it: https://github.com/ValveSoftware/Proton/issues/4093 To sum up, there were already work invested but has stalled for unknown reasons. Maybe here this worthy feature request will move somewhere, and we will be provided some insight, what happened to this project. -- 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 60303] New: Singularity crashes after FAudio 26.09 import
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60303 Bug ID: 60303 Summary: Singularity crashes after FAudio 26.09 import Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com CC: julliard(a)winehq.org, z.figura12(a)gmail.com Target Milestone: --- Regression SHA1: 68474011825a98e9710240209d15b024b1dc6978 Distribution: ArchLinux Created attachment 82053 --> http://bugs.winehq.org/attachment.cgi?id=82053 terminal output Singularity (2010, Activision) has a regression after the FAudio 26.09 import in Wine 11.17. I tested the GOG.com version of Singularity. I don't own the Steam version so don't know whether that version is affected as well (https://store.steampowered.com/app/42670/Singularity/) The game needs Nvidia Physx to be installed ('winetricks -q physx'). The game crashes at various points during startup or loading. The crash is not completely deterministic. The initial splash screens work correctly. After that, the crash may occur: - immediately when the main menu appears - during the loading screen after selecting "Continue Game" - when starting a new game, sometimes after the intro video has finished, when the "Saving content..." message appears. I could not obtain a Wine backtrace. Wine reports that it is starting the debugger, but no useful winedbg backtrace is produced. The game also creates an Unreal crash dump file after each crash (e.g. unreal-v4869-....dmp), but the generated .dmp files are always 0 bytes. I bisected the regression to: commit 68474011825a98e9710240209d15b024b1dc6978 faudio: Import upstream release 26.09. Reverting this commit on top of Wine 11.17 fixes the crashes completely. Still present in wine-11.17-54-g490f6d5dcbb -- 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 6

[Bug 60270] New: Chrome 16 shows with the compositor's window decorations obscuring the tab bar
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60270 Bug ID: 60270 Summary: Chrome 16 shows with the compositor's window decorations obscuring the tab bar Product: Wine Version: 11.16 Hardware: x86-64 URL: https://www.oldversion.com/windows/google-chrome/googl e-chrome-16-0-912-75-1/ OS: Linux Status: UNCONFIRMED Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: lingm+winebz(a)posteo.org Target Milestone: --- Distribution: ArchLinux Created attachment 81988 --> http://bugs.winehq.org/attachment.cgi?id=81988 obscured_tab_bar Pretty sure it's supposed to render custom window controls. Those currently show up in black, but that's bug 60269. In any case, the compositor's window decorations partially obscure the open tabs. Tested on kwin wayland in case it turns out to be relevant. > $ sha1sum chrome_installer_16.0.912.75.exe > b44af829b88ac422b3c3c8848b631c69bb5a463b chrome_installer_16.0.912.75.exe > $ du -h chrome_installer_16.0.912.75.exe > 24M chrome_installer_16.0.912.75.exe -- 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 60207] New: VirtualDJ 2026: persistent skin corruption (ghost hover highlights, flickering) because d3d11_swapchain_Present1 ignores DXGI_PRESENT_PARAMETERS
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60207 Bug ID: 60207 Summary: VirtualDJ 2026: persistent skin corruption (ghost hover highlights, flickering) because d3d11_swapchain_Present1 ignores DXGI_PRESENT_PARAMETERS Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: bghome(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81893 --> http://bugs.winehq.org/attachment.cgi?id=81893 WINEDEBUG=+dxgi, DXVK disabled Overview -------- dlls/dxgi/swapchain.c:d3d11_swapchain_Present1() discards the DXGI_PRESENT_PARAMETERS argument entirely: static HRESULT STDMETHODCALLTYPE d3d11_swapchain_Present1(IDXGISwapChain4 *iface, UINT sync_interval, UINT flags, const DXGI_PRESENT_PARAMETERS *present_parameters) { struct d3d11_swapchain *swapchain = d3d11_swapchain_from_IDXGISwapChain4(iface); TRACE("iface %p, sync_interval %u, flags %#x, present_parameters %p.\n", iface, sync_interval, flags, present_parameters); if (present_parameters) FIXME("Ignored present parameters %p.\n", present_parameters); return d3d11_swapchain_present(swapchain, sync_interval, flags); } That struct carries DirtyRectsCount, pDirtyRects, pScrollRect and pScrollOffset. The FIXME is widely seen and generally assumed to be cosmetic, because for most applications it only costs an optimisation. For an application that presents *incrementally* on a flip-model swap chain it is not cosmetic: it produces permanent, highly visible rendering corruption, and no error is returned. Per Microsoft's flip-model presentation documentation, the scroll rectangle is "the area of the previous frame that the operating system needs to copy to the current frame before it renders the current frame". That copy is the runtime's responsibility, and Wine never performs it. Consequence: as the flip chain rotates, each back buffer only ever receives the damage that happened to be drawn while it was the current buffer. The buffers diverge permanently and the display alternates between two partially-updated frames, forever. Application ----------- VirtualDJ 2026 (build 9583), https://download.virtualdj.com/b9583/89CED1AB/install_virtualdj_2026_b9583_… - free to download and run without a licence, so the bug is reproducible without a purchase. The defect is in its "experimental skin engine" feature, which is enabled by default. Symptoms visible to the user: - a button stays highlighted after the cursor has moved to a different button, so two or more controls appear hovered at once; - dialog window borders flicker continuously; - tooltips and hint balloons blink on and off at frame rate. Steps to reproduce ------------------ 1. Install and start VirtualDJ 2026 (no need to load a track). 2. Make sure Settings -> Performance -> experimentalSkinEngine is "auto" or "yes" (the default). 3. Move the mouse onto deck B's CUE button, then onto the SYNC button next to it, and hold the cursor still. 4. Both CUE and SYNC are shown highlighted, and stay that way. Setting experimentalSkinEngine to "no" makes every symptom disappear. Environment ----------- wine-staging 11.0 under Bottles 66.7, win10 mode, X11 (WINEPREFIX has wayland driver disabled). Intel Arc (MTL), Mesa 26.1.6. Reproduced with Wine's own dxgi + wined3d, i.e. with DXVK disabled. It also reproduces with DXVK 3.0.2, because DXVK has the same gap (dxgi_swapchain.cpp: PresentBase() calls m_presenter->Present(SyncInterval, PresentFlags, nullptr)). So this is not a DXVK-specific problem; both paths discard the struct. Expected behaviour ------------------ d3d11_swapchain_Present1 should honour DXGI_PRESENT_PARAMETERS - at minimum pScrollRect/pScrollOffset, which the runtime is documented to copy from the previously presented buffer before the application renders the current frame. A conservative alternative that would also fix the corruption: when present_parameters is non-NULL, ensure the incoming back buffer contains the previously presented frame before returning, so that an application which redraws only its damaged regions still produces a coherent frame. Actual behaviour ---------------- The parameters are dropped, no copy is performed, no error or warning is returned to the application, and the swap chain's buffers diverge permanently. -- 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 11

[Bug 60505] New: Incorrectly translated strings for Bulgarian - showing Arabic instead
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60505 Bug ID: 60505 Summary: Incorrectly translated strings for Bulgarian - showing Arabic instead 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: mailforporn(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82363 --> http://bugs.winehq.org/attachment.cgi?id=82363 the Arabic texts incorrectly mixed in with the expected Bulgarian in winecfg When I open winecfg I see mixed Arabic and Bulgarian text. When I read terminal error messages I see incorrect Arabic instead of the expected Bulgarian text, for example: ❯ wine paint لم يتمكن التطبيق من العمل ، أو أنه لا يوجد اقتران مع هذا النوعمن الملفات. فشل التطبيق: الملف غير موجود. My LANG and all LC_* env vars are set to bg_BG.UTF8 -- 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 3