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

[Bug 57405] New: Arabic diacritics not rendered correctly
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

https://bugs.winehq.org/show_bug.cgi?id=57405 Bug ID: 57405 Summary: Arabic diacritics not rendered correctly Product: Wine Version: 9.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: usp10 Assignee: wine-bugs(a)winehq.org Reporter: fahad.alsaidi(a)gmail.com Distribution: --- Created attachment 77391 --> https://bugs.winehq.org/attachment.cgi?id=77391 the problem shown comparing with gedit if the arabic text has Arabic diacritics, it will not render correctly. Letters not connecting in the right way How to test it: 1- copy this text to notepad: بِسْمِ ٱللَّٰهِ ٱلرَّحْمَٰنِ ٱلرَّحِيمِ 2- compare it to gedit or any editor supporting Arabic see the attachment. -- 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 7054] Pure Pinball game crashes trying to access freed texture objects
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=7054 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |odecif(a)gmail.com --- Comment #25 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- *** Bug 55612 has been marked as a duplicate of this 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 0

[Bug 60167] New: Silhouette Studio UI gets drawn very slowly
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60167 Bug ID: 60167 Summary: Silhouette Studio UI gets drawn very slowly Product: Wine Version: 11.15 Hardware: x86-64 URL: https://web.archive.org/web/20251028021457/https://d62 nvtdcnsm38.cloudfront.net/files/softwares/ss/SS_V5.0.4 02.001_W6R.exe OS: Linux Status: UNCONFIRMED Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: lingm+winebz(a)posteo.org Target Milestone: --- Distribution: ArchLinux Created attachment 81805 --> http://bugs.winehq.org/attachment.cgi?id=81805 wine11.15 console log Tested with Silhouette Studio 5.0.402.001. As the title says, the UI is very slow to appear. E.g. when you click File -> New it takes a good 5 seconds for the changed UI to be fully done. A lot of d2d fixmes in the output. > $ du -h SS_V5.0.402.001_W6R.exe > 474M SS_V5.0.402.001_W6R.exe > $ sha1sum SS_V5.0.402.001_W6R.exe > 94a6d61cd4f27e3f4a6d3f3116501d2d5b2ad4ef SS_V5.0.402.001_W6R.exe -- 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 60169] New: FileBrowser ListView does not correctly process the mouse-scrolling (horizontally)
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60169 Bug ID: 60169 Summary: FileBrowser ListView does not correctly process the mouse-scrolling (horizontally) Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)list.winehq.org Reporter: kyle.kcsoftwares(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81809 --> http://bugs.winehq.org/attachment.cgi?id=81809 Screenshot Reproduction steps: -open an explorer filebrowser in details view, e.g. in "My computer" -resize the window to make it have a horizontal scrollbar but no vertical scrollbar -click into the list view once to give it focus -now scroll with the mouse wheel Expected behavior: -The horizontal scrollbar gets scrolled Observed behavior: -scrolling does nothing Was supposed to be fixed by https://bugs.winehq.org/show_bug.cgi?id=22253 but is not OR has regressed -- 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 60166] New: AudioScore Ultimate 6.5 demo has problems with uninstalling
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60166 Bug ID: 60166 Summary: AudioScore Ultimate 6.5 demo has problems with uninstalling Product: Wine Version: 11.15 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 Target Milestone: --- Distribution: --- Created attachment 81804 --> http://bugs.winehq.org/attachment.cgi?id=81804 screenshot Using AudioScore Ultimate 6.5 demo from https://www.instaluj.cz/audioscore-ultimate/starsi-verze-download/audioscor… When attempting to uninstall (running "wine UNWISE.EXE") the process is "frozen" at the AudioScore Spawner.exe stage without any relevant log items -- 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 60160] New: Error when trying to run Rapydmark memory tests
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60160 Bug ID: 60160 Summary: Error when trying to run Rapydmark memory tests Product: Wine Version: 10.0 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: iggykvnski(a)gmail.com Target Milestone: --- Created attachment 81786 --> http://bugs.winehq.org/attachment.cgi?id=81786 Rapydmark Backtrace Rapydmark is unable to complete memory tests. It can be downloaded from here: https://www.overclock.net/posts/29596010/ It needs vcredist_x86.exe to be installed. Rapydmark.exe will run. I have not been able to run 64-bit Rapydmark so far but that's not an immediate concern. Backtrace is 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 6

[Bug 58228] New: Move child object page unable to fully load because it is too long
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=58228 Bug ID: 58228 Summary: Move child object page unable to fully load because it is too long Product: WineHQ Apps Database Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: appdb-unknown Assignee: wine-bugs(a)winehq.org Reporter: dimesio(a)earthlink.net Distribution: --- When merging entries, the page that shows the entries to move the child objects to displays as one long list in alphabetical order. That list is now so long that the page cannot fully load: Ooops! Something has gone terribly wrong! Our monkey train has derailed! Worry not, a webmaster gopher help army has been dispatched and is on the way. If this error continues to be a problem, please report it to us on our Forums error details: Error Message: Maximum execution time of 60 seconds exceeded File: query.php:119 Discovered while trying to merge 千千静听 (TTPlayer) https://appdb.winehq.org/objectManager.php?sClass=application&iId=11003 with TTPlayer https://appdb.winehq.org/objectManager.php?sClass=application&iId=6077. The move child objects page only got as far as the H's before timing out. -- 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 59082] New: RtlLeaveCriticalSection section spam wizard101.
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=59082 Bug ID: 59082 Summary: RtlLeaveCriticalSection section spam wizard101. Product: Wine Version: 10.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: cramea(a)proton.me Distribution: ArchLinux Created attachment 79869 --> http://bugs.winehq.org/attachment.cgi?id=79869 Video showing the issue. Everything you do in Wizard101 spams the RtlLeaveCriticalSection error, and everything in the game takes way longer to load than in native Windows. It also affects loading screens and in-world asset loading. The culprit definitely has to be whatever is causing this RtlLeaveCriticalSection error to be spammed. -- 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 14

[Bug 60174] New: Text in BackPacker game main menu is in the wrong place and upside down
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60174 Bug ID: 60174 Summary: Text in BackPacker game main menu is in the wrong place and upside down Product: Wine Version: 8.9 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)list.winehq.org Reporter: alexhenrie24(a)gmail.com Target Milestone: --- Distribution: --- The game BackPacker has been through a lot on Wine: The main menu rendered correctly on Wine 8.8. After <https://gitlab.winehq.org/wine/wine/-/commit/3b01fb113fc9b21ebed63f25ff7b80…>, the text on the buttons became too faint to read. After <https://gitlab.winehq.org/wine/wine/-/commit/b3bec339d7851b14abf6f6ca341731…>, the game failed to start with the error "Not enough memory to run BACKPACK.EXE." After <https://gitlab.winehq.org/wine/wine/-/commit/7292edaf55bd18a83b4067e60e52bb…>, the game starts and the text is the right color but in the wrong place and upside down. $ sha256sum Backpacker-1995-English.iso e42377a1e608e66f4926d5f91ce773cd02a74dc05a718a7f843ee19a2c9b49b8 -- 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 60171] New: A click that falls through a native-surface-less active top-level window incorrectly deactivates it
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

http://bugs.winehq.org/show_bug.cgi?id=60171 Bug ID: 60171 Summary: A click that falls through a native-surface-less active top-level window incorrectly deactivates it Product: Wine Version: 11.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Keywords: patch Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: devel(a)velmeden.info Target Milestone: --- Distribution: ArchLinux Created attachment 81813 --> http://bugs.winehq.org/attachment.cgi?id=81813 Patch *I ran into this bug but could not find or reproduce the underlying cause myself, so I investigated it together with an AI assistant. The text and patch below is written by the AI, based on that interactive troubleshooting session.* ## Summary `process_mouse_message()` (`dlls/win32u/message.c`) reactivates whatever top-level window a click's X11 event resolves to, and deactivates the previously-active window as a side effect, whenever the clicked window differs from the currently active one. This is correct when the click is a genuine user action on a different window. It is wrong when the currently active top-level window has no native (X11) surface of its own: any click physically within that window's on-screen bounds can only ever be delivered by the X server to whatever real window happens to be underneath or around it (typically an ancestor), since the active window itself has nothing on screen to receive input. Wine currently can't tell these two cases apart, so it deactivates a window the user visually clicked on, purely because of how the click was routed at the X11 level. ## Why a top-level window can have no native surface Some applications create ordinary (non-`WS_CHILD`) top-level windows whose visible content is presented through some other mechanism than Wine's own X11 "whole window" — for example, a toolkit-hosted child surface embedded inside a native host window, where the toolkit's own window/surface object is what's actually on screen, while the win32-visible `HWND` exists purely for message routing, focus and activation bookkeeping. In such a case `X11DRV_get_whole_window(hwnd)` legitimately returns `0` for that `HWND` even though it is a real, activatable top-level window as far as the win32 window manager is concerned. ## Observed effect I diagnosed this on Wine 11.14 against Loxone Config (an MFC + Qt6 hybrid application), whose MDI document window is exactly such a case: its X11 "whole window" is destroyed early on and never recreated for the rest of the session (confirmed structural, not a transient timing gap — traced via `create_whole_window()`/`destroy_whole_window()` instrumentation across a full session), while Wine's own bookkeeping still tracks it as the active top-level window (`NtUserGetForegroundWindow()`/`info.hwndActive`). Any real mouse click physically over that window's on-screen area resolves, at the raw X11 level, to whichever window is actually behind it (confirmed via instrumented `X11DRV_ButtonPress` logging the raw event's `window`/`subwindow` fields together with each window's actual X11 id — the click's `ButtonPress` event targets the ancestor's real X11 window, never the document window's, because the latter doesn't have one). `process_mouse_message()` then runs its normal `WM_MOUSEACTIVATE`/`set_foreground_window()`/`set_active_window()` cascade for "a click on a different top-level window", which sends `WM_ACTIVATE(WA_INACTIVE)` to the window that was actually still active and that the click was visually intended for. Any interaction state that window's application logic keeps tied to activation (for example, a pending drag-and-drop-style operation initiated by an earlier click) gets torn down as a result, even though the user's click landed squarely inside that window's visible bounds. This does not require the click to race anything — in the traced case, the affected window had already been without a native surface for ~30 seconds before the failing click, so this is a deterministic misclassification, not a timing-sensitive race. ## Steps to reproduce 1. Download Loxone Config: https://updatefiles.loxone.com/LoxConfig/LoxoneConfigSetup_17010727.zip 2. Unzip it and run the installer under Wine: `wine LoxoneConfigSetup.exe` (click through the installer normally). 3. Launch `LoxoneConfig.exe` and open or create any project. 4. Pick any block/object to add, either via the search dialog (press `F5` to open it, type e.g. `RS` to find the "RS Flipflop" block, and pick it from the results) or by dragging one of the toolbar symbols — either way it attaches to the mouse cursor as a drag preview. 5. Move the mouse over the project canvas and click to place it. Expected: the block is placed on the canvas. Actual: the drag preview disappears on mouse-down, but no block is actually added — no visible change, and `Edit` → `Undo` stays greyed out, confirming the placement was never registered. This is 100% reproducible. ## Fix Attached patch adds a `WindowHasNativeSurface(HWND) -> BOOL` user driver entry point (default `TRUE`; implemented for `winex11.drv` via the existing `X11DRV_get_whole_window()` helper, other drivers unaffected). In `process_mouse_message()`, before running the reactivation cascade for a click that resolves to a different top-level window, check whether the window Wine still considers active has no native surface and geometrically contains the click point; if so, treat this as a click-through rather than a genuine activation change, and skip the cascade. The check is narrowly scoped: it does not redirect the click itself, does not touch window-surface creation/lifecycle, and every other click-resolution/activation path (including everything on drivers other than `winex11.drv`, where the new hook always returns `TRUE`) is unaffected. ## Testing - Live-validated against the real application described above: prior to the fix, the described interaction failed 100% of the time; after the fix, the specific click-misrouting-to-an-ancestor mechanism no longer tears down the document window's activation state (confirmed via the same gdb instrumentation, both on a debug and on a release (`-O2`) Wine build). - `dlls/user32/tests/msg.c` and `dlls/user32/tests/input.c` run clean (via an isolated `Xephyr` X server, since the interactive desktop proved too environment-sensitive for a byte-accurate baseline comparison): no activation/`WM_ACTIVATE`/`WM_MOUSEACTIVATE`-related failures attributable to the patch across multiple runs. ## Known limitation of this report I don't yet have a minimal, app-independent C reproduction case for this specific mechanism (a separate, previously-considered mechanism for the same user-facing symptom turned out, on later investigation, to be a distinct and still-open issue in the same application, unrelated to this patch). I'm glad to build one (the core ingredients — a top-level window with no native surface set as active, and a second, real window overlapping its screen area — should be reproducible with plain Win32 API plus one Wine-internal step to force the surface-less state) if that would help review; in the meantime the patch was developed and validated against a live repro that exhibits the exact structural condition described above, with full gdb-level traces at each step (raw X11 event routing, `set_active_window()` call arguments, and whole-window create/destroy lifecycle) establishing the mechanism precisely rather than by inference. -- 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