--
v4: 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.
mshtml/tests: Implement IServiceProvider and few other interfaces needed
https://gitlab.winehq.org/wine/wine/-/merge_requests/1317
--
v3: 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
On Mon Nov 14 13:31:36 2022 +0000, **** wrote:
> Marvin replied on the mailing list:
> ```
> Hi,
> It looks like your patch introduced the new failures shown below.
> Please investigate and fix them before resubmitting your patch.
> If they are not new, fixing them anyway would help a lot. Otherwise
> please ask for the known failures list to be updated.
> The tests also ran into some preexisting test failures. If you know how
> to fix them that would be helpful. See the TestBot job for the details:
> The full results can be found at:
> https://testbot.winehq.org/JobDetails.pl?Key=126137
> Your paranoid android.
> === debian11 (32 bit report) ===
> crypt32:
> cert.c:4191: Test failed: success
> cert.c:4192: Test failed: got 00000000
> cert.c:4193: Test failed: got 00000000
> qasf:
> asfreader.c:943: Test failed: blocking 0: Wait timed out.
> asfreader.c:955: Test failed: blocking 0: got wrong thread
> asfreader: Timeout
> === debian11 (32 bit de report) ===
> wmvcore:
> wmvcore.c:2981: Test failed: Wait timed out.
> ```
The asfreader failures look genuine, I'll have a look.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15719
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
On Fri Nov 11 21:23:39 2022 +0000, Zebediah Figura wrote:
> > First because it's how it's supposed to be.
> I initially thought that we weren't actually running any visible
> callbacks on these read threads, but I guess the allocation callbacks
> are coming from here. Windows really spawns two threads for each stream? Sheesh.
Yes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15679
On Fri Nov 11 21:26:14 2022 +0000, Zebediah Figura wrote:
> I think we'd still need that GetStreamSelected() check, though, given
> we're looping over all the streams here?
I don't think we need to check it here anymore with the latest version. Deselected streams will never have pending read requests (or they will shortly complete it after deselection, with either error or a last sample).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15680
On Fri Nov 11 21:17:44 2022 +0000, Zebediah Figura wrote:
> Hmm, I never tested selecting streams while running. If that's supposed
> to work it may be better just to leave it as is.
Yeah, starting / stopping threads dynamically didn't seem like a good idea and it's easier to check the correctness with all stream threads started on open / stopped on close.
So instead I keep the thread running but only emit read requests to selected streams. When a stream is deselected, eventually dynamically, it will either fail its read request with `NS_E_NO_MORE_SAMPLES`, or returns a last sample if that happened before, but will then stop receiving read requests.
When a stream is selected again, a read request will be emitted and it will resume reading.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15678