If a Windows program writes a registry key of type REG_DWORD but puts more than 4 bytes of data in—I can't imagine why, but I am working with such a program—currently it is persisted as-is in the `WINEPATH` but `regedit` exports it as a `dword:%08x`, truncating the data.
This patch makes sure that only 4-byte DWORDs are exported as `dword:`; any other size falls through as a `hex(4):`.
(I chose to use the literal `4` here instead of `sizeof(DWORD)` because this value isn't directly coupled to the size of a `DWORD` as the compiler sees it; in the (extremely hypothetical?) world in which Wine is compiled with a `DWORD` of some other size, this value should still be 4, because `export_dword_data` will only correctly export something that can be represented in 8 hexadecimal characters.)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3793
Rainbow 6 Siege and some other games require this. Type is printed in the FIXME to determine which type the application requires.
--
v4: gdi32: Add stub for D3DKMTQueryAdapterInfo.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3777
Based on a finding here: https://github.com/ValveSoftware/Proton/issues/6709#issuecomment-1626059391
On Windows, small (or 0) receive buffer works a bit differently when async IO is concerned. It is supposed to bypass some system buffering and receive the data directly to the user buffer if async receive is pending. So the apps may be using 0 buffer size as a small optimization to skip extra buffer copies in the system. On Unix, if the buffer is too small to receive the network packet the packet will just be dropped. As I interpret my tests though, Windows doesn't actually drop the packets with async socket even if there is no receive currently pending (looking like setting smaller buffer have no effect at all).
This behaves differently with synchronous IO, Windows can also drop packets which don't fit the smaller set buffer in this case.
I think that we can just never set receive buffers smaller than the default one on Unix sockets. The only effect of actually setting that which I can think of is that the system starts dropping packets more eagerly. Which is wrong for async socket I/O case. That might be not so wrong for sync socket I/O case, but implementing that specific to I/O type will add a lot of complication and will only lead that we will dropping packets more eagerly. While we are probably still won't be doing it exactly like on Windows as it depends on multiple factors in Unix and Windows network stack.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3705