Dropping the workarounds for Windows versions that we don't care about anymore makes it easier to understand what these tests are doing and what's going wrong when they fail.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6001
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=44863
The bug has been fixed already by moving ddraw4 vertex buffers into
system memory. Changing this value makes the game create a smaller
buffer, which makes the game fast on video memory buffers. I think we
should stay close to what Windows drivers report even though we
mitigated the original issue in a different way.
--
v2: ddraw: Set dwMaxVertexCount to 2048.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5687
--
v2: win32u: Simplify the logic for driver messages polling.
win32u: Use the thread message queue shared memory in peek_message.
win32u: Allocate heap in peek_message only when necessary.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5970
> Onimusha: Warlords doesn't even use H264 and has several other problems. None of these games need H264 to be explicitly exposed, they only need compressed output.
This merge request isn't about H.264; it's about compressed samples in general. 1/3 and 2/3 are here because H.264 needs slightly special treatment.
> This is also only making my work on upstreaming Proton changes more difficult and I don't really understand what you are trying to achieve here.
The purpose of 3/3 is to fix bugs related to applications explicitly or implicitly assuming that the media source outputs compressed samples.
What changes does it make more difficult to upstream?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5988#note_75210