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

[Bug 60264] New: Wine32 FTBFS using clang and --without-mingw

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60264 Bug ID: 60264 Summary: Wine32 FTBFS using clang and --without-mingw Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: NEW Keywords: download, source Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: imwellcushtymelike(a)gmail.com Target Milestone: --- Distribution: Debian Created attachment 81980 --> http://bugs.winehq.org/attachment.cgi?id=81980 wine-11.16-156-g2ecc2f84b45 logs Trying to build a 32-bit Wine with clang --without-mingw fails, printing hundreds of lines of the type: tmp6a974931/shell32-00000000.spec-00000001.s:42266:10: error: Could not find incbin file 'dlls/shell32/shell32.res' .incbin "dlls/shell32/shell32.res",3114524,1640 ^ tmp6a974931/shell32-00000000.spec-00000001.s:42270:10: error: Could not find incbin file 'dlls/shell32/shell32.res' .incbin "dlls/shell32/shell32.res",3116196,3752 A 64-bit build simply refuses to go ahead ("try installing mingw"), but a new WOW64 build completes without issue. Is this type of build still supported on clang? Workaround is to add -fno-integrated-as to the CFLAGS. -- 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.

Aug. 31, 2026

[Bug 52798] Wine32 Configure on x86-64 System Fails due to libdbus 32-bit development files not found

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=52798 --- Comment #8 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Is this still an issue? -- 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.

Aug. 31, 2026

[Bug 59769] Wine 11.9 FTBFS on Linux aarch64 with Clang: error: call to undeclared library function '_ReadWriteBarrier' with type 'void (void)';

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59769 --- Comment #4 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Which staging patches? Does it build okay without them? -- 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.

Aug. 31, 2026

[Bug 49029] ABBYY FineReader 12 Professional crashes in trial mode

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=49029 --- Comment #4 from Anastasius Focht <focht(a)gmx.net> --- Hello Nikolay, indeed fixed by commit https://gitlab.winehq.org/wine/wine/-/commit/21735ee8342e24fedc5d372d155761… ("msxml3: Rework DOM API.") thanks. Part of Wine 11.7 release. wine-11.6, clicking 'Run Program': --- snip --- $ WINEDEBUG=+msxml,+heap,+seh wine FineReader.exe >>log.txt 2>&1 ... 03a0:trace:msxml:domelem_removeAttribute (033F7DE8)->(L"type") 03a0:trace:msxml:domelem_remove_qualified_item (033F7DE8)->(L"type" (null) 00000000) ... 03a0:trace:msxml:domattr_Release 0515F668, refcount 0. 03a0:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=0000000079BBD071 03a0:trace:seh:dispatch_exception info[0]=0000000000000000 03a0:trace:seh:dispatch_exception info[1]=00000000FEEEFEEE --- snip --- wine-11.7: --- snip --- 0914:trace:msxml:domelem_removeAttribute 037E3FEC, L"type". 0914:trace:heap:RtlSizeHeap handle 00110000, flags 0, ptr 037E2B00, return 0x10, status 0. 0914:trace:heap:RtlFreeHeap handle 00F30000, flags 0, ptr 03D3E690, return 1, status 0. 0914:trace:msxml:domattr_Release 037E401C, refcount 0. 0914:trace:heap:RtlSizeHeap handle 00110000, flags 0, ptr 037E2CB0, return 0x10, status 0. 0914:trace:heap:RtlFreeHeap handle 00110000, flags 0, ptr 037E2CB0, return 1, status 0. --- snip --- $ wine --version wine-11.7 Regards -- 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.

Aug. 31, 2026

[Bug 60263] New: winemac.drv: cross-process child window Metal swapchains not implemented (Steam client renders black); the CAContext/CALayerHost route already exists and is only reached from vulkan.c

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60263 Bug ID: 60263 Summary: winemac.drv: cross-process child window Metal swapchains not implemented (Steam client renders black); the CAContext/CALayerHost route already exists and is only reached from vulkan.c Product: Wine Version: 11.16 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs(a)list.winehq.org Reporter: winebugs(a)protonmail.ch Target Milestone: --- winemac.drv contains this FIXME: Cross-process child window Metal swapchains are not implemented This is the whole reason Steam's client renders as a black window under Wine on macOS, and the route to fix it already exists in the tree — it is simply never reached from the Metal side. ## What happens Steam's CEF GPU process asks for a Metal view for a child window whose root lives in the *browser* process. `get_win_data()` returns NULL by construction for a foreign HWND — `win_datas` is a process-local CFDictionary — and the caller aborts on the null view by design. Chromium restarts the GPU process, it dies identically, and after ~6 attempts it gives up. Black window. Two things make this hard to spot: - The `CreateSwapChain` cross-process guard never fires for this window, because `GetWindowThreadProcessId()` says the *child* belongs to us. The Win32 process check and winemac's realization check disagree, and the path trusts the first. - It is backend-independent: forcing `--use-angle=swiftshader` (no Metal, no GPU driver at all) produces the same crash count and a byte-identical black capture. ## The route already in the tree `macdrv_client_surface_acquire_metal_swapchain()` builds a `CAContext`-backed offscreen swapchain and posts `WM_MACDRV_CREATE_REMOTE_LAYER` to the window's owning process, which hosts it via `CALayerHost`. That is exactly the cross-process case. In stock Wine only `vulkan.c` reaches it. Wiring the Metal side to fall back to that route when `get_win_data()` returns NULL makes Steam's client render completely, out-of-process, with text, no injected switches and 0 GPU crashes. ## Working implementation, for reference A working version of both halves is public here, under MIT: https://github.com/macgameport/cities-skylines-2-macos/blob/main/scripts/wi… Notes from getting it working, in case they save someone time: - **Do not add a member to `macdrv_functions_t`** to expose the entry point — that struct is `C_ASSERT`-ed at a fixed size, so a client built against a larger struct would read past the end of an older winemac's and call whatever followed. A standalone exported symbol degrades safely. - **Convert Win32 pixels to Cocoa points at the CALayerHost entry points.** `CALayer.frame` is in points; unconverted frames are 2x too large on retina and the content is pushed down and right. - **Stack the hosted layers by Win32 paint order, not insertion order.** CEF recreates a swapchain on every resize, so insertion order puts whichever browser was recreated last on top. Steam runs two sibling browsers and the client goes black. - **An empty child rect is not "no rect".** CEF keeps an inactive browser in the z-order at 0x0; treating that as "no rect supplied" and stretching the layer over the view blacks the window. - **Retire a superseded layer on CREATE, not on destroy**, or the child is unhosted between the two and the window blinks through during a resize. ## Disclosure This was investigated with heavy AI assistance, so I am filing a report rather than a patch, and the implementation above is offered only as a reference someone may or may not want to look at. I am also aware of the relicensing discussion in 3Shain/dxmt#152 and am not asking for anything to be taken as-is. -- 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.

Aug. 31, 2026

[Bug 60262] New: winemac.drv: macOS title bar drawn on frameless windows that reclaim the caption via WM_NCCALCSIZE, displacing all mouse input

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60262 Bug ID: 60262 Summary: winemac.drv: macOS title bar drawn on frameless windows that reclaim the caption via WM_NCCALCSIZE, displacing all mouse input Product: Wine Version: 11.16 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs(a)list.winehq.org Reporter: winebugs(a)protonmail.ch Target Milestone: --- winemac.drv draws a macOS title bar on a window that reclaimed its caption area via `WM_NCCALCSIZE`, and the resulting geometry displaces all mouse input by the caption height. ## Reproducer 60 lines, no game or third-party app required: https://github.com/macgameport/cities-skylines-2-macos/blob/main/scripts/fr… ## Steps to reproduce 1. Build the attached 60-line reproducer: `x86_64-w64-mingw32-gcc -O2 -o frameless-repro.exe frameless-window-repro.c -lgdi32` 2. `wine frameless-repro.exe` It creates a `WS_OVERLAPPEDWINDOW` and, in `WM_NCCALCSIZE`, reserves a 5px border on the left, right and bottom and **zero** on the top — the frameless-but-resizable pattern used by Electron and CEF apps. `SWP_FRAMECHANGED` is applied after creation so the change takes effect. ## Expected `dx=5 dy=0` (border kept, caption reclaimed) and **no** title bar — the application declined the caption and draws its own chrome there. ## Actual The window reports `dx=5 dy=0` as expected, and winemac draws a macOS title bar with traffic lights anyway. Applications that draw their own title bar therefore show **two**. The knock-on effect is worse than cosmetic: the Cocoa content view ends up ~28pt shorter than the client rect Win32 reports, so `ScreenToClient` subtracts a window origin ~56px above where the NSWindow actually is. **Every control hit-tests below the visible pointer** — you must hold the cursor above a button to activate it. Measured on a real application (the Paradox launcher shipped with Cities: Skylines II): ``` Win32 window rect : 228,346 px = 114,173 pt Cocoa window drawn at : 232,402 px = 116,201 pt -> 56 px = 28 pt apart Cocoa window 1279 x 674 pt Cocoa content view 1279 x 642 pt -> a 32 pt title bar that should not exist Win32 client rect 1279 x 669.5 pt -> widths identical, heights 27.5 pt apart ``` Not a pointer-mapping bug — `GetCursorPos` agrees with macOS `CGEvent` to within truncation (`dx -0.4, dy -0.4 px`, pointer verified stationary by bracketing the reads). ## Analysis Two functions answer "does this window have a title bar" from different inputs, and nothing reconciles them: | caller | function | input | |---|---|---| | `macdrv_GetWindowStyleMasks` — win32u asks how much non-client space the window rect reserves | `get_window_features_for_style()` | **style bits only** | | window creation / style change — the actual Cocoa decoration | `get_cocoa_window_features()` | style bits **+ `data->rects`** | `get_cocoa_window_features()` already carries an evidence-based override — `EqualRect(&data->rects.window, &data->rects.visible)` — so the incompleteness of the style test was clearly known. But it never consults `rects.client`, which is precisely the record of what `WM_NCCALCSIZE` did, and `struct window_rects` carries it already. **That guard is also why this is not more widely noticed.** An application that reclaims the *entire* window rect gets `dx=0 dy=0`, `window == visible` fires, and the window is left undecorated — Steam's own client does exactly this and is unaffected. The bug needs a **border with no caption**, which is the more common Electron shape. ## What does not fix it Suppressing `title_bar` in `get_cocoa_window_features()` when `client.top == window.top` removes the doubled chrome but **not the offset**: `GetWindowStyleMasks` still reports caption masks, win32u keeps reserving the space, and the NSWindow simply moves down by it. Measured content-view vs client: 27.5pt apart before and after. A fix has to make both answers share one source of truth, and the ordering is the hard part — `GetWindowStyleMasks` is called *while* win32u is computing the very rects it would need to consult. ## Disclosure This was investigated with heavy AI assistance. I am filing a bug report rather than a patch, and the reproducer is deliberately small enough to confirm or dismiss in two minutes without taking my analysis on trust. -- 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.

Aug. 31, 2026

[Bug 60261] New: movavi video editor bug ON STEAM LINUX

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60261 Bug ID: 60261 Summary: movavi video editor bug ON STEAM LINUX 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: pocomal112(a)codverts.com Target Milestone: --- Distribution: --- CANT LAUNCH MOVAVI VIDEO EDITOR 2025 AND 2026 STEAM VERSION ON LINUX AND I DONT HAVE BUG FILES. PLEASE FIX IT. MOVAVI VIDEO EDITOR STEAM VERSION NOT LAUNCHING -- 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.

Aug. 31, 2026

[Bug 60260] Listview text disappears when selected

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60260 --- Comment #3 from Sven Schnelle <svens(a)stackframe.org> --- Created attachment 81979 --> http://bugs.winehq.org/attachment.cgi?id=81979 Text invisible after select -- 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.

Aug. 31, 2026

[Bug 60260] Listview text disappears when selected

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60260 --- Comment #2 from Sven Schnelle <svens(a)stackframe.org> --- Reverting 7499d158b96 ("comctl32/listview: Set the initial background mix mode to TRANSPARENT.") fixes the issue. -- 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.

Aug. 31, 2026

[Bug 60260] Listview text disappears when selected

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60260 --- Comment #1 from Sven Schnelle <svens(a)stackframe.org> --- Created attachment 81978 --> http://bugs.winehq.org/attachment.cgi?id=81978 Screenshot of the window in question -- 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.

Aug. 31, 2026