> 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
Gabriel Ivăncescu (@insn) commented about dlls/jscript/array.c:
> }
>
> add_args = argc-2;
> + } else if (argc && ctx->html_mode) {
> + delete_cnt = length-start;
Are you sure this is html mode specific? To confirm, you should move the test to `documentmode.js` and see what happens in every mode, `es5.js` is for ES5+ (IE9+, but we test it in IE11 mode only).
If it turns out to be ES5 for example, you can use ctx->version >= SCRIPTLANGUAGEVERSION_ES5 instead. Otherwise you can keep html mode of course, if it works in all modes the same.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3567#note_42308