- Wine-GitLab - list.winehq.org

Re: [PATCH v5 0/3] MR11709: Fix GUID paths not being accepted by ShellExecute and explorer's command-line arguments
by Jinoh Kang (＠iamahuman) Aug. 24, 2026

Aug. 24, 2026

On Mon Aug 24 15:13:29 2026 +0000, Andrea Faulds wrote: > I'm not completely sure of this, but I don't think we can. I think the > helper is only designed to close certain windows that appear when errors > occur like “There is no Windows program associated with this type of > file”, and I think this file is only testing things that should trigger > errors… my guess is that there's no existing tests for shell folders > precisely because there's no code for closing them. Thanks for the explanation! In that case, please add ```c if (!winetest_interactive) { skip( "interactive explorer guid argument test (set WINETEST_INTERACTIVE=1)\n" ); return; } ``` at the top of the `test_guid()` function so that it doesn't run in batch mode. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11709#note_149692

1 0

Re: [PATCH v5 0/3] MR11709: Fix GUID paths not being accepted by ShellExecute and explorer's command-line arguments
by Andrea Faulds (＠hikari_no_yume) Aug. 24, 2026

Aug. 24, 2026

On Mon Aug 24 15:02:01 2026 +0000, Jinoh Kang wrote: > Can we reuse the existing helper? It doesn't make multi-process > assumptions and close the window instead. I'm not completely sure of this, but I don't think we can. I think the helper is only designed to close certain windows that appear when errors occur like “There is no Windows program associated with this type of file”, and I think this file is only testing things that should trigger errors… my guess is that there's no existing tests for shell folders precisely because there's no code for closing them. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11709#note_149691

1 0

Re: [PATCH v5 0/3] MR11709: Fix GUID paths not being accepted by ShellExecute and explorer's command-line arguments
by Jinoh Kang (＠iamahuman) Aug. 24, 2026

Aug. 24, 2026

On Mon Aug 24 14:41:54 2026 +0000, Andrea Faulds wrote: > It works under WINE, because WINE launches a separate `explorer` process > for every folder window, and therefore gives a process handle. Without > this bit, the WINE session never ends, which is very annoying. > However, I would not be surprised if it does nothing on Windows (which > doesn't launch separate `explorer` processes) and there is in fact a > hidden explorer window sticking around, which is not good… > I think it might be possible to rework this to try to find the new > window with `IShellWindows` and close it, but that would make things > very complicated and I'm a little worried it might be fragile. > If I removed the test, do you think the fix would still be mergeable? > Otherwise, I guess I'll do the `IShellWindows` thing. Can we reuse the existing helper? It doesn't make multi-process assumptions and close the window instead. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11709#note_149686

1 0

[PATCH v2 0/1] MR11742: krnl386: Don't free DISCARDABLE resources in FreeResource16.
by Alex Henrie (＠alexhenrie) Aug. 24, 2026

Aug. 24, 2026

If a resource is marked DISCARDABLE, it is not actually freed when its refcount reaches 0. In theory the resource's memory is freed when the system is low on memory, but its global handle remains valid to allow the resource to be resurrected with the same handle later. In practice, 16-bit programs can't run out of memory on modern hardware, and the game Tetris Jr. depends on its discardable resources never being discarded. See https://devblogs.microsoft.com/oldnewthing/20040202-00/?p=40783 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=23364 -- v2: krnl386: Don't free DISCARDABLE resources in FreeResource16. https://gitlab.winehq.org/wine/wine/-/merge_requests/11742

3 4

Re: [PATCH v5 0/3] MR11709: Fix GUID paths not being accepted by ShellExecute and explorer's command-line arguments
by Andrea Faulds (＠hikari_no_yume) Aug. 24, 2026

Aug. 24, 2026

On Mon Aug 24 14:24:38 2026 +0000, Jinoh Kang wrote: > Does this actually work? Our tests are non-interactive, and should never > leave stray windows open when the test finishes. It works under WINE, because WINE launches a separate `explorer` process for every folder window, and therefore gives a process handle. Without this bit, the WINE session never ends, which is very annoying. However, I would not be surprised if it does nothing on Windows (which doesn't launch separate `explorer` processes) and there is in fact a hidden explorer window sticking around, which is not good… I think it might be possible to rework this to try to find the new window with `IShellWindows` and close it, but that would make things very complicated and I'm a little worried it might be fragile. If I removed the test, do you think the fix would still be mergeable? Otherwise, I guess I'll do the `IShellWindows` thing. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11709#note_149683

1 0

Re: [PATCH v5 0/3] MR11709: Fix GUID paths not being accepted by ShellExecute and explorer's command-line arguments
by Jinoh Kang (＠iamahuman) Aug. 24, 2026

Aug. 24, 2026

Jinoh Kang (@iamahuman) commented about dlls/shell32/tests/shlexec.c: > + sei.cbSize = sizeof(sei); > + sei.fMask = SEE_MASK_NOCLOSEPROCESS | SEE_MASK_NOASYNC | SEE_MASK_FLAG_NO_UI; > + sei.lpVerb = L"open"; > + sei.lpFile = L"::{20d04fe0-3aea-1069-a2d8-08002b30309d}"; > + sei.nShow = SW_HIDE; > + > + result = ShellExecuteExW(&sei); > + ok(result, "ShellExecuteExW failed\n"); > + > + /* kill the new subprocess if possible as cleanup */ > + > + if (sei.hProcess) > + { > + TerminateProcess(sei.hProcess, 0); > + CloseHandle(sei.hProcess); > + } Does this actually work? Our tests are non-interactive, and should never leave stray windows open when the test finishes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11709#note_149679

1 0

[PATCH 0/3] MR11744: ntdll: Avoid exposing ARM64 syscall dispatcher to the client side.
by Jacek Caban (＠jacek) Aug. 24, 2026

Aug. 24, 2026

Fixes regression from d3b41a854a8b45c0c4fac293bc57df8fe75245c4. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11744

2 4

[PATCH 0/1] MR11741: Draft: gitlab: Install libva-dev.
by Sven Baars (＠sbaars) Aug. 24, 2026

Aug. 24, 2026

I imagine this will reveal that !11692 is needed to be able to compile with -Werror. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11741

3 2

[PATCH 0/1] MR11733: wbemdisp: Avoid out-of-bounds read in objectpath_get_DisplayName.
by Bernhard Übelacker (＠bernhardu) Aug. 24, 2026

Aug. 24, 2026

Followup of 929b2a19cb. Found by ASan. In the call to `SysAllocStringLen` the copy does not stop at a terminating \0, therefore it reads beyond the end of the string constant. [ASan 32-bit report](https://gitlab.winehq.org/bernhardu/wine/-/jobs/297496#L2785) [ASan 64-bit report](https://gitlab.winehq.org/bernhardu/wine/-/jobs/297497#L2927) <details> <summary>ASan details</summary> ``` ==wbemdisp_test.exe==1468==ERROR: AddressSanitizer: global-buffer-overflow on address 0x784dbb14 at pc 0x78595252 bp 0x0022f630 sp 0x0022f1fc READ of size 138 at 0x784dbb14 thread T0 #0 0x78595251 in __asan_memcpy /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:65:3 #1 0x799a9867 in SysAllocStringLen dlls/oleaut32/oleaut.c:358:9 #2 0x784ca369 in objectpath_get_DisplayName dlls/wbemdisp/locator.c:3717:17 #3 0x0040588f in ISWbemObjectPath_get_DisplayName /builds/bernhardu/wine/build64/include/wbemdisp.h:2170:12 #4 0x0040272f in test_ParseDisplayName dlls/wbemdisp/tests/wbemdisp.c:275:30 #5 0x00401021 in func_wbemdisp dlls/wbemdisp/tests/wbemdisp.c:663:5 #6 0x00408dd1 in run_test include/wine/test.h:780:5 #7 0x004088eb in main include/wine/test.h #8 0x0040a5c5 in mainCRTStartup dlls/msvcrt/crt_main.c:70:11 #9 0x7bcc381f in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x7b82381f) #10 0x7be36c2a in call_thread_func_wrapper (C:\windows\system32\ntdll.dll+0x7bc46c2a) #11 0x7be3759a in call_thread_func dlls/ntdll/signal_i386.c:502:9 0x784dbb14 is located 44 bytes before global variable '"objectpath_put_DisplayName"' defined in 'dlls/wbemdisp/locator.c:3733' (0x784dbb40) of size 27 '"objectpath_put_DisplayName"' is ascii string 'objectpath_put_DisplayName' 0x784dbb14 is located 0 bytes after global variable 'L"winmgmts:"' defined in 'dlls/wbemdisp/locator.c:3717' (0x784dbb00) of size 20 SUMMARY: AddressSanitizer: global-buffer-overflow dlls/oleaut32/oleaut.c:358:9 in SysAllocStringLen ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11733

4 4

[PATCH 0/1] MR11742: krnl386: Don't free DISCARDABLE resources in FreeResource16.
by Alex Henrie (＠alexhenrie) Aug. 24, 2026

Aug. 24, 2026

If a resource is marked DISCARDABLE, it is not actually freed when its refcount reaches 0. In theory the resource's memory is freed when the system is low on memory, but its global handle remains valid to allow the resource to be resurrected with the same handle later. In practice, 16-bit programs can't run out of memory on modern hardware, and the game Tetris Jr. depends on its discardable resources never being discarded. See https://devblogs.microsoft.com/oldnewthing/20040202-00/?p=40783 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=23364 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11742

3 2