Fixes error connecting to servers in Life is Strange Remastered (due to timeout).
When there are multiple IP addresses for a host name Linux gethostbyname() returns those in random order upon each call (meaning to provide server load balancing). On Windows the order of IP addresses is not determined as well but it is the same on consequent calls (changes after network resets and probably DNS timeout expiration).
The game executes multiple http requests over TLS connection through its own libraries using only winsock from Wine. Upon executing each next request it calls gethostbyname() for the server DNS name and uses the first returned IP address. When that's different from the previous IP address used for established TLS connection it doesn't reuse the connection and establishes the connection from scratch which is very long process due to how the game does it (on Windows as well).
One obvious way to make gethostbyname() behave like Windows would be to cache the results we get from host. But caching gethostbyname() results is tricky, there are already host-side caches which take into account DNS timeouts and network interfaces change. It is possible in theory to cache the result and then still call native gethostbyname() and keep the order if nothing else has changed in the reply, but it seems to me that would complicate things more than this patch does. The patch sorts the output by IP address randomly hashed with a random transform hash established only once per process run. So it will still provide load balancing between the IP addresses between different clients and different process instances while will be returning the same order of IP addresses on consequent calls.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2074
Fixes 2K Launcher failure on start (which is using Chromium) with Windows version set to 8.1+ in the prefix (although newer CEF versions don't have Win 7/8.0 fallback here at all).
The failure happens in chromium/sandbox/win/src/win_utils.cc:GetCurrentProcessHandles().
The version which the launcher is using has a Win7 / 8.0 fallback if NtQueryInformationProcess( ProcessHandleTable ) but before going for fallback it asserts that the reported Windows version is less than 8.1 and the process crashes from assert's int3 exception. Newer versions of Chromium don't have Win7/8.0 fallback at all, so going to fail without ProcessHandleTable success regardless of prefix version if hit this path.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2070
Currently it doesn't work as expected, namely gets stuck on delimiter and caret is moved before the delimiter.
Unnecessary more robust than Windows, which feels like doesn't do any checks at all.
EDIT1: v2: return length in `WB_RIGHT` if its bigger than default return value of 0 on invalid values
EDIT2: v3: don't test `WB_ISDELIMITER` with out of bounds indices, Windows doesn't check them and does out of bounds reads
--
v5: comctl32: Fix PathWordBreakProc.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1977
There is another things that bothers me:
The while loop in parse_wave_form():
- WAVE file chunk order is fmt and then data
- The last fmt or data chunk will "win"; doubt there are any dmusic related WAVE files with duplicate fmt or data chunks.
But for now we can start with the while() loop:
- No clue where those extra chunks are placed
- We don't do anything with the WAV file; we just store it. Though we might run into memory issues with big WAV files.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2029#note_22349
Michael Stefaniuc (@mstefani) commented about dlls/dmime/segment.c:
> + case FOURCC_LIST: {
> + FIXME("Skipping LIST tag\n");
> + break;
> + }
> + case mmioFOURCC('I','S','F','T'): {
> + FIXME("Skipping ISFT tag\n");
> + break;
> + }
> + case mmioFOURCC('f','a','c','t'): {
> + FIXME("Skipping fact tag\n");
> + break;
> + }
> + }
> + }
> +
> + return S_OK;
The stream_next_chunk() in the while loop can fail too and you'll need to return that failure too.
S_FALSE indicates "no more chunks".
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2029#note_22348