This seems to be more correct than what we previously had with fewer lines of code, so I like that. I still don't really like the extra flag I had to add for Nt{Create,Open}Key, but I couldn't find a way to make things work without it. I also checked that Windows doesn't use a similar flag (by iterating over all bit masks).
--
v5: ntdll/tests: Refactor the Software\Classes tests.
ntdll/tests: Factor out the NtEnumerateKey() tests.
server: Don't return the actual 32-bit Software\Classes key.
ntdll/tests: Add some some Software\Classes query and enumerate tests.
ntdll/tests: Test that NtCreateKeyEx() also recursively obtains the Wow6432Node parent.
server: Recursively obtain the Wow6432Node parent.
ntdll/tests: Add some Software\Classes subkey tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/966
--
v2: mshtml: Handle cNames > 1 in GetIDsOfNames properly.
mshtml: Forward IDispatchEx to the document node.
mshtml: Forward toString to the document node.
mshtml: Expose IEventTarget on HTMLDocumentObj and forward it to the doc node.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1317
Based on a patch by Jinoh Kang:
https://gitlab.winehq.org/wine/wine/-/merge_requests/155
This patch simplifies the comment somewhat; I don't see it as necessary to fully
explain the concept of memory barriers and acquire/release everywhere that they
are used. In my opinion, it's necessary and also sufficient to explain why these
specific places need an acquire/release pair, what that pair is protecting, and
to cross-reference the parts of the pair with each other.
I've also removed the IOSB aliasing patches. Personally I think that there's no
harm in making our code more endianness-conscious, for things like Winelib, but
on the other hand Windows never supported big-endian, and we've resisted adding
support for architectures Windows doesn't support (and see also [1]). Since it's
not clear to me they're desirable, and they're orthogonal to the purpose of this
patch set, I've removed them; they can be submitted later if there is a
favourable consensus.
[1] https://www.winehq.org/pipermail/wine-devel/2021-July/191600.html
--
v2: ntdll: Use an acquire/release pair on the IOSB status.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1342
On Mon Nov 14 12:05:16 2022 +0000, Zebediah Figura wrote:
> Side note that just occurs to me, we should probably add thread
> descriptions for any new threads, though I don't mind deferring that.
Good idea, done.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15681