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
On Windows it seems sending to port 0 does nothing and does not error.
Presently sendmsg errors with EINVAL.
This works around it, by checking if it's port 0 then skipping the data.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2100
In practice they never fail. If they fail, it means that there
is some underlying platform problem and there is little we can do
anyway. Under pthreads function prototypes allow returning failure,
but that's only used for "error checking" mutexes, which we
don't use.
On the other hand, error handling in vkd3d is rather inconsistent:
sometimes the errors are ignored, sometimes logged, sometimes
passed to the caller. It's hard to handle failures appropriately
if you can't even keep your state consistent, so I think it's
better to avoid trying, assume that synchronization primitives do
not fail and at least have consistent logging if something goes
wrong.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/75
Not completely sure if it's worth having for 8.0, but opening this to share the target I'm trying to reach.
--
v5: ntdll: Add a thread-specific category group cache.
ntdll: Use atomics and lock-free list for category groups.
ntdll: Implement Low Fragmentation Heap frontend.
ntdll: Count allocations and automatically enable LFH.
ntdll: Implement HeapCompatibilityInformation.
ntdll: Fix HeapWalk with empty uncommitted consecutive subheaps.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1628