March 2025 - Wine-gitlab - list.winehq.org

Re: [PATCH v27 0/1] MR6884: Iphlpapi.dll: Included SendARP
by Huw Davies (＠huw) 12 Mar '25

12 Mar '25

On Tue Mar 11 14:54:20 2025 +0000, Thi Garlet wrote: > @huw, looking at > [netioapi](https://gitlab.winehq.org/wine/wine/-/blob/master/include/netioap…, > I found some functions from [IP Helper > overview](https://learn.microsoft.com/en-us/windows-hardware/drivers/networ…, > but ResolveIpNetEntry2() is not there. > The SendARP() is workig, is something missing to merge ? > thanks Well the idea is you'd implement `ResolveIpNetEntry2()` and have `SendARP()` call it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6884#note_97547

1 0

[PATCH 0/5] MR7511: opengl32: Stop generating wine/opengl_driver.h.
by Rémi Bernon 12 Mar '25

12 Mar '25

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/7511

4 8

[PATCH 0/1] MR7558: kernel32/tests: Flush pending APCs and close handles (ASan).
by Bernhard Übelacker 12 Mar '25

12 Mar '25

ASan gets triggered in `test_read_write` because an APC gets executed while `test_async_file_errors` is already left, and therefore the `ovl` variable in is no longer at the stack. This patch tries to flush the APC before leaving the function `test_async_file_errors`. Also closes two handles opened inside this function. ``` ================================================================= ==508==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffffe1ea7f8 at pc 0x0001401a4933 bp 0x7ffffe1e2a80 sp 0x7ffffe1e2ac8 READ of size 8 at 0x7ffffe1ea7f8 thread T0 0208:fixme:file:server_get_file_info Unsupported info class e #0 0x0001401a4932 in FileIOComplete .../wine/dlls/kernel32/tests/file.c:3337:24 #1 0x6ffffacef75f in KiUserApcDispatcher (C:\windows\system32\ntdll.dll+0x17000f75f) #2 0x6ffffacedf53 in NtDelayExecution (C:\windows\system32\ntdll.dll+0x17000df53) #3 0x6ffffa6eec5f in SleepEx .../wine/dlls/kernelbase\sync.c:346:14 #4 0x00014015a0e3 in test_read_write .../wine/dlls/kernel32/tests/file.c:3451:5 #5 0x00014015a0e3 in func_file .../wine/dlls/kernel32/tests/file.c:6348:5 #6 0x0001404d7fa1 in run_test .../wine/include/wine/test.h:765:5 #7 0x0001404d7fa1 in main .../wine/include/wine/test.h:884:12 #8 0x0001404d9f8f in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:58:11 #9 0x6ffffbfd4808 in BaseThreadInitThunk .../wine/dlls/kernel32\thread.c:61:5 #10 0x6ffffacefa1a in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x17000fa1a) Address 0x7ffffe1ea7f8 is located in stack of thread T0 at offset 30232 in frame #0 0x00014013223f in func_file .../wine/dlls/kernel32/tests/file.c:6296 This frame has 205 object(s): [32, 292) 'cwd.i6426' (line 6001) [368, 628) 'temp_dir.i6427' (line 6001) [704, 964) 'cwd.i' (line 5922) ... [29536, 29796) 'filename.i2304' (line 3395) [29872, 30132) 'szFile.i' (line 3343) [30208, 30240) 'ovl.i' (line 3347) <== Memory access at offset 30232 is inside this variable [30272, 30276) 'count.i' (line 3364) [30288, 30296) 'h.i' (line 3246) ... [116896, 117156) 'temp_path' (line 6297) HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp, SEH and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-use-after-scope .../wine/dlls/kernel32/tests/file.c:3337:24 in FileIOComplete Shadow bytes around the buggy address: 0x7ffffe1ea500: f2 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 0x7ffffe1ea580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffffe1ea600: 00 00 00 00 00 00 00 00 04 f2 f2 f2 f2 f2 f2 f2 0x7ffffe1ea680: f2 f2 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x7ffffe1ea700: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 =>0x7ffffe1ea780: f8 f8 f8 f2 f2 f2 f2 f2 f2 f2 f2 f2 f8 f8 f8[f8] 0x7ffffe1ea800: f2 f2 f2 f2 f8 f2 f8 f2 f2 f2 f8 f2 f2 f2 f8 f8 0x7ffffe1ea880: f8 f8 f2 f2 f2 f2 f8 f2 f8 f8 f8 f8 f8 f8 f8 f8 0x7ffffe1ea900: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x7ffffe1ea980: f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2 f2 f2 f2 f2 0x7ffffe1eaa00: f8 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==508==ABORTING ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7558

1 1

Re: [PATCH v3 0/1] MR7323: wininet: Treat Expires value "-1" the same as "0"
by Jacek Caban (＠jacek) 12 Mar '25

12 Mar '25

On Wed Mar 12 10:25:16 2025 +0000, Yongjie Yao wrote: > I add 5 tests to test_http_connection(). > The first test sends "Expires: 0", the second test sends "Expires: -1", > the third test sends "Expires: 100", the fourth test sends "Expires: > invalid date", the fifth test sends "Expires: Thu, 06 Mar 2025 06:08:11 GMT". > The tests on actual windows 10 has output informations, such as: > ```null > http.c:6837: expires: 2025-03-06 06:14:13, current time: 2025-03-06 > 06:14:13, server response expires: 0 > http.c:6837: expires: 2025-03-06 06:14:14, current time: 2025-03-06 > 06:14:14, server response expires: -1 > http.c:6837: expires: 2025-03-06 06:14:14, current time: 2025-03-06 > 06:14:14, server response expires: 100 > http.c:6837: expires: 2025-03-06 05:14:15, current time: 2025-03-06 > 06:14:15, server response expires: invalid date > http.c:6837: expires: 2025-03-06 06:08:11, current time: 2025-03-06 > 06:14:15, server response expires: Thu, 06 Mar 2025 06:08:11 GMT > ``` > I think Windows treats all numbers as invalid values and sets the > expiration time to the current system time, while other invalid values > set the expiration time to one hour before the current system time, and > valid expiration times use the set expiration time. > In Wine, handling inconsistencies with Windows 10， We treat "0" as > "1601-01-01 00:00:00", and all other invalid values as 10 minutes after > the current system time. such as > ```coffeescript > http.c:6837: expires: 1601-01-01 00:00:00, current time: 2025-03-06 > 06:10:56, server response expires: 0 > 0118:err:wininet:HTTP_ParseDateAsAsctime unexpected weekday L"-1" > 0118:err:wininet:HTTP_ParseDate unexpected date format L"-1" > http.c:6837: expires: 2025-03-06 06:20:56, current time: 2025-03-06 > 06:10:57, server response expires: -1 > 0110:err:wininet:HTTP_ParseDateAsAsctime unexpected weekday L"100" > 0110:err:wininet:HTTP_ParseDate unexpected date format L"100" > http.c:6837: expires: 2025-03-06 06:20:56, current time: 2025-03-06 > 06:10:57, server response expires: 100 > 0118:err:wininet:HTTP_ParseDateAsAsctime unexpected weekday L"inv" > 0118:err:wininet:HTTP_ParseDate unexpected date format L"invalid date" > http.c:6837: expires: 2025-03-06 06:20:56, current time: 2025-03-06 > 06:10:58, server response expires: invalid date > http.c:6837: expires: 2025-03-06 06:08:10, current time: 2025-03-06 > 06:10:58, server response expires: Thu, 06 Mar 2025 06:08:11 GMT > ``` Those are interesting findings, thanks. Could you please also check what's the behavior for missing "Expires" header? It sounds like we should change error handling in `HTTP_ProcessExpires`, I wonder if `!expirationFound` branch there is right... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7323#note_97540

1 0

[PATCH v2 0/1] MR7544: ieframe: Enter reallocation path one position earlier (ASan).
by Bernhard Übelacker 12 Mar '25

12 Mar '25

Trying to browse through the debugger.chm from an old windbg version with hh.exe, I encountered below ASan message. The reallocation path was not entered when `This->travellog.size < This->travellog.position+1`, with e.g. size == 4 and position == 3. Unfortunately the increment of position takes place a few lines later, therefore writing at index 4 of array with size 4. ``` ================================================================= ==hh.exe==316==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7e99833c9a80 at pc 0x6ffffe8490da bp 0x7ffffe1fea70 sp 0x7ffffe1feab0 WRITE of size 16 at 0x7e99833c9a80 thread T0 #0 0x6ffffe8490d9 in __asan_memset /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt\lib/asan/asan_interceptors_memintrinsics.cpp:67:3 #1 0x6ffffa7cb968 in update_travellog /home/bernhard/data/entwicklung/2025/wine\wine/dlls/ieframe/dochost.c:471:59 #2 0x6ffffa7caf09 in ClOleCommandTarget_Exec /home/bernhard/data/entwicklung/2025/wine\wine/dlls/ieframe/dochost.c:780:13 #3 0x6ffff929b38a in IOleCommandTarget_Exec /home/bernhard/data/entwicklung/2025/wine/wine-build/llvm-newwow64-asan-pe/obj\include\docobj.h:848:12 #4 0x6ffff929ad8c in notify_travellog_update /home/bernhard/data/entwicklung/2025/wine\wine/dlls/mshtml/persist.c:71:9 #5 0x6ffff929a82b in set_current_mon /home/bernhard/data/entwicklung/2025/wine\wine/dlls/mshtml/persist.c:108:17 #6 0x6ffff923abb7 in navigate_proc /home/bernhard/data/entwicklung/2025/wine\wine/dlls/mshtml/navigate.c:2155:9 #7 0x6ffff92d43df in hidden_proc /home/bernhard/data/entwicklung/2025/wine\wine/dlls/mshtml/task.c:398:17 #8 0x6ffffd3f3c8e in WINPROC_wrapper /home/bernhard/data/entwicklung/2025/wine\wine/dlls/user32/winproc.c:86:12 #9 0x6ffffd3f28c8 in call_window_proc /home/bernhard/data/entwicklung/2025/wine\wine/dlls/user32/winproc.c:111:15 #10 0x6ffffd3f2ab2 in dispatch_win_proc_params /home/bernhard/data/entwicklung/2025/wine\wine/dlls/user32/winproc.c #11 0x6ffffd3df4fb in dispatch_message /home/bernhard/data/entwicklung/2025/wine\wine/dlls/user32/message.c:804:14 #12 0x6ffffd3df5a1 in DispatchMessageW /home/bernhard/data/entwicklung/2025/wine\wine/dlls/user32/message.c:890:16 #13 0x6ffffdc63d8e in doWinMain /home/bernhard/data/entwicklung/2025/wine\wine/dlls/hhctrl.ocx/hhctrl.c:580:9 #14 0x000140001036 in WinMain /home/bernhard/data/entwicklung/2025/wine\wine/programs/hh/main.c:34:12 #15 0x00014000118f in main /home/bernhard/data/entwicklung/2025/wine\wine/dlls/msvcrt/crt_winmain.c:53:12 #16 0x0001400010b5 in mainCRTStartup /home/bernhard/data/entwicklung/2025/wine\wine/dlls/msvcrt/crt_main.c:58:11 #17 0x6fffffc3565e in BaseThreadInitThunk /home/bernhard/data/entwicklung/2025/wine\wine/dlls/kernel32/thread.c:61:24 #18 0x6fffffdbba1a in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x17004ba1a) 0x7e99833c9a80 is located 0 bytes after 64-byte region [0x7e99833c9a40,0x7e99833c9a80) allocated by thread T0 here: #0 0x6ffffe84a4a1 in malloc /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt\lib/asan/asan_malloc_win.cpp:80:3 #1 0x6ffffa7cb68b in update_travellog /home/bernhard/data/entwicklung/2025/wine\wine/dlls/ieframe/dochost.c:437:31 #2 0x6ffffa7caf09 in ClOleCommandTarget_Exec /home/bernhard/data/entwicklung/2025/wine\wine/dlls/ieframe/dochost.c:780:13 #3 0x6ffff929b38a in IOleCommandTarget_Exec /home/bernhard/data/entwicklung/2025/wine/wine-build/llvm-newwow64-asan-pe/obj\include\docobj.h:848:12 #4 0x6ffff929ad8c in notify_travellog_update /home/bernhard/data/entwicklung/2025/wine\wine/dlls/mshtml/persist.c:71:9 #5 0x6ffff929a82b in set_current_mon /home/bernhard/data/entwicklung/2025/wine\wine/dlls/mshtml/persist.c:108:17 #6 0x6ffff923abb7 in navigate_proc /home/bernhard/data/entwicklung/2025/wine\wine/dlls/mshtml/navigate.c:2155:9 #7 0x6ffff92d43df in hidden_proc /home/bernhard/data/entwicklung/2025/wine\wine/dlls/mshtml/task.c:398:17 #8 0x6ffffd3f3c8e in WINPROC_wrapper /home/bernhard/data/entwicklung/2025/wine\wine/dlls/user32/winproc.c:86:12 #9 0x6ffffd3f28c8 in call_window_proc /home/bernhard/data/entwicklung/2025/wine\wine/dlls/user32/winproc.c:111:15 #10 0x6ffffd3f2ab2 in dispatch_win_proc_params /home/bernhard/data/entwicklung/2025/wine\wine/dlls/user32/winproc.c #11 0x6ffffd3df4fb in dispatch_message /home/bernhard/data/entwicklung/2025/wine\wine/dlls/user32/message.c:804:14 #12 0x6ffffd3df5a1 in DispatchMessageW /home/bernhard/data/entwicklung/2025/wine\wine/dlls/user32/message.c:890:16 #13 0x6ffffdc63d8e in doWinMain /home/bernhard/data/entwicklung/2025/wine\wine/dlls/hhctrl.ocx/hhctrl.c:580:9 #14 0x000140001036 in WinMain /home/bernhard/data/entwicklung/2025/wine\wine/programs/hh/main.c:34:12 #15 0x00014000118f in main /home/bernhard/data/entwicklung/2025/wine\wine/dlls/msvcrt/crt_winmain.c:53:12 #16 0x0001400010b5 in mainCRTStartup /home/bernhard/data/entwicklung/2025/wine\wine/dlls/msvcrt/crt_main.c:58:11 #17 0x6fffffc3565e in BaseThreadInitThunk /home/bernhard/data/entwicklung/2025/wine\wine/dlls/kernel32/thread.c:61:24 #18 0x6fffffdbba1a in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x17004ba1a) SUMMARY: AddressSanitizer: heap-buffer-overflow /home/bernhard/data/entwicklung/2025/wine\wine/dlls/ieframe/dochost.c:471:59 in update_travellog Shadow bytes around the buggy address: 0x7e99833c9800: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd 0x7e99833c9880: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fd 0x7e99833c9900: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa 0x7e99833c9980: 00 00 00 00 00 00 00 fa fa fa fa fa fd fd fd fd 0x7e99833c9a00: fd fd fd fd fa fa fa fa 00 00 00 00 00 00 00 00 =>0x7e99833c9a80:[fa]fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa 0x7e99833c9b00: 00 00 00 00 00 00 00 fa fa fa fa fa fd fd fd fd 0x7e99833c9b80: fd fd fd fa fa fa fa fa 00 00 00 00 00 00 00 fa 0x7e99833c9c00: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa 0x7e99833c9c80: 00 00 00 00 00 00 00 fa fa fa fa fa fd fd fd fd 0x7e99833c9d00: fd fd fd fd fa fa fa fa fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ``` -- v2: ieframe: Enter reallocation path one position earlier (ASan). https://gitlab.winehq.org/wine/wine/-/merge_requests/7544

3 6

[PATCH v2 0/2] MR7557: ntdll: Implement RtlGetFullPathName_UEx.
by Marc-Aurel Zent (＠mzent) 12 Mar '25

12 Mar '25

-- v2: ntdll: Implement RtlGetFullPathName_UEx. https://gitlab.winehq.org/wine/wine/-/merge_requests/7557

2 2

[PATCH 0/2] MR7557: ntdll: Implement RtlGetFullPathName_UEx.
by Marc-Aurel Zent (＠mzent) 12 Mar '25

12 Mar '25

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/7557

2 3

[PATCH v2 0/6] MR7212: Improvement to winedump for debug information files.
by eric pouech (＠epo) 12 Mar '25

12 Mar '25

This series contain fixes for winedump for debug information: - it fixes a bunch of incorrect information dumping, - it fixes a case of crash for .DBG files, - it allows dumping very large PDB files (>4G) Note: for the later item, current tools' read_file() doesn't work with such large files. Instead of fixing read_file(), I opted for letting a dumper for a given file format to only use a fd to the target file, instead of forcing all dumpers to work from a full in-memory image of the target file. This is useful for PDB files, as their underlying storage requires to reassemble non-contiguous blocks, so this saves memory (the in-memory image of the target file) and one copy of the whole file. This means that all functions to guess the file format now uses a fd instead of the full image. -- v2: tools/winedump: Support dumping large PDB files (>4G). tools/winedump: Support more than 64K files in PDB DBI module source substream. tools/winedump: Don't miss hash entries in PDB files. tools/winedump: Don't miss PDB_SYMBOL_RANGE* in PDB files. tools/winedump: Use correct field when dumping CodeView symbols. tools/winedump: Use correct computation for first section out of a .DBG file. https://gitlab.winehq.org/wine/wine/-/merge_requests/7212

2 7

[PATCH v2 0/1] MR7344: winex11: Fix alpha blending in X11DRV_UpdateLayeredWindow.
by Dmitry Timoshkov (＠dmitry) 12 Mar '25

12 Mar '25

Original patch description https://www.winehq.org/pipermail/wine-patches/2017-February/157574.html winehq.org no longer provides the wine-patches archives, so it's necessary to dig into [web.archive.org](https://web.archive.org/web/20211011014926/https://www.win…: https://web.archive.org/web/20211011014926/https://www.winehq.org/pipermail… https://web.archive.org/web/20211011014930/https://www.winehq.org/pipermail… =================================================================== Based on a patch by Dmitry Timoshkov. ## Signed-off-by: Sebastian Lackner sebastian(a)fds-team.de Fixes https://bugs.winehq.org/show_bug.cgi?id=33943. Battle.Net initially creates completely transparent popup windows and afterwards uses UpdateLayeredWindow without hdcSrc to let them fade in. Testing confirms that this works fine on Windows - on Wine however the original content is lost and no longer available. To avoid that, this patch stores the original content in the surface and uses \_NET_WM_WINDOW_OPACITY to create a transparency effect. The same method is already used by SetLayeredWindowAttributes. If compositing is disabled, the window content will be visible immediately. Dmitrys original patch used a different approach, and manually implemented the alpha blending in x11drv_surface_flush using additional buffers, however this shouldn't really be necessary (yet). We can still use it later if there is any benefit compared to using \_NET_WM_WINDOW_OPACITY. -- v2: winex11: Fix alpha blending in X11DRV_UpdateLayeredWindow. https://gitlab.winehq.org/wine/wine/-/merge_requests/7344

2 2

[PATCH v2 0/4] MR7538: winegstreamer: Implement type handler functions for media sink.
by Ziqing Hui (＠zhui) 12 Mar '25

12 Mar '25

-- v2: winegstreamer: Implement stream_sink_type_handler_GetMediaTypeByIndex. winegstreamer: Implement stream_sink_type_handler_GetMediaTypeCount. winegstreamer: Implement stream_sink_type_handler_GetMajorType. winegstreamer: Assume stream type is always not NULL for media sink. https://gitlab.winehq.org/wine/wine/-/merge_requests/7538

3 5