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

[Bug 18790] Default search does not include resolved bugs

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=18790 --- Comment #10 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Still true and easy to forget. -- 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 60266] Window above a full-screen window is drawn behind it

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60266 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase -- 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 60265] d2d1: ID2D1GeometrySink::Close() never completes on paths with coincident bezier nodes

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60265 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch, testcase --- Comment #4 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Patches are not picked up from Bugzilla. See https://gitlab.winehq.org/wine/wine/-/wikis/Submitting-Patches Note that patches written by AI will not be accepted. -- 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 47062] Multiple E-Banking applications by KOBIL Systems GmbH crash on startup due to ntdll.NtQueryDirectoryObject '\\KnownDlls' failure (MigrosBank EBanking 8.2.x, Sparda Bank SecureApp 1.x)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=47062 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |81ea1e7a20c9cd0698c0416282d | |9ad7c0109e865 --- Comment #4 from Anastasius Focht <focht(a)gmx.net> --- Hello Hans, confirming, the '\KnownDlls' failure is gone. Fixed by commit https://gitlab.winehq.org/wine/wine/-/commit/81ea1e7a20c9cd0698c0416282d9ad… ("wineboot: Create section objects for known dlls."). Part of Wine 10.5 release. Thanks Alexandre. The ntdll TRACE from my comment #0 no longer exists, the object manager calls lost it when they moved to the Unix library. But +server shows the same thing from the wineserver side: --- snip --- $ pwd /home/focht/.wine/drive_c/AST-Client $ WINEDEBUG=+server wine ./SpardaSecureApp.exe >>log.txt 2>&1 ... <wineboot> 002c: create_directory( access=000f000f, objattr={rootdir=0000,attributes=00000010,sd={},name=L"\\KnownDlls"} ) 002c: create_directory() = 0 { handle=005c } 002c: create_symlink( access=000f0001, objattr={rootdir=005c,attributes=00000010,sd={},name=L"KnownDllPath"}, target_name=L"C:\\windows\\system32" ) ... --- snip --- Opened in the app process (tid 0024): --- snip --- ... 0024: open_directory( access=000f000f, attributes=00000040, rootdir=0000, directory_name=L"\\KnownDlls" ) 0024: open_directory() = 0 { handle=001c } 0024: open_mapping( access=02000000, attributes=00000040, rootdir=001c, name=L"kernel32.dll" ) 0024: open_mapping() = 0 { handle=0020 } ... 0024: open_mapping( access=02000000, attributes=00000040, rootdir=001c, name=L"kernelbase.dll" ) 0024: open_mapping() = 0 { handle=0020 } --- snip --- The directory is now populated: section objects resolve against that handle (kernel32, kernelbase, etc.). The app now runs past this point, loads wbemprox and reaches WMI, where it stops at another Wine insufficiency: it tries to connect to namespace 'ROOT\SecurityCenter2', which wbemprox does not implement yet. I will file that separately. $ wine --version wine-11.16 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 60266] New: Window above a full-screen window is drawn behind it

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60266 Bug ID: 60266 Summary: Window above a full-screen window is drawn behind it Product: Wine Version: 11.14 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs(a)list.winehq.org Reporter: realmaitreal(a)deadmail.lat Target Milestone: --- Created attachment 81984 --> http://bugs.winehq.org/attachment.cgi?id=81984 Minimal Win32 reproducer (C source, ~130 lines, no dependencies) Overview A window which the application places above a full-screen window in the Win32 z-order is drawn behind it and is invisible, when the application owns its windows from a common owner window, as Delphi applications do. winemac.drv elevates a full-screen window to NSStatusWindowLevel+1 while the application is active. Reordering or attaching an owned window goes through -[NSWindow addChildWindow:ordered:], which resets window levels. The owner window is not itself full-screen, so it stays at NSNormalWindowLevel, and the attach drops the affected windows to that level. Because the window level dominates the window server ordering, those windows are then ordered behind the full-screen window and are never promoted again by -adjustWindowLevels:, which decides which windows are "in front" from that same ordering. That -addChildWindow: resets a window level is not documented by Apple. Electron saves and restores the parent window's level around the call for this reason: https://github.com/electron/electron/pull/38460 Measured here with CGWindowListCopyWindowInfo(): attaching a newly created dialog also dropped an existing sibling window from level 27 to level 0. Steps to Reproduce Build and run the attached reproducer (about 130 lines, plain Win32): i686-w64-mingw32-gcc -O1 -o repro.exe repro.c -lgdi32 -luser32 -mconsole wine repro.exe It creates four windows, mirroring a Delphi application's arrangement: 1) APP - a 1x1 owner window, created first so it stays at the back and is never elevated (Delphi's hidden TApplication window) 2) MAIN - a full-screen window, owned by APP 3) START - an ordinary window, owned by APP 4) SPLASH - the window which must stay visible, owned by APP Click the WHITE window (SPLASH) so the application becomes active without raising the black full-screen window in the z-order. The program then swaps START and SPLASH in the z-order once per second with SetWindowPos(hwnd, HWND_TOP, ...) and prints the resulting Win32 z-order. Actual Results The white window is invisible while the application is active, although the program reports it as the top of the Win32 z-order: win32: SPLASH > START > MAIN > APP CGWindowListCopyWindowInfo() reports MAIN at window level 26 (NSStatusWindowLevel+1) and SPLASH, START and APP at level 0. All four are on the same Space and all are ordered in; the white window is simply drawn underneath. It reappears as soon as the application is deactivated, and is visible in Mission Control, which ignores window levels. Reproduced on 20 of 20 samples. Expected Results The white window should be drawn over the full-screen one. Windows has no notion of a full-screen window in the z-order. Per "Window Features": "The system maintains the z-order in a single list. It adds windows to the z-order based on whether they are topmost windows, top-level windows, or child windows." "A child window is grouped with its parent in z-order." Position in the z-order is therefore determined by window type, not by a window's size, so a window which happens to cover the screen has no special standing. SetWindowPos() with HWND_TOP "Places the window at the top of the Z order", and after that call the window must not remain obscured. https://learn.microsoft.com/en-us/windows/win32/winmsg/window-features https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setw… Build Date & Hardware wine-11.14, macOS 26.6.2 (Darwin 25.6.0), Apple Silicon running the x86_64 build. -addChildWineWindow:, -setChildWineWindows: and -adjustWindowLevels: are byte-identical in 11.16 and in current master, so those are affected too. Additional Information Found with OMSI 2 (Steam appid 252530): the loading form is invisible for the whole of a map load, leaving a black screen, and the "really quit?" dialog is invisible as well. Both reappear if the application is deactivated and reactivated. The application must be active for the bug to appear, because the elevation only applies while it is. The similar reports Bugzilla suggests (13515, 22944, 31370, 35384, 56021, 58537, 59334) are all on Linux; none is against winemac.drv. -- 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 60265] d2d1: ID2D1GeometrySink::Close() never completes on paths with coincident bezier nodes

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60265 --- Comment #3 from werner.bundschuh(a)pm.me --- Follow-up measurement from the real world document, with the two attached patches applied and the subdivision depth instrumented. The document triggers 6805 calls to d2d_geometry_resolve_beziers(). 6759 of them need no splitting at all. The problematic object is one figure: bezier segments before splitting: 6994 bezier segments after splitting: 10109 growth factor: 1.45 maximum subdivision depth: 8 (the cap) average subdivision depth: 0.92 Two things worth noting for the review of patch 2/2: - The depth cap is what does the work. It binds -- the maximum depth is exactly the cap value -- and without it those pairs run to the float exhaustion depth of 25. Seventeen further levels of halving on the affected pairs is what produced the runaway; before the patches the figure had passed 900,000 vertices and the process was killed by the OOM killer at 66 GB of virtual memory. - The segment budget (16x the initial count) never triggered, not once in the whole session. With a growth factor of 1.45 it is nowhere near. It is a backstop, not the mechanism, and could be dropped or raised freely without affecting this case. With the patches, selecting the object takes 2-5 seconds instead of never completing, and the rendering is visually correct. -- 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 #5 from Sven Schnelle <svens(a)stackframe.org> --- I'm on 2ecc2f84b45 ("ntdll: Return the object manager status from NtQueryFullAttributesFile.") -- 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 60265] d2d1: ID2D1GeometrySink::Close() never completes on paths with coincident bezier nodes

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60265 --- Comment #2 from werner.bundschuh(a)pm.me --- Created attachment 81983 --> http://bugs.winehq.org/attachment.cgi?id=81983 Patch 2/2: bound subdivision (changes rendering output for degenerate input) -- 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 60265] d2d1: ID2D1GeometrySink::Close() never completes on paths with coincident bezier nodes

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60265 --- Comment #1 from werner.bundschuh(a)pm.me --- Created attachment 81982 --> http://bugs.winehq.org/attachment.cgi?id=81982 Patch 1/2: avoid shifting the figure arrays while splitting (no behaviour change) -- 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 60265] New: d2d1: ID2D1GeometrySink::Close() never completes on paths with coincident bezier nodes

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60265 Bug ID: 60265 Summary: d2d1: ID2D1GeometrySink::Close() never completes on paths with coincident bezier nodes Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d2d Assignee: wine-bugs(a)list.winehq.org Reporter: werner.bundschuh(a)pm.me Target Milestone: --- Distribution: --- Created attachment 81981 --> http://bugs.winehq.org/attachment.cgi?id=81981 Standalone reproducer (build with mingw, see bug description) # d2d1: ID2D1GeometrySink::Close() never completes on paths with coincident bezier nodes ## Summary `d2d_geometry_resolve_beziers()` subdivides overlapping bezier control triangles until they no longer overlap. When the underlying curves genuinely cross -- or when several nodes sit on (nearly) the same coordinates -- subdividing never separates them, and the loop only terminates once the control points become collinear in float precision. Every split appends a segment that is then tested against all earlier ones, so the segment count grows combinatorially. On a real world document this exhausts memory instead of finishing. ## Affected code `dlls/d2d1/geometry.c`, `d2d_geometry_resolve_beziers()`, first phase: /* Split overlapping bezier control triangles. */ while (d2d_geometry_get_next_bezier_segment_idx(geometry, &idx_p)) { d2d_geometry_get_first_bezier_segment_idx(geometry, &idx_q); while (idx_q.figure_idx < idx_p.figure_idx || idx_q.vertex_idx < idx_p.vertex_idx) { while (d2d_geometry_check_bezier_overlap(geometry, &idx_p, &idx_q)) { ... d2d_geometry_split_bezier(geometry, &idx_q or &idx_p); } d2d_geometry_get_next_bezier_segment_idx(geometry, &idx_q); } } Unchanged since 2187a1edb ("d2d1: Split overlapping bezier control triangles.", Henri Verbeet, 2017, Wine 2.15). The only termination condition is in `d2d_geometry_check_bezier_overlap()`: if (d2d_point_ccw(a[0], a[1], a[2]) == 0.0f || d2d_point_ccw(b[0], b[1], b[2]) == 0.0f) return FALSE; That is float exhaustion, not an algorithmic bound. ## Measurements Instrumenting the loop to record the subdivision depth per segment, on the attached reproducer: segments start end max depth avg depth 20 220 1544 25 5.51 40 872 2336 25 3.91 80 3312 14948 25 4.82 160 14144 54057 25 4.18 The maximum depth is exactly 25 in every run -- the point at which halving a control triangle with coordinates around 500 no longer changes the float32 mantissa. The average depth is 4 to 5.5, so only a small tail of pairs runs all the way down; those are the pairs whose curves actually cross. Wall clock for `ID2D1GeometrySink::Close()` on the reproducer, Wine 11.16 release build, measured A/B/A/B interleaved on an otherwise unchanged machine (medians; the two runs per variant agree within 3%): segments unpatched patched factor 20 39.2 ms 20.9 ms 1.87 40 85.1 ms 56.7 ms 1.50 80 3114.2 ms 1844.2 ms 1.69 160 42132.9 ms 28794.4 ms 1.46 Note that the reproducer is dominated by the overlap tests, not by the array shifting, so it mostly exercises the subdivision bound. The array shifting is what dominates in the real world case below, where the unpatched version does not finish at all and no ratio can be given. ## Real world case Affinity Designer 3 (via Wine) freezes when selecting a specific object in a customer document. The object contains a cluster of nodes at practically identical coordinates. Sampled with gdb, 30 samples over three minutes, 100% of the time is in `memmove` reached through: d2d_geometry_sink_Close -> d2d_geometry_resolve_beziers -> d2d_geometry_split_bezier -> d2d_figure_insert_vertex -> memmove The figure had grown to roughly 915,000 vertices and was still growing by about 23,000 per minute after eight minutes; each insertion memmoves 1.3 to 6.5 MB. The operation never completes. ## Two independent problems 1. `d2d_geometry_split_bezier()` inserts into the middle of the figure's vertex, vertex type and control arrays. That is O(n) per split, so the phase is O(splits * vertices) -- this is what dominates in the real world case. The splitting phase only ever reads three points per segment (`d2d_geometry_check_bezier_overlap`, `d2d_geometry_bezier_ccw`), so the array bookkeeping is not needed until the phase ends. 2. The number of splits is not bounded by anything except float precision. ## Reproducer `repro.c` (attached) builds a closed path of N quadratic bezier segments whose control points sit near the centre, so the control triangles overlap, and times `ID2D1GeometrySink::Close()`. No render target is needed. Build with mingw: x86_64-w64-mingw32-gcc -O2 -o repro.exe repro.c -ld2d1 -lole32 -lm ## Notes Also observed while reading this code, not addressed here: the middle loop condition while (idx_q.figure_idx < idx_p.figure_idx || idx_q.vertex_idx < idx_p.vertex_idx) is an OR where lexicographic ordering is intended. It happens to be safe only because q always meets p exactly; the return value of the following `d2d_geometry_get_next_bezier_segment_idx()` is not checked, so if q ever ran past p the loop would index `figures[figure_count]`. -- 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