This finally solves a FIXME that was added back in 1997.
NFS High Stakes (and Motor City Online) both emit a 0x190 access
violation on startup (according to game's strings this was meant
to be debugger detection; I think this was done to interfere in
a DRM bypass but I'm probably wrong).
But anyway that feature causes a Wine Debugger dialog to appear
when starting the games (if you click "Show Details" though they
suddenly start working normally but this is an extra annoyance
for average people who just want to play the game).
This change prevents that by not starting the debugger if the
SEM_NOGPFAULTERRORBOX flag is set (if that flag wasn't set then
people would be complaining about the game crashing every time)
which lets the exception silently go through (it can still be seen
with WINEDEBUG=+seh set though).
I'm not sure how I can test for this exception handling behavior
(I'm thinking of calling RaiseException() inside a __try/__except
block but that might not be exactly what the games are doing).
This patch was originally posted by Zeb in a diff form (so the
patch description has been written by me, DodoGTA).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4567
This patch set now has 24 test failures in wmvcore/tests/wmvcore.c: test_async_reader_streaming(). So it won't be merged now. But I'd like to have it reviewed to see if I was doing things in the right direction.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3193
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
--
v21: ddraw: Increasing the vertex batch size on demand
ddraw: add d3d_perf statistics on buffering
wined3d: Add a TRACE in wined3d_streaming_buffer_unmap()
ddraw: Add a local buffer in d3d_device7_DrawPrimitive()
https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
Also: Add new timeouts to NETCON calls impacted by change
Timeout values are able to be set on all hInternet handles, so they should be able to set in a unified way.
Submitting what I have so far for review.
Known TODO: Tests, verify timeouts are set where NETCON is used, verify ULONG vs DWORD usage rules.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3518
--
v20: tests/d3d12: Test multiple clip distance inputs in test_clip_distance().
tests/d3d12: Use five clip distances for the multiple test in test_clip_distance().
vkd3d-shader/ir: Transform clip/cull outputs and patch constants into arrays.
vkd3d-shader/ir: Transform clip/cull inputs into an array.
vkd3d-shader/spirv: Support no-op signature elements.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/564
This is an attempt to invent a vkd3d-shader interface, and begin to implement
the relevant parts of ID3D12ShaderReflection in vkd3d-utils.
This series is missing most Doxygen documentation, mostly because I feel very
uncertain about this interface and don't want to put in the significant effort
to write documentation until I'm sure it's settled.
This series also has tests for bindings but not the implementation, mainly
because I didn't want to bother splitting those tests out to a separate patch
right now, and I see no harm in having them already there and marked todo...
Here is a long list of already open questions:
* As always, should anything be named differently?
* In particular, I've decided to give the variables names that make it clear
this is d3d-specific code. I think trying to make this generic enough to work
for other shader types is a fool's errand.
* Should we even try to use this interface for sm1? It's mostly already a
subset of dxbc; the only addition is the constant register set...
* Should we bother with interfaces? These count as "constant buffers", they have
a distinct type, and they have some extra data that we'd need to account for.
* Should we bother with lib_* targets? This mostly means allowing for a single
shader to hold multiple sets of reflection data. Note that this would also
affect descriptor info and STAT info, although not signature info.
* I've tried to pass through most data directly, partly out of a concern that
that's what d3dcompiler probably does, and so trying to interpret it could
break an extremely hypothetical and unlikely application. More saliently,
converting to a more sensible representation just to convert back is extra
work that I'm not really sure I see a point for.
But if we want to change the interface regardless, here are some ideas:
- enum vkd3d_shader_d3d_buffer_type could just be more flags.
- I think a buffer's size is redundant and can be calculated from its
contained variables.
Same for field offsets (unless packoffset affects this?)
- "constant_register" could be flags too? But we already have a type for them,
so I don't think that's better.
- The kind/type interface is weird in several ways. Majority could be a type
or var flag; objects could be classes...
* Fields of struct vkd3d_shader_d3d_type could be 16-bit (like they are in the
RDEF section). The main reason I didn't do this is because we can't force a
16-bit enum, although we could define the field as uint16_t. But we could also
just define the other "count" fields as 16-bit.
* I suspect I already know the answer to this one, but... If this is all going
to be d3d specific anyway... do we really care about having this in
vkd3d-shader?
Or, alternatively, we could provide an interface that's friendlier than COM,
but still use the d3d struct types instead of copy-pasting and changing all
the names to vkd3d-shader (which is a bit exhausting, honestly—not just
because of rewriting but because of documentation. The latter is certainly a
self-created problem, but so is the former.)
* vkd3d_shader_d3d_field currently has a hole in it on LP64; is that a problem?
(I think it's the only structure with a hole in it.)
* As long as this is a d3d interface, should we go ahead and make it
"scan_d3d_info" and add all the d3d-specific STAT block stuff?
One extra anticipatory note on how this differs from Wine's implementation:
This implementation does *not* store types in an rbtree, nor deduplicate them.
The main reason for this is that native doesn't deduplicate types (I have tests
for this, later in my local branch) and it avoids what seems like a significant
complication to the vkd3d-shader interface.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/606
This is a split from MR3572. It's needed for Underworld Island (2150830) video seeking.
Changes compared to the patches in MR3572:
1. Avoid making session state changes when in paused state.
2. Add tests to show that the MF_MEDIA_ENGINE_EVENT_SEEKING notification is most likely blocking because notify->seeking_event_received is TRUE right after a SetCurrentTime() call. Same for MF_MEDIA_ENGINE_EVENT_TIMEUPDATE when in paused state.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5130
test_reuseaddr and test_exclusiveaddruse bind to the wildcard address
(0.0.0.0 or [::]). This may trigger a firewall alert on Windows 7, and
the alert UI window may interfere with user32:msg tests.
Fix this by trying to disable the firewall, and skipping the wildcard
address tests if it fails.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53891
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54202
--
v2: ws2_32/tests: Try to disable firewall before testing with any addr.
ws2_32/tests: Factor out test_exclusiveaddruse from test_reuseaddr.
ws2_32/tests: Do ANY address tests in a separate loop in test_reuseaddr.
webservices/tests: Move firewall code to a common header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2000