- wine-gitlab - winehq.org

[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

[PATCH 0/1] MR7201: kernel32/tests: Match the value in the debug message the test condition.
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. ASan got triggered on this `lstrlenW( dst )` because it seems the NormalizeString function does not add a termination if the length of the source string does not include the terminating character. Because the `ok` statements condition contains `lstrlenW( ptest->expected[i] )` I assume that value is also expected to get printed if the test would fail. ``` ASAN_OPTIONS="allocator_may_return_null=1:halt_on_error=0" wine dlls/kernel32/tests/x86_64-windows/kernel32_test.exe locale ================================================================= ==640==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffffe1dd420 at pc 0x000140117178 bp 0x7ffffe1dd0d0 sp 0x7ffffe1dd118 READ of size 2 at 0x7ffffe1dd420 thread T0 0800:fixme:file:server_get_file_info Unsupported info class e #0 0x000140117177 in lstrlenW .../wine/include/winbase.h:2921:12 #1 0x00014010d76e in test_NormalizeString .../wine/dlls/kernel32/tests/locale.c:7401:54 #2 0x0001400f0e4c in func_locale .../wine/dlls/kernel32/tests/locale.c:8725:3 #3 0x0001401e6c5e in run_test .../wine/include/wine/test.h:765:5 #4 0x0001401e67a1 in main .../wine/include/wine/test.h:884:12 #5 0x0001401e8113 in mainCRTStartup .../wine/dlls/msvcrt/crt_main.c:58:11 #6 0x6fffffc455ee in BaseThreadInitThunk .../wine/dlls/kernel32/thread.c:61:24 #7 0x6fffffdcaaea in RtlUserThreadStart (C:\windows\system32\ntdll.dll+0x17004aaea) Address 0x7ffffe1dd420 is located in stack of thread T0 at offset 544 in frame #0 0x00014010d13f in test_NormalizeString .../wine/dlls/kernel32/tests/locale.c:7212 This frame has 8 object(s): [32, 544) 'dst' (line 7358) <== Memory access at offset 544 overflows this variable [608, 609) 'ret' (line 7359) [624, 628) 'dstlen' (line 7361) [640, 1664) 'buffer' (line 7620) [1792, 1798) 'str745' (line 7621) [1824, 1888) 'srcW' (line 7621) [1920, 1984) 'dstW' (line 7621) [2016, 2272) 'resW' (line 7621) 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/winbase.h:2921:12 in lstrlenW Shadow bytes around the buggy address: 0x7ffffe1dd180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffffe1dd200: f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffffe1dd280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffffe1dd300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffffe1dd380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x7ffffe1dd400: 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2 01 f2 04 f2 0x7ffffe1dd480: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x7ffffe1dd500: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x7ffffe1dd580: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x7ffffe1dd600: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 0x7ffffe1dd680: 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 ==640==ABORTING ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7201

2 1

[PATCH v3 0/2] MR7161: dinput: Clamp FFB effect report value to the field range.
by Oleg Makarenko (＠JacKeTUs) 26 Jan '25

26 Jan '25

If application sends out-of-range values for FFB effects, they become -1, which is undesireable, when -1 is in the physical range of the field and being sent to the device. This patch fixes it, clamping values to the field range. Clamping was earlier implemented [here](https://gitlab.winehq.org/wine/wine/-/blob/wine-6.19/dlls/dinput/effe… in 6.19. Windows does this clamping silently, and doesn't fail `SetParameters` call when values is out of range. Affected application is Assetto Corsa EVO, which with default settings sends out ConstantForce magnitude under/over [documented](https://learn.microsoft.com/en-us/previous-versions/ms835644(v=… \[-10000, 10000\]. [Link to the discussion with some investigation on Steam](https://steamcommunity.com/app/3058630/discussions/0/756142145462617…. In this submission scaling and clamping were moved to the separate `scale_and_clamp_value` function, which is now called every time from `set_parameter_value`. To avoid regression with sending `-1` for the infinite duration effects, separate function `set_parameter_value_no_scaling` created. Gain values in `hid_joystick_send_device_gain` are also scaled and clamped. -- v3: dinput: Clamp FFB effect report value to the field range. dinput/tests: Add more tests for force feedback. https://gitlab.winehq.org/wine/wine/-/merge_requests/7161

3 3

Re: [PATCH v4 0/2] MR7161: dinput: Clamp FFB effect report value to the field range.
by Oleg Makarenko (＠JacKeTUs) 26 Jan '25

26 Jan '25

Added Constant Force tests, with out-of-bounds Magnitude levels. Also updated Condition Effect tests, now includes Saturation field being out-of-bounds. Tests are passing on Windows. That required modifying test HID descriptor, to include new effect type (Constant) and usage (Magnitude). Now we have an option to not clamp specific fields, specifically - Saturation ones. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7161#note_92866

1 0

2025

2024

2023

2022

wine-gitlab