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

[Bug 59738] New: GetFinalPathNameByHandleW returns unresolved symbolic link path instead of final resolved path
by WineHQ Bugzilla May 15, 2026

May 15, 2026

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.

1 16

[Bug 59733] New: CJK font fallback prioritizes deprecated SimSun over modern UI fonts
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59733 Bug ID: 59733 Summary: CJK font fallback prioritizes deprecated SimSun over modern UI fonts Product: Wine Version: 11.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: fonts Assignee: wine-bugs(a)list.winehq.org Reporter: wszqkzqk(a)qq.com Distribution: --- When running Wine with Chinese (zh-CN) locale, CJK characters in system UI fonts (Tahoma, Microsoft Sans Serif, Lucida Sans Unicode, Segoe UI) fall back to SimSun first if it is installed. SimSun is a deprecated UI font from Windows XP era that provides poor visual quality compared to modern alternatives. This is inconsistent with Windows Vista+ behavior, where: - Segoe UI (default system font since Vista) has its own SystemLink chain - Modern CJK UI fonts (YaHei UI, JhengHei UI, Yu Gothic UI, Malgun Gothic) are prioritized over legacy fonts -- 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 59752] New: PROFILE_Save does not separate sections with empty line, leading to Ressource Hacker saving different ini file on 1st and 2nd run
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59752 Bug ID: 59752 Summary: PROFILE_Save does not separate sections with empty line, leading to Ressource Hacker saving different ini file on 1st and 2nd run Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)list.winehq.org Reporter: kyle.kcsoftwares(a)gmail.com Distribution: --- Resource Hacker 4.7.34 : https://web.archive.org/web/20180426130124if_/http://www.angusj.com/resourc… On first run, .ini file is created in the following format [Section1] Name1=Val1 Name2=Val2 Name3=Val3 [Section2] Name4=Val4 Name5=Val5 Name6=Val6 After second run, .ini file is rewritten in the folowing format [Section1] Name1=Val1 Name2=Val2 Name3=Val3 [Section2] Name4=Val4 Name5=Val5 Name6=Val6 In Windows, it is written as 2nd run from the initial start. Analysis performed here with API Monitor https://jira.reactos.org/browse/CORE-15438?focusedId=147696&page=com.atlass… show that " When Resource Hacker closes: - It checks for the ResourceHacker.ini file - If it is not present, it writes the initial contents using WriteFile (the text before the [MRU List] section - 277 bytes). The buffer of the application contains the double newlines as section separator. The handle is closed and the file is persistent on disk. - It calls WritePrivateProfileStringW for each MRU (1 to 8) - so 8 times - If the section [MRU List] is present, each MRU* entries are updated according (second time and further runs) - If the section [MRU List] is not present (like the first time you close the program), the section is created and the entire .ini file is rebuilt by the PROFILE_Save logic. The profile saving routine puts single new lines as section separator. - If it is present, it will read the memory the content, updates via WritePrivateProfileStringW and resave the content (those 347 bytes) " The guilty code is in kernel32/section.c PROFILE_Save which misses the additional CRLF between sections https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/kernel32/profile.c#L… -- 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 59751] New: WizTree 4.30: Dropdown menu fails to redraw hovered items with active visual style
by WineHQ Bugzilla May 15, 2026

May 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59751 Bug ID: 59751 Summary: WizTree 4.30: Dropdown menu fails to redraw hovered items with active visual style Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: kyle.kcsoftwares(a)gmail.com Distribution: --- Created attachment 80933 --> http://bugs.winehq.org/attachment.cgi?id=80933 Dropdown menu screenshot https://diskanalyzer.com/files/archive/wiztree_4_30_setup.exe WizTree 4.30 download link Dropdown menu fails to redraw hovered items with active visual style of WizTree -- 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 50182] New: Hotline Miami 2 GOG version not launch after install.
by WineHQ Bugzilla May 14, 2026

May 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=50182 Bug ID: 50182 Summary: Hotline Miami 2 GOG version not launch after install. Product: Wine Version: 5.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: pamungkassendy(a)gmail.com Distribution: --- Created attachment 68700 --> https://bugs.winehq.org/attachment.cgi?id=68700 Hotline Miami 2 GOG Version Game Didn't launch and instead give a crasth report -- 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 3

[Bug 59750] New: Game with midi audio will play incorrectly. (test with Poppo)
by WineHQ Bugzilla May 14, 2026

May 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59750 Bug ID: 59750 Summary: Game with midi audio will play incorrectly. (test with Poppo) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: l12436.tw(a)gmail.com Distribution: --- In some game, the BGM will play incorrect in wine, but it play normally in windows -- 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 42898] New: Listbox keyboard input
by wine-bugs＠winehq.org May 14, 2026

May 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=42898 Bug ID: 42898 Summary: Listbox keyboard input Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: janwinehq(a)gmail.com Distribution: --- A listbox widget in Wine does not react the same way to keyboard input as in Windows. In Windows, you can type the first characters of a word and the cursor will jump to the first item matching *all* the characters you typed. This allows you to drill down quickly to the item you want. In Wine, when you start typing it only considers the *last* character you typed when looking for a match. On listboxes where you have lots of items starting with the same character, this can make it problematic to drill down to the correct item. This may be better explained with a simple example. Suppose you have a listbox with the following items, sorted alphabetically: * AMBER * BLUE * BROWN * GREEN * ORANGE * RED * YELLOW Windows behavior: * if you type "B", it will drill down to "BLUE" * if you type "BR", it will drill down to "BROWN" * if you type "BRO", it will drill down to "BROWN" Wine behavior: * if you type "B", it will drill down to "BLUE" * if you type "BR", it will drill down to "RED" * if you type "BRO", it will drill down to "ORANGE" -- 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 11

[Bug 23077] New: UltraEdit 16.10: Plus sign doesn't appear in directory tree
by wine-bugs＠winehq.org May 14, 2026

May 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=23077 Summary: UltraEdit 16.10: Plus sign doesn't appear in directory tree Product: Wine Version: 1.2-rc2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: lukasz.wojnilowicz(a)gmail.com Created an attachment (id=28652) --> (http://bugs.winehq.org/attachment.cgi?id=28652) Image showing the problem Steps to reproduce: 1) remove ~/.wine 2) install UltraEdit 3) wine Uedit32.exe 4) close all popup windows (buy now, tip of the day etc.) 5) In "File View" Window click on plus sign of "C" then "Program Files" 6) Click on plus sign of "Internet Explorer" branch will unfold, plus sign changes to minus sign 7) Click on minus sign of "Internet Explorer" branch will fold Behaviour: After seventh step minus sign of "Internet Explorer" stays minus sign and I cannot unfold that branch anymore Expected behaviour: After seventh step minus sign of "Internet Explorer" should convert itself into plus sign and I should have ability to unfold the branch In terminal I get only fixme:win:LockWindowUpdate (0x100a0), partial stub! fixme:win:LockWindowUpdate ((nil)), partial stub! for every successful fold/unfold operation -- 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 14

[Bug 58149] New: HWiNFO 8.24: mouse-hover tooltips disappear almost instantly
by WineHQ Bugzilla May 14, 2026

May 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=58149 Bug ID: 58149 Summary: HWiNFO 8.24: mouse-hover tooltips disappear almost instantly Product: Wine Version: 10.6 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: cemer99797(a)isorax.com In the settings window of HWiNFO 8.24, the hover tooltips that give more info about the option on mouse-over disappear almost instantly. Steps to reproduce: launch HWiNFO64.exe, in the intro window click on Settings, hover the mouse over a setting (tooltip works correctly and doesn't disappear at first), then hover the mouse over another setting. Now the tooltip will always disappear almost intantly download link: https://sourceforge.net/projects/hwinfo/files/Windows_Portable/hwi_824.zip/… sha256: 74c71b6a8a3498f5a5254b4e692345c45ec5cf88246bf3516cd7c35faf516ca4 I'm using Gcenx's wine-devel 10.6 build (https://github.com/Gcenx/macOS_Wine_builds/releases/tag/10.6) on macOS 11 -- 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 3

[Bug 42308] New: LTspice XVII: some checkboxes not shown or being overlapped by labels
by wine-bugs＠winehq.org May 14, 2026

May 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=42308 Bug ID: 42308 Summary: LTspice XVII: some checkboxes not shown or being overlapped by labels Product: Wine Version: 2.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: Rakusan2(a)gmail.com Distribution: --- Created attachment 57042 --> https://bugs.winehq.org/attachment.cgi?id=57042 Missing checkboxes and their labels bellow the textboxes In LTspice XVII when opening "Edit Simulation cmd" the checkboxes and their labels are not shown. After switching tabs the labels appear but some slightly overlap their checkbox This problem does not occur in native windows -- 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 11