Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into
a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices.
Note, it *increase* the number of vertices, but bandwith is much less costly
than multiple calls.
Note, only a very precise subset of the calls get buffered in order to
ensure that the disruption is minimal.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814
--
v2: ddraw: Add local buffer in d3d_device7_DrawPrimitive()
https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into
a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices.
Note, it *increase* the number of vertices, but bandwith is much less costly
than multiple calls.
Note, only a very precise subset of the calls get buffered in order to
ensure that the disruption is minimal.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
Starting from Win10, when an apiset target dll (most notably in practice, ucrtbase and msvcrt) is loaded through import resolution or LoadLibrary, the dll from system32 directory is loaded regardless of presence of the same dll in a higher priority search path (e. g., at .exe directory). The other version of apiset target dll is still loaded if LoadLibrary() has a path (even if relative).
The practical issue I am trying to solve is the following scenario (encountered with a game using certain Uplay plugin) which has regressed since apisets implementation in Wine. The game imports ucrtbase.dll. Then, a plugin calls GetModuleHandle("api-ms-win-crt-runtime-l1-1-0.dll") and expects GetProcAddress("_crt_atexit") to succeed on the returned handle. The problem is that the game has ucrtbase.dll in its .exe directory. That one currently gets loaded. Then, find_dll_file() resolves api-ms-win-crt-runtime-l1-1-0.dll to the ucrtbase with a full path in system32 and tries to find that one (this part matches Windows behaviour as far as tests show). Since we have the other ucrtbase loaded this results in NULL module handle.
That issue is reproduced in my test in line 1661 (```ok( hapiset == hsystem || broken( old_behaviour && !hapiset )...```), current Wine behaviour corresponds to old Windows before Win10.
The third patch (which removes the last todo in the added test) is not something I hit with any real application so far, just stomped on that in tests and the fix looks trivial.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2101
The Ubisoft overlay version 135 hot patches and hooks wbem_locator_Release(),
but crashes if Release() is called inside CoCreateInstance(), a condition
that doesn't appear to happen on Windows. So we try to exhibit the
same behavior.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2104
--
v4: rpcrt4/tests: Use common code to set the firewall.
wsdapi/tests: Use common code to set the firewall.
dpnet/tests: Use common code to set the firewall.
dplayx/tests: Use common code to set the firewall.
webservices/tests: Move firewall code to a common header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1987