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

[Bug 59965] New: x11drv UI elements become unclickable after switching windows due to unexpected WM_CANCELMODE during mouse grab
by WineHQ Bugzilla July 7, 2026

July 7, 2026

http://bugs.winehq.org/show_bug.cgi?id=59965 Bug ID: 59965 Summary: x11drv UI elements become unclickable after switching windows due to unexpected WM_CANCELMODE during mouse grab Product: Wine Version: 11.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: lldmakhbfcrmqyluns(a)nesopf.com CC: julliard(a)winehq.org, rbernon(a)codeweavers.com Target Milestone: --- Distribution: --- When switching focus between applications via Alt+Tab, the application's buttons and UI elements sometimes become completely unresponsive to mouse clicks. Steps to Reproduce (occurs from time to time): Open an application. Interact with the UI (e.g., click down on a scrollbar, a custom button, or start a drag operation). While the application is in this state, switch focus to another window (Alt+Tab). Switch back to the affected application. Sometimes the bug occurs. Actual Results: The UI ignores mouse clicks. The application is not frozen (it might still respond to keyboard input), but the internal mouse capture/UI state is broken. Workaround: The only way to restore mouse functionality is to minimize the affected window, switch to another app, and then restore the window. Minimizing forces a hard state reset and ReleaseCapture, while restoring forces a full WM_PAINT. This fixes the unclickable UI. Expected Results: Switching windows should not permanently break the application's internal mouse capture or UI state machine. Buttons should remain clickable after returning to the application. Technical Details & Proposed Fix: The issue occurs because winex11.drv sends a WM_CANCELMODE message to the foreground window when it loses focus, even if the application currently holds an X11 mouse grab (x11drv_thread_data()->grab_hwnd). This causes a desync: the application resets its internal state (cancels menus/captures due to WM_CANCELMODE), but the X11-level grab might persist or the app's internal framework gets stuck in a transitional state. Skipping WM_CANCELMODE when a mouse grab is active completely resolves the issue. Here is the patch that fixes the bug: diff --git a/dlls/winex11.drv/event.c b/dlls/winex11.drv/event.c --- a/dlls/winex11.drv/event.c +++ b/dlls/winex11.drv/event.c @@ -888,5 +888,12 @@ if (hwnd != NtUserGetForegroundWindow()) return; if (!(NtUserGetWindowLongW( hwnd, GWL_STYLE ) & WS_MINIMIZE)) - send_message( hwnd, WM_CANCELMODE, 0, 0 ); + { + if (x11drv_thread_data()->grab_hwnd) + { + TRACE("Skipping WM_CANCELMODE, mouse is grabbed by %p.\n", x11drv_thread_data()->grab_hwnd); + } + else + send_message( hwnd, WM_CANCELMODE, 0, 0 ); + } This is the same root cause as here (fix is the same): https://bugs.winehq.org/show_bug.cgi?id=59653 -- 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 51432] New: DXVA Checker 4.x (.NET 4.x app) needs DXVAHD_CreateDevice
by WineHQ Bugzilla July 7, 2026

July 7, 2026

https://bugs.winehq.org/show_bug.cgi?id=51432 Bug ID: 51432 Summary: DXVA Checker 4.x (.NET 4.x app) needs DXVAHD_CreateDevice Product: Wine Version: 6.12 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: dxva2 Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, continuation of bug 35921 Prerequisite: * 32-bit WINEPREFIX (WINEARCH=win32) to work around regression * 'winetricks -q dotnet462' --- snip --- 0148:Call KERNEL32.WideCharToMultiByte(00000000,00000000,021b5ae4 L"DXVAHD_CreateDevice",00000013,0021eb14,00000015,00000000,00000000) ret=79a94936 0148:Ret KERNEL32.WideCharToMultiByte() retval=00000013 ret=79a94936 0148:Call KERNEL32.GetProcAddress(1ff00000,0021eb14 "DXVAHD_CreateDevice") ret=06346611 0148:Ret KERNEL32.GetProcAddress() retval=00000000 ret=06346611 0148:Call KERNEL32.WideCharToMultiByte(00000000,00000000,021b5b48 L"DXVAHD_CreateDeviceW",00000014,0021eb14,00000016,00000000,00000000) ret=79a94936 0148:Ret KERNEL32.WideCharToMultiByte() retval=00000014 ret=79a94936 0148:Call KERNEL32.GetProcAddress(1ff00000,0021eb14 "DXVAHD_CreateDeviceW") ret=06346611 0148:Ret KERNEL32.GetProcAddress() retval=00000000 ret=06346611 ... 0148:trace:seh:dispatch_exception code=e0434352 flags=1 addr=7B0102F8 ip=7b0102f8 tid=0148 0148:trace:seh:dispatch_exception info[0]=80004003 0148:trace:seh:dispatch_exception info[1]=00000000 0148:trace:seh:dispatch_exception info[2]=00000000 0148:trace:seh:dispatch_exception info[3]=00000000 0148:trace:seh:dispatch_exception info[4]=014f0000 0148:warn:seh:dispatch_exception unknown exception (code=e0434352) raised 0148:trace:seh:dispatch_exception eax=0021e994 ebx=00000005 ecx=0021ea8c edx=0021ea90 esi=00000005 edi=0021ea00 0148:trace:seh:dispatch_exception ebp=0021e9e8 esp=0021e994 cs=7bc50023 ds=21002b es=7bc3002b fs=210063 gs=006b flags=00200212 0148:trace:seh:call_vectored_handlers calling handler at 016A0430 code=e0434352 flags=1 ... 0148:Call user32.MessageBoxW(00020076,021b7690 L"GetDXVAHDProcessorDeviceError\r\nValue cannot be null.\r\nParameter name: ptr",02155618 L"DXVA Checker",00000010) ret=05681e44 --- snip --- Microsoft docs: https://docs.microsoft.com/en-us/windows/win32/api/dxvahd/nf-dxvahd-dxvahd_… Wine source: https://source.winehq.org/git/wine.git/blob/d10887b8f56792ebcca717ccc28a289… (spec file doesn't list it) $ sha1sum DXVAChecker_4.5.2.zip 358542765adae8e05aa66676ba82402077e655e4 DXVAChecker_4.5.2.zip $ du -sh DXVAChecker_4.5.2.zip 1.2M DXVAChecker_4.5.2.zip $ wine --version wine-6.12-162-gd10887b8f56 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.

2 2

[Bug 58464] New: Some text now looks terrible in IDA Free 5.0
by WineHQ Bugzilla July 7, 2026

July 7, 2026

http://bugs.winehq.org/show_bug.cgi?id=58464 Bug ID: 58464 Summary: Some text now looks terrible in IDA Free 5.0 Product: Wine Version: 10.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: personaalunioon(a)disroot.org Distribution: Other After upgrading from 10.10, some text in IDA Free 5.0 looks almost unreadable. Might be related to bug 58431. Using Void Linux. -- 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 5

[Bug 59653] New: winex11.drv: FocusOut sends WM_CANCELMODE during active mouse grab, breaking drag operations
by WineHQ Bugzilla July 7, 2026

July 7, 2026

http://bugs.winehq.org/show_bug.cgi?id=59653 Bug ID: 59653 Summary: winex11.drv: FocusOut sends WM_CANCELMODE during active mouse grab, breaking drag operations Product: Wine Version: 11.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: lldmakhbfcrmqyluns(a)nesopf.com Distribution: --- When a Wine application performs a drag operation (which involves an active mouse capture via SetCapture), and the user switches focus with Alt+Tab, XWayland sends a FocusOut event to the Wine window. Currently, Wine's focus_out() handler in dlls/winex11.drv/event.c unconditionally sends a WM_CANCELMODE message to the window losing focus. This forces any well-behaved Win32 application to call ReleaseCapture() and abort the modal drag operation. This behavior is incorrect. On native Windows, an active mouse capture survives keyboard focus changes. WM_CANCELMODE should not be sent in this state. This issue is specific to the winex11.drv backend and is prominently observed on XWayland. The native winewayland.drv does not suffer from this issue, as it handles input grabs differently. The successful drag-and-drop in native Wayland mode (with the ole32 fix applied) further proves that this is an X11-specific event handling bug. Steps to Reproduce: Implement patch from bug #59652 to enable drag and drop. Run Wine under an XWayland session. Start two applications (e.g., a file manager and a text editor). In the source application, begin a drag operation by holding the left mouse button. While still holding the mouse button, press Alt+Tab to switch focus to the other application. Actual Results: The drag operation is silently cancelled. Expected Results: The drag operation should continue, allowing the user to complete the drop in the other window. Patch: The following patch modifies focus_out() to check for an active mouse grab (grab_hwnd) before sending WM_CANCELMODE. This aligns Wine's behavior with native Windows and fixes the bug. diff --- a/dlls/winex11.drv/event.c +++ b/dlls/winex11.drv/event.c @@ -2019,7 +2019,15 @@ set_focus( thread_data, NULL, NULL ); if (!(NtUserGetWindowLongW( hwnd, GWL_STYLE ) & WS_MINIMIZE)) - send_message( hwnd, WM_CANCELMODE, 0, 0 ); + { + if (x11drv_thread_data()->grab_hwnd) + { + TRACE("Skipping WM_CANCELMODE, mouse is grabbed by %p.\\n", x11drv_thread_data()->grab_hwnd); + } + else + send_message( hwnd, WM_CANCELMODE, 0, 0 ); + } if (X11DRV_GetKeyboardLayout(0) != get_thread_input_hkl(0)) X11DRV_ActivateKeyboardLayout( get_thread_input_hkl(0), 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 4

[Bug 59940] New: dxgi: dxgi_get_output_from_window returns DXGI_ERROR_NOT_FOUND with no fallback when no output matches monitor
by WineHQ Bugzilla July 6, 2026

July 6, 2026

http://bugs.winehq.org/show_bug.cgi?id=59940 Bug ID: 59940 Summary: dxgi: dxgi_get_output_from_window returns DXGI_ERROR_NOT_FOUND with no fallback when no output matches monitor Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: nileshkumbhar1604(a)gmail.com Distribution: --- Created attachment 81284 --> http://bugs.winehq.org/attachment.cgi?id=81284 DXGI error log from Epic Games Launcher Epic Games Launcher fails to start under Wine. Error in terminal: err:dxgi:dxgi_device_init Failed to get output from window Root cause: dxgi_get_output_from_window() in dlls/dxgi/swapchain.c loops through all adapter outputs looking for a monitor match. When no match is found, it returns DXGI_ERROR_NOT_FOUND with no fallback. Fix needed: Add fallback to first available output when no monitor match is found. Wine version: 11.11 OS: Linux (Ubuntu, VirtualBox) Hardware: x86-64 Additional behavior : Launcher enters a crash-restart loop. Process continuously restarts after dxgi initialization failure -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 59451] New: Open Rails component - Track Viewer drop-down menus works but are rendered black
by WineHQ Bugzilla July 6, 2026

July 6, 2026

http://bugs.winehq.org/show_bug.cgi?id=59451 Bug ID: 59451 Summary: Open Rails component - Track Viewer drop-down menus works but are rendered black Product: Wine Version: 11.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: deim(a)seznam.cz Distribution: --- Created attachment 80437 --> http://bugs.winehq.org/attachment.cgi?id=80437 All dropdowns have correct size but are rendered black Winetricks -> dxvk, dotnet48, corefonts Everything in this game works well but drop-down menus are drawn black -- 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 59959] New: Minor correction to wiki content
by WineHQ Bugzilla July 6, 2026

July 6, 2026

http://bugs.winehq.org/show_bug.cgi?id=59959 Bug ID: 59959 Summary: Minor correction to wiki content Product: WineHQ Gitlab Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: gitlab-unknown Assignee: wine-bugs(a)list.winehq.org Reporter: matt.m.seng(a)gmail.com Distribution: --- Sorry if this isn't the right place to report; it was very unclear how one might contribute discourse regarding the wiki content. I just wanted to share that there is an omission in the code posted in the following page/section: https://gitlab.winehq.org/wine/wine/-/wikis/FAQ#how-do-i-associate-a-native… The existing code block: ------------------------------------------------ [HKEY_CLASSES_ROOT\.pdf] @="PDFfile" "Content Type"="application/pdf" [HKEY_CLASSES_ROOT\PDFfile\Shell\Open\command] @="winebrowser \"%1\"" ------------------------------------------------ ... is not valid content for a properly-formatted .reg file, in the context of this documentation at least. A header defining the registry editor version is needed in order for the subsquently-documented commands to work. The following code block corrects this: ------------------------------------------------ Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\.pdf] @="PDFfile" "Content Type"="application/pdf" [HKEY_CLASSES_ROOT\PDFfile\Shell\Open\command] @="winebrowser \"%1\"" ------------------------------------------------ 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.

1 2

[Bug 59961] New: dwrite.dll (builtin) does not apply bold weight for CSS font-weight in CEF/Chromium-based application (Evernote), works correctly with native dwrite.dll
by WineHQ Bugzilla July 6, 2026

July 6, 2026

http://bugs.winehq.org/show_bug.cgi?id=59961 Bug ID: 59961 Summary: dwrite.dll (builtin) does not apply bold weight for CSS font-weight in CEF/Chromium-based application (Evernote), works correctly with native dwrite.dll Product: Wine Version: 11.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dwrite Assignee: wine-bugs(a)list.winehq.org Reporter: markus.kern1(a)gmx.at Distribution: --- Created attachment 81344 --> http://bugs.winehq.org/attachment.cgi?id=81344 with override -- Bug Report Created by Claude --- Version: wine-11.12 OS: Fedora 44, Linux (Wine devel branch) Description When running a CEF/Chromium-based Windows application under Wine, text styled with CSS font-weight: bold (or HTML tags) renders in the regular weight instead of bold. This occurs with a TrueType font family installed as separate static weight files (Regular, Bold, etc.), each registered individually under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts (e.g. "<Family> Bold (TrueType)"="<family>-bold.ttf"). Classic GDI-based rendering (tested with Notepad, same font family, same installed files) correctly displays bold text. This isolates the issue to Wine's builtin dwrite.dll font weight/family grouping rather than to font installation, registry setup, or the application itself. Steps to reproduce Install a TrueType font family with separate static weight files (Regular + Bold at minimum) into C:\windows\Fonts, with matching registry entries under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts. Run a CEF/Chromium-based Windows application that renders HTML/CSS text referencing that font family and applies font-weight: bold (or ) to part of the text. Observe that the bold text renders visually identical to the regular weight. For comparison: open Notepad and manually apply Bold formatting to text using the same installed font family — bold renders correctly there. welcher bug passt am besten zu meinem fehlerbild? Durchforstete Fehlerliste und identifizierte nächstbeste Übereinstimmung Von der Liste passt am besten: Bug 32965 – "arialbd.ttf not found (Text applied to textures in Kerbal Space Program are not visible)" (Component: fonts) Warum das die beste Übereinstimmung ist Das ist der einzige Eintrag in der Liste, der sich explizit auf die Bold-Variante einer Font-Datei bezieht (arialbd.ttf = Arial Bold) – exakt das Muster, das du hattest: Regular-Schnitt wird gefunden und korrekt gerendert, der Bold-Schnitt wird von Wine nicht aufgelöst/gefunden, obwohl die Datei vorhanden ist. Einschränkung, die du kennen solltest Er liegt unter Komponente fonts, nicht dwrite – das ist wahrscheinlich ein älterer, GDI-naher Bug (Kerbal Space Program nutzt vermutlich kein DirectWrite), während dein Fall ja klar über die dwrite-Schicht lief. Die Symptomatik (Bold-Datei wird nicht gefunden/genutzt) ist aber sehr ähnlich, auch wenn der zugrunde liegende Code-Pfad ein anderer sein könnte. Von den echten dwrite-Bugs in der Liste (54028, 53739, 59252, 59488/89, 48447, 51150, 51367, 56717, 59218, 59487, 50627, 53311) behandelt keiner explizit Weight-/Bold-Gruppierung – die meisten drehen sich um Font-Fallback, fehlenden Text, Performance oder Abstürze bei anderen Programmen. Dein spezifisches Problem (Familie wird erkannt, aber Bold-Weight-Zuordnung schlägt fehl) scheint als eigenständiger Bug noch nicht sauber erfasst zu sein. Praktischer Vorschlag Falls du das dokumentieren willst, wäre ein neuer Bugreport unter Komponente dwrite vermutlich der sauberere Weg, statt 32965 zu kommentieren (der ja ein anderes Programm und wahrscheinlich einen anderen Code-Pfad betrifft). Du hättest mit deinem Fall (Evernote/CEF, Inter-Variable-Font-Familie, Bold wird bei Wine-dwrite.dll ignoriert, mit nativer dwrite.dll behoben) einen sehr klaren, reproduzierbaren Report – das ist genau die Art von Beitrag, die den Wine-Entwicklern hilft, weil du schon den Vergleich Wine-dwrite vs. Native-dwrite als Beweis lieferst. Willst du, dass ich dir einen strukturierten Bugreport-Entwurf dafür erstelle? ist eigentlich inter zwingend notwendig? Evaluierte Notwendigkeit von Inter-Schriftart nach Behebung des Rendering-Problems Nein – "Inter" ist nur der erste Kandidat in der CSS-Fallback-Kette, kein Hard-Requirement: font-family: Inter, system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen-Sans, Ubuntu, Cantarell, Helvetica Neue, sans-serif Der Browser/CEF-Renderer geht die Liste von links nach rechts durch und nimmt den ersten Font, den er tatsächlich findet. Fehlt "Inter" komplett, fällt er automatisch auf den nächsten verfügbaren zurück – z.B. "Segoe UI" (die ist ja über deine kopierten Windows-Fonts vermutlich ohnehin vorhanden) oder letztlich das generische sans-serif. Der entscheidende Punkt jetzt, nach deinem Fix Da die eigentliche Ursache (Wines dwrite.dll gruppiert Bold-Varianten nicht korrekt) jetzt durch die native dwrite.dll systemweit behoben ist, betrifft das nicht nur Inter, sondern jede Font-Familie in deinem Prefix. Das heißt: Selbst wenn du "Inter" komplett entfernst und der Browser auf "Segoe UI" oder sogar nur generisches sans-serif zurückfällt, würde Bold jetzt korrekt dargestellt werden – weil die native DirectWrite-Engine die Weight-Gruppierung für alle installierten Fonts sauber übernimmt, nicht nur für Inter. Praktisch heißt das für dich Du musst Inter nicht behalten, wenn du Speicherplatz sparen oder den Prefix aufräumen willst Die optische Übereinstimmung mit dem "echten" Evernote-Look (Windows/Mac-Client) ist aber nur mit Inter gegeben – ohne Inter sieht der Text etwas anders aus (Segoe UI hat andere Proportionen/Zeichenformen) Falls dir das Erscheinungsbild egal ist und nur "Bold funktioniert" zählt, kannst du die Inter-Dateien und den Registry-Import jederzeit wieder entfernen, ohne dass das Bold-Problem zurückkommt – der Fix sitzt ja jetzt auf Ebene der DirectWrite-Engine, nicht auf Ebene der einzelnen Font Falls du die Inter-Fonts drinlässt, hast du also im Grunde nur den optisch "originalgetreueren" Look zusätzlich zur ohnehin behobenen Bold-Funktionalität. ok - erstelle mir infos für einen bugreport bei wine Orchestrierte strukturierten Bug-Report mit technischen Details und bilingualer Formatierung Hier ein strukturierter Report-Entwurf, den du bei WineHQ Bugzilla (Component: dwrite) einreichen kannst. Bug-Reports dort sind auf Englisch üblich, daher hab ich den Report-Inhalt direkt auf Englisch formuliert – du musst nur noch die Platzhalter (Wine-Version etc.) ergänzen. Component: dwrite Summary: dwrite.dll (builtin) does not apply bold weight for CSS font-weight in CEF/Chromium-based application (Evernote), works correctly with native dwrite.dll Version: [bitte wine --version einfügen] OS: Fedora 44, Linux (Wine devel branch) Description When running a CEF/Chromium-based Windows application (Evernote 11.23.2) under Wine, text styled with font-weight: bold (or tags) is rendered in the regular weight instead of bold — but only for certain font families. The issue is reproducible with the "Inter" font family (all 18 static weight variants, Thin through Black, plus italics, installed as separate HKLM\...\CurrentVersion\Fonts registry entries pointing to individual .ttf files per weight, e.g. "Inter Bold (TrueType)"="Inter-Bold.ttf"). Classic GDI-based rendering (tested with Notepad) correctly displays bold text using the exact same installed fonts. This isolates the issue to Wine's dwrite.dll (builtin) font weight/family grouping, rather than to font installation or GDI itself. Steps to reproduce Install Inter font family (all static weights) into C:\windows\Fonts, with matching registry entries under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts. Run a CEF/Chromium-based Windows application that renders HTML/CSS text with font-family: Inter, ... and applies font-weight: bold (or ) to some of that text. Observe that bold text renders visually identical to regular-weight text. For comparison: open Notepad (or another classic GDI app) and manually apply Bold formatting to text in the same font family — bold renders correctly. Expected result Bold text should render with the corresponding bold font face, matching GDI-based rendering behavior. Actual result Bold text renders in the regular weight; no visual distinction between normal and bold text. Workaround confirmed Overriding dwrite to use the native Windows DLL fixes the issue completely: wine reg add "HKCU\Software\Wine\DllOverrides" /v "dwrite" /t REG_SZ /d "native,builtin" /f With dwrite.dll copied from a genuine Windows installation into system32, bold rendering works correctly for the same font/application/registry setup — confirming the regression is isolated to Wine's builtin dwrite.dll implementation, not to font installation, registry setup, or the application itself. Additional notes Fully disabling dwrite (DllOverride: disabled) causes the application to fail to start entirely — the application has a hard dependency on dwrite.dll being present in some form (native or builtin), it cannot fall back to GDI-only rendering. This may be related to font family/weight grouping logic in Wine's dwrite implementation (similar in nature to historic issues like bug 584769 in other DirectWrite implementations, where GDI-style vs. DirectWrite-style family grouping — based on name table / weight-width-slope family name — differ). Zwei Dinge, die du vor dem Einreichen noch ergänzen solltest: wine --version – exakte Versionsnummer Falls du magst, ein Vorher/Nachher-Screenshot (Bold mit builtin dwrite vs. mit nativer dwrite.dll) – das ist bei Font-Rendering-Bugs fast immer hilfreicher als reine Textbeschreibung und wird von Wine-Maintainern gerne gesehen Soll ich dir noch eine minimale Testanwendung/HTML-Datei vorbereiten, die das Problem ganz ohne Evernote reproduziert (nur reines HTML mit font-family: Inter + font-weight: bold in einem CEF-Testkontext)? Das würde den Report für die Wine-Entwickler noch einfacher nachvollziehbar machen, da er nicht an eine proprietäre App gebunden ist. beim bugreport - lass das mit inter weg und mache in auf english neu Generalized bug report, removing font-specific details Hier die überarbeitete Version – generisch gehalten, ohne Bezug zu Inter, auf Englisch: Component: dwrite Summary: dwrite.dll (builtin) does not apply bold font weight in CEF/Chromium-based application; native dwrite.dll works correctly Version: [insert wine --version output here] OS: Fedora 44, Linux (Wine devel branch) Description When running a CEF/Chromium-based Windows application under Wine, text styled with CSS font-weight: bold (or HTML tags) renders in the regular weight instead of bold. This occurs with a TrueType font family installed as separate static weight files (Regular, Bold, etc.), each registered individually under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts (e.g. "<Family> Bold (TrueType)"="<family>-bold.ttf"). Classic GDI-based rendering (tested with Notepad, same font family, same installed files) correctly displays bold text. This isolates the issue to Wine's builtin dwrite.dll font weight/family grouping rather than to font installation, registry setup, or the application itself. Steps to reproduce #1 Install a TrueType font family with separate static weight files (Regular + Bold at minimum) into C:\windows\Fonts, with matching registry entries under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts. #2 Run a CEF/Chromium-based Windows application that renders HTML/CSS text referencing that font family and applies font-weight: bold (or ) to part of the text. #3 Observe that the bold text renders visually identical to the regular weight. #4 For comparison: open Notepad and manually apply Bold formatting to text using the same installed font family — bold renders correctly there. Expected result Bold text should render using the corresponding bold font face, matching the behavior seen with GDI-based rendering. Actual result Bold text renders in the regular weight; there is no visual distinction between normal and bold text within the CEF/Chromium-based application. Workaround confirmed Overriding dwrite to use the native Windows DLL fixes the issue completely: wine reg add "HKCU\Software\Wine\DllOverrides" /v "dwrite" /t REG_SZ /d "native,builtin" /f With a genuine dwrite.dll copied from a real Windows installation into system32, bold rendering works correctly for the identical font/application/registry setup — confirming the regression is isolated to Wine's builtin dwrite.dll implementation. Additional notes Fully disabling dwrite (DllOverride: disabled) causes the application to fail to start entirely — it has a hard dependency on dwrite.dll being present in some form (native or builtin) and cannot fall back to GDI-only rendering. This may be related to font family/weight grouping logic in Wine's dwrite implementation — potentially similar in nature to historic family-grouping issues seen in other DirectWrite implementations, where GDI-style grouping (by name table ID 1) and DirectWrite-style grouping (by weight-width-slope family name) can diverge for fonts installed as separate per-weight files. -- 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 59952] New: Support an environment variable disable for user mode dispatch!
by WineHQ Bugzilla July 6, 2026

July 6, 2026

http://bugs.winehq.org/show_bug.cgi?id=59952 Bug ID: 59952 Summary: Support an environment variable disable for user mode dispatch! 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: timothylottes(a)protonmail.com Distribution: --- The old way to work around problems in Wine on Linux was to do direct Linux system calls from inside the WIN32 application using inline assembly. However now with user mode dispatch, those SYSCALL instructions get trapped. This makes it impossible to implement in-app workarounds for Wine bugs. The request here is an environment variable that can be set before execution of "wine" that would disable use of userr-mode-dispatch, so that it restores ability to do Linux system calls instead. -- 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 27313] New: Requiem: Avenging Angel - Loading a savegame freezes the keyboard.
by wine-bugs＠winehq.org July 6, 2026

July 6, 2026

http://bugs.winehq.org/show_bug.cgi?id=27313 Summary: Requiem: Avenging Angel - Loading a savegame freezes the keyboard. Product: Wine Version: 1.3.21 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: cyclops(a)fastwebnet.it Sometimes, when you load a previous savegame, keyboard is freezed and the game must be rebooted to make it run well again. Also, health goes to 1, armour goes to 0 and essence goes to 666 (strange, uh?). If you need a log, please ask me. -- 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 9