February 2023 - Wine-GitLab

Re: [PATCH v3 0/5] MR2073: scardsvr: Add stub service. - approved
by Alexandre Julliard (＠julliard) Feb. 8, 2023

Feb. 8, 2023

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2073

1 0

Re: [PATCH v4 0/5] MR81: vkd3d-shader/hlsl: Fixes for SM1 writemasks and swizzles. - approved
by Alexandre Julliard (＠julliard) Feb. 8, 2023

Feb. 8, 2023

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/81

1 0

Re: [PATCH v9 0/2] MR2100: ntdll: Do not send data to port 0.
by Zebediah Figura (＠zfigura) Feb. 8, 2023

Feb. 8, 2023

The prefix of patch 1/2 should be changed to "ws2_32/tests". The subject is not quite a grammatical sentence; I'd just write "Check if sending to port 0 succeeds." > + char buf[12] = "hello world"; No reason to specify the buffer size; you can just write "char buf[]". > + DWORD bytesSent = 0; -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2100#note_23489

1 0

[PATCH 0/1] MR2128: ntdll/tests: Remove some Vista broken broken(<constant>) calls.
by Michael Stefaniuc (＠mstefani) Feb. 8, 2023

Feb. 8, 2023

One of them still needs a broken() for some Win8 machines. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2128

3 2

[PATCH v4 0/3] MR2130: Fix missing *out=NULL in (WMReader|unknown_inner)_QueryInterface
by Ivan Chikish (＠nekotekina) Feb. 8, 2023

Feb. 8, 2023

QueryInterface should set *out to NULL on failure, as it seems to do in many different places. This seems to be a regression from !888. One old game started to crash on startup with this merge request. I bisected it and it pointed to the commit 131ada052a2dbec66df695ce536ca048a2bd9174. -- v4: wmvcore/tests: check out value for NULL in check_interface https://gitlab.winehq.org/wine/wine/-/merge_requests/2130

3 5

[PATCH v3 0/1] MR80: vkd3d-shader/hlsl: Support reflect() intrinsic.
by Nikolay Sivov (＠nsivov) Feb. 8, 2023

Feb. 8, 2023

-- v3: vkd3d-shader/hlsl: Support reflect() intrinsic. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/80

3 2

Re: [PATCH v2 0/1] MR2126: ntdll: Print an error if we receive a signal not on the signal stack.
by Zebediah Figura (＠zfigura) Feb. 8, 2023

Feb. 8, 2023

On Wed Feb 8 19:01:54 2023 +0000, **** wrote: > Paul Gofman replied on the mailing list: > ``` > On 2/8/23 12:55, Rémi Bernon (@rbernon) wrote: > > > > USR1 / USR2 / INT for instance could be blocked in non-Wine threads, > raising them again until they reach a Wine thread. > I think USR1 may only be received by a non-Wine thread if it was > originated by some native library and not by wineserver which sends that > only to threads it knows? In that case, not sure how that can be handled > better in a Wine thread? > Also, is there a good way to block signals in threads which are created > by native libraries, I think we don't know anything about those threads? > ``` Yes, what Paul said. If a non-Wine thread gets USR1 or USR2 it didn't come from us, and handing it to a Wine thread is not going to do the right thing. Note that signal masks are per-thread, but according to my understanding signal *actions* aren't. QUIT is supposed to kill the entire process by default, not just a thread, so just killing that thread doesn't seem right. I suppose we *could* exit() in that case, but QUIT also dumps core by default, so it doesn't seem quite right to do a clean exit either. At least not right enough to be worth the extra complexity. Rethrowing INT to a Wine thread is... nontrivial, but possible, I guess? I'd rather leave it for a follow-up patch if it's really worth doing. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2126#note_23484

1 0

[PATCH 0/1] MR2134: httpapi: Avoid calling RtlInitUnicodeString on a static constant.
by Alex Henrie (＠alexhenrie) Feb. 8, 2023

Feb. 8, 2023

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

3 5

Re: [PATCH v2 0/1] MR2126: ntdll: Print an error if we receive a signal not on the signal stack.
by Rémi Bernon Feb. 8, 2023

Feb. 8, 2023

On Wed Feb 8 18:55:31 2023 +0000, Zebediah Figura wrote: > > Should we really crash on any unexpected signal? > All of the signals we catch are signals for which the default action > specified by POSIX is to terminate. In the case of TRAP, SEGV, ILL, BUS > we have no choice. That might be true for FPE too but I can't remember; > but either way, either the program was expecting an exception and won't > get it, or it was going to crash anyway. > In the case of ABRT, QUIT, INT not terminating seems like the wrong > thing to do (and we can't handle them the normal way because we don't > have a TEB and can't contact the server). > We could potentially ignore USR1 and USR2, but that doesn't seem great > for stability. Whatever was sending them had a reason to do so, and > isn't going to function correctly. > Perhaps more saliently, we were already crashing on unexpected signals, > simply by virtue of trying to access the TEB and then dereferencing it. > This patch just makes it more obvious. Well we currently crash indeed but I don't think it is intentional. Making it explicit would make it look more like it is. I'd think that instead we should block the signals in the threads that cannot handle them, or handle them in a way that doesn't require a TEB. USR1 / USR2 / INT for instance could be blocked in non-Wine threads, raising them again until they reach a Wine thread. I think QUIT should be handled properly by calling `pthread_cancel` or `pthread_exit` and letting the thread cleanup properly. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2126#note_23475

2 1

[PATCH 0/1] MR2126: ntdll: Print an error if we receive a signal not on the signal stack.
by Zebediah Figura (＠zfigura) Feb. 8, 2023

Feb. 8, 2023

Without this patch the process will silently die. I managed to trigger this while trying to trace Child of Light with Renderdoc, the latter of which crashed in its own "TargetControlServerThread". This, confusingly, manifested in the game restarting itself without the Ubisoft overlay; apparently the game or one of its launchers was capable of recognizing when the process had died and restarting it, but would not try to inject the overlay a second time. I have not investigated the cause of the crash; it is not unlikely that it resulted from the overlay injection (despite the fact that that should only directly affect PE code.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2126

5 5