November 2025 - Wine-GitLab

[PATCH 0/1] MR9555: Fix ICAP_BITDEPTH semantics, allow setting it
by Bernd Herd (＠herdsoft) Nov. 21, 2025

Nov. 21, 2025

In Twain the capability ICAP_BITDEPTH defines the number of bits to transfer per pixel during a scan. So for an RGB image with 8 bit per color channel, ICAP_BITDEPTH is 24. In Sane the depth is defined as the number of bits per color channel, so for an RGB image with 8 bit per color channel, depth is 8. See Page 10-132 (PDF Page 550) if the Twain 2.5 Spec. Obviously older spec versions where not as exact, so there were misunderstandings. The existing code to handle ICAP_BITDEPTH did not consider this difference and returned the sane depth value. This merge request fixes this and adds the ability to set the depth to 16 bit per color channel for those sane backends that support the "depth" option. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9555

2 1

[PATCH 0/7] MR9554: Cmd engine rewrite (part XXXXI)
by eric pouech (＠epo) Nov. 21, 2025

Nov. 21, 2025

This is cmd engine rewrite part XXXXI. Main goal is to cover bug entry 39289. To do so we need to: - properly handle the echo of commands when not in interactive mode + good news if that this shares mostly the code we added to rewrite commands to pass them in pipe sub-shells, + also fixing the handling of @ at start of command (there we a bunch of issues: it was only supported at the start of a single command, all the other forms IF/FOR/() are supposed to handle them too) + some of the tests assumed there is some kind of propagation of @ in chained commands; I do believe it's mostly linked to the commands actually run + most of the tests related to echo now pass (expect a few where there are discrepancies but only on the number of spaces inserted). I don't feel like fixing these unless an app actually depends on it, - fix a couple of other issues: + prompt $H actually echo:es \x08\x20\x08 instead of \x08... to ensure that prev char is actually cleaned (manually tested on Windows) + loop variables when not expanded inside a !foo! construct (other env variables were). Test program from Bug 29389 works as expected, even if output isn't as nice as on windows, mainly because of conhost refresh rate (BZ#56851). Side note: this is probably the last MR from the cmd engine rewrite saga. There are still open tickets on cmd.exe but most of the structural work should be ok by now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9554

2 7

[PATCH 0/3] MR9537: dmsynth: Add layering support
by Anton Baskanov (＠baskanov) Nov. 21, 2025

Nov. 21, 2025

Required by many SF2 instruments. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9537

4 6

[PATCH 0/2] MR9553: ntdll: Refuse to start if wineserver is in wrong pid namespace
by Alfred Agrell (＠Alcaro) Nov. 21, 2025

Nov. 21, 2025

To reproduce: - `unshare -Upf ./wine cmd` - (in another terminal) `unshare -Upf ./wine not-a-command` The first terminal will now go completely unresponsive, until you kill -9 the relevant start.exe from the second terminal. Root cause analysis: In the first Wine, wineserver gets Unix pid 3 in its namespace. (And a different pid in the root namespace, but no relevant process sees that.) In the second Wine, cmd.exe gets Unix pid 3 in its namespace, and sends it to wineserver. When the second cmd exits, wineserver checks if pid 3 did indeed exit, and SIGKILLs it if not. But since that pid is from wrong namespace, wineserver ends up killing itself instead. While this only happens in badly configured sandboxes, such things do exist in the wild. https://github.com/flathub/org.winehq.Wine/issues/41 The real solution would be either fixing the sandbox config, or making Wine use pidfds instead of pids, but former is out of our control, and latter would be a lot of effort and ifdefs. The second commit only blocks cases where wineserver exists in ntdll's namespace, but not the other way round. It's a much rarer case than having the processes in mutually-inaccessible sibling namespaces, it's a much bigger patch than the ntdll side, and the error is detected at wrong side (meaning it can't print a friendly error). I'm not sure if it's worth keeping. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9553

2 2

[PATCH 0/1] MR9552: kernel32/tests: Skip some tests when feature isn't present on Windows.
by eric pouech (＠epo) Nov. 21, 2025

Nov. 21, 2025

Also forcing access through function pointers when needed. Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9552

2 1

[PATCH 0/1] MR9551: shell32: Avoid double-free in enumerate_strings when cur is zero (ASan).
by Bernhard Übelacker Nov. 21, 2025

Nov. 21, 2025

If this realloc is reached and cur is zero, the realloc is called with a size of zero, which behaves like a free. And returns NULL, because of which the `fail:` label is reached, where the memory, strs is still pointing to, is freed the second time. I did not notice any difference in the tests when `enumerate_strings` is left via the `fail:` label or via the return. I am assuming the case when cur is zero is not intended to reach the `fail:` label. [This is a testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=161003) [ASan details from gitlab](https://gitlab.winehq.org/bernhardu/wine/-/jobs/210107#L2772) <details> <summary>ASan details</summary> ``` ================================================================= ==392==ERROR: AddressSanitizer: attempting double-free on 0x7fa7ca514900 in thread T0: #0 0x6ffffe8cd721 in free /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt\lib/asan/asan_malloc_win.cpp:71:3 #1 0x6ffffba8fa24 in enumerate_strings .../wine/dlls/shell32/autocomplete.c:245 #2 0x6ffffba8ea26 in autocomplete_text .../wine/dlls/shell32/autocomplete.c:637 #3 0x6ffffba8cf86 in ACEditSubclassProc .../wine/dlls/shell32/autocomplete.c:796 #4 0x6ffffd4a8bb0 in WINPROC_wrapper .../wine/dlls/user32/winproc.c:86 #5 0x6ffffd4a775c in call_window_proc .../wine/dlls/user32/winproc.c:111 #6 0x6ffffd4a78be in dispatch_win_proc_params .../wine/dlls/user32/winproc.c #7 0x6ffffd492022 in dispatch_send_message .../wine/dlls/user32/message.c:568 #8 0x6ffffd491fa6 in SendMessageW .../wine/dlls/user32/message.c:587 #9 0x0001400107b9 in test_string_enumerator .../wine/dlls/shell32/tests/autocomplete.c:731 #10 0x00014000cb22 in test_custom_source .../wine/dlls/shell32/tests/autocomplete.c:904 #11 0x00014000a6bf in func_autocomplete .../wine/dlls/shell32/tests/autocomplete.c:938 #12 0x0001400d6c62 in run_test .../wine/include/wine/test.h:780 #13 0x0001400d666b in main .../wine/include/wine/test.h:900 #14 0x0001400d88fa in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:62 #15 0x6fffffc67a54 in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x178027a54) #16 0x6fffffde06e6 in signal_start_thread (C:\windows\system32\ntdll.dll+0x1700506e6) 0x7fa7ca514900 is located 0 bytes inside of 8192-byte region [0x7fa7ca514900,0x7fa7ca516900) freed by thread T0 here: #0 0x6ffffe8cda76 in realloc /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt\lib/asan/asan_malloc_win.cpp:110:3 #1 0x6ffffba8f964 in enumerate_strings .../wine/dlls/shell32/autocomplete.c:231 #2 0x6ffffba8ea26 in autocomplete_text .../wine/dlls/shell32/autocomplete.c:637 #3 0x6ffffba8cf86 in ACEditSubclassProc .../wine/dlls/shell32/autocomplete.c:796 #4 0x6ffffd4a8bb0 in WINPROC_wrapper .../wine/dlls/user32/winproc.c:86 #5 0x6ffffd4a775c in call_window_proc .../wine/dlls/user32/winproc.c:111 #6 0x6ffffd4a78be in dispatch_win_proc_params .../wine/dlls/user32/winproc.c #7 0x6ffffd492022 in dispatch_send_message .../wine/dlls/user32/message.c:568 #8 0x6ffffd491fa6 in SendMessageW .../wine/dlls/user32/message.c:587 #9 0x0001400107b9 in test_string_enumerator .../wine/dlls/shell32/tests/autocomplete.c:731 #10 0x00014000cb22 in test_custom_source .../wine/dlls/shell32/tests/autocomplete.c:904 #11 0x00014000a6bf in func_autocomplete .../wine/dlls/shell32/tests/autocomplete.c:938 #12 0x0001400d6c62 in run_test .../wine/include/wine/test.h:780 #13 0x0001400d666b in main .../wine/include/wine/test.h:900 #14 0x0001400d88fa in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:62 #15 0x6fffffc67a54 in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x178027a54) #16 0x6fffffde06e6 in signal_start_thread (C:\windows\system32\ntdll.dll+0x1700506e6) previously allocated by thread T0 here: #0 0x6ffffe8cda76 in realloc /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt\lib/asan/asan_malloc_win.cpp:110:3 #1 0x6ffffba8f8ee in enumerate_strings .../wine/dlls/shell32/autocomplete.c:212 #2 0x6ffffba8ea26 in autocomplete_text .../wine/dlls/shell32/autocomplete.c:637 #3 0x6ffffba8cf86 in ACEditSubclassProc .../wine/dlls/shell32/autocomplete.c:796 #4 0x6ffffd4a8bb0 in WINPROC_wrapper .../wine/dlls/user32/winproc.c:86 #5 0x6ffffd4a775c in call_window_proc .../wine/dlls/user32/winproc.c:111 #6 0x6ffffd4a78be in dispatch_win_proc_params .../wine/dlls/user32/winproc.c #7 0x6ffffd492022 in dispatch_send_message .../wine/dlls/user32/message.c:568 #8 0x6ffffd491fa6 in SendMessageW .../wine/dlls/user32/message.c:587 #9 0x0001400107b9 in test_string_enumerator .../wine/dlls/shell32/tests/autocomplete.c:731 #10 0x00014000cb22 in test_custom_source .../wine/dlls/shell32/tests/autocomplete.c:904 #11 0x00014000a6bf in func_autocomplete .../wine/dlls/shell32/tests/autocomplete.c:938 #12 0x0001400d6c62 in run_test .../wine/include/wine/test.h:780 #13 0x0001400d666b in main .../wine/include/wine/test.h:900 #14 0x0001400d88fa in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:62 #15 0x6fffffc67a54 in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x178027a54) #16 0x6fffffde06e6 in signal_start_thread (C:\windows\system32\ntdll.dll+0x1700506e6) ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9551

1 1

Re: [PATCH v5 0/1] MR5861: mshtml: Implement visibilitychange event.
by Gabriel Ivăncescu Nov. 21, 2025

Nov. 21, 2025

Simplified this a bit, got rid of having to store list of GeckoBrowsers, now just iterating through the window map we already have to possibly dispatch minimize events. I thought of some ways to try simplify or get rid the refcounting for the hook, but couldn't figure out something better, if you have any ideas let me know. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5861#note_123288

1 0

[PATCH v14 0/5] MR9112: XCOPY and COPY should not attempt to copy a file to itself.
by Joe Souza (＠JoeS209) Nov. 21, 2025

Nov. 21, 2025

Current code attempts to copy a file to itself. File is not actually copied; instead, a file sharing error is received. This result is ugly and differs from native. Behavior now appears to be the same as native with changes in this MR . -- v14: xcopy: Don't attempt to copy a file to itself. https://gitlab.winehq.org/wine/wine/-/merge_requests/9112

3 9

[PATCH v2 0/3] MR9550: dwrite/fallback: Add the Cyrillic range to the fallback data.
by Nikolay Sivov (＠nsivov) Nov. 21, 2025

Nov. 21, 2025

Signed-off-by: Bernhard Kölbl <bkoelbl(a)codeweavers.com> -- v2: dwrite: Add an alternative name for the Noto Sans Symbols font. dwrite: Add the Supplemental Arrows-C range to the fallback data. dwrite: Add the Cyrillic range to the fallback data. https://gitlab.winehq.org/wine/wine/-/merge_requests/9550

3 4

[PATCH v2 0/2] MR9469: dwrite/fallback: Add a few more fallbacks
by Bernhard Kölbl Nov. 21, 2025

Nov. 21, 2025

-- v2: drwite/fallback: Add the Supplemental Arrows-C range to the fallback data. dwrite/fallback: Add the Cyrillic range to the fallback data. https://gitlab.winehq.org/wine/wine/-/merge_requests/9469

2 9