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

[Bug 59609] New: comctl32: LVM_GETITEMPOSITION returns client coordinates instead of view coordinates in ICON/SMALLICON views (breaks FastStone Image Viewer)
by WineHQ Bugzilla July 8, 2026

July 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59609 Bug ID: 59609 Summary: comctl32: LVM_GETITEMPOSITION returns client coordinates instead of view coordinates in ICON/SMALLICON views (breaks FastStone Image Viewer) Product: Wine Version: 11.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: comctl32 Assignee: wine-bugs(a)list.winehq.org Reporter: lldmakhbfcrmqyluns(a)nesopf.com Distribution: --- Bug overview: In `dlls/comctl32/listview.c`, the function `LISTVIEW_GetItemPosition` unconditionally adds `Origin.x` and `Origin.y` to the item's coordinates. This converts the coordinates to Client coordinates. However, according to MSDN, for `LV_VIEW_ICON` and `LV_VIEW_SMALLICON` modes, `LVM_GETITEMPOSITION` must return View coordinates (absolute coordinates on the canvas), not Client coordinates. MSDN Documentation reference for LVM_GETITEMPOSITION: "In icon or small icon view, the LVM_GETITEMPOSITION message returns the item's position in view coordinates. To get the client coordinates of an item, subtract the origin from the view coordinates." Symptoms & Application Behavior: This bug breaks the top thumbnail strip in full screen mode of FastStone Image Viewer (FSViewer.exe) when scrolling horizontally. The thumbnail strip is a ListView in Icon mode (height: 150px). When the user scrolls to the right by approximately the width of the screen (e.g., ~1900px on a 1080p monitor), the thumbnails suddenly disappear, leaving blank white spaces and cropped thumbnails. The Mathematical Root Cause: Because Wine incorrectly returns Client coordinates instead of View coordinates, a "double subtraction" occurs in the application's logic: 1. Wine calculates internally: `Returned_X = Absolute_X - ScrollPos` (by adding the negative Origin). 2. FSViewer (following MSDN) attempts to calculate the client position to determine if the item is visible: `App_Client_X = Returned_X - ScrollPos`. 3. The resulting math is: `App_Client_X = Absolute_X - 2 * ScrollPos`. When `ScrollPos` exceeds the width of the window (e.g., scrolling past 1920px), the calculated right edge of the visible items becomes negative. FSViewer incorrectly concludes that all items have moved off-screen to the left. To save resources, FSViewer returns `CDRF_SKIPDEFAULT` (0x4) during the `CDDS_PREPAINT` custom draw notification. Wine respects this flag, skips drawing the items, and `BitBlt` copies a blank/white double-buffer background to the screen. Proposed Fix / Patch: The addition of `Origin` should be restricted to `LV_VIEW_DETAILS` and `LV_VIEW_LIST` views, where Client coordinates are actually expected. In `dlls/comctl32/listview.c`, modify `LISTVIEW_GetItemPosition`: --- a/dlls/comctl32/listview.c +++ b/dlls/comctl32/listview.c @@ -XXXX,X +XXXX,X @@ static BOOL LISTVIEW_GetItemPosition(const LISTVIEW_INFO *infoPtr, INT nItem, LP if (infoPtr->uView == LV_VIEW_ICON) { lpptPosition->x += (infoPtr->nItemWidth - infoPtr->iconSize.cx) / 2; lpptPosition->y += ICON_TOP_PADDING; } - lpptPosition->x += Origin.x; - lpptPosition->y += Origin.y; + + /* In Icon/SmallIcon views, position is in view coordinates (absolute). + * In Details/List views, position is in client coordinates. */ + if (infoPtr->uView == LV_VIEW_DETAILS || infoPtr->uView == LV_VIEW_LIST) + { + lpptPosition->x += Origin.x; + lpptPosition->y += Origin.y; + } TRACE (" lpptPosition=%s\n", wine_dbgstr_point(lpptPosition)); return TRUE; Testing: Applying this exact logic fully resolves the white-space rendering bug in FastStone Image Viewer without breaking standard ListView internal mechanics (since Wine internally relies on `LISTVIEW_GetItemOrigin` for drawing, which remains unaffected). -- 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 8

[Bug 59885] New: Sonic Boom (1995 Klik & Play fangame) locks up in new WoW64 build
by WineHQ Bugzilla July 8, 2026

July 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59885 Bug ID: 59885 Summary: Sonic Boom (1995 Klik & Play fangame) locks up in new WoW64 build Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)list.winehq.org Reporter: gerbilsoft(a)gerbilsoft.com Distribution: --- The fix for bug 59871 allowed the game to get a bit further in starting up. On wine and wine-staging with the "old" WoW64 setup, the game works (with a 32-bit prefix). With the "new" WoW64 setup, it hangs, and the following message prints in the console every 60 seconds: 01bc:err:sync:RtlpWaitForCriticalSection section 7BA07A00 "dlls/krnl386.exe16/syslevel.c: Win16Mutex" wait timed out in thread 01bc, blocked by 01a0, retrying (60 sec) Using standard wine 11.1 and wine-staging 11.11, both with new WoW64 enabled. (Tested the non-WoW64 build as well, as indicated in bug 59871.) OS: Gentoo Linux Kernel: Linux 7.0.10 Desktop: KDE Plasma 6.7 Beta 2 -- 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 7

[Bug 59921] New: cdak demo - hlsl_codegen.c Unreachable code reached
by WineHQ Bugzilla July 8, 2026

July 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59921 Bug ID: 59921 Summary: cdak demo - hlsl_codegen.c Unreachable code reached Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: sashok.olen(a)gmail.com Distribution: --- Created attachment 81253 --> http://bugs.winehq.org/attachment.cgi?id=81253 shaders Link to the demo https://files.scene.org/view/parties/2010/chaosconstructions10/combined_64k… Launching it causes this line to get spammed in output: vkd3d:0024:err:vkd3d:compute_liveness_recurse ../wine/libs/vkd3d/libs/vkd3d-shader/hlsl_codegen.c:6461: Unreachable code reached. Installing Microsoft's d3dx9_37 workarounds the issue. Shaders dumped with VKD3D_SHADER_DUMP_PATH 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 7

[Bug 57330] New: NtQueryVolumeInformationFile does not work on Z: drive on default configuration
by WineHQ Bugzilla July 8, 2026

July 8, 2026

https://bugs.winehq.org/show_bug.cgi?id=57330 Bug ID: 57330 Summary: NtQueryVolumeInformationFile does not work on Z: drive on default configuration Product: Wine Version: 9.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: joshudson(a)gmail.com Distribution: --- Calling NtQueryVolumeInformationFile on an open handle that's opened from the Z: drive returns Invalid Function. I tried to run the test harness for my .NET File Systems DLL on Wine, and it didn't get very far. Almost nothing works because it wants the volume serial number, which on actual Windows is a cheap call. Source code line of failure: https://github.com/joshudson/Emet/blob/302fe61d0b8614e2a57930fc75cffa034ba3… What's interesting is this code *doesn't want* the volume serial number; it *wants* any unique volume identifier given a handle where all handles on the same handle get the same result. I could in theory detect wine here if I had a good way to implement the problem elsehow on Wine; say by one of the wine specific IOCTL calls. (The obvious solution is if I get back Invalid Function here; make the wine-specific call before giving up.) If you actually run the test battery https://github.com/joshudson/Emet/blob/302fe61d0b8614e2a57930fc75cffa034ba3… it should be a pretty good supplemental test battery for Wine's filesystem layer. -- 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 2

[Bug 59872] New: In version 11.11, clicks appeared in Red Dead Remastered
by WineHQ Bugzilla July 8, 2026

July 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59872 Bug ID: 59872 Summary: In version 11.11, clicks appeared in Red Dead Remastered Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: jon9097(a)gmail.com Distribution: --- In version 11.11, clicks appeared in Red Dead Remastered. When I press Esc, clicks are heard and clicks also appeared in the game itself, there were no clicks in version 11.10. The logs are still the same and there is nothing suspicious. Sometimes the clicks are so strong that they interfere with playing. -- 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 13

[Bug 24352] New: Virtual desktop does not respect modeless child window Z-order
by wine-bugs＠winehq.org July 8, 2026

July 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=24352 Summary: Virtual desktop does not respect modeless child window Z-order Product: Wine Version: 1.3.2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: multitude(a)internode.on.net 1. Run 'winecfg' and ensure the 'Graphics -> Emulate a virtual desktop' option is off. 2. Press the OK button to apply any changes and close 'winecfg'. 2. Run 'wine notepad' and search for text (Ctrl-F). 3. Leaving the 'Find' window open, mouse click the main 'Notepad' window. CORRECT RESULT: The 'Notepad' window becomes active, the 'Find' child window becomes inactive and remains in front of the main 'Notepad' window. 4. Exit 'notepad', run 'winecfg' and enable the 'Graphics -> Emulate a virtual desktop' option. 5. Press the OK button to apply the change and close 'winecfg'. 6. Run 'wine notepad' again and search for text (Ctrl-F). 7. Leaving the 'Find' window open, mouse click the main 'Notepad' window. INCORRECT RESULT: When the 'Notepad' window becomes active the 'Find' window disappears behind the 'Notepad' window. Confirmed in Wine 1.3.2 and Wine 1.2. Bug found when testing Chessmaster Grandmaster Edition. -- 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 19

[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 July 8, 2026

July 8, 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 4

[Bug 59477] New: SolidWorks 2025: GDI-rendered child window (Feature Manager tree) invisible behind sibling OpenGL child window on macOS
by WineHQ Bugzilla July 8, 2026

July 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59477 Bug ID: 59477 Summary: SolidWorks 2025: GDI-rendered child window (Feature Manager tree) invisible behind sibling OpenGL child window on macOS 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 80466 --> http://bugs.winehq.org/attachment.cgi?id=80466 Wine terminal output with WINEDEBUG=+win,+key showing F9 toggle for featuremanager SolidWorks 2025 Education Edition has a GDI-rendered Feature Manager tree panel (SysTreeView32) as a sibling child window to an OpenGL-rendered 3D viewport. On macOS with the winemac driver, the OpenGL content renders on top of the tree panel, making it completely invisible. The tree control is fully functional — items populate, right-click context menus work, selections register — but nothing is visible on screen. The tree becomes briefly visible when closing a document (OpenGL surface is destroyed) and a black rectangle appears in its place when dragging the document window. This appears to be the macOS equivalent of bug 2398 ("OpenGL is only used on top level windows so child windows get overdrawn"), which was fixed for the X11 driver in Wine 0.9.57. The Mac driver uses separate Core Animation layers for OpenGL surfaces, and these layers always render on top of GDI-rendered sibling windows regardless of WS_CLIPSIBLINGS. Steps to reproduce: 1. Install SolidWorks 2025 in a clean wineprefix on macOS (Apple Silicon via Rosetta 2). As the solidworks installer does not work this must be done manually either from the offline installer or from an existing installation. 2. Launch SolidWorks and open any part document 3. Observe that the left panel area (Feature Manager tree) is blank/invisible 4. Right-click the blank area — correct context menus appear, confirming the tree exists Expected: Tree panel visible alongside the 3D viewport, with viewport clipped by WS_CLIPSIBLINGS Actual: OpenGL viewport's CALayer covers the entire tree panel area Wine debug output (+win) shows: - Tree panel window uses parent surface (apply_window_pos reports surface 0x0 -> 0x0) - Viewport window rect (-1,150)-(1709,1090) overlaps tree at (0,150)-(240,1090) - Both windows receive paint messages and render correctly to their respective surfaces The OpenGLSurfaceMode registry setting partially confirms this: - "transparent": tree becomes visible when viewport is undocked, but opaque GL rendering still covers tree when docked - "behind": viewport becomes invisible (GL behind all content) System: macOS 26.3, Apple Silicon (M-series), Wine 11.0 stable, Rosetta 2 translation Attachments to include: - Wine terminal output with WINEDEBUG=+win,+key showing F9 toggle (attach as .txt.gz) - Screenshot showing blank tree area with working right-click menu -- 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 50824] New: ISdone.dll error 5, something releated to insufficient virtual memory
by WineHQ Bugzilla July 8, 2026

July 8, 2026

https://bugs.winehq.org/show_bug.cgi?id=50824 Bug ID: 50824 Summary: ISdone.dll error 5, something releated to insufficient virtual memory Product: Wine Version: 6.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: gab.pulcio(a)gmail.com Distribution: --- Created attachment 69642 --> https://bugs.winehq.org/attachment.cgi?id=69642 WINEDEBUG loaddll Warning: I know I'm about to ask you to fix something releated to game repacks, which they're illegal (provided I don't have the legal copy) but in my logic, that's a windows releated-thing and it should be fixed, maybe not now, but at least should be considered. Now, fitgirl repacks crashes at random progress, while rg-mechanics repacks are straight to the error, the same as always. I read that in the past this was fixed so that's a regression but since no-one has reported this and apparently no one has that problem, I'm filing this bug as normal. For the record: this bug happens since I installed linux, at the time Wine was at version 6.0. In my case, this repack is of a game that I legally own (Far Cry 3: Blood Dragon) but I've got a capped data plan and I have to install a repack then I'll be able to verify the game with Uplay. -- 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 16

[Bug 59825] New: focus tracking not quite correct when focus-follows-mouse
by WineHQ Bugzilla July 8, 2026

July 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59825 Bug ID: 59825 Summary: focus tracking not quite correct when focus-follows-mouse Product: Wine Version: 11.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: galtgendo(a)o2.pl Distribution: --- This might be just a different variant of bug 57682, but till proven otherwise, I treat it as a separate problem. It might also just be an openbox specific issue. Anyway, getting to point. Window manager is set to focus-follows-mouse with focus delay of 800ms. As an example, I'm using two f2p games to demonstrate the problem, but simply cause it's easiest to show it with these two. The mentioned games are Unnamed Space Idle and Synergism (both in their Windows versions). USI is Godot, Synergism is Electron. After putting Synergism on top of the other in a cascade like manner, I'm able to do the following: I move the mouse cursor from outside of the windows through uncovered portion of USI window to the Synergism window quickly enough that focus delay doesn't raise USI window then stop there. Window manager gives the focus to Synergism window and that should be it... Yet, as I move mouse over the Synergism window, I can see that despite USI window not having focus, it displays mouse tooltips for the elements it hovers over, despite being mostly covered and technically unfocused. As USI doesn't have (IIRC) any 'trigger by hover' actions, in this case it's mostly cosmetic, but if it did, I strongly suspect it would be more than that. -- 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