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

[Bug 60189] New: Built-in d3dx9 causes visual artifacts in Lego Star Wars 3 III (GoG version)
by WineHQ Bugzilla Aug. 18, 2026

Aug. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60189 Bug ID: 60189 Summary: Built-in d3dx9 causes visual artifacts in Lego Star Wars 3 III (GoG version) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: fcasas(a)codeweavers.com Target Milestone: --- Distribution: --- Created attachment 81874 --> http://bugs.winehq.org/attachment.cgi?id=81874 Screenshot with highlighted artifacts. Recent upstream vkd3d-shader updates allow the game shaders to compile correctly. However I noticed that updating Wine itself (on a Wine with custom vkd3d build) introduces small, previously unseen, visual artifacts. These artifacts consist in some flickering black stains that can be easily seen in the characters in the intro animation. They are easier to spot in motion but I attach a screenshot highlighting them. I ran a bisection and concluded that this bug is introduced in commit 306c3af83faca8bd384df24d370a863cab5ed394 d3dx9: No longer prefer native. So it might be considered a regression. -- 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 60193] New: wineconsole: ReadConsoleInputW never delivers a KEY_DOWN record for non-Latin (Cyrillic) keyboard-layout keys, only KEY_UP
by WineHQ Bugzilla Aug. 18, 2026

Aug. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60193 Bug ID: 60193 Summary: wineconsole: ReadConsoleInputW never delivers a KEY_DOWN record for non-Latin (Cyrillic) keyboard-layout keys, only KEY_UP 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: unxed(a)mail.ru Target Milestone: --- Distribution: --- Component: console Version: (fill in actual `wine --version`, seen with a recent 11.x build) Summary: When the active keyboard layout is switched to a non-Latin one (Cyrillic, via Alt+Shift) inside a console application that reads raw input via ReadConsoleInputW, pressing a key that produces a Cyrillic character delivers only the KEY_UP input record for that key. The corresponding KEY_DOWN record is never generated/delivered at all -- not filtered by modifiers, not present with a zero character, simply absent. The same physical key, before switching layout (still Latin/US), delivers both KEY_DOWN and KEY_UP normally. Reproduction: 1. Run a console application under `wineconsole` (also reproduces under plain `wine app.exe` launched from a unix terminal) that logs every KEY_EVENT_RECORD it receives from ReadConsoleInputW/PeekConsoleInputW, including bKeyDown, wVirtualKeyCode, wVirtualScanCode, uChar, and dwControlKeyState. 2. Type a Latin letter, e.g. `f`. Confirm both KEY_DOWN and KEY_UP records are logged. 3. Switch the keyboard layout to Russian (Alt+Shift, or whatever the host is configured to use). 4. Type the Cyrillic letter on the same physical key (e.g. `ф`, which sits on the same key as Latin `a`, scan code 0x1E on a US-QWERTY board). Expected: a KEY_DOWN record with bKeyDown=TRUE, the Cyrillic character in uChar, followed by a matching KEY_UP record. Actual: no KEY_DOWN record appears at all for that keypress. Only a single KEY_UP record is delivered, with bKeyDown=FALSE and uChar=0 ('\0'). The application has no way to know a key was pressed until it's already released, and never receives the character. Example log excerpt (application-side, timestamps/PID prefix stripped): Key{VK:VK_MENU Scan:0x38 DOWN Mods:Alt} <- Alt down (layout switch chord) Key{VK:VK_MENU Scan:0x38 UP Mods:Shift} Key{VK:VK_SHIFT Scan:0x2A UP Mods:None} Key{VK:VK_A Scan:0x1E UP Mods:None} <- the "ф" key: KEY_UP only, no KEY_DOWN, Char=0 No KEY_DOWN for VK_A/scan 0x1E appears anywhere in the log before this KEY_UP, at any point since the previous, unrelated keypress. This was diagnosed by instrumenting the calling application at the very first point after ReadConsoleInputW returns (before any of the application's own filtering), so it is not the application dropping or misinterpreting an incoming DOWN event -- the DOWN event itself is not being produced/delivered by Wine's console input path for this key in this layout state. Environment where this was observed: - Host: Linux (Mint/Cinnamon, X11) and separately a second machine running a different distro -- reproduced on at least two independent setups. - Both `wineconsole app.exe` and `wine app.exe` (launched from a unix terminal, using the console's own window) show the same symptom. - Not observed for Latin-layout keys on the same host/session. Impact: any console application relying on ReadConsoleInputW for text entry cannot receive Cyrillic (and presumably other non-Latin-layout) character input at all under affected Wine versions/console frontends. Happy to attach a WINEDEBUG=+key,+keyboard trace and/or a minimal reproducer if useful -- ask and I'll provide it. -- 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 60191] New: winex11: Owned WS_EX_TOOLWINDOW popups are override-redirect and stay above other applications
by WineHQ Bugzilla Aug. 18, 2026

Aug. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60191 Bug ID: 60191 Summary: winex11: Owned WS_EX_TOOLWINDOW popups are override-redirect and stay above other applications Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: Urias.Uhle(a)web.de Target Milestone: --- Distribution: --- An owned WS_POPUP window with WS_EX_TOOLWINDOW is a palette. On Windows it stays above its owner but goes behind another application when that application is activated. is_window_managed() in dlls/winex11.drv/window.c returns FALSE for such a window, so Wine creates it override-redirect. The window manager never stacks it, and it floats above every other window on the desktop for as long as it exists. Reproduced with Autodesk Fusion, whose docked palettes are exactly this window class. Qt creates WS_POPUP | WS_EX_TOOLWINDOW; see !11415 for the same window class on the Wayland side, there without an owner. Managing owned tool window popups fixes it. Adding the rule as the last check in is_window_managed(), right before the default "return FALSE", keeps it free of side effects, because every window reaching that point is unmanaged in stock Wine. I measured that over a matrix of 25 top level windows covering 21 style, ex-style and owner combinations, reading back override-redirect, _NET_WM_WINDOW_TYPE and WM_TRANSIENT_FOR from the X server: exactly one row changes, the owned tool window, from unmanaged to managed. Two things that make it safe are already in place. get_mwm_decorations_for_style() returns 0 for WS_EX_TOOLWINDOW, so no title bar appears, and _NET_WM_STATE_SKIP_TASKBAR is already set for tool windows, so no taskbar entry appears. _NET_WM_WINDOW_TYPE_UTILITY would also be the correct type for these windows. EWMH defines it as "a small persistent utility window, such as a palette or toolbox". The atom is declared in Wine but never used; owned popups currently get the dialog type. Tested on GNOME with XWayland. I am not opening a merge request, because I worked this out with LLM assistance and the WineHQ contributor policies ask contributors to refrain from 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 3

[Bug 60192] New: ntsync: lost wakeup causes permanent deadlock on infinite-timeout WAIT_ANY
by WineHQ Bugzilla Aug. 18, 2026

Aug. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60192 Bug ID: 60192 Summary: ntsync: lost wakeup causes permanent deadlock on infinite-timeout WAIT_ANY Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: strikeralt40(a)gmail.com Target Milestone: --- Distribution: --- Summary Under heavy multi-threaded load, ntsync intermittently and permanently loses a wakeup for an infinite-timeout wait (NTSYNC_IOC_WAIT_ANY with timeout = U64_MAX). The waiter never wakes even though the event it waits on is set tens of thousands of times afterward. The task remains blocked in schedule_hrtimeout_range_clock() forever, deadlocking the entire application. Reproduced with Grand Theft Auto V (job-system synchronization) on kernel 7.1.8-1-cachyos. The same workload runs indefinitely with esync/fsync, and the same game runs indefinitely on ntsync once it gets past the freeze window, so the failure is a rare, intermittent lost-wakeup race, not a guaranteed bug. Environment - Kernel: 7.1.8-1-cachyos (CONFIG_NTSYNC=m, ntsync loaded, /dev/ntsync rw-rw-rw) - ntsync source: drivers/misc/ntsync.c, identical logic in v7.1 and current master (the only master difference is timens_ktime_to_host, which does not touch the sleep path) - Wine: cachyos-11.0 (Wine 11.0), 64-bit, NTSYNC_IOC_WAIT_ANY - Application: Grand Theft Auto V v1.69, job-system spawns dozens of worker threads - strace 7.0 attached to all GTA5.exe threads during a live freeze Reproduction Run GTA V (or any app that heavily uses ntsync events with infinite waits across many threads) under Wine with ntsync. The job system freezes at a random time — minutes to ~2 hours in. Symptoms at freeze: - Main thread spins forever in GTA5.exe+0x165F5B5 (job-sync spin loop) - Job counter frozen at 30 (0x1e) - Workers keep calling NTSYNC_IOC_EVENT_SET on the event the main thread waits on, but the main thread never wakes. The freeze is permanent (observed 30+ minutes). esync/fsync do not reproduce it. Trace evidence (215 MB strace capture, all GTA5.exe threads) Key ioctl counts during the freeze: ioctl count NTSYNC_IOC_EVENT_SET total 506,041 NTSYNC_IOC_EVENT_SET on fd 733 243,225 NTSYNC_IOC_WAIT_ANY issued 841,093 NTSYNC_IOC_WAIT_ANY still unfinished at capture 622,071 threads stuck in WAIT_ANY at capture end 694 The main thread's ioctl(10, NTSYNC_IOC_WAIT_ANY, ...) was issued once and never resumed (<unfinished ...> persists to end of capture), while fd 733 (a ntsync event) was set 243,225 times by worker threads. The signal was delivered to the kernel's wake path, but the waiter's wake_up_process() either raced with its schedule() or was absorbed, and the thread slept forever. Root-cause analysis ntsync_schedule() (drivers/misc/ntsync.c, both v7.1 and master): static int ntsync_schedule(const struct ntsync_q *q, const struct ntsync_wait_args *args) { ktime_t timeout = ns_to_ktime(args->timeout); clockid_t clock = CLOCK_MONOTONIC; ktime_t *timeout_ptr; int ret = 0; timeout_ptr = (args->timeout == U64_MAX ? NULL : &timeout); do { if (signal_pending(current)) { ret = -ERESTARTSYS; break; } set_current_state(TASK_INTERRUPTIBLE); if (atomic_read(&q->signaled) != -1) { ret = 0; break; } ret = schedule_hrtimeout_range_clock(timeout_ptr, 0, HRTIMER_MODE_ABS, clock); } while (ret < 0); __set_current_state(TASK_RUNNING); return ret; } The wake path (try_wake_any_event): if (atomic_try_cmpxchg(&q->signaled, &signaled, entry->index)) { if (!event->u.event.manual) event->u.event.signaled = false; wake_up_process(q->task); } For an infinite wait, timeout_ptr == NULL, so schedule_hrtimeout_range_clock(NULL, ...) is reached. In kernel/time/sleep_timeout.c: if (!expires) { schedule(); return -EINTR; } For the NULL (infinite) case, schedule_hrtimeout_range_clock() performs a plain, unconditional schedule() — it does not re-check the condition after waking, and more importantly it does not participate in the wakeup protocol the same way the non-NULL path does (hrtimer_sleeper_start_expires() + schedule() + hrtimer_cancel()). The racy window: 1. Waiter runs set_current_state(TASK_INTERRUPTIBLE), reads q->signaled == -1 (not yet signaled), is about to call schedule_hrtimeout_range_clock(NULL). 2. Waker wins atomic_try_cmpxchg(&q->signaled, -1, index), then calls wake_up_process(q->task). 3. The waiter is still on the runqueue at this point (it has not yet entered schedule()), so try_to_wake_up() takes the on_rq && ttwu_runnable() fast path in kernel/sched/core.c — it "wakes" the task without actually placing it on the runqueue, because it is already there. 4. The waiter then calls schedule(); with prev->state == TASK_INTERRUPTIBLE, __schedule() dequeues it and it sleeps. 5. q->signaled is now non--1, so every subsequent NTSYNC_IOC_EVENT_SET fails the atomic_try_cmpxchg(&q->signaled, -1, ...) and never calls wake_up_process() again. The wake is permanently lost. This exactly matches the trace: 243,225 EVENT_SET calls on the event, none of which can re-wake the thread, because the cmpxchg only succeeds once and the thread never consumes the signal. esync/fsync are immune because futex FUTEX_WAIT/FUTEX_WAKE and eventfd wakeup have stricter semantics than wake_up_process() on a task that has set_current_state(TASK_INTERRUPTIBLE) but has not yet called schedule(). Suggested fix directions 1. In ntsync_schedule(), for the infinite (timeout_ptr == NULL) case, use a loop that re-checks atomic_read(&q->signaled) after every schedule()/wakeup instead of relying on schedule_hrtimeout_range_clock() returning; and/or use wait_event_interruptible()-style semantics so that a condition satisfied before schedule() is observed after it. e.g. for timeout_ptr == NULL, replace with: while (!signal_pending(current) && atomic_read(&q->signaled) == -1) { set_current_state(TASK_INTERRUPTIBLE); if (atomic_read(&q->signaled) != -1) { ret = 0; break; } schedule(); } (which mirrors what wait_event_interruptible() does internally) so that a wakeup that "lands" before the task actually sleeps is not lost. 2. Alternatively, in the wake path, ensure that once q->signaled has been set, a subsequent wake_up_process() is issued even if the cmpxchg fails — i.e., make the wake resilient to the race by not gating the wake strictly on the cmpxchg winning. 3. Consider whether schedule_hrtimeout_range_clock(NULL) should be avoided in favor of an explicit bounded timeout converted from U64_MAX semantics, so the timer-based path (which handles spurious-wakeup correctly) is always used. Files inspected - drivers/misc/ntsync.c (v7.1.8 and master — identical sleep logic) - kernel/time/sleep_timeout.c (schedule_hrtimeout_range_clock, NULL/infinite path) - kernel/sched/core.c (try_to_wake_up, ttwu_runnable, __schedule) - strace capture /tmp/opencode/ntsync_trace.txt (215 MB, all GTA5.exe threads) Impact Any Windows app using ntsync events/mutexes with infinite waits under heavy multithreading can freeze permanently. This is not GTA-specific; GTA V is simply the test case that exercises the race often enough to observe it. The bug is present in current mainline ntsync (verified against master as of the report date). -- 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 60170] New: Emacs zoom not fully working for ASCII vs non-ASCII, unicode
by WineHQ Bugzilla Aug. 18, 2026

Aug. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60170 Bug ID: 60170 Summary: Emacs zoom not fully working for ASCII vs non-ASCII, unicode Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: fonts Assignee: wine-bugs(a)list.winehq.org Reporter: wineryyyyy(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81810 --> http://bugs.winehq.org/attachment.cgi?id=81810 Screenshot GNU Emacs 30.2 zoom not fully working for wine-11.15-ab0b3e25268 `M-x view-hello-file` shows most non-ASCII supporting zoom but not ASCII. `M-x describe-char` provides more details about each of the characters: character: λ (displayed as λ) (codepoint 955, #o1673, #x3bb) charset: unicode (Unicode (ISO10646)) code point in charset: 0x03BB script: greek Most Emacs modes mostly deal with ASCII only especially for dev purposes so zoom is broken for some of the most common modes including: - Dired - org-mode - magit - c-mode - ibuffer - shell - info Some more edge modes like eww (web browser) and image viewer support zoom. Most Emacs users will probably just use native vs Windows via wine but whatever is bugged may affect other apps so it provides a reliable reproduction. I've used Emacs to test other text/font related bugs that are still an enigma so hopefully progress for this bug will lead to solutions for those others. -- 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 16

[Bug 60186] New: Installing Mad Max [PC] causes the attached log errors.
by WineHQ Bugzilla Aug. 17, 2026

Aug. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60186 Bug ID: 60186 Summary: Installing Mad Max [PC] causes the attached log errors. Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: asiedurichard213(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81869 --> http://bugs.winehq.org/attachment.cgi?id=81869 Mad max pc game installation error(Bottles) Mad Max setup crashing on installation(Bottles) -- 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 60100] New: AppDB migration to Content Management System
by WineHQ Bugzilla Aug. 17, 2026

Aug. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60100 Bug ID: 60100 Summary: AppDB migration to Content Management System Product: WineHQ Apps Database Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: appdb-unknown Assignee: wine-bugs(a)list.winehq.org Reporter: wineryyyyy(a)gmail.com Target Milestone: --- Distribution: --- This is more an enhancement request than bug but may serve as a catch all for current AppDB bugs: - https://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&b… AppDB repo celebrates it's 22th anniversary this year: 8f28ae10c40de0794a72fef07f7e05f1017cb691 Author: Jeremy Newman <jnewman(a)winehq.org> AuthorDate: Mon Mar 15 16:22:00 2004 +0000 Commit: Jeremy Newman <jnewman(a)winehq.org> CommitDate: Mon Mar 15 16:22:00 2004 +0000 In-house AppDB may have been a wiser decision in 2004 because many open source CMSs were still fairly early and perhaps less capable of serving AppDB needs but for 2026 it feels like a decision whether to use Bugzilla or Gitlab vs custom in-house solutions. Therefore this bug is for open discussion and feedback regarding migrating AppDB to one of many CMS solutions: - https://en.wikipedia.org/wiki/List_of_content_management_systems I have most dev exp. and expertise with Drupal and Moodle both written in PHP and supported by nearly identical software stack as AppDB. Moodle has an online demo available and Drupal offers a lesser convenient localhost demo that requires downloading: - https://sandbox51.moodledemo.net/login/index.php - https://www.drupal.org/project/drupaldemo Moodle is technically a Learning Management System (LMS) but may be used as a CMS just as Drupal may also be customized as an LMS via various plugin modules. Moodle has some builtin surveying/quiz features that may be useful for AppDB and better handled as an integral part vs as plugins by Drupal or other more generic CMSs. Customizing these CMSs from AppDB admins/maintainers experience should feel equivalent to that of Bugzilla and Gitlab which is largely supported via web-based UIs vs involving PHP or SQL changes often required for AppDB customizations. Source is still available when needed but changes overall should be rare like Bugzilla and Gitlab. CMSs would automatically fix many AppDB bugs including security vulnerabilities: - https://bugs.winehq.org/show_bug.cgi?id=21639 - https://bugs.winehq.org/show_bug.cgi?id=22798 Upgrading AppDB may also enable it to evolve in a more modern flexible direction toward protondb which may encourage more user engagement and assist maintainers with more convenient workflows: - https://www.protondb.com/app/1042380 There is much more to discuss but please consider this hardly urgent enough to distract from much higher priorities. If anyone has any suggests, requests, or feedback regarding their experience with AppDB and how it may be improved outside what has already been reported for Bugzilla or what may be currently be considered outside the realm of possibility then please feel free to report it here. In the meantime I continue to work in my spare time toward a proof of concept for review based on my exposure to AppDB and experience with CMSs. -- 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 10

[Bug 60187] New: Ownerless layered popup windows are mapped override-redirect, so the window manager keeps them above every other window and on every virtual desktop
by WineHQ Bugzilla Aug. 17, 2026

Aug. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60187 Bug ID: 60187 Summary: Ownerless layered popup windows are mapped override-redirect, so the window manager keeps them above every other window and on every virtual desktop Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: Wagner.a18(a)yahoo.com Target Milestone: --- Distribution: --- `is_window_managed()` in `dlls/winex11.drv/window.c` classifies an ownerless `WS_POPUP` window carrying `WS_EX_LAYERED | WS_EX_TOOLWINDOW | WS_EX_NOACTIVATE` as unmanaged, so winex11.drv maps it override-redirect. Override-redirect is the right choice for the transient UI it was designed for (menus, tooltips), but applications also use exactly these flags for long-lived windows — most notably custom frame decorations. Codejock Xtreme Toolkit Pro draws the drop shadow of its main frame into such a window (caption `XTPFrameShadow`), and it stays mapped for as long as the main frame is in its restored state. Because the window is override-redirect, the window manager cannot place it in the normal stacking order and cannot assign it a virtual desktop. The result is a window that: - floats above every other window on the screen, including windows of other applications, regardless of which window has focus - appears on every virtual desktop, while the main frame it belongs to stays on the one it was opened on On Windows the same window is an ordinary top-level window that participates normally in the Z order and disappears with the rest of the application. ## Steps to reproduce 1. Build the attached reproducer: `winegcc -mwindows -o repro repro.c -luser32 -lgdi32` 2. Run it: `wine repro.exe.so` 3. Give another application focus so that it overlaps the reproducer's main window 4. Switch to another virtual desktop ## Current behaviour The semi-transparent grey `ReproOverlay` rectangle stays on top of the other application, and it remains visible after switching virtual desktops. Walking the X window tree shows the overlay is override-redirect while the main window is not: 0x3c00001 592x366 +204+230 VIEWABLE ovr=0 repro main window 0x3c00004 620x420 +190+190 VIEWABLE ovr=1 ReproOverlay ## Expected behaviour The overlay should be stacked with its application and confined to the virtual desktop that application is on, i.e. it should be a managed window. With the patch below applied, the same reproducer maps the overlay as a managed window: 0x3a00001 592x366 +204+230 VIEWABLE ovr=0 repro main window 0x3a00004 620x420 +190+190 VIEWABLE ovr=0 ReproOverlay and the window manager now tracks it like any other window: ReproOverlay WM_STATE : Normal _NET_WM_DESKTOP : 0 _NET_WM_STATE : DEMANDS_ATTENTION, SKIP_TASKBAR, SKIP_PAGER, _KDE_NET_WM_STATE_SKIP_SWITCHER Note `_NET_WM_DESKTOP`, which an override-redirect window cannot carry at all - that is what confines the overlay to one virtual desktop. The skip states come from the existing `WS_EX_NOACTIVATE` handling, so the window does not show up in the taskbar or the window switcher. One observation: KWin also sets `_NET_WM_STATE_DEMANDS_ATTENTION` on the overlay, presumably because it is mapped without ever taking focus. With the three skip states set there is no UI element left for it to affect, so this appears harmless, but it is a behaviour difference worth mentioning. ## Analysis The window falls through every branch of `is_window_managed()`: - it is `WS_POPUP`, so the `WS_CHILD` early-out does not apply - it is shown with `SWP_NOACTIVATE` and is not the active window - it has neither `WS_CAPTION` nor `WS_THICKFRAME` - it is `WS_POPUP` but has no `WS_SYSMENU` and is not fullscreen - it has no `WS_EX_APPWINDOW` - it owns no popups so the function returns FALSE and the window is created with `attr.override_redirect = TRUE`. Observed flags of the real-world case (Codejock `XTPFrameShadow`, read with `GetWindowLongW` from a separate process attached to the same prefix): STYLE 0x94000000 : WS_POPUP WS_VISIBLE WS_CLIPSIBLINGS EXSTYLE 0x08080080 : WS_EX_TOOLWINDOW WS_EX_LAYERED WS_EX_NOACTIVATE owner : NULL ## Proposed patch Treat ownerless layered popups as managed unless they are click-through. `WS_EX_TRANSPARENT` is what separates this case from short-lived drag images, which do need to stay unmanaged. ```diff --- a/dlls/winex11.drv/window.c +++ b/dlls/winex11.drv/window.c @@ -461,6 +461,16 @@ static BOOL is_window_managed( HWND hwnd, UINT swp_flags, BOOL fullscreen ) /* application windows are managed */ ex_style = NtUserGetWindowLongW( hwnd, GWL_EXSTYLE ); if (ex_style & WS_EX_APPWINDOW) return TRUE; + /* Ownerless layered popups that aren't click-through belong to applications + * drawing their own frame decorations - Codejock's XTPFrameShadow puts the + * drop shadow of its main frame into one. They live as long as the frame + * does, so leaving them unmanaged makes the window manager stack them in + * its override-redirect layer, above every other window and on every + * virtual desktop. Click-through ones (WS_EX_TRANSPARENT) are short-lived + * drag images and have to stay unmanaged. */ + if ((style & WS_POPUP) && !NtUserGetWindowRelative( hwnd, GW_OWNER ) && + (ex_style & (WS_EX_LAYERED | WS_EX_TRANSPARENT)) == WS_EX_LAYERED) + return TRUE; /* windows that own popups are managed */ if (has_owned_popups( hwnd )) return TRUE; /* default: not managed */ ``` No decoration or taskbar regression is expected for such windows: `get_mwm_decorations_for_style()` already returns 0 for both `WS_EX_TOOLWINDOW` and `WS_EX_LAYERED`, and `WS_EX_NOACTIVATE` already causes `SKIP_TASKBAR | SKIP_PAGER | SKIP_SWITCHER` to be set. The heuristic is open to discussion — the point of the report is the mapping decision, not this particular discriminator. ## Environment - Wine 11.15 - KDE Plasma / KWin on Wayland, application running through XWayland - Only verified against KWin. The mapping decision itself is WM-independent, but the precise stacking and virtual-desktop consequences are KWin's behaviour for override-redirect windows. ## Reproducer ```c /* winegcc -mwindows -o repro repro.c -luser32 -lgdi32 */ #include <windows.h> static LRESULT CALLBACK proc( HWND h, UINT m, WPARAM w, LPARAM l ) { if (m == WM_DESTROY) { PostQuitMessage( 0 ); return 0; } if (m == WM_PAINT) { PAINTSTRUCT ps; HDC dc = BeginPaint( h, &ps ); FillRect( dc, &ps.rcPaint, (HBRUSH)GetStockObject( GRAY_BRUSH ) ); EndPaint( h, &ps ); return 0; } return DefWindowProcA( h, m, w, l ); } int WINAPI WinMain( HINSTANCE inst, HINSTANCE prev, char *cmd, int show ) { WNDCLASSA c = { 0 }; HWND main_wnd, overlay; MSG msg; c.lpfnWndProc = proc; c.hInstance = inst; c.hCursor = LoadCursorA( NULL, (LPCSTR)IDC_ARROW ); c.lpszClassName = "ReproMain"; RegisterClassA( &c ); c.lpszClassName = "ReproOverlay"; RegisterClassA( &c ); main_wnd = CreateWindowExA( 0, "ReproMain", "repro main window", WS_OVERLAPPEDWINDOW | WS_VISIBLE, 200, 200, 600, 400, NULL, NULL, inst, NULL ); /* Same flags Codejock's XTPFrameShadow uses for the frame drop shadow. * No owner, and deliberately no WS_EX_TRANSPARENT. */ overlay = CreateWindowExA( WS_EX_LAYERED | WS_EX_TOOLWINDOW | WS_EX_NOACTIVATE, "ReproOverlay", "ReproOverlay", WS_POPUP, 190, 190, 620, 420, NULL, NULL, inst, NULL ); SetLayeredWindowAttributes( overlay, 0, 128, LWA_ALPHA ); SetWindowPos( overlay, HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE | SWP_SHOWWINDOW ); while (GetMessageA( &msg, NULL, 0, 0 )) { TranslateMessage( &msg ); DispatchMessageA( &msg ); } return 0; } ``` -- 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 60183] New: wg_format_from_caps has no image/* branch — Media Foundation Source Reader fails to decode WebP sprites (MEError 0xc00d3e85)
by WineHQ Bugzilla Aug. 17, 2026

Aug. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60183 Bug ID: 60183 Summary: wg_format_from_caps has no image/* branch — Media Foundation Source Reader fails to decode WebP sprites (MEError 0xc00d3e85) Product: Wine Version: 11.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)list.winehq.org Reporter: mendez.gabriele(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81858 --> http://bugs.winehq.org/attachment.cgi?id=81858 MF Source Reader fails to decode WebP sprites (Unhandled caps image/webp → MEError 0xc00d3e85), PNG through same path works. WINEDEBUG=+mfplat,+mfreadwrite,+mf, wine 11. A Windows game (Internet Survivor Survivors, Steam app 4625810, DXライブラリ/DxLib engine) decodes sprite images stored as WebP through the Media Foundation Source Reader. On wine, this fails: every WebP sprite produces MEError 0xc00d3e85 and an empty texture, while PNG and MP4 files going through the exact same MFCreateSourceReaderFromURL path decode correctly. The root cause is a missing branch in wg_format_from_caps: wine's GStreamer backend successfully typefinds image/webp, loads libgstwebp, creates the "webpdec" element and links it — but wine's glue layer (wg_format_from_caps in dlls/winegstreamer/wg_format.c) has no case for image/* caps at all, so it falls through to the GST_FIXME "Unhandled caps" path and the conversion from GStreamer caps to MF media type never happens. Relevant fact: wg_format_from_caps() in wine master (as of 2026-08-16) only handles: audio/x-raw, video/x-raw, audio/mpeg, audio/x-wma, video/x-cinepak, video/x-indeo, video/x-wmv, video/mpeg, video/x-h264. There is no image/* major type. Any image format decoded via GStreamer will hit the same wall — not just WebP. The game works on real Windows because the OS ships the "WebP Image Extensions" Store package, which registers the MF/WIC handler for image/webp. Environment: - wine base: wine 11 (via proton-cachyos-slr, CachyOS Proton build) - GPU: AMD Radeon RX 6400 (RADV, Mesa 26.1.6-arch3.1) - Kernel: 7.1.8-1-cachyos - Compositor: Hyprland (Wayland), game launched through gamescope Steps to reproduce: 1. Launch the game (Internet Survivor Survivors, Steam 4625810) under wine/Proton. 2. Play until any enemy drops coins or until a WebP sprite is loaded. 3. Observe: the sprite is invisible (empty texture). The game continues normally. 4. (Instrumented) Launch with WINEDEBUG=+mfplat,+mfreadwrite,+mf to capture the Source Reader traces. Expected behavior: WebP sprites decode to textures and render visibly, same as PNG. Actual behavior: WebP sprites produce MEError 0xc00d3e85 and render as empty/black. Trace evidence (from WINEDEBUG=+mfplat,+mfreadwrite,+mf, 667k-line log): 1. GStreamer side works — image/webp is typefound, libgstwebp loads, webpdec element is created and linked: 0:00:00.009092474 GST_TYPEFIND gsttypefind.c:72:gst_type_find_register: registering typefind function for image/webp 0:00:00.011216905 GST_EVENT gstevent.c:912:gst_event_new_caps: creating caps event image/webp 0:00:00.012228410 GST_PLUGIN_LOADING gstplugin.c:999:_priv_gst_plugin_load_file_for_registry: plugin "...libgstwebp.so" loaded 0:00:00.012233630 GST_ELEMENT_FACTORY gstelementfactory.c:490:gst_element_factory_create_with_properties: creating element "webpdec" 0:00:00.012308701 GST_PADS gstpad.c:2449:gst_pad_link_prepare: trying to link typefind:src and webpdec0:sink 0:00:00.012313270 GST_PADS gstpad.c:2630:gst_pad_link_full: linked typefind:src and webpdec0:sink, successful 0:00:00.012331264 GST_STATES gstelement.c:2798:gst_element_continue_state: <webpdec0> completed state change to READY 2. Wine's glue then fails — wg_format_from_caps hits the unhandled-caps FIXME: 0:00:00.011275646 FIXME WINE wg_format.c:681:wg_format_from_caps: Unhandled caps image/webp. (Also from winedmo:) 0288:fixme:dmo:demuxer_create Unknown MIME type for format "webp_pipe", url "C:\\users\\steamuser\\AppData\\Local\\Temp\\tmp1c21.tmp" 3. MEError 0xc00d3e85 is queued for every WebP sprite: 01c4:trace:mfplat:eventqueue_QueueEventParamVar 00000000007131C0, MEError, {00000000-0000-0000-0000-000000000000}, 0xc00d3e85, (null) 01c4:trace:mfplat:MFCreateMediaEvent MEError, {00000000-0000-0000-0000-000000000000}, 0xc00d3e85, (null), 0000000004A3DEE8. 4. The full chain for one sprite (goldcoinbig): - Game calls MFCreateSourceReaderFromURL on the original PNG: 0194:trace:mfplat:MFCreateSourceReaderFromURL L"Z:\\...\\Data\\img\\item\\goldcoinbig.png", 0000000000000000, 000000000A8F1220. - Game then extracts a WebP copy to %TEMP% and calls MFCreateSourceReaderFromURL on it: 0194:trace:mfplat:MFCreateSourceReaderFromURL L"C:\\users\\steamuser\\AppData\\Local\\Temp\\tmp32aa.tmp", 0000000000000000, 000000000A8F1220. - GStreamer processes it (typefind → webpdec, see #1 above)... - Wine glue aborts (see #2 above)... - MEError fires (see #3 above). - Result: empty texture, sprite invisible. 5. For comparison, PNG through the same Source Reader produces zero errors: 01c4:trace:mfplat:MFCreateSourceReaderFromURL L"Z:\\...\\Data\\img\\Shot\\berry_circle_b\\magiccircleb0320.png", 0000000000000000, 000000000A7C3480. (No MEError follows — clean decode.) 6. The WebP files are static lossless (VP8L), not animated: - 96 WebP files dumped from %TEMP%, every one is RIFF...WEBP with VP8L chunk. - No ANIM or ANMF chunks present in any file. Suggested fix: Add an image/* branch to wg_format_from_caps() in dlls/winegstreamer/wg_format.c, mapping image/webp (and potentially other image formats) to the appropriate MF media type (MFMediaType_Image with MFImageFormat_WebP, or a raw video format equivalent). The GStreamer decoder pipeline already works end to end — only the caps-to-MF-type conversion is missing. Additionally, the winedmo demuxer_create() in dlls/winedmo/unix_demuxer.c should handle the "webp_pipe" MIME type (currently falls through to "Unsupported MIME type"). See also: - Bug 59848 (feature request: "Please add WebP, AVIF and JXL support") — this report provides a concrete game reproduction and trace evidence for the WebP case. - wine master wg_format.c: https://github.com/wine-mirror/wine/blob/master/dlls/winegstreamer/wg_forma… -- 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 57777] New: "Hoshi no Otome to Rikka no Shimai" (AdvHD.exe): unable to run with font errors
by WineHQ Bugzilla Aug. 17, 2026

Aug. 17, 2026

https://bugs.winehq.org/show_bug.cgi?id=57777 Bug ID: 57777 Summary: "Hoshi no Otome to Rikka no Shimai" (AdvHD.exe): unable to run with font errors Product: Wine Version: 10.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: sd369888(a)outlook.com Distribution: --- Created attachment 77977 --> https://bugs.winehq.org/attachment.cgi?id=77977 logs The game "Hoshi no Otome to Rikka no Shimai" (AdvHD.exe), crashes when I try to run it in wine, and throws an error: 0024:fixme:font:NtGdiRemoveFontMemResourceEx (0x77386331) stub. I have only installed wine geko and did not touch anything of my wine installation. The heap log is here: https://oshi.at/PLup -- 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 20