- Wine-Bugs - list.winehq.org

[Bug 50711] New: Fuji X-RAW installation fails
by WineHQ Bugzilla March 14, 2026

March 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=50711 Bug ID: 50711 Summary: Fuji X-RAW installation fails Product: Wine Version: 6.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: testing.tigerwolf(a)mail.com Distribution: --- Created attachment 69455 --> https://bugs.winehq.org/attachment.cgi?id=69455 Fuji X-RAW installation logs Fuji X-RAW Installation fails without message Application could be downloaded here : https://fujifilm-x.com/fr-fr/support/download/software/x-raw-studio/ -- 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

[Bug 58667] New: Multi-touch gestures not passed through on CSP
by WineHQ Bugzilla March 14, 2026

March 14, 2026

http://bugs.winehq.org/show_bug.cgi?id=58667 Bug ID: 58667 Summary: Multi-touch gestures not passed through on CSP Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: despair.chick(a)proton.me Distribution: --- On clip studio paint and other windows art based applications traditional touch operations are recognized but gestures are not. *Pinch-to-zoom *Rotation *Three-finger-operations -- 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 7

[Bug 49253] New: 2048 freeze before showing anything
by WineHQ Bugzilla March 14, 2026

March 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=49253 Bug ID: 49253 Summary: 2048 freeze before showing anything Product: Wine Version: 5.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mikrutrafal54(a)gmail.com Distribution: --- Created attachment 67259 --> https://bugs.winehq.org/attachment.cgi?id=67259 2048 Log When I try to open 2048, then nothing happens. App seems to try use network, but it is unable to do it. File to download - https://portableapps.com/downloading/?a=2048Portable&n=2048%20Portable&s=s&… -- 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 10

[Bug 49196] New: Crash in Delrina Daily Planner 3.0
by WineHQ Bugzilla March 14, 2026

March 14, 2026

https://bugs.winehq.org/show_bug.cgi?id=49196 Bug ID: 49196 Summary: Crash in Delrina Daily Planner 3.0 Product: Wine Version: 5.0 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)winehq.org Reporter: buellboy9(a)verizon.net Distribution: --- Created attachment 67211 --> https://bugs.winehq.org/attachment.cgi?id=67211 Error log created during the crash. Crash when opening any event in the Delrina Daily Planner 3.0. Used to work before upgrading to Version 5.0. Still works in native Windows 7. -- 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 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 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