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