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

[PATCH 0/1] MR11562: cmd: Fix usage of uninitialized variable in node_build_parse.
by Santino Mazza (＠tati) Aug. 4, 2026

Aug. 4, 2026

I reproduced this bug when running cmd tests on a 32 bit build with optimizations disabled and debugging symbols enabled, built in Debian. It caused problems when processing a line like this `echo Hello & (echo Hello && echo Bye)`, the `done` variable would sometimes have a random non-zero value and cause `node_build_parse` to return when processing the `echo Hello` command inside the parenthesis context. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11562

3 2

Re: [PATCH v2 0/1] MR11497: win32u: Do not discard dmPosition in add_modes
by Zhiyi Zhang (＠zhiyi) Aug. 4, 2026

Aug. 4, 2026

Looks good to me. You can assume `current` is not NULL. I am not sure about the original intention of "physical = modes_count == 1 ? *modes : *current;" though. CCing @rbernon -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11497#note_147814

1 0

[PATCH v2 0/1] MR11558: win32u: Fix off-by-one in kbd_tables_init_vsc2vk.
by Bernhard Übelacker (＠bernhardu) Aug. 4, 2026

Aug. 4, 2026

Found by ASan (unix). <details> <summary>ASan report details</summary> ``` ASAN_OPTIONS="halt_on_error=0:detect_leaks=0:log_exe_name=1:log_path=\"/home/bernhard/asan\"" wine cmd ps aux | grep conhost gdb-multiarch -q --pid 364794 b Die cont # pressed d key in the konsole with the running cmd (gdb) bt #0 __sanitizer::Die () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:50 #1 0x00007fe0358fee3f in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0x7ffffeead316, __in_chrg=<optimized out>) at ../../../../src/libsanitizer/asan/asan_report.cpp:192 #2 0x00007fe0358fe4a0 in __asan::ReportGenericError (pc=140600888834656, bp=140737470193536, sp=sp@entry=140737470193528, addr=140600890957854, is_write=is_write@entry=false, access_size=2, fatal=true, exp=<optimized out>) at ../../../../src/libsanitizer/asan/asan_report.cpp:497 #3 0x00007fe0358fe60e in __asan::ReportGenericError (pc=<optimized out>, bp=bp@entry=140737470193536, sp=sp@entry=140737470193528, addr=<optimized out>, is_write=is_write@entry=false, access_size=access_size@entry=2, exp=<optimized out>, fatal=true) at ../../../../src/libsanitizer/asan/asan_report.cpp:497 #4 0x00007fe0358ff48c in __asan::__asan_report_load2 (addr=<optimized out>) at ../../../../src/libsanitizer/asan/asan_rtl.cpp:129 #5 0x00007fe03208ba60 in kbd_tables_init_vsc2vk (tables=0x7fe032362380 <kbdus_tables>, vsc2vk=0x7fe0157c4960) at dlls/win32u/input.c:434 #6 0x00007fe03209261a in NtUserMapVirtualKeyEx (code=68, type=<optimized out>, layout=<optimized out>) at dlls/win32u/input.c:1245 #7 0x00007fe032ad4106 in __wine_syscall_dispatcher () from dlls/ntdll/ntdll.so #8 0x00007fe032ace093 in server_init_thread (data=data@entry=0x7ffffeda0000) at dlls/ntdll/unix/server.c:1818 #9 0x00007fe03585b1d6 in asan_thread_start (arg=0x7fe02f003000) at ../../../../src/libsanitizer/asan/asan_interceptors.cpp:234 #10 0x00007fe03569e8bb in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448 #11 0x00007fe03571c538 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 ================================================================= ==wine==364794==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7fe03229201e at pc 0x7fe03208ba60 bp 0x7ffffeeadf80 sp 0x7ffffeeadf78 READ of size 2 at 0x7fe03229201e thread T19 #0 0x7fe03208ba5f in kbd_tables_init_vsc2vk dlls/win32u/input.c:434 #1 0x7fe032092619 in NtUserMapVirtualKeyEx dlls/win32u/input.c:1245 #2 0x7fe032ad4105 in __wine_syscall_dispatcher (dlls/ntdll/ntdll.so+0xcf105) (BuildId: 7bc5cb3f128a1e422fc0ae4549a1c6aa689df369) #3 0x7fe032ace092 in server_init_thread dlls/ntdll/unix/server.c:1818 #4 0x7fe03585b1d5 in asan_thread_start ../../../../src/libsanitizer/asan/asan_interceptors.cpp:234 #5 0x7fe03569e8ba in start_thread nptl/pthread_create.c:448 #6 0x7fe03571c537 in __clone3 ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 0x7fe03229201e is located 34 bytes before global variable 'vk_to_wchars1' defined in 'dlls/win32u/input.c:219:28' (0x7fe032292040) of size 44 0x7fe03229201e is located 0 bytes after global variable 'vsc_to_vk' defined in 'dlls/win32u/input.c:326:21' (0x7fe032291f20) of size 254 SUMMARY: AddressSanitizer: global-buffer-overflow dlls/win32u/input.c:434 in kbd_tables_init_vsc2vk ``` </details -- v2: win32u: Fix off-by-one in kbdus_tables. https://gitlab.winehq.org/wine/wine/-/merge_requests/11558

3 4

[PATCH 0/1] MR11556: win32u: Lock host window state updates when applying new state.
by Rémi Bernon (＠rbernon) Aug. 4, 2026

Aug. 4, 2026

Since https://gitlab.winehq.org/wine/wine/-/merge_requests/10699 and the revert of f82b115dfcf3eefbbb533d31976d178e21bf1237 we now call again into the window message proc before the restored state is applied to the win32 side. Any call to SetWindowPos, and more precisely any call that ends up in apply_window_pos and drivers WindowPosChanged, will request the win32 state again to the host, racing with the restored state being applied. In most cases this will resolve on its own when SC_RESTORE overrides the requests with the restored state again, but it emits a spurious minize / restore state requests that can confuse some picky window managers. If we're unlucky enough we might even process the transient state before SC_RESTORE. --- Fwiw this isn't actually specific to winex11, but it's the only driver using GetWindowStateUpdates at the moment. It's mostly a temporary fix to some immediate issue rather than a well thought out solution. It helps getting focus working with gamescope. I'm looking into ways to unify this a bit more with other drivers, but I'm not yet sure how to do that. Other drivers manage their host window state on a separate thread and perhaps it'd be better to move winex11 to the same model, though it is a lot of change. More generally I think it'd be nice to further separate win32 / host window states, with state tracking and transactional(-ish) updates, a bit like what we now have in winex11 but generalized for all drivers. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11556

4 4

[PATCH v7 0/4] MR11491: comctl32/listbox: Fix SetRedraw top item handling
by Tobi Laskowski (＠tobil) Aug. 4, 2026

Aug. 4, 2026

The old code was not correct for multicolumn listboxes, so it caused the items to be displayed at an incorrect offset. LISTBOX_GetMaxTopIndex implements special cases for MULTICOLUMN and OWNERDRAWVARIABLE listboxes, allowing the top item to remain consistent. The fix is taken from the following bug report: https://bugs.winehq.org/show_bug.cgi?id=59591 -- v7: user32/listbox: Fix SetRedraw top item handling comctl32/listbox: Fix SetRedraw top item handling user32/tests: Check multicolumn listbox redraw comctl32/tests: Check multicolumn listbox redraw https://gitlab.winehq.org/wine/wine/-/merge_requests/11491

2 5

[PATCH v2 0/2] MR11546: winhttp: Handle incorrect handle state when querying WINHTTP_OPTION_SERVER_CERT_CHAIN_CONTEXT.
by Paul Gofman (＠gofman) Aug. 4, 2026

Aug. 4, 2026

-- v2: winhttp: Use chain established in netconn_verify_cert() for WINHTTP_OPTION_SERVER_CERT_CHAIN_CONTEXT. winhttp: Handle incorrect handle state when querying WINHTTP_OPTION_SERVER_CERT_CHAIN_CONTEXT. https://gitlab.winehq.org/wine/wine/-/merge_requests/11546

3 6

Re: [PATCH v6 0/4] MR11491: comctl32/listbox: Fix SetRedraw top item handling
by Zhiyi Zhang (＠zhiyi) Aug. 4, 2026

Aug. 4, 2026

On Tue Aug 4 08:00:38 2026 +0000, Tobi Laskowski wrote: > The other tests in this file seem to clean up both separately, should I > deviate from that? Yes, child windows will be deleted automatically when you destroy the parent window. So there is really no need to delete the child window. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11491#note_147802

1 0

Re: [PATCH v6 0/4] MR11491: comctl32/listbox: Fix SetRedraw top item handling
by Tobi Laskowski (＠tobil) Aug. 4, 2026

Aug. 4, 2026

On Tue Aug 4 07:46:21 2026 +0000, Zhiyi Zhang wrote: > listbox will be destroyed when you destroy its parent. The other tests in this file seem to clean up both separately, should I deviate from that? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11491#note_147801

1 0

[PATCH 0/2] MR11561: bcrypt: Support BCRYPT_INITIALIZATION_VECTOR
by Allan Vester (＠AllanVester) Aug. 4, 2026

Aug. 4, 2026

Games like Forza Motorsport imports an AES-128 key, sets the initialization vector with `BCryptSetProperty()` and then calls `BCryptDecrypt()` with a NULL pbIV. `set_key_property()` rejects the property with STATUS_NOT_IMPLEMENTED, so the game never decrypts any of its content. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11561

3 4

[PATCH v7 0/4] MR10261: Fix toolbar wrapping issues
by Ivan Ivlev (＠iviv) Aug. 4, 2026

Aug. 4, 2026

This MR resolves two bugs with toolbar wrapping I have discovered. 1. Toolbar missing four buttons when app window is maximized (wrap should not appear at all in this case). 2. Last toolbar button disappears when window size (toolbar size) is slightly narrower then button right border. Reasons of this behavior: 1. Toolbar buttons have BTNS_AUTOSIZE style, toolbar width is set using CCS_NORESIZE and equals to widths of all autosized buttons combined. cx (button width) value in TOOLBAR_WrapToolbar is set from nButtonWidth, which contains widest button width. Since buttons in toolbar have different widths, TOOLBAR_WrapToolbar miscalculates total width, because actual buttons widths are less then nButtonWidth. This results in TOOLBAR_WrapToolbar setting TBSTATE_WRAP when it is not not needed, and since app does not paint second button row, wrapped buttons just disappear. 2. After I fixed first issue, I noticed, that last button disappears, when toolbar become narrower then its right border. Then, when toolbar right border approximately in the middle of disappeared button, wrap happens. In windows system, wrapping occurs immediately when toolbar becomes narrower. Found solutions: 1. I noticed, that TOOLBAR_LayoutToolbar calculates buttons rects differently, thats because it checks if button have BTNS_AUTOSIZE style and then calculate size. So i moved this BTNS_AUTOSIZE size calculation in separate function for it to then be used in TOOLBAR_LayoutToolbar and TOOLBAR_WrapToolbar to guarantee that cx values for specific button will be equal in both functions. 2. TOOLBAR_WrapToolbar function decides to wrap in case `if ((x + cx - (infoPtr->nButtonWidth - infoPtr->nBitmapWidth) / 2 > width).` This `(infoPtr->nButtonWidth - infoPtr->nBitmapWidth) / 2` turns out, makes this gap, where button right border (x + cx) exceed toolbar right border (width), but wrap wont appear. I did not found any reasons to make this half-button gap, so I just removed it and it solved this issue. The comment above says /\* The layout makes sure the bitmap is visible, but not the button. \*/, but it was introduced in 1999, when TOOLBAR_LayoutToolbar did not existed, and I think its irrelevant now, since layout calculates cx taking both bitmap and string into account. I wrote tests for both fixes: 1. Creates CCS_NORESIZE toolbar, then add BTNS_AUTOSIZE buttons of different widths one by one and checks if wrap happened. In normal case (in windows) wrap should only happen on fourth button, but without fix wrap happens on third. 2. Creates CCS_NORESIZE toolbar with 4 BTNS_AUTOSIZE buttons. Toolbar width at the creation is calculated beforehand and equals exactly buttons widths combined. Then test reduces toolbar width by 1 and checks if wrap happened, in normal case wrap happens, without the fix its not. -- v7: comctl32/toolbar: Remove redundant toolbar wrapping logic. comctl32/toolbar: Use TOOLBAR_AutoSizeButtonWidth in WrapToolbar. comctl32/toolbar: Add TOOLBAR_AutoSizeButtonWidth from LayoutToolbar as a separate function. https://gitlab.winehq.org/wine/wine/-/merge_requests/10261

3 7