- Wine-Bugs - list.winehq.org

[Bug 59523] New: Quicken 2013 - Undue line break in installer
by WineHQ Bugzilla March 14, 2026

March 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59523 Bug ID: 59523 Summary: Quicken 2013 - Undue line break in installer Product: Wine Version: 11.4 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 80547 --> http://bugs.winehq.org/attachment.cgi?id=80547 Line break in Wine Download from https://bit.ly/Quicken2013 Installer show undue line break -- 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 59479] New: SolidWorks 2025: owner-drawn buttons inside large (10000x10000) child window receive WM_LBUTTONDOWN but BN_CLICKED is never sent
by WineHQ Bugzilla March 14, 2026

March 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59479 Bug ID: 59479 Summary: SolidWorks 2025: owner-drawn buttons inside large (10000x10000) child window receive WM_LBUTTONDOWN but BN_CLICKED is never sent Product: Wine Version: 11.0 Hardware: arm OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: junkwalkers(a)gmail.com Created attachment 80467 --> http://bugs.winehq.org/attachment.cgi?id=80467 Window hierarchy dump from inspector tool SolidWorks 2025 Education Edition hosts PropertyManager controls inside a child window titled "Dve sheet" sized 10000x10000 pixels. Owner-drawn buttons (BS_OWNERDRAW, style 0x5001000B) inside this window visually depress when clicked (WM_LBUTTONDOWN is delivered) but the BN_CLICKED notification (WM_COMMAND) is never sent to the parent window on mouse release. Steps to reproduce: 1. Install SolidWorks 2025 in a clean wineprefix 2. Open a part and enter sketch edit mode (e.g., draw a circle) 3. The PropertyManager sidebar displays controls inside a "Dve sheet" window (10000x10000) 4. Click any owner-drawn button: the confirm checkmark, cancel X, or circle type selectors Expected: Button fires its action (BN_CLICKED sent via WM_COMMAND to parent) Actual: Button visually depresses and releases but no action occurs Additional observations: - Standard buttons in normal-sized windows (Command Manager toolbar, viewport overlay buttons) work correctly - Text fields, dropdowns, and checkboxes in the same PropertyManager panel work - A custom window inspector confirms the buttons are BS_OWNERDRAW (style 0x5001000B) children of the "Dve sheet" window - Manually posting WM_COMMAND with BN_CLICKED to the button's parent via an external helper process makes the buttons function correctly, confirming the parent is listening for the notification This suggests the issue is in Wine's button control or mouse capture handling when the owning window has very large dimensions (10000x10000). Window hierarchy (from EnumChildWindows inspection): "Dve sheet" [AfxWnd140u] size=10000x10000 "Circle" [Button] style=0x5001000B size=242x24 ← broken "dvePage ScrollView" [AfxFrameOrView140u] size=243x798 [#32770] style=0x52000044 size=240x407 (various controls: buttons, checkboxes, labels) [Button] style=0x5001000B size=24x24 ← broken (confirm/cancel) System: macOS 26.3, Apple Silicon (M-series), Wine 11.0 stable, Rosetta 2 translation This may also affect the X11 driver — not tested. -- 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 59478] New: SolidWorks 2025: owner-drawn buttons inside large (10000x10000) child window receive WM_LBUTTONDOWN but BN_CLICKED is never sent
by WineHQ Bugzilla March 14, 2026

March 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59478 Bug ID: 59478 Summary: SolidWorks 2025: owner-drawn buttons inside large (10000x10000) child window receive WM_LBUTTONDOWN but BN_CLICKED is never sent Product: Wine Version: 11.0 Hardware: arm OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: junkwalkers(a)gmail.com Created attachment 80468 --> http://bugs.winehq.org/attachment.cgi?id=80468 Window hierarchy dump from inspector tool SolidWorks 2025 Education Edition hosts PropertyManager controls inside a child window titled "Dve sheet" sized 10000x10000 pixels. Owner-drawn buttons (BS_OWNERDRAW, style 0x5001000B) inside this window visually depress when clicked (WM_LBUTTONDOWN is delivered) but the BN_CLICKED notification (WM_COMMAND) is never sent to the parent window on mouse release. Steps to reproduce: 1. Install SolidWorks 2025 in a clean wineprefix 2. Open a part and enter sketch edit mode (e.g., draw a circle) 3. The PropertyManager sidebar displays controls inside a "Dve sheet" window (10000x10000) 4. Click any owner-drawn button: the confirm checkmark, cancel X, or circle type selectors Expected: Button fires its action (BN_CLICKED sent via WM_COMMAND to parent) Actual: Button visually depresses and releases but no action occurs Additional observations: - Standard buttons in normal-sized windows (Command Manager toolbar, viewport overlay buttons) work correctly - Text fields, dropdowns, and checkboxes in the same PropertyManager panel work - A custom window inspector confirms the buttons are BS_OWNERDRAW (style 0x5001000B) children of the "Dve sheet" window - Manually posting WM_COMMAND with BN_CLICKED to the button's parent via an external helper process makes the buttons function correctly, confirming the parent is listening for the notification This suggests the issue is in Wine's button control or mouse capture handling when the owning window has very large dimensions (10000x10000). Window hierarchy (from EnumChildWindows inspection): "Dve sheet" [AfxWnd140u] size=10000x10000 "Circle" [Button] style=0x5001000B size=242x24 ← broken "dvePage ScrollView" [AfxFrameOrView140u] size=243x798 [#32770] style=0x52000044 size=240x407 (various controls: buttons, checkboxes, labels) [Button] style=0x5001000B size=24x24 ← broken (confirm/cancel) System: macOS 26.3, Apple Silicon (M-series), Wine 11.0 stable, Rosetta 2 translation This may also affect the X11 driver — not tested. -- 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 59512] New: HID devices report wrong DeviceType causing GetFileType() to return FILE_TYPE_DISK
by WineHQ Bugzilla March 14, 2026

March 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59512 Bug ID: 59512 Summary: HID devices report wrong DeviceType causing GetFileType() to return FILE_TYPE_DISK Product: Wine Version: 11.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: hid Assignee: wine-bugs(a)list.winehq.org Reporter: Robert-Gerigk(a)online.de Distribution: --- Created attachment 80536 --> http://bugs.winehq.org/attachment.cgi?id=80536 test program HID device handles return incorrect values for GetFileType() and NtQueryVolumeInformationFile(FileFsDeviceInformation). Windows behavior (tested on Windows 11): - GetFileType() returns FILE_TYPE_UNKNOWN (0) - DeviceType = FILE_DEVICE_UNKNOWN (0x22) - Characteristics = FILE_AUTOGENERATED_DEVICE_NAME (0x80) Wine behavior (Wine 11.4): - GetFileType() returns FILE_TYPE_DISK (1) - DeviceType = 0x00000000 - Characteristics = 0x00000000 Root cause: hidclass.sys creates child PDOs with DeviceType=0 and no IRP_MJ_QUERY_VOLUME_INFORMATION handler. GetFileType() maps DeviceType 0 to its default case, returning FILE_TYPE_DISK. This breaks .NET applications that use FileStream on HID device handles (e.g. KNX automation software ETS6), because FileStream treats FILE_TYPE_DISK handles as seekable files and fails when trying to seek on a HID device. Tested with MDT KNX USB Interface (VID 16D0, PID 0491). Windows 11 output of hid_filetype_test.exe (attached to this ticket): === HID GetFileType / DeviceType Test === HID GUID: {4D1E55B2-F16F-11CF-88CB-001111000030} Device 0: \\?\hid#msft1234#5&149340ea&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} GetFileType: FILE_TYPE_UNKNOWN (0) NtQueryVolumeInformationFile(FileFsDeviceInformation): Status: 0x00000000 DeviceType: 0x00000022 Characteristics: 0x00000080 ... Device 5: \\?\hid#vid_16d0&pid_0491#6&2b4efaa3&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} GetFileType: FILE_TYPE_UNKNOWN (0) NtQueryVolumeInformationFile(FileFsDeviceInformation): Status: 0x00000000 DeviceType: 0x00000022 Characteristics: 0x00000080 HID: VID=16D0 PID=0491 Ver=513 Caps: UsagePage=0xFF00 Usage=0x0001 InLen=64 OutLen=64 Product: KNX-USB Inteface ... --- 10 device(s) opened, all report identical values --- Wine 11.4 output of same executable: === HID GetFileType / DeviceType Test === Device 0: \\?\hid#vid_16d0&pid_0491&mi_00#...#{4d1e55b2-f16f-11cf-88cb-001111000030} GetFileType: FILE_TYPE_DISK (1) NtQueryVolumeInformationFile(FileFsDeviceInformation): Status: 0x00000000 DeviceType: 0x00000000 Characteristics: 0x00000000 HID: VID=16D0 PID=0491 Ver=513 Caps: UsagePage=0xFF00 Usage=0x0001 InLen=64 OutLen=64 Product: KNX-USB Inteface --- 3 device(s) opened, all report identical values --- I have a patch ready (test + fix) and will submit a merge request once confirmed. -- 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 50582] New: Delphi app - TPageControl button have no text in WinManage.
by WineHQ Bugzilla March 14, 2026

March 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=50582 Bug ID: 50582 Summary: Delphi app - TPageControl button have no text in WinManage. Product: Wine Version: 6.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: julenuri(a)hotmail.com Distribution: --- Created attachment 69256 --> https://bugs.winehq.org/attachment.cgi?id=69256 Win mgr software There is still an issue with the text not showing the TPageControl, and also with the position of them in Delphi apps. In this case I tested the Win Manage v1.0 software. It'll be attached. Affects also ReactOS, JIRA issue on: https://jira.reactos.org/browse/CORE-17419 I'll attach snapshots of Windows XP and Wine 5.0.3, however, 6.0 is still affected. -- 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 59524] New: Apps running with Win10 or Win11 compatibility detect Win8.1
by WineHQ Bugzilla March 14, 2026

March 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59524 Bug ID: 59524 Summary: Apps running with Win10 or Win11 compatibility detect Win8.1 Product: Wine Version: 11.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: winehq-bugs(a)brocky.net Distribution: --- Created attachment 80550 --> http://bugs.winehq.org/attachment.cgi?id=80550 Patch to add Win10 compatibility to msiexec.manifest that doesn't seem to work I'm dealing with a suite of applications that only work on Windows 10 or 11 (as a software-defined block from what I can tell), but when I run them, they detect the version as Windows 8.1 (6.2) and abort, even when running with the Windows Version set to Windows 11 both as the default, and specifically for the .exe I try to run. I was even unable to install the app because msiexec.exe had the same issue, where the installer would check the `Environment.OSVersion.Version` (C#, which calls `GetVersionEx` under the hood) and abort because it got 6.2 instead of 10.0. There seems to be several parts to this problem: 1. The application I'm trying to run has the MajorOperatingSystemVersion.MinorOperatingSystemVersion in the OptionalHeader set to 6.0, and the manifest doesn't declare a `supportedOS`, so Wine seems to be thinking it needs to limit the compatibility level to Win8.1. I'm not really sure what's standard or normal, but I checked a few other programs I have (only in a hex editor, not in Wine) that also require Windows 10, and none of them seem to fit that criteria. They all have versions less than 10 in their EXE headers and nothing in the manifest saying otherwise either. 2. Even if I try to force the compatibility level for the specific EXEs in winecfg to be Win10 or Win11, that setting is ignored. This is because the compatibility that has been selected is done in RtlGetVersion(), but then the init_current_version() that is used for GetVersionEx (in init_current_version) applies the backwards-compatibility logic afterwards, essentially ignoring the configuration. 3. msiexec has the same problem as point 1, but has the MajorOperatingSystemVersion.MinorOperatingSystemVersion set to 4.0 and also doesn't declare a supportedOS in the manifest. Presumably, any installer that checks the OS version would fail if it requires Win10 or later, even if the programs it installs do set the image headers or manifest correctly. I tried adding the below to msiexec.manifest (also attached as a patch), but it didn't seem to help with the installer detecting the desired 10.0 version. From what I can understand of the code in init_current_version (dlls\kernelbase\version.c), this should have worked, but didn't. Not sure if I messed something up or I misunderstood how to declare this. <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">  <application>  <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" /> </application> </compatibility> </assembly> The only way I was able to get my program to install and run was to delete the final `if` statement that updates the `current_version` to the downgraded `ver`, effectively disabling the entire compatibility stuff. After that, the programs seem to install and run just 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 2

[Bug 59525] New: Apps running with Win10 or Win11 compatibility detect Win8.1
by WineHQ Bugzilla March 14, 2026

March 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=59525 Bug ID: 59525 Summary: Apps running with Win10 or Win11 compatibility detect Win8.1 Product: Wine Version: 11.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: winehq-bugs(a)brocky.net Distribution: --- Created attachment 80549 --> http://bugs.winehq.org/attachment.cgi?id=80549 Patch to add Win10 compatibility to msiexec.manifest that doesn't seem to work I'm dealing with a suite of applications that only work on Windows 10 or 11 (as a software-defined block from what I can tell), but when I run them, they detect the version as Windows 8.1 (6.2) and abort, even when running with the Windows Version set to Windows 11 both as the default, and specifically for the .exe I try to run. I was even unable to install the app because msiexec.exe had the same issue, where the installer would check the `Environment.OSVersion.Version` (C#, which calls `GetVersionEx` under the hood) and abort because it got 6.2 instead of 10.0. There seems to be several parts to this problem: 1. The application I'm trying to run has the MajorOperatingSystemVersion.MinorOperatingSystemVersion in the OptionalHeader set to 6.0, and the manifest doesn't declare a `supportedOS`, so Wine seems to be thinking it needs to limit the compatibility level to Win8.1. I'm not really sure what's standard or normal, but I checked a few other programs I have (only in a hex editor, not in Wine) that also require Windows 10, and none of them seem to fit that criteria. They all have versions less than 10 in their EXE headers and nothing in the manifest saying otherwise either. 2. Even if I try to force the compatibility level for the specific EXEs in winecfg to be Win10 or Win11, that setting is ignored. This is because the compatibility that has been selected is done in RtlGetVersion(), but then the init_current_version() that is used for GetVersionEx (in init_current_version) applies the backwards-compatibility logic afterwards, essentially ignoring the configuration. 3. msiexec has the same problem as point 1, but has the MajorOperatingSystemVersion.MinorOperatingSystemVersion set to 4.0 and also doesn't declare a supportedOS in the manifest. Presumably, any installer that checks the OS version would fail if it requires Win10 or later, even if the programs it installs do set the image headers or manifest correctly. I tried adding the below to msiexec.manifest (also attached as a patch), but it didn't seem to help with the installer detecting the desired 10.0 version. From what I can understand of the code in init_current_version (dlls\kernelbase\version.c), this should have worked, but didn't. Not sure if I messed something up or I misunderstood how to declare this. <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">  <application>  <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" /> </application> </compatibility> </assembly> The only way I was able to get my program to install and run was to delete the final `if` statement that updates the `current_version` to the downgraded `ver`, effectively disabling the entire compatibility stuff. After that, the programs seem to install and run just 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 2

[Bug 50495] New: the WS_EX_LAYERED set SetWindowLong GWL_EXSTYLE , Window show white rather than transparency.
by WineHQ Bugzilla March 14, 2026

March 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=50495 Bug ID: 50495 Summary: the WS_EX_LAYERED set SetWindowLong GWL_EXSTYLE , Window show white rather than transparency. Product: WineHQ Bugzilla Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: bugzilla-unknown Assignee: wine-bugs(a)winehq.org Reporter: 490165508(a)qq.com CC: austinenglish(a)gmail.com Distribution: --- Created attachment 69150 --> https://bugs.winehq.org/attachment.cgi?id=69150 This program will create a transparent full screen window. When I use the following code to create a transparent full screen window. ``` HWND hWnd; hWnd = CreateWindowEx(WS_EX_APPWINDOW, "WindowClass", "Demo", WS_VISIBLE| WS_MAXIMIZE, CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL); SetWindowLong(hWnd, GWL_STYLE, GetWindowLong(hWnd, GWL_STYLE) & (~WS_DLGFRAME)); RECT rect; GetWindowRect(hWnd, &rect); SetWindowPos(hWnd, HWND_TOPMOST, rect.left, rect.top, rect.right - rect.left, rect.bottom - rect.top, SWP_DRAWFRAME); LONG ret = GetWindowLong(hWnd, GWL_EXSTYLE); ret = ret | WS_EX_LAYERED; SetWindowLong(hWnd, GWL_EXSTYLE, ret); ShowWindow(hWnd, SW_SHOWMAXIMIZED); UpdateWindow(hWnd); ``` In Windows this program display window is a full screen transparent window，But running this little program with Wine on Linux displays a full-screen white window. This problem occurred. I tried to modify the SetWindowLong API function implementation, but it didn't change much. I hope the bosses can help me. -- 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 4

[Bug 37662] New: ResEdit 1.6.3 insaller/downloader crashes early
by wine-bugs＠winehq.org March 14, 2026

March 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=37662 Bug ID: 37662 Summary: ResEdit 1.6.3 insaller/downloader crashes early Product: Wine Version: 1.7.32 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bunglehead(a)gmail.com Distribution: --- As it says it crashes on launch - dumps some server response data in terminal and then dies. -- 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 9

[Bug 49925] New: Closing Apps With ALT+F4 Bad File Descripter
by WineHQ Bugzilla March 14, 2026

March 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=49925 Bug ID: 49925 Summary: Closing Apps With ALT+F4 Bad File Descripter Product: Wine Version: 5.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: SolisX007(a)yahoo.com Distribution: --- Closing apps with ALT+F4 causes bad file descripter err on wine-5.18. -- 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 1