--
v4: mshtml: Don't create dynamic prop before checking if elem prop even exists.
mshtml: Allow accessing some document elements as props via id.
mshtml: Expose props via element name only for specific element types.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1031
On Thu Oct 13 19:11:33 2022 +0000, Alexandre Julliard wrote:
> This is causing random deadlocks when running the d3d tests here;
> basically the entire Wine session freezes.
> Applying just the first patch is enough to trigger it.
Sorry, I'll have a look.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/944#note_10591
I'd suggest moving some of the existing code into helper functions first. It's already hard to follow and these changes to it aren't making it any simpler.
Also, ten commits per MR is rather too many (especially when they're non trivial). Try sending the first five or so.
If you want to show where it's going, then include a link to a branch which contains the finished set.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/969#note_10582
--
v3: mshtml: Don't create dynamic prop before checking if elem prop even exists.
mshtml: Allow accessing some document elements as props via id.
mshtml: Expose props via element name only for specific element types.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1031
With this series it's now possible to run and pass `user32:monitor` and `user32:sysparams` tests with nulldrv, and so most `user32` tests (except for a few desktop cursor position tests). This still requires some prefix configuration to enable the nulldrv driver, or a change like https://gitlab.winehq.org/rbernon/wine/-/commit/753368ad0ec52f03f8d6e78ca79… to enable it when `DISPLAY` environment variable is unset.
This then shows that some of the user32 tests are failing with winex11 but passing with nulldrv, as in https://gitlab.winehq.org/rbernon/wine/-/commit/6d5f4109a514a0dc266899fcacf….
--
v9: win32u: Read mode from the registry if GetCurrentDisplaySettings fails.
win32u: Write display settings to the registry in apply_display_settings.
win32u: Lock display devices while applying display settings.
win32u: Use an internal WINE_DM_PRIMARY_DEVICE flag on primary adapter modes.
win32u: Remove the device name parameter from GetCurrentDisplaySettings.
win32u: Force update display cache after NtUserChangeDisplaySettingsEx.
win32u: Add a BOOL force parameter to update_display_cache.
https://gitlab.winehq.org/wine/wine/-/merge_requests/551
I used the following test program (compiled with MSVC with /MD):
```
#include <windows.h>
#include <stdio.h>
typedef void** (__cdecl *pcurrent_exception)(void);
int main()
{
HMODULE hvcr = LoadLibraryA("vcruntime140.dll");
HMODULE ucrtb = LoadLibraryA("ucrtbase.dll");
pcurrent_exception p__current_exception1, p__current_exception2;
p__current_exception1 = (pcurrent_exception)GetProcAddress(hvcr, "__current_exception");
p__current_exception2 = (pcurrent_exception)GetProcAddress(ucrtb, "__current_exception");
try
{
throw("ex1");
}
catch (const char *s)
{
EXCEPTION_RECORD* rec1 = (EXCEPTION_RECORD *)*p__current_exception1();
EXCEPTION_RECORD* rec2 = (EXCEPTION_RECORD *)*p__current_exception2();
printf("Exception %s, rec1 %p (code %#lx), rec2 %p.\n", s, rec1, rec1->ExceptionCode, rec2);
}
}
```
This outputs the following on Windows:
```
Exception ex1, rec1 00000089CAF9F990 (code 0xe06d7363), rec2 0000000000000000.
```
So I think that confirms that:
1. vcruntime140 and ucrtbase have distinct local data (or at least current exception data) on Windows;
2. vcruntime140_1 links to vcruntime140.
3. msvcp140 should link to vcruntime140's exception data too as it is apparently able to get the correct current exception in ?__ExceptionPtrCurrentException@@YAXPEAX@Z.
These patches allow the current exception to be correctly located when there are mixed builtin and native VC runtime 140.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1047
With this series it's now possible to run and pass `user32:monitor` and `user32:sysparams` tests with nulldrv, and so most `user32` tests (except for a few desktop cursor position tests). This still requires some prefix configuration to enable the nulldrv driver, or a change like https://gitlab.winehq.org/rbernon/wine/-/commit/753368ad0ec52f03f8d6e78ca79… to enable it when `DISPLAY` environment variable is unset.
This then shows that some of the user32 tests are failing with winex11 but passing with nulldrv, as in https://gitlab.winehq.org/rbernon/wine/-/commit/6d5f4109a514a0dc266899fcacf….
--
v8: win32u: Read mode from the registry if GetCurrentDisplaySettings fails.
win32u: Write display settings to the registry in apply_display_settings.
win32u: Lock display devices while applying display settings.
win32u: Use an internal WINE_DM_PRIMARY_DEVICE flag on primary adapter modes.
win32u: Force update display cache after NtUserChangeDisplaySettingsEx.
win32u: Add a BOOL force parameter to update_display_cache.
https://gitlab.winehq.org/wine/wine/-/merge_requests/551
This is slightly different from dlltool but I think it should be compatible. The transition is done by first replacing dlltool with its bugs, and fixing them in separate changes.
I based the ARM / AARCH64 implementation on the existing code around, but I have no idea if it is correct, and dlltool also doesn't include any delay load implementation for ARM.
--
v2: winebuild: Put the delay import descriptor in data section.
winebuild: Fix import hint value for symbols imported by name.
winebuild: Implement import lib generation to replace dlltool.
winebuild: Split output_static_lib into output_(import|static)_lib.
winebuild: Use asm_name to add underscore prefix in asm_globl.
winebuild: Pass the desired symbol name to get_link_name.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1001
This shows that media session samples are correctly oriented, but that mfmediaengine renders them upside down.
--
v4: mfmediaengine: Remove vertical flipping of video frames.
mfmediaengine/tests: Check IMFMediaEngine_TransferVideoFrames output orientation.
mfmediaengine/tests: Pass a device and output format to create_media_engine.
mf/tests: Check sample grabber RGB / NV12 orientation.
mf/tests: Factor test grabber callback implementations.
https://gitlab.winehq.org/wine/wine/-/merge_requests/874
The practical aspect of this (besides that msvcp140 just should not probably load msvcp120) is that for an app using VC runtime 140 mspcp140.__ExceptionPtrCurrentException gets the thread data from msvcp120.dll while vcruntime140_1 sets those thread data from ucrtbase.dll which are different data. So the application calling mspcp140.__ExceptionPtrCurrentException in catch block gets NULL exception while it was technically set by vcruntime140_1 before calling the app's catch block handler. After this patchset all the current exception data should end up in ucrtbase for VC runtime 140.
There is a bit more to it (not covered by this patchset) when there is a mix of native and builtin VC runtime 140 dlls. From the app behaviour and some tests it looks like with native DLLs msvcp140 and vcruntime140_1 handle current exception data through vcruntime140.dll and vcruntime140.dll does not forward that to ucrtbase. I am not sure if the latter (not forwarding vcruntime140->ucrtbase) is practically important but to avoid the similar problem when mixing native and builtin VC runtime DLLs we should also probably link msvcp140 and vcruntime140_1 to vcruntime140.
--
v2: msvcp140: Import __ExceptionPtrCompare implementation.
msvcp140: Import __ExceptionPtrCopyException implementation.
msvcp140: Import __ExceptionPtrToBool implementation.
msvcp140: Import __ExceptionPtrCurrentException implementation.
msvcp140: Import __ExceptionPtrRethrow implementation.
msvcp140: Import __ExceptionPtrAssign implementation.
msvcp140: Import __ExceptionPtrCopy implementation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1034
Could you split the first commit further? Just make the code change with the commit msg something like "win32u: Add mechanism for font specific system links", but don't add the MS UI Gothic entries. A second commit would add the Gothic entries, and a third the additional Tahoma ones.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1037#note_10391
To avoid direct callbacks from display drivers to win32u while changing display settings.
--
v4: winemac.drv: Resize desktop window on WM_DISPLAYCHANGE message.
winex11.drv: Resize desktop window on WM_DISPLAYCHANGE message.
win32u: Send WM_DISPLAYCHANGE message to the desktop window.
winex11.drv: Send WM_X11DRV_CLIP_CURSOR_REQUEST message from the deskop.
winex11.drv: Sync window positions in a WM_X11DRV_DESKTOP_RESIZED message.
https://gitlab.winehq.org/wine/wine/-/merge_requests/944
--
v3: vkd3d-shader/hlsl: Pass a location pointer to init_node().
vkd3d-shader/hlsl: Introduce a hlsl_new_expr() helper.
vkd3d-shader/hlsl: Write SM4 reinterpret instructions.
vkd3d-shader/hlsl: Parse the asuint() intrinsic.
tests: Add a test for asuint().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/25
The practical aspect of this (besides that msvcp140 just should not probably load msvcp120) is that for an app using VC runtime 140 mspcp140.__ExceptionPtrCurrentException gets the thread data from msvcp120.dll while vcruntime140_1 sets those thread data from ucrtbase.dll which are different data. So the application calling mspcp140.__ExceptionPtrCurrentException in catch block gets NULL exception while it was technically set by vcruntime140_1 before calling the app's catch block handler. After this patchset all the current exception data should end up in ucrtbase for VC runtime 140.
There is a bit more to it (not covered by this patchset) when there is a mix of native and builtin VC runtime 140 dlls. From the app behaviour and some tests it looks like with native DLLs msvcp140 and vcruntime140_1 handle current exception data through vcruntime140.dll and vcruntime140.dll does not forward that to ucrtbase. I am not sure if the latter (not forwarding vcruntime140->ucrtbase) is practically important but to avoid the similar problem when mixing native and builtin VC runtime DLLs we should also probably link msvcp140 and vcruntime140_1 to vcruntime140.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1034
Interpreting the fist two bytes of the `sockaddr` struct as `sa_family`
produces incorrect behaviour on macOS and (presumbly) BSD.
This change is however still backwards compatible with Linux since
`sa_family` is of effective type `uint8_t` and `sa_len` is currently disregarded.
For reference https://www.ibm.com/docs/en/i/7.3?topic=family-af-inet-address and this is from the <sys/socket.h> on macOS
```
/*
* [XSI] Structure used by kernel to store most addresses.
*/
struct sockaddr {
__uint8_t sa_len; /* total length */
sa_family_t sa_family; /* [XSI] address family */
char sa_data[14]; /* [XSI] addr value (actually larger) */
};
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1015
This is slightly different from dlltool but I think it should be compatible. The transition is done by first replacing dlltool with its bugs, and fixing them in separate changes.
I based the ARM / AARCH64 implementation on the existing code around, but I have no idea if it is correct, and dlltool also doesn't include any delay load implementation for ARM.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1001
I'm going to need to add a few more compressed formats, WMV which is straightforward, but also AAC (so MPEG v2/v4 audio), and I think wg_format could be cleaned up a bit like this beforehand.
Then, AAC could either be added as a separate `AUDIO_MPEG4` format, or, with an version field, to the (renamed) `AUDIO_MPEG` format, though it doesn't share any of the current `AUDIO_MPEG1` properties. FWIW GStreamer caps is `audio/mpeg` for both, with an `mpegversion` that can be 1, 2 or 4. Could be very well added as `AUDIO_AAC` too, I don't really mind.
--
v2: winegstreamer: Reorder video format struct in wg_format.
winegstreamer: Rename WG_MAJOR_TYPE_H264 to WG_MAJOR_TYPE_VIDEO_H264.
winegstreamer: Rename WG_MAJOR_TYPE_WMA to WG_MAJOR_TYPE_AUDIO_WMA.
winegstreamer: Rename WG_MAJOR_TYPE_MPEG1_AUDIO to WG_MAJOR_TYPE_AUDIO_MPEG1.
winegstreamer: Move CINEPAK encoded format to a separate major type.
https://gitlab.winehq.org/wine/wine/-/merge_requests/937
On Windows, \Device\NamedPipe\ is the root directory of the named pipe
file system (NPFS), and can be used as RootDirectory to skip its path
when accessing the NPFS namespace.
This introduces a regression that makes it possible to use
\Device\NamedPipe (note the lack of trailing backslash) as RootDirectory
as well, since Wine does not distinguish between \Device\NamedPipe (the
device itself) and \Device\NamedPipe\ (the root directory of the
filesystem).
(Previous iteration of this patch did distinguish between the two, but the method in which it was implemented was deemed hacky.)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/498
`mscomctl.ocx` (part of the VB6 common controls) calls `HeapCreate(0x04000000,1,0)`, that flag is the old and undocumented `HEAP_SHARED`.
`HEAP_CreateSystemHeap()` tries to map memory at `0x80000000`, this fails on Wow64 (and probably should for all 32-bit platforms for non-LAA EXEs).
As a workaround, map the memory anywhere if it fails at `0x80000000`.
I wasn't able to find much documentation about `HEAP_SHARED`, it dates back to Win9x and I guess Wine may have needed it for some native DLLs.
It's not clear whether modern Windows really implements any shared heap functionality any more, every 'shared' heap created returns a different pointer (even in the same process). Maybe Wine should remove the functionality too?
--
v2: kernel32: Remove shared heap functionality.
ntdll: Remove shared heap functionality.
https://gitlab.winehq.org/wine/wine/-/merge_requests/920
Add the ability to disconnect nested node providers, and return element properties for nested nodes.
--
v7: uiautomationcore: Add UIAutomationType_Element property support for nested node providers.
uiautomationcore: Store provider thread nodes that have a runtime ID in an rbtree.
uiautomationcore: Implement UiaDisconnectProvider.
uiautomationcore: Track all HUIANODEs returned from the provider thread.
uiautomationcore: Don't use nested node providers for same-thread HWNDs.
uiautomationcore: Use a separate vtbl for nested node IWineUiaProviders.
https://gitlab.winehq.org/wine/wine/-/merge_requests/908
It's possible for a proxy to be released during the middle of an Invoke.
A specific scenario where this happened was a single-shot event sink
which, upon receiving the event it was waiting for, would immediately
call DispEventUnadvise. This removed the proxy pointing to that sink
from the connection point's list of subscribers and released it.
For such cases all state used to complete the Invoke must be owned by
the __proxy_frame kept on the stack; after calling NdrProxySendReceive
(which pumps STA messages and permits reentrancy), anything inside
*This could be use-after-free. MIDL_STUB_MESSAGE already had its own
IRPCChannelBuffer *pRpcChannelBuffer, but lacked its own refcount.
When this does crash, the exception is caught by RpcTryFinally, but
still leads to leaks since NdrProxyFreeBuffer wasn't able to call
IRPCChannelBuffer::FreeBuffer. To fix this, StdProxy_GetChannel() now
calls AddRef() when setting __proxy_frame::_StubMsg::pRpcChannelBuffer
and NdrProxyFreeBuffer() calls the corresponding Release().
--
v3: rpcrt4: Add a refcount owned by MIDL_STUB_MESSAGE.
rpcrt4/tests: Add tests for lifetime of IRpcChannelBuffer.
https://gitlab.winehq.org/wine/wine/-/merge_requests/957
this gets the YSDrv service to start successfully (with the MmAllocateContiguousMemorySpecifyCache semi-stub)
this service is used by the nox android emulator
--
v25: ntoskrnl.exe: KeInsertQueueDpc stub.
https://gitlab.winehq.org/wine/wine/-/merge_requests/778
this gets the YSDrv service to start successfully (with the MmAllocateContiguousMemorySpecifyCache semi-stub)
this service is used by the nox android emulator
--
v22: ntoskrnl: KeInsertQueueDpc stub
https://gitlab.winehq.org/wine/wine/-/merge_requests/778
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