This series has been split up more than the prior two, keeping the non-tests diffs below 200. Hopefully it's easier to review now. If not, please let me know and I can _try_ to split it further, but I'm not sure it can get much more split up than this.
--
v2: uiautomationcore: Add tests for UiaNodeFromHandle.
uiautomationcore: Create UI Automation client thread.
uiautomationcore: Implement UiaNodeFromHandle.
uiautomationcore: Shutdown provider thread when all returned nodes are released.
uiautomationcore: Increment module reference count when starting provider thread.
uiautomationcore: Implement UiaReturnRawElementProvider.
https://gitlab.winehq.org/wine/wine/-/merge_requests/832
This series has been split up more than the prior two, keeping the non-tests diffs below 200. Hopefully it's easier to review now. If not, please let me know and I can _try_ to split it further, but I'm not sure it can get much more split up than this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/832
On Wed Sep 14 11:53:01 2022 +0000, Santino Mazza wrote:
> Because it simplifies the implementation for saving the registry into
> the file when NtClose get's called. If I want to keep the object handle
> implementation the server should take control for closing the file
> handle, and I don't like that idea so much, I think the caller should be
> responsible for closing the objects it opens.
Ok, let me look into that more.
There are a couple more changes you could make in the meantime:
- Split the `REG_LOAD_APP_KEY` logic and the return key logic into two commits.
- Move the `NtClose()` outside of the `SERVER_START_REQ` block.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/820#note_8415
On Wed Sep 14 10:35:23 2022 +0000, Huw Davies wrote:
> Why are you now sending the filename, rather than the file object
> handle, to the server?
Because it simplifies the implementation for saving the registry into the file when NtClose get's called. If I want to keep the object handle implementation the server should take control for closing the file handle, and I don't like that idea so much, I think the caller should be responsible for closing the objects it opens.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/820#note_8405
On Wed Sep 14 10:36:44 2022 +0000, Alexandre Julliard wrote:
> > I bisected the failure and it looks like it's caused instead by
> 44d6f2adbcca119faebc095f3cfbeeafc50d04f3, from
> https://gitlab.winehq.org/wine/wine/-/merge_requests/657. Reverting it
> alone fixes it:
> Ah sorry about that, reverting your MR fixed it for me but it's possible
> that I screwed up the test.
- Just a test message from E-Mail. -
Am Mi., 14. Sept. 2022 um 11:05 Uhr schrieb Alexandre Julliard
(@julliard) <gitlab(a)winehq.org>:
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/814#note_8404
Huw Davies (@huw) commented about server/protocol.def:
>
> /* Load a registry branch from a file */
> @REQ(load_registry)
> - obj_handle_t file; /* file to load from */
> + unsigned int flags; /* flags */
> + unsigned int access; /* wanted access rights */
> VARARG(objattr,object_attributes); /* object attributes */
> + VARARG(filename,string); /* file to load name */
Why are you now sending the filename, rather than the file object handle, to the server?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/820#note_8403
Huw Davies (@huw) commented about dlls/advapi32/tests/registry.c:
> /* Test simple key load */
> /* Check if the changes are saved */
> ret = RegLoadAppKeyA(hivefilepath, &appkey, KEY_READ | KEY_WRITE, 0, 0);
> - ok(ret == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %ld\n", ret);
> - ok(appkey != NULL, "got a null key\n");
> + todo_wine ok(ret == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %ld\n", ret);
> + todo_wine ok(appkey != NULL, "got a null key\n");
I'd suggest swapping the order of these commits so that you don't end up having to flip-flop these `todo_wine`s.
Also note that there's now no need to add the Signed-off-by tags.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/820#note_8402