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

[Bug 60177] New: Microsoft Agent 2.0: Characters.Load fails with 0x80042001 (custom marshaling of the notify sink never reaches AgentSvr)
by WineHQ Bugzilla Aug. 17, 2026

Aug. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60177 Bug ID: 60177 Summary: Microsoft Agent 2.0: Characters.Load fails with 0x80042001 (custom marshaling of the notify sink never reaches AgentSvr) Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs(a)list.winehq.org Reporter: wehrwolfmann(a)gmail.com Target Milestone: --- Distribution: --- Microsoft Agent 2.0 does not work under Wine. Any app built on it fails the same way: the client connects to the server, but every Characters.Load returns 0x80042001, "The specified Agent client was not found". The character file is never even opened. Three lines of VBScript are enough, no third-party app needed. With MS Agent 2.0 Core installed into the prefix, run this with the 32-bit cscript (wine C:\windows\syswow64\cscript.exe /nologo agent.vbs): Set a = CreateObject("Agent.Control.2") a.Connected = True a.Characters.Load "Bonzi", "C:\windows\msagent\chars\Bonzi.acs" Steps 1 and 2 succeed, step 3 fails with 0x80042001. What I see with WINEDEBUG=+ole. AgentSvr starts fine and hands the client its IAgentEx through MS Agent's own custom marshaler (AgentMPx.dll) — that direction works, the client gets a usable proxy. Then the client marshals its notify sink back: CoMarshalInterface {00000000-0000-0000-c000-000000000046}, dwDestContext=2, custom CoMarshalInterface completed with hr 0 and the server never unmarshals it — there is not a single "Using custom unmarshaling" in the server process for the whole run. So the server has no registered client and answers Load with "client not found". With WINEDEBUG=+file you can see the character file is located and then dropped: FindFirstFileExW on C:\windows\Msagent\CHARS\Bonzi.acs finds it, but NtCreateFile is never called on it. The failure is well before any file I/O. I also tried the workaround from the AppDB entry for Animation:Master (start AgentSvr.exe by hand first, set it to Windows 98 in winecfg). It changes nothing here. Tested on wine-11.15, 32-bit MS Agent 2.0 Core in a clean WoW64 prefix. I can attach the +ole logs for both the script and a real application if that helps. -- 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 55002] New: Product Manager by IK Multimedia does not let you type text
by WineHQ Bugzilla Aug. 16, 2026

Aug. 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=55002 Bug ID: 55002 Summary: Product Manager by IK Multimedia does not let you type text Product: Wine Version: 8.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hadresadri(a)gufum.com Distribution: --- IK Multimedia Manager https://www.ikmultimedia.com/products/productmanager/ will not let you input text in the home screen which essentially renders it useless as you can't log in. Also, I have discovered with bottles this can be avoided however even if you do manager to get it open it won't let you download anything, it will just freeze and crash -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 7

[Bug 54716] New: Hard Time (2007): incorrect text rendering caused by font anti-aliasing
by WineHQ Bugzilla Aug. 16, 2026

Aug. 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=54716 Bug ID: 54716 Summary: Hard Time (2007): incorrect text rendering caused by font anti-aliasing Product: Wine Version: 4.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: liamstevens2287(a)gmail.com Distribution: --- Created attachment 74224 --> https://bugs.winehq.org/attachment.cgi?id=74224 A screenshot of 2007's 'Hard Time' showing incorrect font rendering on the left, with the intended appearance on the right. Distros tested: Arch Linux, EndeavourOS, SteamOS Versions tested: Wine 4.21, 7.2, 8.3, 8.4, and all versions of Valve Proton 2007 indie game 'Hard Time' incorrectly displays white outlines around all text, caused by font anti-aliasing being forced. On Windows, the game correctly runs with no AA without tweaking required by the user. Disabling font anti-aliasing at the Xorg level or by using your DE's options works around this, as there is no way to disable font AA in Wine itself (that I can tell). The game is free, and the official download is located at http://www.mdickie.com/downloads.htm (direct link at http://www.mdickie.com/downloads/new/hardtime_setup.exe) Attached is an image of two screenshots with font anti-aliasing enabled on the left, and disabled on the right to show the intended appearance. As this is my first Wine bug, please do tell me if there is any other information which is needed. Many thanks. -- 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 3

[Bug 60181] New: Bengali fonts don't handle subjoined letters
by WineHQ Bugzilla Aug. 16, 2026

Aug. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60181 Bug ID: 60181 Summary: Bengali fonts don't handle subjoined letters Product: Wine Version: 11.15 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)list.winehq.org Reporter: afifsworld132(a)gmail.com Target Milestone: --- Created attachment 81849 --> http://bugs.winehq.org/attachment.cgi?id=81849 Log of appwiz.cpl with +gdi,+uniscribe,+font System: MacBook Pro M1 (2020), macOS 14.1.1, Wine Staging 11.15, DXMT 0.80 I have been trying to localize Bangla (Bangladesh) for wine. When I ran my changes, I saw the text's were broken up due to conjoined letters not being properly handled (য-ফলা,ব-ফলা,র-ফলা). A screenshot of it and a log are given. -- 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 55538] New: Bad graphics rendering in VirtualDJ
by WineHQ Bugzilla Aug. 16, 2026

Aug. 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=55538 Bug ID: 55538 Summary: Bad graphics rendering in VirtualDJ Product: Wine Version: 8.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bique.alexandre(a)gmail.com Distribution: --- Created attachment 75096 --> https://bugs.winehq.org/attachment.cgi?id=75096 VirtualDJ Screenshot VirtualDJ is a DJ software. https://virtualdj.com The graphics rendering in VirtualDJ is broken. The font looks crippled. There are a bunch of gradients which are plain black. The interface flickers. I'm using Archlinux, Gnome/X11, nvidia. This message comes a lot: 0190:fixme:d2d:d2d_text_renderer_DrawGlyphRun Ignoring options 0x2. This also happens: vkd3d:fixme:d3d12_device_MakeResident iface 0000000003A4AC10, object_count 1, objects 0000000001C872C8 stub! vkd3d:fixme:d3d12_root_signature_init_descriptor_table_push_constants Push constants size 260 exceeds maximum allowed size 256. Try VKD3D_CONFIG=virtual_heaps. 0110:fixme:win:RegisterTouchWindow hwnd 0000000000040084, flags 0x2 stub! 0190:err:sync:RtlpWaitForCriticalSection section 000000014448FB50 (null) wait timed out in thread 0190, blocked by 0110, retrying (60 sec) 0190:err:sync:RtlpWaitForCriticalSection section 000000014448FB50 (null) wait timed out in thread 0190, blocked by 0110, retrying (60 sec) 0190:err:sync:RtlpWaitForCriticalSection section 000000014448FB50 (null) wait timed out in thread 0190, blocked by 0110, retrying (60 sec) Cheers, Alex -- 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 60180] New: UpdateLayeredWindow ignores a PALETTEINDEX colour key (ULW_COLORKEY)
by WineHQ Bugzilla Aug. 16, 2026

Aug. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60180 Bug ID: 60180 Summary: UpdateLayeredWindow ignores a PALETTEINDEX colour key (ULW_COLORKEY) Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)list.winehq.org Reporter: wehrwolfmann(a)gmail.com Target Milestone: --- Distribution: --- Microsoft Agent 2.0 (AgentSvr.exe, part of the free MS Agent runtime) draws its character in a layered window. With +relay narrowed down to the layered-window calls, this is all it does: Call user32.UpdateLayeredWindow(...,010000fe,00000000,00000001) Ret user32.UpdateLayeredWindow() retval=00000001 dwFlags is ULW_COLORKEY, pblend is NULL, and crKey is 0x010000FE, i.e. PALETTEINDEX(254). The character bitmaps inside the .acs file are 8-bit paletted and entry 254 is the transparent colour, which on screen is #00FFFF. SetWindowRgn is never called, so the colour key is the only thing that is supposed to cut the background away. Wine returns success but the window stays completely opaque: the character sits on a solid cyan rectangle instead of on the desktop. It looks like the key is compared against the raw COLORREF and PALETTEINDEX is never resolved through the source DC palette. I checked the same trace on 7.0 and on 10.0: identical call, same crKey, and SetWindowRgn is not called on either. This is not a regression - I get the same cyan rectangle on every version where the character loads at all. Colour keying itself is not missing in general - bug 15118 implemented it back in 2012. What looks unhandled here is specifically the PALETTEINDEX form of crKey. I have not tested a plain RGB key against this application myself, so treat that last part as a reading of the trace rather than a measurement. -- 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 60182] New: Nested user-mode callback limit is 64, Windows stops around 32; deep WM_SHOWWINDOW recursion then makes unrelated CreateWindowEx calls fail
by WineHQ Bugzilla Aug. 16, 2026

Aug. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60182 Bug ID: 60182 Summary: Nested user-mode callback limit is 64, Windows stops around 32; deep WM_SHOWWINDOW recursion then makes unrelated CreateWindowEx calls fail Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)list.winehq.org Reporter: Wagner.a18(a)yahoo.com Target Milestone: --- Distribution: --- ================================================================================ DESCRIPTION ================================================================================ dlls/win32u/message.c limits how deeply window messages may nest: #define MAX_WINPROC_RECURSION 64 static LRESULT dispatch_win_proc_params(...) { if (thread_info->msg_call_depth > MAX_WINPROC_RECURSION) return 0; Windows has the same kind of limit, and it applies under the same condition (only to messages that do not take the client-side fast path), but it stops at roughly half that depth. Measured with the two probes attached to this report: Windows Wine 11.15 ShowWindow(SW_HIDE) recursion 31 65 nested SendMessage, no hook 300* 300* nested SendMessage, with a WH_CALLWNDPROC hook installed 31 65 WS_VISIBLE set inside handler yes yes * 300 is the probe's own cap; neither system stopped before it. So Wine's structure is already right - both systems count only the messages that go through a kernel/user callback, which is why a plain same-thread SendMessage is unlimited until a hook is installed. Only the ceiling differs. Two things follow that are worth stating explicitly, because both were wrong guesses on the way here: - Wine sending WM_SHOWWINDOW before it clears WS_VISIBLE is NOT a bug. Windows does the same; the flag is still set inside the handler there too. - The recursion itself is not the bug. Windows recurses as well, it just stops sooner. ================================================================================ WHY THE HIGHER LIMIT IS HARMFUL ================================================================================ Exceeding the limit is not graceful. dispatch_win_proc_params() returns 0 *without calling the window procedure*, and the caller cannot tell that apart from a window procedure that legitimately returned 0. For WM_NCCREATE a return of 0 means "the window refuses to be created", so every CreateWindowEx() issued while the counter is pinned fails: warn:win:NtUserCreateWindowEx 0x70240: aborted by WM_NCCREATE An application that recurses deeply for its own reasons therefore does not just lose the recursion, it loses unrelated window creation happening inside it. The lower Windows ceiling keeps applications out of that region; Wine's does not. ================================================================================ STEPS TO REPRODUCE ================================================================================ Both probes are C# using P/Invoke, so they need no toolchain: csc.exe ships with every Windows install and runs under Wine as well. %WINDIR%\Microsoft.NET\Framework64\v4.0.30319\csc.exe /nologo ShowHideProbe.cs ShowHideProbe.exe %WINDIR%\Microsoft.NET\Framework64\v4.0.30319\csc.exe /nologo NestProbe.cs NestProbe.exe (Use Framework instead of Framework64 on 32-bit Windows.) ShowHideProbe hides a window from inside its own WM_SHOWWINDOW handler and reports the nesting depth reached plus whether WS_VISIBLE is still set. NestProbe sends a plain WM_APP message to a window from that window's own handler, once without a hook and once with WH_CALLWNDPROC installed. ACTUAL (wine-11.15) EXPECTED (measured on Windows 10) ShowHideProbe: depth 65 ShowHideProbe: depth 31 NestProbe: 300 / 65 NestProbe: 300 / 31 ================================================================================ REAL-WORLD IMPACT ================================================================================ Found in LASAL Class 2 (Sigmatek), an MFC 14 application using CodeJock Xtreme Toolkit. While building its docking panes, CodeJock hides a pane from that pane's own WM_SHOWWINDOW handler. With Wine's ceiling the recursion ran to 257 (with the limit temporarily raised for measurement) instead of stopping where Windows would, one window being notified 256 times in a row with cmd=SW_HIDE show_flag=0 was_visible=1. With msg_call_depth pinned, the WM_NCCREATE of docking panes still being created is answered with 0. The first failing class is XTPDockingPaneAutoHidePanel. MFC turns the CreateWindowEx failure into a CResourceException and shows its generic AFX_IDP_FAILED_RESOURCE_LOAD message box ("A required resource was unavailable"). Because that box is modal, MFC calls EnableWindow(FALSE) on the main frame: the splash screen never goes away, the menu bar is never painted, and no click is accepted. The dialog reappears on every menu hover. The application is unusable, while the message points at a missing resource that does not exist - no resource lookup ever fails. ================================================================================ SUGGESTED FIX ================================================================================ Lowering the ceiling to match the measurement is sufficient; nothing else was needed: -#define MAX_WINPROC_RECURSION 64 +#define MAX_WINPROC_RECURSION 32 With this one-line change and no other patch, LASAL Class 2 starts normally: 0 "aborted by WM_NCCREATE" (was 4), no leftover splash screen, no message box, and the main window reaches its full title. dlls/user32:win and dlls/user32:msg produce byte-identical failure sets with and without the change (5 resp. 1 pre-existing failures), compared against a purpose-built unpatched tree. Two caveats worth a maintainer's judgement: - Exact value. With MAX_WINPROC_RECURSION at 32 Wine reports depth 33 where Windows reports 31, because the check is "depth > MAX" against a zero-based counter. Matching Windows exactly would need the comparison adjusted as well. I left that alone since the constant's history is unknown to me. - The failure mode. Even at the correct depth, returning 0 for a WM_NCCREATE that was never dispatched is indistinguishable from a genuine refusal. If Windows behaves differently once the ceiling is reached, that is a separate issue this report does not settle. All numbers above for "Windows" were measured on a Windows 10 VM; the Wine numbers on wine-11.15 (Arch Linux package build). -- 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 44598] New: Hebrew font: rendering of vowels is offset
by wine-bugs＠winehq.org Aug. 16, 2026

Aug. 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=44598 Bug ID: 44598 Summary: Hebrew font: rendering of vowels is offset Product: Wine Version: 3.2 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: chris(a)vine-cottage.org.uk Created attachment 60587 --> https://bugs.winehq.org/attachment.cgi?id=60587 Comparison of font rendering in wine and Windows Using theWord http://www.theword.net/index.php?article.download&l=english to view a Hebrew bible, the font rendering of Hebrew vowel points is incorrect. All fonts I have tried show inconsistencies, the best font appears to be Cardo. In the attached image, the top 2 lines of text shows the font rendering in Wine. The bottom 2 lines of text are the same text rendered in Windows 7. I have circled some of the incorrect rendering in Red. Other fonts show more significant offsets of vowel points from the correct positions. -- 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 60178] New: indowless transparent NPAPI plugin content is cleared to blank and not repainted when the host window is deactivated or a popup appears; only physically moving the window restores it. Works correctly on Windows.
by WineHQ Bugzilla Aug. 16, 2026

Aug. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60178 Bug ID: 60178 Summary: indowless transparent NPAPI plugin content is cleared to blank and not repainted when the host window is deactivated or a popup appears; only physically moving the window restores it. Works correctly on Windows. Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: aiyakiss(a)163.com Target Milestone: --- Distribution: --- Wine 11.15 (Staging), x86_64, wow64 - Ubuntu 26.04 LTS, GNOME (Mutter / X11 session), DPI 120 - Host application: Chanjet T+ Browser (Chromium ~60 based, 2018 build), 32-bit PE - Run flags: `--enable-npapi --disable-gpu --disable-gpu-compositing --disable-direct-composition --disable-accelerated-2d-canvas --disable-direct-write --force-color-profile=srgb` ## The plugin - NPAPI plugin `npBillOne.dll`, **windowless + transparent** mode (implements `IOleInPlaceSiteWindowless`; renders via `CreateDIBSection` + `AlphaBlend`) - The plugin draws its print-preview content directly into the browser page area (there is no separate top-level HWND for the preview document). ## Steps to reproduce 1. Launch the browser and open a document, then open the plugin's print preview (the preview content renders correctly at first). 2. Do ONE of the following: - move the mouse pointer out of the browser window (window loses focus), or - open the plugin's drop-down menu (printer / paper list). 3. Observe the preview content area. ## Actual result The plugin-drawn preview area is cleared to **white/blank** and is **never repainted**, even though the window is still visible. The rest of the page (normal Chromium content) renders fine — only the windowless plugin region is affected. ## Expected result The plugin region should keep its content (as on Windows) or be repainted automatically. ## Workaround (the only thing that restores the content) **Physically drag/move the window.** A real window move makes Chromium repaint the windowless plugin region and the content reappears. Neither of the following reproduces the fix: ## What was tested (all FAILED to restore the content) 1. `RedrawWindow(hwnd, NULL, 0, RDW_INVALIDATE | RDW_ALLCHILDREN)` → repaints only ~1/5 (left strip) of the plugin region. 2. `SetWindowPos(..., SWP_FRAMECHANGED | SWP_NOMOVE | SWP_NOSIZE)` → no effect. 3. `SetWindowPos` with a real 1px move → no effect (window does not actually relocate). 4. `_NET_MOVERESIZE_WINDOW` client message (multiple gravity values) → WM refuses to move the window. 5. XTest synthetic `MotionNotify` over the region → no effect. 6. XTest synthetic window-drag gesture (title-bar drag / Super+drag) → no effect (Mutter ignores synthetic input for window-move gestures). ## Diagnostic evidence collected - The host window's surface clip region stays the full window at all times (`update_surface_region` region == full client rect). No surface replacement, no `client_surface`/GL activity — the app is pure GDI. - Sending `XClearArea(exposures=True)` on the window does not restore it (Expose → repaint keeps the already-white content), proving Wine's surface is intact; the blank region is because the windowless plugin is simply not asked to redraw. - A genuine interactive window move (which generates `WM_WINDOWPOSCHANGED` + move/expose sequence through the WM) is the only thing that makes Chromium re-invoke the plugin paint. ## Analysis / hypothesis On deactivation (`WM_ACTIVATEAPP` false / `WM_KILLFOCUS`) or when a popup is shown, the windowless plugin region is invalidated, but Wine does not deliver the repaint in a way that makes the (Chromium 60) host re-invoke the plugin's paint callback. On Windows the same sequence repaints correctly. The discrepancy appears to be in how Wine forwards invalidation/paint for the windowless-plugin region during activation change / popup handling. ## Additional notes - Actual printing (via Spooler + XPS virtual printer) works; only the on-screen preview is affected. - NPAPI is deprecated, but Wine still advertises windowless NPAPI support, hence the report. -- 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 58010] New: Fallout 3 Error Wine 10.4 Failure to Launch New Game
by WineHQ Bugzilla Aug. 15, 2026

Aug. 15, 2026

https://bugs.winehq.org/show_bug.cgi?id=58010 Bug ID: 58010 Summary: Fallout 3 Error Wine 10.4 Failure to Launch New Game Product: Wine Version: 10.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mdcarroll6(a)hotmail.com Distribution: --- Created attachment 78269 --> https://bugs.winehq.org/attachment.cgi?id=78269 Error Log Having trouble with running Fallout 3 on Fedora 41 Linux. Used the normal installation methods and even configured wine to use Windows 7 compatibility instead of Windows 10. Attached an error log just in case it helps. -- 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