- wine-gitlab - winehq.org

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

27 Jan '25

Hello, Piotr. Thanks for your review and comments. However, I'm unsure the issue is there (and I have no other clue, because no window machine nor VM). I agree that [MS documentation](https://learn.microsoft.com/en-us/cpp/c-runtime-library/refe… defines the signature you mention, but it is the same for _Cbuild, and I used it as a template. I could have suspected the entries crealf(int64) & cimagf(int64) to be the cause if it had been a 32 vs 64 bit issue. But I don't understand why the difference is between windows & linux. Moreover, I checked the stage log, and I see only zeroes in the failing tests reports, which is weird, even with params size issues). By the way, the positive thing is I figured out that msvcr120_app/msvcr120_app.spec had to be updated. However, the current build-linux stage seems to fail for reasons not related to the branch (I tried to revert a commit then commit back after setting again my user name & email, and still fails saying email not set when other stage do not complain). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7109#note_92974

1 0

[PATCH v12 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 -- v12: 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

3 4

[PATCH v11 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 -- v11: 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

3 10

[PATCH v2 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. -- v2: dlls/oleaut32: Add DeleteTypeInfo() base-cases in typelib.c https://gitlab.winehq.org/wine/wine/-/merge_requests/7203

5 8

[PATCH 0/3] MR7206: Update some include headers regarding debug information.
by eric pouech (＠epo) 27 Jan '25

27 Jan '25

Mostly adding a couple of missing bits. Regarding the 32-bit KDHELP structure definition: - I checked against some SDK:s back to 2000, and the overall size of this structure hasn't changed ever since (some fields have been added with decreasing Reserved array size) - so it's really Wine's header which were missing these fields not the callers -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7206

3 4

[PATCH v10 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 -- v10: 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 8

[PATCH 0/1] MR7138: sapi: Remove some unnecessary traces.
by Shaun Ren (＠shaunren) 27 Jan '25

27 Jan '25

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

3 2

[PATCH v3 0/5] MR7137: sapi: Implement most ISpStream methods.
by Shaun Ren (＠shaunren) 27 Jan '25

27 Jan '25

Needed for Diablo 4's screen reader. -- v3: sapi: Implement IStream methods for SpStream. sapi: Implement ISpStream::GetFormat. https://gitlab.winehq.org/wine/wine/-/merge_requests/7137

4 7

Re: [PATCH v7 0/2] MR5633: win32u: Use the first vertical alternates table regardless of script.
by Huw Davies (＠huw) 27 Jan '25

27 Jan '25

On Mon Jan 27 16:37:50 2025 +0000, Akihiro Sagawa wrote: > @huw, I have been waiting for your review for several months. Do you > have any concerns? Looks good. By the time it was ready, it was too late in the release cycle. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5633#note_92949

1 0

Re: [PATCH v7 0/2] MR5633: win32u: Use the first vertical alternates table regardless of script. - approved
by Huw Davies (＠huw) 27 Jan '25

27 Jan '25

This merge request was approved by Huw Davies. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5633

1 0

[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 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

[PATCH 0/1] MR7199: tapi32: Use wide character string literals.
by Alex Henrie (＠alexhenrie) 26 Jan '25

26 Jan '25

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

3 2

[PATCH 0/1] MR7200: winhlp32: Use wide character string literals.
by Alex Henrie (＠alexhenrie) 26 Jan '25

26 Jan '25

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

3 2

[PATCH 0/1] MR7198: hhctrl: Fix spelling of "local" in OnTopicChange.
by Alex Henrie (＠alexhenrie) 26 Jan '25

26 Jan '25

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

3 2

2025

2024

2023

2022