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

[Bug 59928] New: Std 32-bit build fails with "../wine/dlls/oleaut32/vartype.c:3000:1: internal compiler error"
by WineHQ Bugzilla Sept. 4, 2026

Sept. 4, 2026

http://bugs.winehq.org/show_bug.cgi?id=59928 Bug ID: 59928 Summary: Std 32-bit build fails with "../wine/dlls/oleaut32/vartype.c:3000:1: internal compiler error" Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: build-env Assignee: wine-bugs(a)list.winehq.org Reporter: depaoli.renzo(a)gmail.com Distribution: --- Good afternoon. Environment: Debian 12 32-bit Test case: Bog standard 32-bit build attempt, .i.e. cd ~/Downloads/sources/wine.win32/ ../wine/configure make -j8 Make fails with: ../wine/dlls/oleaut32/vartype.c: In function 'VarR4FromUI8': ../wine/dlls/oleaut32/vartype.c:3000:1: internal compiler error: in assign_stack_local_1, at function.cc:429 3000 | } | ^ 0xb75c82d4 __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0xb75c8397 __libc_start_main_impl ../csu/libc-start.c:360 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. make: *** [Makefile:155835: dlls/oleaut32/i386-windows/vartype.o] Error 1 make: *** Waiting for unfinished jobs.... -- 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 26

[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 Sept. 3, 2026

Sept. 3, 2026

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.

1 5

[Bug 60207] New: VirtualDJ 2026: persistent skin corruption (ghost hover highlights, flickering) because d3d11_swapchain_Present1 ignores DXGI_PRESENT_PARAMETERS
by WineHQ Bugzilla Sept. 3, 2026

Sept. 3, 2026

http://bugs.winehq.org/show_bug.cgi?id=60207 Bug ID: 60207 Summary: VirtualDJ 2026: persistent skin corruption (ghost hover highlights, flickering) because d3d11_swapchain_Present1 ignores DXGI_PRESENT_PARAMETERS Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: bghome(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81893 --> http://bugs.winehq.org/attachment.cgi?id=81893 WINEDEBUG=+dxgi, DXVK disabled Overview -------- dlls/dxgi/swapchain.c:d3d11_swapchain_Present1() discards the DXGI_PRESENT_PARAMETERS argument entirely: static HRESULT STDMETHODCALLTYPE d3d11_swapchain_Present1(IDXGISwapChain4 *iface, UINT sync_interval, UINT flags, const DXGI_PRESENT_PARAMETERS *present_parameters) { struct d3d11_swapchain *swapchain = d3d11_swapchain_from_IDXGISwapChain4(iface); TRACE("iface %p, sync_interval %u, flags %#x, present_parameters %p.\n", iface, sync_interval, flags, present_parameters); if (present_parameters) FIXME("Ignored present parameters %p.\n", present_parameters); return d3d11_swapchain_present(swapchain, sync_interval, flags); } That struct carries DirtyRectsCount, pDirtyRects, pScrollRect and pScrollOffset. The FIXME is widely seen and generally assumed to be cosmetic, because for most applications it only costs an optimisation. For an application that presents *incrementally* on a flip-model swap chain it is not cosmetic: it produces permanent, highly visible rendering corruption, and no error is returned. Per Microsoft's flip-model presentation documentation, the scroll rectangle is "the area of the previous frame that the operating system needs to copy to the current frame before it renders the current frame". That copy is the runtime's responsibility, and Wine never performs it. Consequence: as the flip chain rotates, each back buffer only ever receives the damage that happened to be drawn while it was the current buffer. The buffers diverge permanently and the display alternates between two partially-updated frames, forever. Application ----------- VirtualDJ 2026 (build 9583), https://download.virtualdj.com/b9583/89CED1AB/install_virtualdj_2026_b9583_… - free to download and run without a licence, so the bug is reproducible without a purchase. The defect is in its "experimental skin engine" feature, which is enabled by default. Symptoms visible to the user: - a button stays highlighted after the cursor has moved to a different button, so two or more controls appear hovered at once; - dialog window borders flicker continuously; - tooltips and hint balloons blink on and off at frame rate. Steps to reproduce ------------------ 1. Install and start VirtualDJ 2026 (no need to load a track). 2. Make sure Settings -> Performance -> experimentalSkinEngine is "auto" or "yes" (the default). 3. Move the mouse onto deck B's CUE button, then onto the SYNC button next to it, and hold the cursor still. 4. Both CUE and SYNC are shown highlighted, and stay that way. Setting experimentalSkinEngine to "no" makes every symptom disappear. Environment ----------- wine-staging 11.0 under Bottles 66.7, win10 mode, X11 (WINEPREFIX has wayland driver disabled). Intel Arc (MTL), Mesa 26.1.6. Reproduced with Wine's own dxgi + wined3d, i.e. with DXVK disabled. It also reproduces with DXVK 3.0.2, because DXVK has the same gap (dxgi_swapchain.cpp: PresentBase() calls m_presenter->Present(SyncInterval, PresentFlags, nullptr)). So this is not a DXVK-specific problem; both paths discard the struct. Expected behaviour ------------------ d3d11_swapchain_Present1 should honour DXGI_PRESENT_PARAMETERS - at minimum pScrollRect/pScrollOffset, which the runtime is documented to copy from the previously presented buffer before the application renders the current frame. A conservative alternative that would also fix the corruption: when present_parameters is non-NULL, ensure the incoming back buffer contains the previously presented frame before returning, so that an application which redraws only its damaged regions still produces a coherent frame. Actual behaviour ---------------- The parameters are dropped, no copy is performed, no error or warning is returned to the application, and the swap chain's buffers diverge permanently. -- 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 57473] New: Virtual DJ 2024: Main interface animation flickers
by WineHQ Bugzilla Sept. 3, 2026

Sept. 3, 2026

https://bugs.winehq.org/show_bug.cgi?id=57473 Bug ID: 57473 Summary: Virtual DJ 2024: Main interface animation flickers Product: Wine Version: 9.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: rizalmart98(a)gmail.com Distribution: --- The main interface was shaking and flickers The terminal shows this error message: 01f0:fixme:d2d:d2d_text_renderer_DrawGlyphRun Ignoring options 0x6. -- 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 11

[Bug 60251] New: ~29s stall on ntdll loader_section during startup, tied to a Win32_LogicalDiskToPartition WMI query on the Z: drive
by WineHQ Bugzilla Sept. 3, 2026

Sept. 3, 2026

http://bugs.winehq.org/show_bug.cgi?id=60251 Bug ID: 60251 Summary: ~29s stall on ntdll loader_section during startup, tied to a Win32_LogicalDiskToPartition WMI query on the Z: drive Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wmi&wbemprox Assignee: wine-bugs(a)list.winehq.org Reporter: aktaskazimcan0(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81964 --> http://bugs.winehq.org/attachment.cgi?id=81964 WINEDEBUG=+loaddll,+wbemprox trace showing the loader_section stall Note on environment: I'm running this under a Vinegar-managed prefix with DXVK-Sarek installed (native d3d8/d3d9/d3d10core/d3d11/dxgi overrides) and a custom Wine build (see "Additional information" below). I'm flagging this upfront per the Wine bug-reporting guidelines around native DLL overrides/third-party builds. That said, the stall happens while loading comctl32/compstui/winspool/wbemprox - none of the DLLs DXVK overrides - so it's unlikely to be DXVK-related, but I wanted to be transparent about the setup rather than have that surface later. Description of problem: On startup, my application (Roblox Studio, running under a Vinegar-managed prefix on Linux/CachyOS, btrfs root) consistently stalls for ~29 seconds early in startup, blocking the whole process. With WINEDEBUG=+loaddll,+wbemprox, the trace shows wbemprox.dll being loaded, followed by a ~29 second gap with *no trace output at all* on either channel, during which four other threads time out waiting on the ntdll loader_section (held by the thread that loaded wbemprox.dll). Full trace excerpt attached (winedebug-loaddll-wbemprox-trace.log). After the gap, thread 00fc proceeds through WbemLocator_create -> ConnectServer(ROOT\CIMV2) -> ExecQuery with an ASSOCIATORS query against Win32_LogicalDisk.DeviceID='Z:' (AssocClass=Win32_LogicalDiskToPartition). This query then resolves within the same second (fill_logicaldisktopartition created 1 rows, etc.) - the ~29s delay appears to happen *before* the WMI call chain is even entered (DllGetClassObject itself is the first thing logged after the gap), not within WMI processing itself. I was not able to pin down the exact syscall/operation responsible for the gap via strace - the slowest filesystem-related syscalls captured were on the order of tens of milliseconds, nowhere near 29s, so it does not appear to be filesystem/disk I/O bound in any obvious way. Happy to gather additional traces (e.g. a specific WINEDEBUG channel, or strace focused on a narrower window) if that would help narrow it down further. This reproduces consistently (every launch) on this system. How reproducible: Always (on this system) Steps to reproduce: 1. Launch an application that performs a Win32_LogicalDiskToPartition ASSOCIATORS WMI query against a drive early in startup (observed with Roblox Studio; have not yet tried a minimal WMI-only reproducer). 2. Run with WINEDEBUG=+loaddll,+wbemprox and observe the gap between wbemprox.dll loading and the first wbemprox trace line. Actual results: ~29 second stall, with the whole process blocked (other threads time out on the loader lock). Expected results: No significant stall before the WMI query executes. Additional information: - Wine version: wine-11.16 (custom build via vinegarhq/kombucha, built from upstream Wine commit 8da89f8493b21ebfbe344a54dbef0cde23c7ea59). This build carries 14 local patches; two touch ntdll (one adjusts LFH heap block-group lifetime in dlls/ntdll/heap.c, one narrows known-DLL/ search-path handling specifically for ucrtbase.dll in dlls/ntdll/loader.c - both ported from Valve's Wine/Proton fork). The ucrtbase.dll one does touch find_dll_file/open_known_dll in loader.c, though its actual behavior change is gated on the DLL name being "ucrtbase.dll" specifically, not wbemprox.dll/comctl32.dll/winspool.drv (the DLLs involved in this stall) - so it looks unlikely to be the direct cause, but I can't fully rule out an indirect interaction given it's in the same loader path. Neither patch touches wmi/wbemprox code directly. Happy to attempt a repro against a clean upstream Wine build if that would help isolate this. - Distro: CachyOS (Arch-based), root filesystem is btrfs - The affected drive (Z:) maps to the Linux root filesystem -- 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 60026] New: Adobe Photoshop Camera Raw AI-Denoiser issue
by WineHQ Bugzilla Sept. 3, 2026

Sept. 3, 2026

http://bugs.winehq.org/show_bug.cgi?id=60026 Bug ID: 60026 Summary: Adobe Photoshop Camera Raw AI-Denoiser issue Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: lyushukovdmitry(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81459 --> http://bugs.winehq.org/attachment.cgi?id=81459 Camera raw log Error from Camera Raw`s log: *** Error: WML API Failed (WML_LoadFromData, unknown error ) *** -- 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 12

[Bug 37355] New: Tages Protection v5.x needs ntoskrnl 'MmMapLockedPagesSpecifyCache' implementation
by wine-bugs＠winehq.org Sept. 3, 2026

Sept. 3, 2026

https://bugs.winehq.org/show_bug.cgi?id=37355 Bug ID: 37355 Summary: Tages Protection v5.x needs ntoskrnl 'MmMapLockedPagesSpecifyCache' implementation Product: Wine Version: 1.7.27 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntoskrnl Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Hello folks, reported here: https://github.com/compholio/wine-compholio/issues/80 Michael Müller from FDS team: --- quote --- Sadly this is not enough to make the Tages copy protection happy. The issue you are now running into is: fixme:ntoskrnl:MmMapLockedPagesSpecifyCache (0x111988, 0, 1, (nil), 0, 32): stub The MmMapLockedPagesSpecifyCache command is used to map memory of a process into the kernel, so that a kernel driver can write / read it. This is necessary since the kernel does not share the same address space as the process. The problem is that this command is a stub and always returns 0 as mapped address. The Tages protection does not check for NULL pointers and tries to write to the address resulting in: wine: Unhandled page fault on write access to 0x00000000 at address 0x57fe27 (thread 0018), starting debugger... The problem is that there is no way to properly implement this on Linux since there is no way to simply map the memory of a different process if you are not inside the kernel. Since wine is no kernel module it can only use memory of different processes, when they explicitly create it as shared memory block. Sadly you can not declare a memory block as shared after it was allocated, so this does not help implementing this command. Anyway in the case of the Tages protection we have some luck since it seems like the process is paused (I think it was waiting for the response of the DeviceIoControl function) while the memory is changed by the windows kernel driver. This allows us to emulate the mapping of the memory by using ReadProcessMemory and WriteProcessMemory. I wrote some hack to implement this, but this only prevented the crash and made the application to exit silently. I either made a mistake in my hack or there is still something else which prevents it from working. --- quote --- 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.

3 57

[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 Sept. 2, 2026

Sept. 2, 2026

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.

1 2

[Bug 30523] New: Jupiter crashes when trying to fill online tax declarations
by wine-bugs＠winehq.org Sept. 2, 2026

Sept. 2, 2026

http://bugs.winehq.org/show_bug.cgi?id=30523 Bug #: 30523 Summary: Jupiter crashes when trying to fill online tax declarations Product: Wine Version: 1.5.2 Platform: x86 URL: http://pity.elfin.pl/pliki/Jupiter/Jupiter2011/std/1.0 .5.6/Jupiter2011_std_1.0.5.exe OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: washuu(a)eastnews.com.pl Classification: Unclassified Created attachment 39930 --> http://bugs.winehq.org/attachment.cgi?id=39930 sample data file with bogus numbers Jupiter is free, downloadable program for calculating taxes in Poland, it's quite popular. I found using it under Wine quite uncomfortable, because of a few bugs. Here is one of them: - install the application. In my case it went without any glitches. - run the application. - open the attached sample data file, using menu "Plik" ("file") and "Otworz" ("open"). - wait a few seconds to open data file, when it is loaded you see some text in the middle, starting with "dziekujemy za skorzystanie z programu". - in the menu, choose "Rozliczenia" ("statements") and "e-deklaracje" ("e-declarations"). The program crashes with error: Unhandled exception: page fault on write access to 0x017c0bce in 32-bit code (0x02358bf5). Backtrace: =>0 0x02358bf5 (0x0033f804) 1 0x7c0af136 in mscoree (+0xf135) (0x0033f874) 2 0x7e71b84a CoCreateInstance+0x369() in ole32 (0x0033f8e4) 3 0x004167e4 in jupiter (+0x167e3) (0x7ea9c9d0) 4 0xb8ec81ec (0x8b55ff8b) 0x02358bf5: addb %al,0x0(%eax). -- 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.

2 10

[Bug 60087] New: GDI+ cannot find a private font family by its reported name
by WineHQ Bugzilla Sept. 1, 2026

Sept. 1, 2026

http://bugs.winehq.org/show_bug.cgi?id=60087 Bug ID: 60087 Summary: GDI+ cannot find a private font family by its reported name Product: Wine Version: 11.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdiplus Assignee: wine-bugs(a)list.winehq.org Reporter: brandowlucas(a)gmail.com Target Milestone: --- Distribution: ArchLinux Created attachment 81608 --> http://bugs.winehq.org/attachment.cgi?id=81608 +timestamp,+tid,+gdiplus,+font When running Adobe Premiere Pro 2025 25.5 with Wine 11.14-14-g84fe968b936, startup fails with the following message after the Adobe Clean fonts have been installed and registered: unable to load operating system font. GDI Status: FontFamilyNotFound Font: Adobe Clean Style The same behavior can be reproduced without Adobe using the existing long font name resource in the GDI+ font tests. After a private font is loaded, `GdipGetFamilyName()` reports its family name, but passing that name and the same collection to `GdipCreateFontFamilyFromName()` returns `FontFamilyNotFound`. The reduced trace shows: trace:gdiplus:GdipGetFamilyName 0000000000837220, 000000000031F9F0, 0 trace:gdiplus:GdipCreateFontFamilyFromName L"wine_3_this_is_a_very_long_name", 0000000000823FC0 000000000031F9E0 trace:font:font_EnumFonts facename = L"wine_3_this_is_a_very_long_name" charset 1 font.c:124: Test failed: GdipCreateFontFamilyFromName failed: 14 `GdipCreateFontFamilyFromName()` currently asks GDI to enumerate the requested name and compares the resulting `LOGFONTW.lfFaceName` with the family names stored in the private collection: if (!wcsicmp(lf.lfFaceName, collection->FontFamilies[i]->FamilyName)) The name returned by GDI can differ from the name stored and reported by GDI+. This causes a valid family in the supplied private collection to be rejected. Steps to reproduce: 1. Add a font with a long family name to a private GDI+ font collection. 2. Obtain its name with `GdipGetFamilyName()`. 3. Pass that name and the same collection to `GdipCreateFontFamilyFromName()`. 4. Observe that unpatched Wine returns `FontFamilyNotFound` with status 14. The candidate patch first compares the requested name with the family names in the supplied collection. It retains the existing comparison with the name returned by GDI as a fallback. The patch also extends `test_long_name()` to exercise this lookup. The new check fails on unpatched Wine in both 32 bit and 64 bit tests: font.c:124: Test failed: GdipCreateFontFamilyFromName failed: 14 The check passes with the candidate patch in both architectures. The complete local font test still has four unrelated metric failures at `font.c:452`, which occur with both the patched and unpatched builds. Application verification confirms that the patch removes the Adobe Clean `FontFamilyNotFound` startup failure. Native Windows test results have not been 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