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

[Bug 25974] AutoCAD 2009 LT: acadlt.msi doesn't start installer

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=25974 Janne <janne.kekkonen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |janne.kekkonen(a)gmail.com --- Comment #18 from Janne <janne.kekkonen(a)gmail.com> --- Hello, i was able to run msiexec without error messages with following command. wine msiexec /i x86/acadlt.msi /qn /norestart I did not try to launch autocad. -- 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.

May 19, 2026

[Bug 59453] uSimmics crashes on unimplemented function msvcp100.dll._Sinh

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59453 Bartosz <gang65(a)poczta.onet.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs(a)list.winehq.org |gang65(a)poczta.onet.pl -- 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.

May 19, 2026

[Bug 59771] TrackChecker-x64.exe hangs at 100% CPU on startup since Wine 11.7 (msxml3 regression)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59771 --- Comment #3 from fumadordeducados(a)gmail.com --- (In reply to Nikolay Sivov from comment #2) > Does it work for you if you do a new installation, in a clean wineprefix? I > don't see any problems with it, it starts up fine for me. > > Parsing errors are from "parsing" file at > \\AppData\\Roaming\\TrackChecker\\services.dat, which is not an xml file. > > --- > Create a win64 WINEPREFIX with the setup above > Copy TrackChecker-x64.exe and its data files (including data.xml, ~3.4MB) > into C:\TrackChecker\ > Run: wine "C:\\TrackChecker\\TrackChecker-x64.exe" > --- > > Why would you do that? If it's installed, it should be run from installation > directory. > > Let's focus on reproducing this first, we'll need exact steps, when using > freshly installed application. Not working in a clean prefix. Reporting prefix setup just for info. I was using these winetricks setup because they make a calendar control in the app workable, but you'll hit the bug right away on a clean installation in a vanilla prefix. -- 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.

May 19, 2026

[Bug 59248] Foundation Galactic Frontier: unable to click on mission to start the game

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59248 --- Comment #5 from sil <ssantos(a)web.de> --- For me, wineserver64 is running when it hangs. -- 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.

May 19, 2026

[Bug 59771] TrackChecker-x64.exe hangs at 100% CPU on startup since Wine 11.7 (msxml3 regression)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59771 --- Comment #2 from Nikolay Sivov <bunglehead(a)gmail.com> --- Does it work for you if you do a new installation, in a clean wineprefix? I don't see any problems with it, it starts up fine for me. Parsing errors are from "parsing" file at \\AppData\\Roaming\\TrackChecker\\services.dat, which is not an xml file. --- Create a win64 WINEPREFIX with the setup above Copy TrackChecker-x64.exe and its data files (including data.xml, ~3.4MB) into C:\TrackChecker\ Run: wine "C:\\TrackChecker\\TrackChecker-x64.exe" --- Why would you do that? If it's installed, it should be run from installation directory. Let's focus on reproducing this first, we'll need exact steps, when using freshly installed application. -- 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.

May 19, 2026

[Bug 59771] TrackChecker-x64.exe hangs at 100% CPU on startup since Wine 11.7 (msxml3 regression)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59771 --- Comment #1 from alfrlr(a)gmail.com --- Created attachment 80979 --> http://bugs.winehq.org/attachment.cgi?id=80979 Wine debug output with native msxml3 override set (64-bit msxml3.dll copied from Windows 10 System32) Shows OLE errors: apartment_add_dll couldn't load in-process dll, class {f6d90f11-9c73-11d3-b32e-00c04f990bb4} not registered. Native DLL fails to load, app exits with error dialog. -- 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.

May 19, 2026

[Bug 59771] New: TrackChecker-x64.exe hangs at 100% CPU on startup since Wine 11.7 (msxml3 regression)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59771 Bug ID: 59771 Summary: TrackChecker-x64.exe hangs at 100% CPU on startup since Wine 11.7 (msxml3 regression) Product: Wine Version: 11.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msxml3 Assignee: wine-bugs(a)list.winehq.org Reporter: alfrlr(a)gmail.com Distribution: --- Created attachment 80978 --> http://bugs.winehq.org/attachment.cgi?id=80978 Wine debug output (err+all,warn-all) with builtin msxml3. Shows fixme:msxml:domdoc_get_parseError calls immediately before the process enters 100% CPU infinite recursion loop. Process was killed after TrackChecker (https://trackchecker.net) a 64-bit Windows application (PE32+ x86-64, subsystem 6.00), worked correctly under Wine Staging 11.6 but hangs at 100% CPU with no window since Wine 11.7. The process never terminates on its own and must be killed. Regression introduced: Wine 11.7 ("Beginnings of MSXML reimplementation without libxml2") Last working version: Wine Staging 11.6 Prefix setup: WINEARCH=win64 wineboot winetricks vcrun2013 winetricks oleaut32 winetricks comctl32 Windows version in prefix: 6.1 (Win 7), confirmed via: wine reg query "HKLM\Software\Microsoft\Windows NT\CurrentVersion" /v CurrentVersion Note: these components may not be necessary to trigger the bug. They reflect the tested configuration. Steps to reproduce: Create a win64 WINEPREFIX with the setup above Copy TrackChecker-x64.exe and its data files (including data.xml, ~3.4MB) into C:\TrackChecker\ Run: wine "C:\\TrackChecker\\TrackChecker-x64.exe" Expected: Application window appears Actual: Process spins at 100% CPU indefinitely, no window is created, must be killed manually Technical analysis: With WINEDEBUG=err+all, the last msxml activity logged before the spin begins: fixme:msxml:domdoc_get_parseError ... semi-stub fixme:msxml:domdoc_get_parseError ... semi-stub fixme:msxml:domdoc_get_parseError ... semi-stub strace attached to the spinning process shows a continuous tight loop of Wine's stack growth handler: rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT USR1 USR2 ALRM CHLD IO], [], 8) = 0 mprotect(0xc3e0000, 65536, PROT_READ|PROT_WRITE) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT USR1 USR2 ALRM CHLD IO], [], 8) = 0 mprotect(0xc3f0000, 65536, PROT_READ|PROT_WRITE) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 ... This pattern (mprotect on incrementing addresses) is Wine's guard page expansion firing continuously — definitive infinite recursion consuming the entire stack. /proc/<pid>/wchan = 0 — the process is spinning entirely in userspace, never blocking. The application uses CoCreateInstance on CLSID {f6d90f11-9c73-11d3-b32e-00c04f990bb4} (DOMDocument30 / msxml3) to parse its data.xml configuration file at startup. The COM class is correctly registered in the prefix. Attempting to use native msxml3 (both via winetricks and by manually copying a genuine 64-bit msxml3.dll from a Windows 10 installation) did not resolve the issue: winetricks msxml3 installs only a 32-bit DLL which cannot load in a 64-bit process, and the Windows 10 native 64-bit DLL fails to load in Wine due to unresolved dependencies. A related regression (PLSQL Developer failing to start on Wine 11.7, also msxml3-related) was fixed in Wine 11.8, but TrackChecker's code path is not covered by that fix and remains broken in Wine 11.9. Workaround: Using Wine Staging 11.6 resolves the issue completely. -- 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.

May 19, 2026

[Bug 59732] Custom WinXP/7 app printing garbled from wine 9 onwards

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59732 --- Comment #10 from hascc <hugoac2004(a)gmail.com> --- (In reply to Rafał Mużyło from comment #6) > Well, given that 8.8 had a major wineps.drv rework, that's likely what broke. > I wonder what corner case your app covers, that hasn't been stumbled upon > for all that time elsewhere... > > (8.13 doesn't have anything labeled 'crash fix', but one of the psdrv > commits fixes a potential div by zero, so perhaps...) > > So, a 'psdrv' log from 8.8 and 8.13 each, if you don't mind, given that only > you have access to the app. Greetings again, here I'll add links for winedebugs from wine-devel 8.7 to 8.13: * https://shorturl.at/ZL3oU - test wine-devel 8.7, prints OK * https://shorturl.at/DxpvF - test wine-devel 8.8, crash at printing * https://shorturl.at/WDpHm - test wine-devel 8.9, crash at printing * https://shorturl.at/wce9d - test wine-devel 8.10, crash at printing * https://tinyurl.com/yp5hjte8 - test wine-devel 8.11, crash at printing * https://shorturl.at/jhWz2 - test wine-devel 8.12, crash at printing * https://tinyurl.com/yc56zaew - test wine-devel 8.13, prints garbled -- 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.

May 19, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #8 from Aaron Rainbolt <arraybolt3(a)gmail.com> --- Do you propose a better way for offering a file handler registration mechanism that is explicitly for non-executable file types, whereby any application that registers an executable file type with it can be considered buggy? It's very hard for me to understand how "there is no bug in Wine" when Wine is using a mechanism in the exact way the mechanism documents should never be done. -- 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.

May 19, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |enhancement -- 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.

May 19, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #7 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, That's design and software architecture discussion and highly debatable. There is no bug in Wine. Regards. -- 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.

May 19, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #6 from Aaron Rainbolt <arraybolt3(a)gmail.com> --- > That is the issue. Flatpak and Snap are not true sandbox if they let the app run > code outside of the sandbox. That depends on the kind of code though. If a user downloads a Word document with a sandboxed Firefox, then clicks the "Open" button in the browser to open it, the user would naturally expect that a) the file should open, and b) opening the file won't run arbitrary code within the file. To open the file, the sandboxed browser needs to either bundle an office suite within its own sandbox (which is unrealistic for per-app sandbox systems like Flatpak), or it needs to tell something outside the sandbox to open the file. That "something" is xdg-desktop-portal-gtk, and the way it determines how to open the file is by MIME handlers. This is a safe operation if the documentation that says "never register a MIME handler that blindly runs code from a file" is followed, it's an unsafe operation otherwise. I don't see how Wine doing something the documentation explicitly says to not do makes Flatpak "not a true sandbox". If there was a way to register MIME handlers with a warning on them that says "this will run arbitrary code", then I would agree with you, but there is a mechanism like that already, binfmt-misc. If that was used instead of MIME, it would allow people to double-click EXE files in their file manager and run them, while also not allowing a sandboxed app to break out. By using MIME, Wine is telling the system "Hi, I can open EXE files without running them", when in reality it does run them. binfmt-misc would let Wine say "Hi, I can open EXE files, but I will run them in the process", which is more in line with what Wine actually does. -- 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.

May 19, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be --- Comment #5 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello. It's not an issue with WINE, because you can associate EXE files (or any other executable file format, including scripts) with anything other than WINE and the issue remains the same. Your issue is more generic and the cause lies in the way the sandbox handles associations. (In reply to Aaron Rainbolt from comment #4) > Both Flatpak and Snap allow a sandboxed > application to say "open this file with whatever its default file handler > is", which will either launch an app in a different sandbox, or launch an > unsandboxed app. That is the issue. Flatpak and Snap are not true sandbox if they let the app run code outside of the sandbox. If you want your sandboxed app to not be allowed to run executable files outside of the sandbox, then use a sandbox that doesn't allow that. Regards. -- 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.

May 19, 2026

[Bug 59770] New: Broken Input under Neko Project 21/W (Gentoo Linux)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59770 Bug ID: 59770 Summary: Broken Input under Neko Project 21/W (Gentoo Linux) Product: Wine Version: 11.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: enkiferreiracosta867(a)gmail.com Distribution: --- After the update to Wine version 11.9 (from 11.8), I noticed that, when playing Touhou on the Neko Project 21/W emulator, the input seems to be broken when attempting to move around. The game has a "slowdown" feature, where holding the Shift key makes the character you're playing as move slowly while you're moving it, but what happens here is that it feels like this key is kept being held down even if I'm not even touching it, despite me being able to type normally under the initial DOS command prompt. I then tried updating Wine to version 9999 (the live ebuild, updated on the latest commit), but no difference whatsoever. I've then tested the emulator on my Windows partition, and no issues were found there, so it can only be a Wine issue. -- 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.

May 19, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #4 from Aaron Rainbolt <arraybolt3(a)gmail.com> --- > I don't mean Wine but whatever app (desktop environment?) is installed in the > sandbox. If you don't want it to be able to automatically execute programs > outside the of sandbox that mechanism should be disabled. There may be other > launchers (emulators) that could be used in the same way. I think we may be having a misunderstanding about how Linux app sandboxing mechanisms work. Both Flatpak and Snap assume that opening a file and executing a file are two different things. This assumption is warranted, because the mechanism that handles file associations under Linux (xdg-mime) explicitly documents that opening and executing are two different things and that file openers should never blindly execute code. Both Flatpak and Snap allow a sandboxed application to say "open this file with whatever its default file handler is", which will either launch an app in a different sandbox, or launch an unsandboxed app. xdg-desktop-portal-gtk then finds a file handler for the file its been given, and runs it, pointing it at the file. In the context of Wine, that file handler happens to execute arbitrary code. There isn't anything in the pipeline that knows it's about to execute code, except for Wine. That's why I suggested adding a prompt to Wine itself. There isn't any such thing as "disabling" this. One would have to either disable access to xdg-desktop-portal-gtk entirely (which is impossible with the current design of Flatpak from what I understand and would severely break applications if it was done in general), or they would have to remove the Wine EXE file association from the system entirely. There isn't any way to say "ignore this particular file association because it executes code". Even if there was a way to ignore a specific file association, it would be unreasonable to make sandbox designers use it, since that would require maintaining a blacklist of known-unsafe file handlers, and there's no good way to find every application that registers an unsafe handler. According to the docs, unsafe handlers shouldn't exist at all. > This is the responsibility of the process that invokes Wine (or any other app > that executes a file). Only if the process that executes a file knows that it is going to execute a file. -- 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.

May 19, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #3 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Aaron Rainbolt from comment #2) > Disabling registration when installed in a sandbox doesn't help / isn't > possible. In this scenario, Wine is installed unsandboxed on the host (which > is the typical way one gets Wine if installing it from the winehq repos). I don't mean Wine but whatever app (desktop environment?) is installed in the sandbox. If you don't want it to be able to automatically execute programs outside the of sandbox that mechanism should be disabled. There may be other launchers (emulators) that could be used in the same way. > Maybe instead of removing the handler, a prompt could be put in place so that > users have to say "yes, I really do want to execute this" before code execution > begins? This is the responsibility of the process that invokes Wine (or any other app that executes a file). -- 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.

May 19, 2026

[Bug 59747] Total War: Shogun 2 crashes during HLSL preprocessing

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59747 Andrey Gusev <andrey.goosev(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |bcd4f45431005760ca2635843eb | |38841da50dda8 Status|NEW |RESOLVED --- Comment #8 from Andrey Gusev <andrey.goosev(a)gmail.com> --- Marking fixed. -- 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.

May 19, 2026

[Bug 59767] loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59767 --- Comment #2 from Aaron Rainbolt <arraybolt3(a)gmail.com> --- Disabling registration when installed in a sandbox doesn't help / isn't possible. In this scenario, Wine is installed unsandboxed on the host (which is the typical way one gets Wine if installing it from the winehq repos). The handler is registered on the host, and the handler is detected and triggered by an unsandboxed process (xdg-desktop-portal-gtk), so the handler would have to be unregistered on the host, something a sandboxed process obviously cannot do if everything is working right. Maybe instead of removing the handler, a prompt could be put in place so that users have to say "yes, I really do want to execute this" before code execution begins? -- 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.

May 19, 2026

[Bug 52959] Some games are rendered in square instead fullscreen

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=52959 Stian Low <wineryyyyy(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy(a)gmail.com --- Comment #21 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 80977 --> http://bugs.winehq.org/attachment.cgi?id=80977 Screenshots confirming bug for wine-11.8 for wayland with DPI 96 vs 256 comparisons Attached are screenshots confirming for wayland for wine-11.9-0c0d2643208. X11 seems to properly handle default fullscreen for all these games tested: Commandos: Behind Enemy Lines Cave Story (Doukutsu.exe) Plants vs Zombies Empire Earth: Gold (same bug but not in screenshot) Screenshots show comparisons of DPI 96 vs 256 based on tests for related bug: https://bugs.winehq.org/show_bug.cgi?id=59078#c13 DPI changes do not seem advised as fixes for these fullscreen/resolution bugs but should be considered for compatibility by bug fixes. Alt+Tab issues vary widely but worst case seems Empire Earth which malfunctions the same for both X11 and Wayland: https://bugs.winehq.org/show_bug.cgi?id=58308 MangoHUD reveals Empire Earth pauses rendering after window refocused via Alt+Tab and makes rendering updates thereafter only for mouse moves which causes the cursors trail bugs reported. -- 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.

May 19, 2026

[Bug 59078] 8 low-res old GOG-Games don't work being extremely scaled (i.e. blurred) and show less than 1/4 part of normal screen output - thus options menu not reachable

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59078 --- Comment #14 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Stian Low from comment #13) > Wayland seems to render many games shrunk at top-left corner of fullscreen > surrounded by blackscreen related to: > https://bugs.winehq.org/show_bug.cgi?id=59078 Typo: https://bugs.winehq.org/show_bug.cgi?id=52959 -- 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.

May 19, 2026

[Bug 59078] 8 low-res old GOG-Games don't work being extremely scaled (i.e. blurred) and show less than 1/4 part of normal screen output - thus options menu not reachable

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59078 --- Comment #13 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 80976 --> http://bugs.winehq.org/attachment.cgi?id=80976 Commandos screenshot with zoomed graphics on wayland for 256 DPI (not zoomed for x11 despite 256 DPI for some reason) Attached is a screenshot for wayland for "Commandos: Behind Enemy Lines" with zoom similar to "Nine Parchments" screenshot by reporter. My previous screenshots were all X11 which seems to behave different than wayland and seems to better handle fullscreen and resolutions for games. Wayland seems to render many games shrunk at top-left corner of fullscreen surrounded by blackscreen related to: https://bugs.winehq.org/show_bug.cgi?id=59078 I'll continue to test all games from both of these bugs for both wayland and x11 because behavior varies widely with a lot of inconsistency that needs to be sorted out to understand the bugs and fixes. DPI changes may not be advised for fixing fullscreen/resolution issues for games. Instead the fullscreen/resolutions need to be fixed without requiring DPI changes as workarounds. Its unclear how DPI should be handled for games even with fullscreen/resolution bugs fixed for default DPI. Even winecfg DPI changes produced inconsistencies so there may bugs that need to be fixed there. -- 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.

May 19, 2026

[Bug 55868] Horizontal tab character (ASCII 0x09) not rendered in text fields

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=55868 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #76819|0 |1 is obsolete| | --- Comment #13 from Bernhard Übelacker <bernhardu(a)mailbox.org> --- Created attachment 80975 --> http://bugs.winehq.org/attachment.cgi?id=80975 0001-user32-comctl32-gdi32-Improve-rendering-of-tab-chara.patch Still visible with wine-11.9, rebased patch. Simple steps to reproduce: echo -e "y\x9y\x9y\x9y" > test.txt wine notepad test.txt # ctrl+a to select all # ctrl+c to copy # ctrl+f to open search dialog # ctrl+v to pase, this shows no space between the 'y' characters -- 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.

May 19, 2026

[Bug 59766] PaintTool SAI 2: NtSetInformationFile FileRenameInformation in place move does not work correctly

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59766 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu(a)mailbox.org --- Comment #2 from Bernhard Übelacker <bernhardu(a)mailbox.org> --- Currently we receive the error because FileName is not starting with a backslash. (rr) stepi 3742 if (!name_len || name[0] != '\\') return STATUS_OBJECT_PATH_SYNTAX_BAD; 4: x/i $pc => 0xf7bc596a <nt_to_unix_file_name_no_root+1740>: mov $0xc000003b,%esi (rr) bt #0 nt_to_unix_file_name_no_root at dlls/ntdll/unix/file.c:3742 #1 nt_to_unix_file_name dlls/ntdll/unix/file.c:3853 #2 get_nt_and_unix_names dlls/ntdll/unix/file.c:4412 #3 NtSetInformationFile dlls/ntdll/unix/file.c:5443 #4 __wine_syscall_dispatcher from dlls/ntdll/ntdll.so ... (rr) x/hs name 0x63f6c0: u"2.0.0.h.dat" -- 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.

May 19, 2026

[Bug 59078] 8 low-res old GOG-Games don't work being extremely scaled (i.e. blurred) and show less than 1/4 part of normal screen output - thus options menu not reachable

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59078 --- Comment #12 from Stian Low <wineryyyyy(a)gmail.com> --- Created attachment 80974 --> http://bugs.winehq.org/attachment.cgi?id=80974 winecfg DPI 256 showing Nine Parchments without 1/4 zoom bug (but shows MANGOHUD "zoomed") I seem to have mistook the meaning of "1/4 part of normal screen output" as the same issues described by this bug: https://bugs.winehq.org/show_bug.cgi?id=52959 But bug 52959 describes the case of the entire game being rendered but shrunk to only fit to the top left 1/4 corner of the screen with the remaining 3/4 surrounding area rendered black (typically). However based on reporter screenshot of Nine Parchments it seems that the game is not being shrunk to 1/4 but rather zoomed to only display the top left 1/4 corner of the game which fills the entire screen (and not just 1/4 of the screen). Attached are screenshots of Nine Parchments running with 256 DPI set which shows MangoHUD applied 256 DPI but the game still rendered correctly without zooming the top left 1/4 corner of the game. My original tests used default 96 DPI. DPI increases the size of winecfg window as if zoomed as shown in screenshot but seems not to affect game rendering graphics in the same way so unable to reproduce for a regular laptop display. Does changing DPI back to default 96 fix the 1/4 zoom? Is game zoomed more when DPI is set greater than 256? Suggestion that in-game display settings may still provide a fix, otherwise as stated before it may be more related to the 4k screen with DPI factor 256 which I'm unable to test for now. -- 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.

May 19, 2026

[Bug 59769] Wine 11.9 FTBFS on Linux aarch64 with Clang: error: call to undeclared library function '_ReadWriteBarrier' with type 'void (void)';

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59769 Kaiyang Wu <origincode(a)aosc.io> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |origincode(a)aosc.io -- 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.

May 19, 2026