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

[Bug 59739] Ability to set theme for all prefixes easily

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59739 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan(a)codeweavers.com --- Comment #2 from Stefan Dösinger <stefan(a)codeweavers.com> --- My 2c is that we don't want to soften the separation between prefixes. Wine Mono, Wine Gecko, etc are static data. The current theme selection is not. The best solution to easily changeable themes would be a default theme that manages to follow the system gtk/qt/macos theme, but as you observed, it isn't easy to do. I tried to go a little step into this direction by cleaning up the color management in light.msstyles, but Windows theming is awful (MR 7590). -- 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 10, 2026

[Bug 59738] GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59738 --- Comment #7 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to BugSeeker from comment #6) > Yes — in that situation invisible Unix symlinks are useful, but I still > don’t think that should alter how GetFinalPathNameByHandleW behaves: callers > use it precisely to get a fully resolved path, and that expectation should > be honoured. Windows apps don't expect that because they have no notion of Unix symlinks. Humans may expect that but resolving to a Unix symlink means fully resolved from the perspective of the Windows app. Also note that if you treat Unix symlinks as a type of Windows symlinks then it needs to be done consistently, not only in GetFinalPathNameByHandleW(). -- 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 10, 2026

[Bug 59734] Can't login anymore to battle.net after upgraded nettle from 3.10.2 to 4.0

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59734 --- Comment #3 from Hans Leidekker <hans(a)meelstraat.net> --- This looks like a bug in nettle. Applications should not be able to trigger assertions in a library. -- 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 10, 2026

[Bug 59738] GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59738 --- Comment #6 from BugSeeker <rikul(a)inbox.ru> --- Yes — in that situation invisible Unix symlinks are useful, but I still don’t think that should alter how GetFinalPathNameByHandleW behaves: callers use it precisely to get a fully resolved path, and that expectation should be honoured. -- 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 10, 2026

[Bug 59738] GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59738 --- Comment #5 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to BugSeeker from comment #4) > I understand the distinction you’re making. > Even so, I don’t think ignoring Unix symlinks here is the right trade-off: > on Linux, the actual filesystem people run Wine against is dominated by Unix > symlinks, not whatever Wine maps as Windows symlinks. > Callers of GetFinalPathNameByHandleW therefore reasonably expect full > resolution of the path that produced the handle — including those Unix > symlinks — so the result matches Windows-style “final path” semantics. Invisible Unix symlinks can be a useful feature. It means you can use them where Windows apps don't expect symlinks. -- 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 10, 2026

[Bug 59738] GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59738 --- Comment #4 from BugSeeker <rikul(a)inbox.ru> --- I understand the distinction you’re making. Even so, I don’t think ignoring Unix symlinks here is the right trade-off: on Linux, the actual filesystem people run Wine against is dominated by Unix symlinks, not whatever Wine maps as Windows symlinks. Callers of GetFinalPathNameByHandleW therefore reasonably expect full resolution of the path that produced the handle — including those Unix symlinks — so the result matches Windows-style “final path” semantics. -- 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 10, 2026

[Bug 59738] GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59738 --- Comment #3 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to BugSeeker from comment #2) > So this is not about Unix symlink semantics per se, but about matching > Windows API behavior, which Wine aims to emulate. Wine emulates Windows symlinks but not with Unix symlinks. -- 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 10, 2026

[Bug 59718] d2d1: Three correctness issues in arc Bezier-approximation code (d2d_arc_to_bezier, d2d_figure_add_arc, d2d_arc_transform)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59718 --- Comment #6 from Giang Nguyen <nen24t(a)gmail.com> --- Thanks! Also cherry-picked into giang17/wine#d2d1-dcomp-11.0 for fork users on Wine 11.0 base. Verified with Trinity + Serum 2. -- 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 10, 2026

[Bug 59738] GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59738 --- Comment #2 from BugSeeker <rikul(a)inbox.ru> --- I understand that Unix symlinks themselves are not guaranteed to exist on Windows, and applications cannot generally rely on Unix-specific filesystem behavior. However, the issue here is about GetFinalPathNameByHandleW() behavior on Wine versus Windows. On native Windows, when opening a file via a symbolic link, GetFinalPathNameByHandleW() returns the fully resolved final path — i.e., the target of the symlink — not the original path containing the link. I have verified this on Windows, and the results confirm that the path returned points to the target, not the symlink itself. This is what applications like std::filesystem::weakly_canonical rely on: the resolved, canonical path of the file handle. So this is not about Unix symlink semantics per se, but about matching Windows API behavior, which Wine aims to emulate. Windows test result: ------------------- mklink C:\workarea\link.txt C:\workarea\real.txt symlink_test.exe c:\workarea\link.txt Input path: c:\workarea\link.txt GetFinalPathNameByHandleW result: \\?\C:\workarea\real.txt std::filesystem::weakly_canonical result: C:\workarea\real.txt -- 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 10, 2026

[Bug 59740] New: Programs running under Wayland do not notice when they lose focus

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59740 Bug ID: 59740 Summary: Programs running under Wayland do not notice when they lose focus Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: winewayland Assignee: wine-bugs(a)list.winehq.org Reporter: winezilla(a)xobs.io Distribution: --- When running under X11, programs can use `GetForegroundWindow()` to detect if they have focus or not. This gets updated as part of `X11DRV_FocusIn()` and `focus_out()` (which is called by `X11DRV_FocusOut()`. The X11 code works by setting the foreground window to the desktop when this happens: /* Abey : 6-Oct-99. Check again if the focus out window is the Foreground window, because in most cases the messages sent above must have already changed the foreground window, in which case we don't have to change the foreground window to 0 */ if (hwnd == NtUserGetForegroundWindow()) { TRACE( "lost focus, setting fg to desktop\n" ); NtUserSetForegroundWindowInternal( NtUserGetDesktopWindow() ); } The Wayland driver has no such check, and as a result programs don't notice they are not the foreground window any more. Instead, the function `keyboard_handle_leave()` has this comment: /* FIXME: update foreground window as well */ -- 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 10, 2026

[Bug 45364] Frostpunk is very dark

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=45364 --- Comment #21 from Stian Low <wineryyyyy(a)gmail.com> --- Foundation Galactic Frontier is yet another Unity game found to produce dark graphics for win10 and fixed via `winecfg -v wine8`: https://bugs.winehq.org/show_bug.cgi?id=59248 Latest patch also fixes vulkan rendering too darker for win10. -- 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 9, 2026

[Bug 56100] Greenshot: Error when adding a textbox

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=56100 Rose Hellsing <rose(a)pinkro.se> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rose(a)pinkro.se --- Comment #2 from Rose Hellsing <rose(a)pinkro.se> --- This is an issue with Mono/mscoree not properly cloning the FontFamily object. The component keyword of the bug should properly be adjusted properly. A MR to fix this has been submitted https://gitlab.winehq.org/mono/mono/-/merge_requests/211 -- 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 9, 2026

[Bug 59739] Ability to set theme for all prefixes easily

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #1 from fatihbakal7(a)protonmail.com --- Edit: found duplicate of this issue https://bugs.winehq.org/show_bug.cgi?id=48506 somebody please let me know on the last part I might look into it if there's interest from upstream people just like the other PR -- 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 9, 2026

[Bug 59738] GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59738 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #1 from Zeb Figura <z.figura12(a)gmail.com> --- What exactly depends on this? Windows applications can't depend on Unix symlinks being resolved... -- 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 9, 2026

[Bug 59739] New: Ability to set theme for all prefixes easily

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59739 Bug ID: 59739 Summary: Ability to set theme for all prefixes easily Product: Wine Version: 11.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: uxtheme Assignee: wine-bugs(a)list.winehq.org Reporter: fatihbakal7(a)protonmail.com Distribution: --- Disclaimer: I know there are already similar issues to this. This one is just a proposal for a global setting tho so I thought it deserves it's own issue. It's just way too much of a hassle to set a theme up to each prefix. Currently there's 3 ways of theming wine that I'm aware of. 1. .reg files 2. .msstyle/.theme files 3. That 1 experimental GTK3 theming patch that's been in staging for ages (broken on most installs) My proposal is that every single prefix uses the same directory to check for `theme.reg/.msstyle/.theme` files in one of these directories; `~/.config/wine` `~/.local/share/wine/` `$HOME/` (would have to be named wine_theme for this to not be confusing) Also does anybody know a way I can contact upstream people quickly? I did think of opening a PR for this but thought I would end up not getting a response like this https://gitlab.winehq.org/wine/wine/-/merge_requests/10543 -- 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 9, 2026

[Bug 59736] Turbo Virtual Machine (turbo.net) crashes with NULL pointer dereference in ntdll path handling

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59736 --- Comment #2 from ugursarp2001(a)gmail.com --- (In reply to Rafał Mużyło from comment #1) > A question: just how much is your prefix messed up...I mean 'tweaked' with > randomly picked native libraries ? > > Given that RtlIsThreadWithinLoaderCallout is a stub, nothing in wine tree > uses it. > > > RELATED BUG: #29244 (Spoon Studio, same underlying technology, open since 2011) > > Closed since December 2013 as a duplicate of a bug that has been fixed in > August2015. ....? The prefix is mostly stock. The only modifications made during troubleshooting: - uxtheme.dll and cryptbase.dll copied to the application directory (not system32) - winetricks dotnet48 was installed in a separate test prefix only - Application was also tested with a completely fresh prefix with identical results Regarding the related bugs: we checked both #29244 and #30399. Comment 11 in #29244 notes that Xenocode wrapped apps require both bugs to be fixed. Both appear to be fixed since Wine 1.7.50, yet the application still fails on Wine 11.8. This suggests the problem domain has moved further, possibly related to the NtWaitForXxx implementation mentioned in #30399 comment 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.

May 9, 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 #3 from sil <ssantos(a)web.de> --- Update: it still does not react on a mouse-click for the very first decision to save the crew or to retrieve the load. Tested on FGF version 1.0.1.1180 on wine 10.0. -- 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 9, 2026

[Bug 59738] GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59738 BugSeeker <rikul(a)inbox.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|inkobj |-unknown -- 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 9, 2026

[Bug 59738] GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59738 BugSeeker <rikul(a)inbox.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |af35741d3681f21222a85900b54 | |d95ee422fe074 Component|-unknown |inkobj -- 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 9, 2026

[Bug 59738] GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59738 BugSeeker <rikul(a)inbox.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |l(a)laa.am -- 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 9, 2026

[Bug 59738] New: GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59738 Bug ID: 59738 Summary: GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path 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: rikul(a)inbox.ru Distribution: --- Created attachment 80903 --> http://bugs.winehq.org/attachment.cgi?id=80903 The archive contains a minimal reproducer and a prebuilt executable demonstrating the issue. According to Microsoft documentation, GetFinalPathNameByHandleW() is expected to return the fully resolved final path for the object referenced by the handle. The documentation explicitly states: “A final path is the path that is returned when a path is fully resolved. For example, for a symbolic link named C:\tmp\mydir that points to D:\yourdir, the final path would be D:\yourdir.” Wine currently returns the original unresolved path containing the symbolic link component instead of the resolved target path. This differs from native Windows behavior and breaks applications relying on canonical filesystem paths. The issue also affects std::filesystem::weakly_canonical, which internally depends on GetFinalPathNameByHandleW. Steps to reproduce ------------------ Create a symbolic link: 1. touch /tmp/real.txt 2. ln -s /tmp/real.txt /tmp/link.txt 3. wine symlink_test.exe /tmp/link.txt. The program opens link.txt and calls GetFinalPathNameByHandleW() on the handle. Expected behavior ------------------ Input path: /tmp/link.txt GetFinalPathNameByHandleW result: \\?\Z:\tmp\real.txt std::filesystem::weakly_canonical result: Z:\tmp\real.txt The returned path is fully resolved and does not contain the symbolic link component. Actual behavior --------------- Input path: /tmp/link.txt GetFinalPathNameByHandleW result: \\?\Z:\tmp\link.txt std::filesystem::weakly_canonical result: Z:\tmp\link.txt Wine returns the unresolved original path used to open the handle. Regression information ---------------------- A git bisect identifies the following commit as the first bad commit: https://gitlab.winehq.org/wine/wine/-/commit/af35741d3681f21222a85900b54d95… Before this commit, GetFinalPathNameByHandleW() returned the resolved canonical path correctly. Tested on Wine 11.0 -- 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 9, 2026

[Bug 59726] Syscall emulation on Linux using Syscall User Dispatch broken with glibc 2.34

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59726 --- Comment #8 from Zeb Figura <z.figura12(a)gmail.com> --- It won't run for me even after disabling syscall emulation. I get the error mentioned in comment 2. -- 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 9, 2026

[Bug 59726] Syscall emulation on Linux using Syscall User Dispatch broken with glibc 2.34

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59726 --- Comment #7 from valy(a)etersoft.ru <valy(a)etersoft.ru> --- (In reply to Zeb Figura from comment #5) > How exactly did you get visual studio to run? Did you use external patches > or winetricks verbs? What helped me was adding an additional condition check in the libc_addr_cb function (dlls/ntdll/unix/signal_x86_64.c): if (strcmp(p, "libc.so.6") && strcmp(p, "libpthread.so.0")) return 0; I also found that setting static LONG syscall_dispatch_enabled = false; was helpful. -- 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 9, 2026

[Bug 56966] firefox 128 needs unimplemented function twinapi.appcore.BiChangeUserState

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=56966 --- Comment #2 from Fabian Maurer <dark.shadow4(a)web.de> --- I still got crashes from time to time, but not sure if that's because of this function or something else - it doesn't seem to appear in the log anymore. I'd try against wine-9.12, but I can't get that to work anymore. -- 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 9, 2026

[Bug 45364] Frostpunk is very dark

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=45364 --- Comment #20 from Stian Low <wineryyyyy(a)gmail.com> --- Test results for other games reported with similar bugs addressed by patch: https://bugs.winehq.org/show_bug.cgi?id=57916#c18 -- 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 9, 2026