June 2022 - Wine-Devel - list.winehq.org

Re: [PATCH vkd3d 3/3] vkd3d-utils: Allow writing log output via a custom callback.

by Henri Verbeet

Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>

June 7, 2022

Re: [PATCH vkd3d 2/3] vkd3d: Allow writing log output via a custom callback.

by Henri Verbeet

Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>

June 7, 2022

Re: [PATCH vkd3d 1/3] vkd3d-shader: Allow writing log output via a custom callback.

by Henri Verbeet

Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>

June 7, 2022

Re: [PATCH vkd3d] include: Add ID3D12Debug interface declarations in vkd3d_d3d12sdklayers.idl.

by Henri Verbeet

Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>

June 7, 2022

Re: [PATCH 2/6] uiautomationcore/tests: Skip UiaProviderFromIAccessible tests on Win10v1507.

by Connor McAdams

On Tue, Jun 07, 2022 at 04:13:45PM +0100, Huw Davies wrote: > On Tue, Jun 07, 2022 at 11:02:31AM -0400, Connor McAdams wrote: > > On Tue, Jun 07, 2022 at 10:07:22AM +0100, Huw Davies wrote: > > > On Wed, May 25, 2022 at 02:37:35PM -0400, Connor McAdams wrote: > > > > In Windows 10 version 1507, UiaProviderFromIAccessible will try to check > > > > the IAccessible passed in against the root IAccessible of the HWND > > > > associated with the passed in IAccessible. In all other Windows > > > > versions, this check is done on a call to get_HostRawElementProvider, or > > > > the first time navigating towards a parent or sibling. Rather than work > > > > around this, just skip the tests if this happens. > > > > > > Could we write the tests so that they don't rely on implementation > > > details? Presumably applications run correctly on Windows 10 v1507. > > > > > > Huw. > > > > So, essentially most of my tests for UI Automation kind of revolve > > around things like SET_EXPECT/CHECK_EXPECT/CHECK_CALLED tests as a way > > of testing what UI Automation does with the interfaces we pass into it. > > This is similar to how the tests for oleacc are done. In this case, we'd > > end up with a number of tests where we'd have to add a bunch of > > SET_EXPECT's to account for one specific version of Windows, then we'd > > need some sort of special CHECK_CALLED that could account for a broken > > behavior. It's a lot more work than I think it's worth to work around a > > bug in one specific version of Windows 10. > > Is it really a bug in Windows; it seems more like a different > implementation? How different are the call sequences? > > Huw. I believe it's a bug, or at least a behavior that was undesirable. All other versions of Windows seem to delay this root IAccessible check until specific methods are called on the IRawElementProviderSimple wrapper. The check is basically sending the HWND associated with an IAccessible a WM_GETOBJECT message, and then the returned IAccessible is compared against the currently wrapped one. This can end up with: SET_EXPECT(Accessible_get_accRole); SET_EXPECT(Accessible_get_accState); SET_EXPECT(Accessible_get_accChildCount); SET_EXPECT(Accessible_accLocation); SET_EXPECT(Accessible_get_accName); On both interfaces. This also causes issues when testing the methods that trigger the same check on other versions of Windows, because if the check is done immediately when UiaProviderFromIAccessible is called, the check isn't done on the method calls, meaning we again have to work around this.

June 7, 2022

Re: [PATCH 2/6] uiautomationcore/tests: Skip UiaProviderFromIAccessible tests on Win10v1507.

by Huw Davies

On Tue, Jun 07, 2022 at 11:02:31AM -0400, Connor McAdams wrote: > On Tue, Jun 07, 2022 at 10:07:22AM +0100, Huw Davies wrote: > > On Wed, May 25, 2022 at 02:37:35PM -0400, Connor McAdams wrote: > > > In Windows 10 version 1507, UiaProviderFromIAccessible will try to check > > > the IAccessible passed in against the root IAccessible of the HWND > > > associated with the passed in IAccessible. In all other Windows > > > versions, this check is done on a call to get_HostRawElementProvider, or > > > the first time navigating towards a parent or sibling. Rather than work > > > around this, just skip the tests if this happens. > > > > Could we write the tests so that they don't rely on implementation > > details? Presumably applications run correctly on Windows 10 v1507. > > > > Huw. > > So, essentially most of my tests for UI Automation kind of revolve > around things like SET_EXPECT/CHECK_EXPECT/CHECK_CALLED tests as a way > of testing what UI Automation does with the interfaces we pass into it. > This is similar to how the tests for oleacc are done. In this case, we'd > end up with a number of tests where we'd have to add a bunch of > SET_EXPECT's to account for one specific version of Windows, then we'd > need some sort of special CHECK_CALLED that could account for a broken > behavior. It's a lot more work than I think it's worth to work around a > bug in one specific version of Windows 10. Is it really a bug in Windows; it seems more like a different implementation? How different are the call sequences? Huw.

June 7, 2022

Re: [PATCH 2/6] uiautomationcore/tests: Skip UiaProviderFromIAccessible tests on Win10v1507.

by Connor McAdams

On Tue, Jun 07, 2022 at 10:07:22AM +0100, Huw Davies wrote: > On Wed, May 25, 2022 at 02:37:35PM -0400, Connor McAdams wrote: > > In Windows 10 version 1507, UiaProviderFromIAccessible will try to check > > the IAccessible passed in against the root IAccessible of the HWND > > associated with the passed in IAccessible. In all other Windows > > versions, this check is done on a call to get_HostRawElementProvider, or > > the first time navigating towards a parent or sibling. Rather than work > > around this, just skip the tests if this happens. > > Could we write the tests so that they don't rely on implementation > details? Presumably applications run correctly on Windows 10 v1507. > > Huw. So, essentially most of my tests for UI Automation kind of revolve around things like SET_EXPECT/CHECK_EXPECT/CHECK_CALLED tests as a way of testing what UI Automation does with the interfaces we pass into it. This is similar to how the tests for oleacc are done. In this case, we'd end up with a number of tests where we'd have to add a bunch of SET_EXPECT's to account for one specific version of Windows, then we'd need some sort of special CHECK_CALLED that could account for a broken behavior. It's a lot more work than I think it's worth to work around a bug in one specific version of Windows 10. We could also just remove the whole checking of what methods are called in the tests, but most of my UI Automation tests rely upon this. Thanks for the review. :)

June 7, 2022

Re: [PATCH 0/7] MR195: winhttp: Abort web socket receive operations when the socket handle is closed

by Hans Leidekker

On Tue, 2022-06-07 at 09:05 -0500, Paul Gofman wrote: > > On 7 Jun 2022, at 07:54, Hans Leidekker (@hans) <wine(a)gitlab.winehq.org> wrote: > > > > Hans Leidekker (@hans) commented about dlls/winhttp/request.c: > > > return !ret; > > > } > > > > > > +static void socket_handle_closing( struct object_header *hdr ) > > > +{ > > > + struct socket *socket = (struct socket *)hdr; > > > + > > > + if (socket->request->netconn->secure) > > > + { > > > + cancel_queue( &socket->send_q ); > > > + cancel_queue( &socket->recv_q ); > > > + } > > > + if (!is_queue_empty( &socket->send_q ) || !is_queue_empty( &socket->recv_q )) > > > + netconn_cancel_io( socket->request->netconn ); > > > +} > > I doesn't make a lot of sense that async behavior depends on the connection being secure. Do we really need to replicate this? > > > I don’t have any examples of apps which are happy with one way of doing it and not another. I’d suggest to keep ‘secure’ variant then as I think secure connection is used more often. Also, this variant should deliver callbacks earlier (before exiting close handle call, except for handle closing notification) and apps are more likely to depend on that (e. g. a game where I saw crash on exit without these patches seems to have a race and not crashing depends on all the notifications delivered during WinHttpHandleClose or very shortly after; it also uses secure connection). I agree. The other patches look good. >

June 7, 2022

Re: [PATCH v2 0/5] MR131: wined3d: Introduce wined3d_device_check_format_support().

by Henri Verbeet

On Mon, 6 Jun 2022 at 21:32, Zebediah Figura <zfigura(a)codeweavers.com> wrote: > Henri, do you have any thoughts on the matter? The direction I had planned to go in was pretty much what you suggested in an earlier mail: returning the set of supported format flags/capabilities like d3d11 does, instead of querying for a particular combination. On a certain level, that wouldn't be that different from wined3d_device_check_format_support() introduced by this series, but I'd start from wined3d_check_device_format(), and gradually convert it to the new model, instead of introducing a parallel API like this. (I.e., one of the first steps would be returning the WINED3DUSAGE_QUERY_* flags as an output variable instead of as part of the "usage" variable.) As you say, that's largely orthogonal to adding additional caps that can be queried.

June 7, 2022

Re: [PATCH 0/7] MR195: winhttp: Abort web socket receive operations when the socket handle is closed

by Paul Gofman

> On 7 Jun 2022, at 07:54, Hans Leidekker (@hans) <wine(a)gitlab.winehq.org> wrote: > > Hans Leidekker (@hans) commented about dlls/winhttp/request.c: >> return !ret; >> } >> >> +static void socket_handle_closing( struct object_header *hdr ) >> +{ >> + struct socket *socket = (struct socket *)hdr; >> + >> + if (socket->request->netconn->secure) >> + { >> + cancel_queue( &socket->send_q ); >> + cancel_queue( &socket->recv_q ); >> + } >> + if (!is_queue_empty( &socket->send_q ) || !is_queue_empty( &socket->recv_q )) >> + netconn_cancel_io( socket->request->netconn ); >> +} > I doesn't make a lot of sense that async behavior depends on the connection being secure. Do we really need to replicate this? > I don’t have any examples of apps which are happy with one way of doing it and not another. I’d suggest to keep ‘secure’ variant then as I think secure connection is used more often. Also, this variant should deliver callbacks earlier (before exiting close handle call, except for handle closing notification) and apps are more likely to depend on that (e. g. a game where I saw crash on exit without these patches seems to have a race and not crashing depends on all the notifications delivered during WinHttpHandleClose or very shortly after; it also uses secure connection). > -- > https://gitlab.winehq.org/wine/wine/-/merge_requests/195#note_1639 >

June 7, 2022