August 2023 - Wine-gitlab - list.winehq.org

[PATCH v4 0/1] MR3567: jscript: handle Array.prototype.splice with omitted deleteCount
by Yuxuan Shui (＠yshui) 15 Aug '23

15 Aug '23

Current code handles omitted deleteCount but assumes it to be zero in that case. Instead an omitted deleteCount means delete everything from `start`. This prevents Adobe sign-in page from loading. -- v4: jscript: fix Array.prototype.splice with omitted deleteCount in html mode https://gitlab.winehq.org/wine/wine/-/merge_requests/3567

3 5

[PATCH 0/1] MR3574: configure: don't require pcsclite header for winscard
by David McFarland (＠corngood) 15 Aug '23

15 Aug '23

The header is unused, and the header check fails with: configure:7860: checking for PCSC/pcsclite.h configure:7860: gcc -m32 -c -g -O2 conftest.c >&5 In file included from conftest.c:50: [...]/include/PCSC/pcsclite.h:45:10: fatal error: wintypes.h: No such file or directory 45 | #include <wintypes.h> | ^~~~~~~~~~~~ Fixes: d405a688ba6b5042775d733f57d00ba6318e1d0f -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3574

3 4

Re: [PATCH v2 0/1] MR3447: ntdll/unix: NtTerminateThread should accept NULL handle
by Ake Rehnman (＠ake.rehnman) 15 Aug '23

15 Aug '23

On Tue Aug 15 14:52:18 2023 +0000, Ake Rehnman wrote: > ```plaintext > int test_ntterminatethread_proc_failed; > DWORD WINAPI test_ntterminatethread_proc( void *arg ) > { > DWORD status = (UINT_PTR)arg; > status = pNtTerminateThread(0, status); > test_ntterminatethread_proc_failed = 1; > return status; > } > /* verifies NtTerminateThread accepts NULL handle */ > static void test_terminate_thread(void) > { > HANDLE thread; > DWORD exitcode; > NTSTATUS status; > test_ntterminatethread_proc_failed = 0; > status = pNtCreateThreadEx( &thread, THREAD_ALL_ACCESS, NULL, GetCurrentProcess(), > (PRTL_THREAD_START_ROUTINE)test_ntterminatethread_proc, > (void*)0x1234, 0, 0, 0, 0, NULL ); > ok( status == STATUS_SUCCESS, "Got unexpected status %#lx.\n", > status ); > WaitForSingleObject(thread, INFINITE); > GetExitCodeThread(thread, &exitcode); > ok( exitcode == 0x1234, "NtTerminateThread failed exitcode = %lx\n", (long)exitcode); > ok( test_ntterminatethread_proc_failed == 0, "NtTerminateThread failed\n"); > } > ``` > Better? The reason it was not in the test case is I already tested it in the snippet in the Bugzilla ticket. The test case was more for making sure it did not pop up again. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3447#note_42339

1 0

Re: [PATCH v2 0/1] MR3447: ntdll/unix: NtTerminateThread should accept NULL handle
by Ake Rehnman (＠ake.rehnman) 15 Aug '23

15 Aug '23

On Tue Aug 15 14:30:00 2023 +0000, Alexandre Julliard wrote: > > If arg == 0x1234 and NtTerminateThread returns to the caller > GetExitCodeThread status would be some other value than 0x1234 unless > NtTerminateThread would return 0x1234 to the caller (which it does not). > It's possible that it sets the exit code without exiting, this is what > NtTerminateProcess does. It really needs an explicit test. ```plaintext int test_ntterminatethread_proc_failed; DWORD WINAPI test_ntterminatethread_proc( void *arg ) { DWORD status = (UINT_PTR)arg; status = pNtTerminateThread(0, status); test_ntterminatethread_proc_failed = 1; return status; } /* verifies NtTerminateThread accepts NULL handle */ static void test_terminate_thread(void) { HANDLE thread; DWORD exitcode; NTSTATUS status; test_ntterminatethread_proc_failed = 0; status = pNtCreateThreadEx( &thread, THREAD_ALL_ACCESS, NULL, GetCurrentProcess(), (PRTL_THREAD_START_ROUTINE)test_ntterminatethread_proc, (void*)0x1234, 0, 0, 0, 0, NULL ); ok( status == STATUS_SUCCESS, "Got unexpected status %#lx.\n", status ); WaitForSingleObject(thread, INFINITE); GetExitCodeThread(thread, &exitcode); ok( exitcode == 0x1234, "NtTerminateThread failed exitcode = %lx\n", (long)exitcode); ok( test_ntterminatethread_proc_failed == 0, "NtTerminateThread failed\n"); } ``` Better? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3447#note_42338

1 0

[PATCH 0/5] MR3534: wined3d: Move GL declarations to wined3d_gl.h, part 3.
by Zebediah Figura (＠zfigura) 15 Aug '23

15 Aug '23

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

3 6

Re: [PATCH v2 0/2] MR3431: wined3d: Fix clears of the current render target in Vulkan - approved
by Jan Sikorski (＠jsikorski) 15 Aug '23

15 Aug '23

This merge request was approved by Jan Sikorski. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3431

1 0

Re: [PATCH v2 0/1] MR3447: ntdll/unix: NtTerminateThread should accept NULL handle
by Alexandre Julliard (＠julliard) 15 Aug '23

15 Aug '23

> If arg == 0x1234 and NtTerminateThread returns to the caller GetExitCodeThread status would be some other value than 0x1234 unless NtTerminateThread would return 0x1234 to the caller (which it does not). It's possible that it sets the exit code without exiting, this is what NtTerminateProcess does. It really needs an explicit test. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3447#note_42334

1 0

Re: [PATCH v2 0/1] MR3447: ntdll/unix: NtTerminateThread should accept NULL handle
by Ake Rehnman (＠ake.rehnman) 15 Aug '23

15 Aug '23

On Tue Aug 15 13:21:04 2023 +0000, Jinoh Kang wrote: > No, I don't think so. > How do you determine whether `NtTerminateThread()` actually terminated > the thread on the spot, or just returned normally to > `test_ntterminatethread_proc` which *in turn* returned to the system? > There's nothing between `status = pNtTerminateThread(0, status);` and > `return status;` that signals that the thread was still alive after the call. > On the other hand, we *do* test that `NtTerminateProcess(0, 195);` > returns to the caller without immediately terminating the process. See > `dlls/kernel32/tests/loader.c` for details. ``` DWORD WINAPI test_ntterminatethread_proc( void *arg ) { DWORD status = (UINT_PTR)arg; status = pNtTerminateThread(0, status); return status; } ``` If arg == 0x1234 and NtTerminateProcess returns to the caller GetExitCodeThread status would be some other value than 0x1234 unless NtTerminateThread would return 0x1234 to the caller (which it does not). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3447#note_42325

1 0

[PATCH v4 0/4] MR3554: mmdevapi: fixes for Yousician
by David McFarland (＠corngood) 15 Aug '23

15 Aug '23

Since Yousician's last update, it was throwing an error when initialising audio output. Unfortunately I don't have access to the old version, but they seem to have dropped win<10 support, and are using only IAudioClient3_InitializeSharedAudioStream. They also use IDeviceTopology to get the type of the first output connector. This is the bare minimum I needed to get it working. -- v4: mmdevapi: add stub for IDeviceTopology mmdevapi/tests: add test for IDeviceTopology mmdevapi: implement IAudioClient3_InitializeSharedAudioStream mmdevapi/tests: add test for AudioClient3_InitializeSharedAudioStream https://gitlab.winehq.org/wine/wine/-/merge_requests/3554

3 9

Re: [PATCH v2 0/1] MR3447: ntdll/unix: NtTerminateThread should accept NULL handle
by Jinoh Kang (＠iamahuman) 15 Aug '23

15 Aug '23

On Tue Aug 15 13:21:04 2023 +0000, Ake Rehnman wrote: > > The most obvious test that I can think off the top of my head is > whether `NtTerminateThread(NULL, _)` returns or not. > It is already in the test case for the patch. No, I don't think so. How do you determine whether `NtTerminateThread()` actually terminated the thread on the spot, or just returned normally to `test_ntterminatethread_proc` which *in turn* returned to the system? There's nothing between `status = pNtTerminateThread(0, status);` and `return status;` that signals that the thread was still alive after the call. On the other hand, we *do* test that `NtTerminateProcess(0, 195);` returns to the caller without immediately terminating the process. See `dlls/kernel32/tests/loader.c` for details. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3447#note_42320

1 0