March 2026 - Wine-bugs - list.winehq.org

[Bug 59384] New: Legacy Family Tree random crash
by WineHQ Bugzilla 02 Mar '26

02 Mar '26

http://bugs.winehq.org/show_bug.cgi?id=59384 Bug ID: 59384 Summary: Legacy Family Tree random crash Product: Wine Version: 11.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: mice(a)duck.com Distribution: --- Created attachment 80337 --> http://bugs.winehq.org/attachment.cgi?id=80337 Crash backtrace file This crash happens at random times when using the application. Unable to reproduce as many operations work normally for most of the time. -- 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 59448] New: Emulate undocumented behaviors of MS TreeView customdraw
by WineHQ Bugzilla 02 Mar '26

02 Mar '26

http://bugs.winehq.org/show_bug.cgi?id=59448 Bug ID: 59448 Summary: Emulate undocumented behaviors of MS TreeView customdraw Product: Wine Version: 11.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: comctl32 Assignee: wine-bugs(a)list.winehq.org Reporter: p(a)perkele.cc Distribution: --- Created attachment 80432 --> http://bugs.winehq.org/attachment.cgi?id=80432 Minimal repro code MS TreeView can be made draw items with app-supplied selection state, allowing native-looking multi-selection support. Specifically, NM_CUSTOMDRAW CDDS_ITEMPREPAINT handler can set CDIS_SELECTED flag, causing the item to be drawn selected. Setting Explorer theme seems to enable the behavior, uItemState changes appear ignored otherwise. Wine currently does not emulate this behavior. Recommended change: pay attention to CDDS_ITEMPREPAINT altering uItemState and use changed state for drawing - but only if Explorer theme is set. Test C program attached: * 2 tree views, left themeless, right with Explorer theme * Custom draw handler sets CDIS_SELECTED everywhere * Windows behavior: left ignores CDIS_SELECTED, right draws all selected -- 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 59463] New: Use of OpenThemeData() on treeview causes rendering bugs
by WineHQ Bugzilla 02 Mar '26

02 Mar '26

http://bugs.winehq.org/show_bug.cgi?id=59463 Bug ID: 59463 Summary: Use of OpenThemeData() on treeview causes rendering bugs Product: Wine Version: 11.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: uxtheme Assignee: wine-bugs(a)list.winehq.org Reporter: p(a)perkele.cc Distribution: --- Created attachment 80450 --> http://bugs.winehq.org/attachment.cgi?id=80450 Repro See attached program. Circles are drawn instead of treeview expand marks after use of OpenThemeData(). Original context was my code using theme data to render checkbox images for use in treeview. Attached program has been simplified to do nothing else but trigger the bug. -- 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 2

[Bug 59473] New: Crashed while opening misaka26
by WineHQ Bugzilla 02 Mar '26

02 Mar '26

http://bugs.winehq.org/show_bug.cgi?id=59473 Bug ID: 59473 Summary: Crashed while opening misaka26 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: zahriyehhamoody(a)gmail.com Distribution: --- Created attachment 80461 --> http://bugs.winehq.org/attachment.cgi?id=80461 The backtrace given to me by the Wine app. I tried to run misaka26 on Bazzite, MacBook Air 2017, and it failed. I tried twice, and when i had windows on this same pc, it ran fine. -- 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 19368] New: lpfnWndProc can't catch Up/Down/Left/Right and CTRL+ other Button
by wine-bugs＠winehq.org 01 Mar '26

01 Mar '26

http://bugs.winehq.org/show_bug.cgi?id=19368 Summary: lpfnWndProc can't catch Up/Down/Left/Right and CTRL+ other Button Product: Wine Version: 1.1.26 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: sakaihdt(a)d2.dion.ne.jp Hello I want to use "sakura editor". (a Japanese Open Souce text editor for MS Windows) (http://sakura-editor.sourceforge.net/) But this application is not work well in wine(1.0.1 or 1.1.26 Ubuntu GNU/Linux 9.0.4) - Not work Up/Down/Left/Right button in text area - Not work CTRL+C or CTRL+A and other in text area - Not work Backspace in text area - Not work Function Key in text area normal text button( a-z, 0-9 ) is work well, and Up/Down... is work well in menu . "sakura editor" catch Up/Down/Ctrl event from lpfnWndProc() callback. but wine's lpfnWndProc seem not work when push Up/Down... key. ( I insert log in sakura editor source and check.) I have 2 question. please tell me. (1) Can lpfnWndProc() catch Up/Down/Left/Right CTRL+A,X,C and Function key in Wine ? (2) "lpfnWndProc() can catch Up/Down/Left/Right ..." is WindowsAPI specification? Thank you. -- 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.

2 13

[Bug 34134] New: "open file" dialog does not shrink after switching to "use adobe dialog" and back to system dialog
by wine-bugs＠winehq.org 01 Mar '26

01 Mar '26

http://bugs.winehq.org/show_bug.cgi?id=34134 Bug #: 34134 Summary: "open file" dialog does not shrink after switching to "use adobe dialog" and back to system dialog Product: Wine Version: 1.6 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: unxed(a)mail.ru Classification: Unclassified If you press "use adobe dialog" button in "open file" dialog, it grows. If you press "use os dialog" after it, window does not shrink back. -- 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.

2 3

[Bug 59460] New: bcrypt: Implement RSA-OAEP padding defaults (fixes Wallpaper Engine mobile sync)
by WineHQ Bugzilla 01 Mar '26

01 Mar '26

http://bugs.winehq.org/show_bug.cgi?id=59460 Bug ID: 59460 Summary: bcrypt: Implement RSA-OAEP padding defaults (fixes Wallpaper Engine mobile sync) Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: bcrypt Assignee: wine-bugs(a)list.winehq.org Reporter: sreehari7102008(a)gmail.com Distribution: --- Created attachment 80447 --> http://bugs.winehq.org/attachment.cgi?id=80447 Patch implementing default OAEP padding (SHA-1 + empty label) for BCryptEncrypt when pPaddingInfo is NULL. Fixes Wallpaper Engine mobile sync on Proton. When BCryptEncrypt is called with BCRYPT_PAD_OAEP and pPaddingInfo = NULL (common in many high-level libraries), Windows defaults to SHA-1 hash algorithm with an empty label. The GnuTLS backend in Wine currently requires a full BCRYPT_OAEP_PADDING_INFO structure even for encryption and returns STATUS_INVALID_PARAMETER. This breaks RSA-OAEP handshakes in several applications, notably the mobile device pairing / sync feature in Wallpaper Engine. This patch makes the encryption path match real Windows behaviour: - if pPaddingInfo == NULL → use SHA-1 + empty label - otherwise use the supplied hash and label (label may still be empty) Decryption side remains unchanged (still requires pszAlgId, which matches Windows). Tested on Proton 10 with Wallpaper Engine mobile pairing — the sync now works. Full patch 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 9

[Bug 33241] New: incorrect display of a combobox in a Clipper application
by wine-bugs＠winehq.org 01 Mar '26

01 Mar '26

http://bugs.winehq.org/show_bug.cgi?id=33241 Bug #: 33241 Summary: incorrect display of a combobox in a Clipper application Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: ironeman(a)tiscali.it Classification: Unclassified As mentioned in http://forum.winehq.org/viewtopic.php?f=8&t=18198, I am using 16-bit Clipper/xBase programs. When I have a listbox, the field is not correctly initialized, despite the list is ok. Debugging my application, I have found that it is due to a strange memory management. I start by saying that Clipper/xBase uses dynamic scoping, so the value of a variable is the last assigned to it into the stack; a variable can be local or global (prefixed by m->). When using the dialog that has the problem, I use the activation command (Fivewin library): m->mTipoDoc:=.... // assign the global variable m->mTipoDoc activate DIALOG oDlg centered on init (SettaCombo()) function SettaCombo() // initialization code of the dialog ... // use the global variable m->mTipoDoc but, at this point, when using WINE, the variable has lost its content and is empty I solved the problem using a local variable that temporarily holds the value of the global variable: m->mTipoDoc:=.... // assign the global variable m->mTipoDoc local tmpcod:=m->mTipoDoc // to solve the wine bug activate DIALOG oDlg centered on init (SettaCombo(tmpcod)) function SettaCombo(val) m->mTipoDoc:=val // to solve the wine bug ... // use the global variable m->mTipoDoc Evidently the local variable is managed in a different way by WINE and the error has disappered. To test this behaviour, I wrote the attached sample program. Into the zip there is a readme.pdf that explains how it works. Best regards. -- 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.

2 5

[Bug 21127] New: What Colour color picking functionality is not identical to Windows
by wine-bugs＠winehq.org 01 Mar '26

01 Mar '26

http://bugs.winehq.org/show_bug.cgi?id=21127 Summary: What Colour color picking functionality is not identical to Windows Product: Wine Version: 1.1.35 Platform: x86 URL: http://www.jumpjet.info/Win2k/05/What_Colour/WhatColou r.zip OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: arethusa26(a)gmail.com With wine-1.1.35-105-gd4a7a9d, when the color picker in the What Colour program is selected, moving the mouse outside the What Colour's client area doesn't result in any color selection changes until the mouse is pressed, causing the application to finally grab the color under the mouse cursor by presumably taking a "screenshot" of the desktop area. On Windows XP, this "screenshotting" behavior happens first, made obvious by a brief, visible change in the screen, and then moving the color picker over the area outside the What Colour client area shows active changes in the color selection, which is only halted when the mouse is pressed. -- 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.

2 8

[Bug 59472] New: FreeArc hangs on startup in new wow64 mode
by WineHQ Bugzilla 01 Mar '26

01 Mar '26

http://bugs.winehq.org/show_bug.cgi?id=59472 Bug ID: 59472 Summary: FreeArc hangs on startup in new wow64 mode Product: Wine Version: 11.3 Hardware: x86-64 URL: https://archive.org/details/FreeArc-0.666-win32bin-Sou rces OS: Linux Status: NEW Keywords: download, testcase, wow64 Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: arethusa26(a)gmail.com Distribution: --- Created attachment 80459 --> http://bugs.winehq.org/attachment.cgi?id=80459 Largest memory block loop test case executable When running the FreeArc archiver tool on the command line to add a file to an archive with a new wow64 build of Wine, the tool hangs indefinitely with only a banner output string: $ wine freearc/bin/Arc.exe a test.arc empty_file 0124:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION FreeArc 0.666 With a old wow64 build of Wine, the tool runs and completes successfully: $ wine freearc/bin/Arc.exe a test.arc empty_file 0024:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION FreeArc 0.666 0024:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x80010000, unix_prot 0 0024:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 80000000 0024:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x78010000, unix_prot 0 0024:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 78000000 ... creating archive: test.arc Compressing 1 file, 1,024 bytes. Processed 0% 0024:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x80010000, unix_prot 0 0024:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 80000000 0024:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x78010000, unix_prot 0 0024:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 78000000 ... Compressed 1 file, 1,024 => 44 bytes. Ratio 4.2% Compression time: cpu 0.62 secs, real 0.31 secs. Speed 3 kB/s All OK To reproduce the issue with FreeArc, download "FreeArc-portable-0.666-win32.zip" from the URL link and extract the contents of the ZIP file to a directory named "freearc". The Arc.exe binary can be run with the provided command line. When FreeArc is run with new wow64 Wine, there appears to be a thread that is stuck repeatedly calling VirtualAlloc with 0 size: 0124:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000000 2000 00000004 0124:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff (nil) 00000000 8000 0124:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000000 2000 00000004 0124:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff (nil) 00000000 8000 The code involved in the hang appears to be the LargestMemoryBlock::LargestMemoryBlock() constructor in Environment.cpp from the FreeArc sources. It's a (buggy) loop that attempts a binary search for the largest size it can successfully pass to VirtualAlloc. I have extracted the logic to create a standalone test case, which is built with: i686-w64-mingw32-gcc -O2 -Wall -Wl,--large-address-aware -o largest_memory_block.exe largest_memory_block.c On Windows 10, the largest_memory_block.exe test case shows the following output: a = 0 b = ffffffff Freeing pointer 00000000 with VirtualFree Allocating 7fffffff bytes with VirtualAlloc VirtualAlloc returned 00000000 VirtualAlloc failed, updating b to 7fffffff a = 0 b = 7fffffff Freeing pointer 00000000 with VirtualFree Allocating 3fffffff bytes with VirtualAlloc VirtualAlloc returned 01970000 VirtualAlloc succeeded, updating a to 3fffffff ... a = 7f98ffff b = 7f990001 Freeing pointer 00000000 with VirtualFree Allocating 7f990000 bytes with VirtualAlloc VirtualAlloc returned 7fff0000 VirtualAlloc succeeded, updating a to 7f990000 On new wow64 Wine, the test case shows the following output: a = 0 b = ffffffff Freeing pointer 00000000 with VirtualFree Allocating 7fffffff bytes with VirtualAlloc VirtualAlloc returned 7fff0000 VirtualAlloc succeeded, updating a to 7fffffff a = 7fffffff b = ffffffff Freeing pointer 7fff0000 with VirtualFree Allocating 3fffffff bytes with VirtualAlloc VirtualAlloc returned 00900000 VirtualAlloc succeeded, updating a to 3fffffff ... a = 1 b = ffffffff Freeing pointer 003f0000 with VirtualFree Allocating 0 bytes with VirtualAlloc VirtualAlloc returned 00000000 VirtualAlloc failed, updating b to 0 a = 1 b = 0 Freeing pointer 00000000 with VirtualFree Allocating 0 bytes with VirtualAlloc VirtualAlloc returned 00000000 VirtualAlloc failed, updating b to 0 ... The midpoint computation "c = (a + b) / 2" in the loop overflows when the initial allocation succeeds on Wine and leads to incorrect execution, whereas the initial allocation doesn't appear to succeed on 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 1