January 2025 - wine-gitlab

[PATCH v9 0/2] MR7169: ntdll: Fix the return value of NtDelayExecution.
by William Horvath (＠whrvth) 27 Jan '25

27 Jan '25

The key change is to never return STATUS_TIMEOUT, and to instead return the result of NtYieldExecution() if zero timeout was passed, or STATUS_SUCCESS otherwise. An overview of the correct values for each combination, copied from the test commit: - Non-alertable, zero timeout: STATUS_SUCCESS or STATUS_NO_YIELD_PERFORMED - Non-alertable, non-zero timeout: STATUS_SUCCESS - Alertable, zero timeout: STATUS_SUCCESS, STATUS_NO_YIELD_PERFORMED, or STATUS_USER_APC - Alertable, non-zero timeout: STATUS_SUCCESS or STATUS_USER_APC -- v9: ntdll: Fix the return value of NtDelayExecution. https://gitlab.winehq.org/wine/wine/-/merge_requests/7169

4 6

[PATCH v8 0/2] MR7169: ntdll: Fix the return value of NtDelayExecution.
by William Horvath (＠whrvth) 27 Jan '25

27 Jan '25

The key change is to never return STATUS_TIMEOUT, and to instead return the result of NtYieldExecution() if zero timeout was passed, or STATUS_SUCCESS otherwise. An overview of the correct values for each combination, copied from the test commit: - Non-alertable, zero timeout: STATUS_SUCCESS or STATUS_NO_YIELD_PERFORMED - Non-alertable, non-zero timeout: STATUS_SUCCESS - Alertable, zero timeout: STATUS_SUCCESS, STATUS_NO_YIELD_PERFORMED, or STATUS_USER_APC - Alertable, non-zero timeout: STATUS_SUCCESS or STATUS_USER_APC -- v8: ntdll: Fix the return value of NtDelayExecution. ntdll/tests: Add tests for NtDelayExecution and Sleep(Ex). https://gitlab.winehq.org/wine/wine/-/merge_requests/7169

4 7

[PATCH v3 0/2] MR7109: Added missing functions _FCbuild, cimag, crealf and cimagf
by Stéphane Bacri (＠fr33z00) 27 Jan '25

27 Jan '25

This MR intends to add the complex numbers related functions: * cimag * _FCbuild * crealf * cimagf These functions are defined in dlls/msvcr120/math.c and mapped in dlls/msvcr120/msvcr120.spec and dlls/ucrbase/ucrbase.spec. The related tests were added in dlls/mscr120/tests/msvcr120.c and result were checked. -- v3: fixed msvcr120_app spec https://gitlab.winehq.org/wine/wine/-/merge_requests/7109

3 3

[PATCH 0/5] MR7205: winecrt0: Add builtin functions for msvc/arm mode
by Martin Storsjö (＠mstorsjo) 27 Jan '25

27 Jan '25

Since 9b8409fce4da18e3d9a914a9e5831d10eb9052de, a PE compiler is required for 32 bit arm. That can either be supplied by using plain Clang (from a distro), or llvm-mingw. However when using plain Clang (in MSVC mode), we're lacking compiler builtin functions that either would be provided by MSVC libraries or by compiler-rt libraries bundled in llvm-mingw. Vendor a copy of the relevant files from compiler-rt and include them when building for arm in MSVC mode. This allows building a functional wine for 32 bit arm without requiring third party tools such as llvm-mingw. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7205

4 20

[PATCH v2 0/2] MR7196: msvcp140: Fix field order in _Mtx_t.
by Daniel Lehman (＠dlehman25) 27 Jan '25

27 Jan '25

recent vs2022 upgrade bypasses _Mtx_init* calls -- v2: msvcp140: Fix field order in _Mtx_t. msvcp140/tests: Add more tests for _Mtx_t. https://gitlab.winehq.org/wine/wine/-/merge_requests/7196

4 4

[PATCH 0/3] MR7204: Fix running arm+arm64 in old wow64 mode
by Martin Storsjö (＠mstorsjo) 27 Jan '25

27 Jan '25

This allows using one single wineprefix, one wineserver and one single wine executable for running both arm and arm64 executables. This setup actually has worked earlier; Ubuntu 22.04 packages Wine 6.0, where the wine32 + wine64 packages together end up working this way. However, since Wine 6.0, a couple of refactorings has broken this setup along the way; reinstate this way of working. The new wow64 mode probably won't work on arm, as it's not easily possible to switch between 32 and 64 bit execution mode within a process, as far as I know, but the old wow64 mode is still a great convenience - especially considering distro-packaged use for users who aren't familiar with the particular quirks on this architecture. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7204

2 3

[PATCH v5 0/7] MR7193: crypt32: A refcount fix and cert enumeraton improvement.
by Paul Gofman (＠gofman) 27 Jan '25

27 Jan '25

-- v5: crypt32: Don't assert in Context_Release() on invalid refcount. crypt32/tests: Add a test for deleting and adding certs during enumeration. crypt32: Only remove cert from mem store list when deleting it. https://gitlab.winehq.org/wine/wine/-/merge_requests/7193

4 9

[PATCH 0/4] MR7203: dlls/oleaut32: Cleanups
by Edward OC (＠funfunctor) 27 Jan '25

27 Jan '25

The intention is to have ICreateTypeLib2_fnDeleteTypeInfo() fully implemented such that Cashbooks can run on Linux. I believe this should fix a number of other Windows apps that lean heavily on oleaut32.dll as well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7203

3 5

[PATCH 0/1] MR7202: shlwapi: Use wide character string literals.
by Alex Henrie (＠alexhenrie) 27 Jan '25

27 Jan '25

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

2 1

[PATCH 0/14] MR7194: Use fixed length to print possibly unterminated buffers. (ASan)
by Bernhard Übelacker (＠bernhardu) 26 Jan '25

26 Jan '25

Recently I am experimenting with an ASan instrumented Wine build (Details [here](https://gitlab.winehq.org/bernhardu/wine/-/blob/asan-pe_2024-12-29/RE…), which was showing some issues when running the confirmance tests. One issue seems to be `ok` statements, which if I understand it right, do evaluate the condition inside the `winetest_ok` function. Unfortunately at that time e.g. `debugstr_w(buf)` as parameters to the `ok` statement got already executed. This leads in some places to overrunning these buffers, especially those which initialize the whole buffer with e.g. `memset(dst, 0xcc, ...`. This patches replace e.g. `debugstr_w(buf)` by their length limiting variant `debugstr_wn(buf, ARRAY_SIZE(buf))`. Following is the example output of the `win32u:win32u` test: ``` wine dlls/win32u/tests/i386-windows/win32u_test.exe win32u ================================================================= ==2640==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x005cf650 at pc 0x0042d112 bp 0x005cdf34 sp 0x005cdf30 READ of size 2 at 0x005cf650 thread T0 #0 0x0042d111 in wine_dbgstr_wn .../wine/include/wine/debug.h:263:30 #1 0x0040394a in debugstr_w .../wine/include/wine/debug.h:522:65 #2 0x0040394a in test_class .../wine/dlls/win32u/tests/win32u.c:269:41 #3 0x0040394a in func_win32u .../wine/dlls/win32u/tests/win32u.c:2548:5 #4 0x00436849 in run_test .../wine/include/wine/test.h:765:5 #5 0x00436260 in main .../wine/include/wine/test.h #6 0x00437f0b in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:58:11 #7 0x7877ea3f in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x7b80ea3f) #8 0x788fce82 in call_thread_func_wrapper (C:\windows\system32\ntdll.dll+0x7bc0ce82) #9 0x789304b4 in call_thread_func .../wine/dlls/ntdll\signal_i386.c:524:9 Address 0x005cf650 is located in stack of thread T0 at offset 5296 in frame #0 0x0040100f in func_win32u .../wine/dlls/win32u/tests/win32u.c:2518 This frame has 37 object(s): [16, 100) 'source_name.i' (line 1291) [144, 184) 'cls.i675' (line 2031) [224, 264) 'cls.i638' (line 1349) [304, 564) 'path.i' (line 1350) [640, 656) 'pi.i' (line 1351) [672, 740) 'startup.i' (line 1352) [784, 812) 'msg.i639' (line 1353) [848, 876) 'msg.i615' (line 1271) [912, 940) 'msg.i' (line 1220) [976, 1024) 'item.i' (line 1143) [1056, 2080) 'buf.i537' (line 1088) [2208, 2216) 'callback_params.i' (line 1024) [2240, 2252) 'smp.i' (line 1028) [2272, 2312) 'cls.i440' (line 1029) [2352, 2872) 'module.i' (line 891) [3008, 3528) 'res_buf.i' (line 891) [3664, 3672) 'module_str.i' (line 892) [3696, 3704) 'res_str.i' (line 892) [3728, 4752) 'bmp_bits.i' (line 893) [4880, 4884) 'width.i' (line 894) [4896, 4900) 'height.i' (line 894) [4912, 4916) 'rate.i' (line 895) [4928, 4932) 'steps.i' (line 895) [4944, 4964) 'info.i348' (line 898) [5008, 5012) 'ret_size.i' (line 752) [5024, 5056) 'buf.i234' (line 415) [5088, 5100) 'himc.i' (line 415) [5120, 5124) 'size.i' (line 417) [5136, 5144) 'name.i' (line 180) [5168, 5296) 'buf.i173' (line 181) <== Memory access at offset 5296 overflows this variable [5328, 5368) 'cls.i' (line 182) [5408, 5412) 'count.i' (line 123) [5424, 6264) 'info.i' (line 71) [6400, 6436) 'mdi.i' (line 1389) [6480, 6680) 'bufW.i' (line 1390) [6752, 6852) 'buf.i' (line 1391) [6896, 6900) 'argv' (line 2519) 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-buffer-overflow .../wine/include/wine/debug.h:263:30 in wine_dbgstr_wn Shadow bytes around the buggy address: 0x005cf380: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x005cf400: f8 f8 f8 f8 f8 f8 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 0x005cf480: f2 f2 f2 f2 f2 f2 f8 f2 f8 f2 f8 f2 f8 f2 f8 f8 0x005cf500: f8 f2 f2 f2 f2 f2 f8 f2 f8 f8 f8 f8 f2 f2 f2 f2 0x005cf580: f8 f8 f2 f2 f8 f2 00 f2 f2 f2 00 00 00 00 00 00 =>0x005cf600: 00 00 00 00 00 00 00 00 00 00[f2]f2 f2 f2 00 00 0x005cf680: 00 00 00 f2 f2 f2 f2 f2 f8 f2 f8 f8 f8 f8 f8 f8 0x005cf700: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x005cf780: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x005cf800: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x005cf880: f8 f8 f8 f8 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 ==2640==ABORTING ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7194

6 24

2025

2024

2023

2022

wine-gitlab January 2025