November 2025 - Wine-Bugs - list.winehq.org

[Bug 58764] New: Missing pages tree in .chm HTML help viewer
by WineHQ Bugzilla Nov. 11, 2025

Nov. 11, 2025

http://bugs.winehq.org/show_bug.cgi?id=58764 Bug ID: 58764 Summary: Missing pages tree in .chm HTML help viewer Product: Wine Version: unspecified Hardware: x86-64 OS: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tomislav.budor(a)lovatoelectric.hr Created attachment 79405 --> http://bugs.winehq.org/attachment.cgi?id=79405 screenshot of .chm helper Missing pages tree in .chm HTML help viewer i ReactOS. -- 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 47154] New: Rise of the Tomb Raider crashes after 1st bink video
by wine-bugs＠winehq.org Nov. 11, 2025

Nov. 11, 2025

https://bugs.winehq.org/show_bug.cgi?id=47154 Bug ID: 47154 Summary: Rise of the Tomb Raider crashes after 1st bink video Product: vkd3d Version: 1.1 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: vkd3d Assignee: wine-bugs(a)winehq.org Reporter: berillions(a)gmail.com Distribution: --- Created attachment 64383 --> https://bugs.winehq.org/attachment.cgi?id=64383 Rise of the Tomb Raider d3d12 log Hello, I'm on Gentoo + AMD Rx580 + Mesa Git + LLVM git (9.0.0) + Vkd3d Git and i decided to try the only d3d12 game i have : Rise of the Tomb Raider. The game runs but crash after the 1st bink video when the main menu must be appear. The game runs on wined3d/d3d11 but it's unplayable, works (of course with DXVK) and with the Native version. I attach the +d3d12 log. Josef, i you need something else to help you, don't hesitate. -- 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 9

[Bug 58314] New: GetGlyphOutlineW returns a negative number sometimes
by WineHQ Bugzilla Nov. 11, 2025

Nov. 11, 2025

http://bugs.winehq.org/show_bug.cgi?id=58314 Bug ID: 58314 Summary: GetGlyphOutlineW returns a negative number sometimes Product: Wine Version: 10.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: skyfloogle(a)protonmail.com Distribution: --- Created attachment 78672 --> http://bugs.winehq.org/attachment.cgi?id=78672 Source code for a repro, an exe build, Windows and Wine sample logs, and the necessary font. In an application I'm developing, I've found that GetGlyphOutlineW returns a negative number under specific circumstances in Wine. According to the documentation, it should return a positive number, with the exception of GDI_ERROR (-1). My program therefore treats the return value as unsigned (as specified in the documentation) and checks against -1, which doesn't work when it returns -32 instead. It's not clear to me why this value is being returned, but I've only seen it reproduce with a specific character (¯) in a specific font. I've put together a minimal reproducing sample. The issue reproduces on both 32 and 64 bit, and does not reproduce on Windows. Source code and a copy of the necessary font (https://ggbot.itch.io/raster-forge-font) are attached, as are expected and actual logs. In this sample, -8 is returned instead of -32, but I suspect the root cause is similar - it shouldn't be returning anything lower than -1 in either case. For what it's worth, I'm running on EndeavourOS, which hasn't received 10.9 yet at the time of writing, but I've checked the commit logs for gdi32 and haven't seen anything that looks relevant. -- 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 58938] New: Japanese vertical text is printed slightly higher when using SetMapMode with MM_LOMETRIC
by WineHQ Bugzilla Nov. 11, 2025

Nov. 11, 2025

http://bugs.winehq.org/show_bug.cgi?id=58938 Bug ID: 58938 Summary: Japanese vertical text is printed slightly higher when using SetMapMode with MM_LOMETRIC Product: Wine Version: 10.18 Hardware: aarch64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineps.drv Assignee: wine-bugs(a)list.winehq.org Reporter: ssnffb30(a)gmail.com Created attachment 79633 --> http://bugs.winehq.org/attachment.cgi?id=79633 A simple test tool(contains source code + compiled EXE) This is a simple test tool that prints "あいうえお、かきくけこ" vertically and "Hello World!" horizontally. The horizontal text is printed in the correct position, while the vertical text is shifted upward when MapMode is set to MM_LOMETRIC. The issue does not appear when using MM_TEXT (with setting lfEscapement=2700). * Steps to Reproduce: 1. Run winetricks fakejapanese_ipamona 2. Launch the provided test tool vertical-print-test.exe 3. Press the Print button(You can print to a virtual printer for convenience) This issue is expected to occur on Linux as well. For macOS users: note that PostScript printing is no longer supported on macOS Sonoma or later. Use Ventura/Monterey if testing on macOS. -- 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 53542] New: Hog4PC 3.17 installer VBScript custom action needs IWshShell::Run to return signed type.
by WineHQ Bugzilla Nov. 11, 2025

Nov. 11, 2025

https://bugs.winehq.org/show_bug.cgi?id=53542 Bug ID: 53542 Summary: Hog4PC 3.17 installer VBScript custom action needs IWshShell::Run to return signed type. Product: Wine Version: 7.11 Hardware: x86-64 URL: https://web.archive.org/web/20211128125004/https://cdn .etcconnect.com/Hog_4_PC_3.17.0.3327.msi.zip OS: Linux Status: NEW Keywords: download, Installer, patch Severity: normal Priority: P2 Component: wshom.ocx Assignee: wine-bugs(a)winehq.org Reporter: sloper42(a)yahoo.com CC: focht(a)gmx.net, sloper42(a)yahoo.com, temp82(a)luukku.com Depends on: 52128 Distribution: --- +++ This is successor to Bug #52128 +++ After applying scrrun::Movefolder patch, we get script error in msi custom action $WINEDEBUG=+vbscript ./wine msiexec -i C:\Hog_4_PC_3.17.0.3327.msi ... 01c4:trace:vbscript:do_icall L"unpack1" 0 01c4:trace:vbscript:interp_int 0 01c4:trace:vbscript:interp_equal 01c4:trace:vbscript:var_cmp 0017A75C {VT_UI4: 0} 00176FB8 {VT_I2: 0} 01c4:trace:vbscript:VBScriptError_GetExceptionInfo (0017AE58)->(03D0FB10) 01c4:err:msi:MsiActiveScriptSite_OnScriptError script error: L"Type mismatch" Excerpt from script file: ... Set objShell = CreateObject("Shell.Application") ... firstCmd = """" & TargetDir & "\7za.exe"" x -y " & """" & FixtureLib & """" & " -o""" & FixtureLibDir & """" unpack1 = shell.Run(firstCmd, 0, True) If ( unpack1 = 0 ) Then ... Return value of shell.Run is of type VT_UI4 which is no integrated type of vbscript. Output value of IWshShell::Run [out, retval] DWORD* out_ExitCode) seems to be int* in native and not DWORD* as in wine. -- 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 12

[Bug 4309] Directory-chooser GUI component is confused by directories named "..."
by WineHQ Bugzilla Nov. 11, 2025

Nov. 11, 2025

http://bugs.winehq.org/show_bug.cgi?id=4309 KRosUser <kyle.kcsoftwares(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle.kcsoftwares(a)gmail.com --- Comment #10 from KRosUser <kyle.kcsoftwares(a)gmail.com> --- Check https://gitlab.winehq.org/wine/wine/-/merge_requests/9414 -- 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 54670] New: 16-bit applications fail in wow64 mode
by WineHQ Bugzilla Nov. 11, 2025

Nov. 11, 2025

https://bugs.winehq.org/show_bug.cgi?id=54670 Bug ID: 54670 Summary: 16-bit applications fail in wow64 mode Product: Wine Version: 8.0 Hardware: x86-64 OS: Linux Status: NEW Keywords: download, Installer, wow64 Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Distribution: Debian $ wineserver -k ; rm -rf ~/.wine ; WINE=/opt/oldwownew/wine-8.0/bin/wine winetricks -q icodecs ------------------------------------------------------ Executing load_icodecs Executing cabextract -q -d /home/austin/.wine/dosdevices/c:/windows/temp/codinstl/ /home/austin/.cache/winetricks/icodecs/codinstl.exe Executing cd /home/austin/.wine/dosdevices/c:/windows/temp/codinstl/ Executing /opt/oldwownew/wine-8.0/bin/wine setup.exe /s 0284:err:environ:init_peb starting L"C:\\windows\\syswow64\\winevdm.exe" in experimental wow64 mode 0284:fixme:wow:wow64_NtSetLdtEntries 0107 02d0323f 0100f338 0000 00000000 00000000: stub 0284:err:module:LdrInitializeThunk "krnl386.exe16" failed to initialize, aborting 0284:err:module:LdrInitializeThunk Initializing dlls for L"C:\\windows\\syswow64\\winevdm.exe" failed, status c0000005 ------------------------------------------------------ -- 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 19

[Bug 58698] New: Application goes into an infinite loop under new wow64 but works okay under old wow64
by WineHQ Bugzilla Nov. 10, 2025

Nov. 10, 2025

http://bugs.winehq.org/show_bug.cgi?id=58698 Bug ID: 58698 Summary: Application goes into an infinite loop under new wow64 but works okay under old wow64 Product: Wine Version: 10.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: dkk089(a)gmail.com Distribution: --- Created attachment 79297 --> http://bugs.winehq.org/attachment.cgi?id=79297 WINEDEBUG=+virtual under "new wow64" Application goes into an infinite loop under new wow64 but works okay under old wow64 I have an application that enters an infinite loop under "new wow64" but works okay with "old wow64". Running under actual 64-bit Windows is okay too. The problem seems to be caused by application logic which calls VirtualAlloc() repeatedly in order to (presumably) find out the maximum available amount of memory that the application is able to allocate. The first hint that this might be somehow related to memory were the error messages reported when running under "old wow64" : 01a0:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x80010000, unix_prot 0 01a0:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 80000000 01a0:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x78010000, unix_prot 0 01a0:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 78000000 01a0:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x74010000, unix_prot 0 01a0:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 74000000 Running the application with WINEDEBUG=+virtual showed the NtAllocateVirtualMemory calls that are made by the application, starting with a size of 0x7fffffff, exploring a number of different sizes, and then eventually settling on 0x701f0000 : 01a0:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 7fffffff 2000 00000004 01a0:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x80010000, unix_prot 0 01a0:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 80000000 01a0:trace:virtual:NtFreeVirtualMemory 0xffffffff (nil) 00000000 8000 01a0:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 3fffffff 2000 00000004 01a0:trace:virtual:map_view got mem in reserved area 0x11050000-0x51050000 01a0:trace:virtual:dump_view View: 0x11050000 - 0x5104ffff (valloc) 01a0:trace:virtual:dump_view 0x11050000 - 0x5104ffff --rw- 01a0:trace:virtual:NtFreeVirtualMemory 0xffffffff 0x11050000 00000000 8000 -- snip : successful calls after that with sizes 0x5fffffff , 0x6fffffff -- 01a0:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 77ffffff 2000 00000004 01a0:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x78010000, unix_prot 0 01a0:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 78000000 01a0:trace:virtual:NtFreeVirtualMemory 0xffffffff (nil) 00000000 8000 -- snip : goes on to try sizes starting with 0x70 ... -- 01a0:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 701f0001 2000 00000004 01a0:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x70201000, unix_prot 0 01a0:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 701f1000 01a0:trace:virtual:NtFreeVirtualMemory 0xffffffff (nil) 00000000 8000 01a0:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 701f0000 2000 00000004 01a0:trace:virtual:map_view got mem with anon mmap 0x80000000-0xf01f0000 01a0:trace:virtual:dump_view View: 0x80000000 - 0xf01effff (valloc) 01a0:trace:virtual:dump_view 0x80000000 - 0xf01effff --rw- 01a0:trace:virtual:NtFreeVirtualMemory 0xffffffff (nil) 00000000 8000 The application makes the same calls under "new wow64", but since none of those calls ever fail, it seems to get confused, reaches size=0, and then gets stuck on that size : 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 7fffffff 2000 00000004 016c:trace:virtual:map_view got mem with map_free_area 0x7fff0000-0xffff0000 016c:trace:virtual:dump_view View: 0x7fff0000 - 0xfffeffff (valloc) 016c:trace:virtual:dump_view 0x7fff0000 - 0xfffeffff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x7fff0000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 3fffffff 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x11050000-0x51050000 016c:trace:virtual:dump_view View: 0x11050000 - 0x5104ffff (valloc) 016c:trace:virtual:dump_view 0x11050000 - 0x5104ffff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x11050000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 1fffffff 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x11050000-0x31050000 016c:trace:virtual:dump_view View: 0x11050000 - 0x3104ffff (valloc) 016c:trace:virtual:dump_view 0x11050000 - 0x3104ffff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x11050000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 0fffffff 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x11050000-0x21050000 016c:trace:virtual:dump_view View: 0x11050000 - 0x2104ffff (valloc) 016c:trace:virtual:dump_view 0x11050000 - 0x2104ffff --rw- -- snip : repeated calls with size right-shifted by 1 -- 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 0000000f 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x3750000-0x3751000 016c:trace:virtual:dump_view View: 0x3750000 - 0x3750fff (valloc) 016c:trace:virtual:dump_view 0x3750000 - 0x3750fff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x3750000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000007 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x3750000-0x3751000 016c:trace:virtual:dump_view View: 0x3750000 - 0x3750fff (valloc) 016c:trace:virtual:dump_view 0x3750000 - 0x3750fff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x3750000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000003 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x3750000-0x3751000 016c:trace:virtual:dump_view View: 0x3750000 - 0x3750fff (valloc) 016c:trace:virtual:dump_view 0x3750000 - 0x3750fff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x3750000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000001 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x3750000-0x3751000 016c:trace:virtual:dump_view View: 0x3750000 - 0x3750fff (valloc) 016c:trace:virtual:dump_view 0x3750000 - 0x3750fff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x3750000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000000 2000 00000004 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff (nil) 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000000 2000 00000004 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff (nil) 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000000 2000 00000004 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff (nil) 00000000 8000 It then loops on the call with size=0 indefinitely and keeps running until I kill the wineserver. Unfortunately, this is a proprietary legacy application so I can't share it, however I'll be more than glad to accept pointers on which debug channels to activate, any other further debugging steps, or changes to the code that might fix this. Thanks in advance. -- 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 54508] New: psapi:psapi_main - The 64-bit test_EnumProcessModulesEx() gets unexpected snapshot counts on Windows 7 and 11
by WineHQ Bugzilla Nov. 10, 2025

Nov. 10, 2025

https://bugs.winehq.org/show_bug.cgi?id=54508 Bug ID: 54508 Summary: psapi:psapi_main - The 64-bit test_EnumProcessModulesEx() gets unexpected snapshot counts on Windows 7 and 11 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: psapi Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com psapi:psapi_main - The 64-bit test_EnumProcessModulesEx() gets unexpected snapshot counts on Windows 7 and 11: w7pro64: psapi_main.c:483: Test failed: pcs-6432: Wrong count 23 in C:\Windows\SysWOW64 psapi_main.c:488: Test failed: pcs-6432: Wrong count 2 in C:\Windows\system32 w11pro64: psapi_main.c:488: Test failed: pcs-6432: Wrong count 0 in C:\Windows\system32 See https://test.winehq.org/data/patterns.html#psapi:psapi_main These failures don't happen on Windows 8 to Windows 10! These tests and failures were introduced in the following commit: commit e38455a2181ab5ce0bf842f2c9a638b3ee9b538c Author: Eric Pouech <eric.pouech(a)gmail.com> AuthorDate: Tue Feb 14 11:06:57 2023 +0100 psapi/tests: Test directory of enumerated loaded modules. Showing that Wine incorrectly reports, for a Wow64 process, the system DLLs from within the wow64 directory while they should be from system32. Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- 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 54436] New: wine-staging-8.0 regression (not working): Command & Conquer 3: Tiberium Wars Kane's Wrath
by WineHQ Bugzilla Nov. 10, 2025

Nov. 10, 2025

https://bugs.winehq.org/show_bug.cgi?id=54436 Bug ID: 54436 Summary: wine-staging-8.0 regression (not working): Command & Conquer 3: Tiberium Wars Kane's Wrath Product: Wine-staging Version: 8.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: kolAflash(a)kolahilft.de CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 73981 --> https://bugs.winehq.org/attachment.cgi?id=73981 wine-staging-8.0: left is fine, right is broken With wine-staging-7.0 "Command & Conquer 3: Tiberium Wars Kane's Wrath" was working fine. In wine-8.0 and wine-staging-8.0 it's broken. With wine-staging-8.0 the menu looks broken. See attached screenshot. (left is fine, right is broken) With wine-8.0 the menu loads, but starting a skirmish game crashes the application. There's an error dialog window saying: Direct3D error 0x8007000e (E_OUTOFMEMORY) -- 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 33