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