Various notes:
- LowestStartingAddress is still unsupported;
- Patch 5 ("wow64: Set HighestEndingAddress in wow64_NtAllocateVirtualMemoryEx() if it is absent") is fixing existing WOW issue: NtAllocateVirtualMemoryEx() called from wow64 currently does not constraing the allocation to 32 bit address space (wow64_NtAllocateVirtualMemory() passes zero_bits for that).
- I initially thought of using a single inter process APC but added a different one due to zero_bits handling which is easier to convert in the target process.
--
v3: ntdll: Support specified alignment in NtAllocateVirtualMemoryEx().
wow64: Set HighestEndingAddress in wow64_NtAllocateVirtualMemoryEx() if it is absent.
wow64: Support MEM_ADDRESS_REQUIREMENTS in wow64_NtAllocateVirtualMemoryEx().
ntdll/tests: Add tests for memory address requiements.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1025
--
v3: mshtml: Enumerate document elements with name.
mshtml: Split the lookup for an element with name into a separate helper.
mshtml: Do not enumerate internal dynamic props.
mshtml: Fix enumerating first custom prop after builtins.
jscript: Refill the props at end of enumeration in html mode and retry.
jscript: Fill the builtin props for enumeration on prototypes as well.
https://gitlab.winehq.org/wine/wine/-/merge_requests/965
On Mon Oct 10 21:33:57 2022 +0000, Huw Davies wrote:
> This looks correct to me, however afaict, Windows also sets
> `stubMessage.pRpcChannelBuffer` to `NULL` when it releases it, so it
> would be good to have a test for that, as well as it added to the implementation.
> It would be clearer to split this into two commits: the first commit
> would contain just the tests with appropriate `todo_wine`s. A second
> commit would then add the implementation changes and remove the
> `todo_wine`s. That way it's clear what the new changes are fixing.
Ok, easy to do
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/957#note_10232
Huw Davies (@huw) commented about dlls/rpcrt4/tests/cstub.c:
> + /* stubMessage doesn't add its own refcounts on proxy_if1 or proxy_buffer,
> + * so it's possible these are freed out from under it.
> + * E.g. an event sink might unadvise upon receiving the event it was waiting for;
> + * this unadvise could be reentrant to Invoke because SendReceive pumps STA messages.
> + * The source would then erase that conection point entry and Release the proxy. */
> + IRpcProxyBuffer_Disconnect(proxy_buffer);
> + ok(test_chanbuf.RefCount == 1, "got %ld\n", test_chanbuf.RefCount);
> + IRpcProxyBuffer_Release(proxy_buffer);
> + refs = IUnknown_Release(proxy_if1);
> + ok(refs == 0, "got %ld\n", refs);
> + ok(test_chanbuf.RefCount == 1, "got %ld\n", test_chanbuf.RefCount);
> +
> + /* NdrProxyFreeBuffer must not dereference the the now-freed proxy_if1,
> + * yet should still free the remaining reference on test_chanbuf */
> + NdrProxyFreeBuffer(proxy_if1, &stubMessage);
> + ok(test_chanbuf.RefCount == 0, "got %ld\n", test_chanbuf.RefCount);
This looks correct to me, however afaict, Windows also sets `stubMessage.pRpcChannelBuffer` to `NULL` when it releases it, so it would be good to have a test for that, as well as it added to the implementation.
It would be clearer to split this into two commits: the first commit would contain just the tests with appropriate `todo_wine`s. A second commit would then add the implementation changes and remove the `todo_wine`s. That way it's clear what the new changes are fixing.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/957#note_10221