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