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