- wine-gitlab - winehq.org

[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

Re: [PATCH v2 0/1] MR3564: configure: fix caching of PCSCLITE_LIBS on mac
by David McFarland (＠corngood) 15 Aug '23

15 Aug '23

On Tue Aug 15 13:17:06 2023 +0000, Gijs Vermeulen wrote: > @corngood On Linux, it seems I'm now always getting the no-pcsc warning > even though pcsclite is installed and I didn't get this warning before. Sorry about that, see https://gitlab.winehq.org/wine/wine/-/merge_requests/3574 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3564#note_42318

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

> 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3447#note_42313

1 0

[PATCH 0/2] MR3563: server: Symlink CurrentControlSet to ControlSet001
by Torge Matthies (＠tmatthies) 15 Aug '23

15 Aug '23

Signed-off-by: Torge Matthies <openglfreak(a)googlemail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3563

4 6

Re: [PATCH v3 0/1] MR3567: jscript: handle Array.prototype.splice with omitted deleteCount
by Gabriel Ivăncescu (＠insn) 15 Aug '23

15 Aug '23

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

1 0

2025

2024

2023

2022

wine-gitlab