[PATCH v4 4/6] ddraw: Use WINED3D_SWAPCHAIN_NO_WINDOW_CHANGES only if window is inactive.

[Gabriel Ivăncescu]

On 10/01/2022 20:28, Stefan Dösinger wrote:
> I'll have a closer look at this tomorrow. In particular, I want to see if the behavior is the same on my Windows machines.
> 
> One general musing (doesn't apply to a particular patch / line of code, hence the toppost) is how much of this behavior is d3d's / ddraw's doing and how much might be an external process like explorer.exe or whatever Windows equivalent of a window manager is. Prohibiting non-foreground applications from spawning a fullscreen window over your desktop sounds like a focus stealing prevention mechanism. I'd implement that in a component that is outside the badly behaved / malicious process and not inside like d3d*.dll are.
> 

I'm not sure if that will work, unless you have something in mind. As 
you can see, each version is different. In fact, d3d8 is the only one 
that cares about "foreground thread" in this respect. d3d9ex cares only 
about the focus_window being in the foreground, so you can say it's a 
more strict subset of this.

However, there's d3d9 (normal one) and dxgi which don't care at all 
about what's in foreground / active / thread, and always do change to 
topmost, so from what I can see, how are we supposed to implement this 
outside d3d* (or wined3d) and have d3d9/dxgi still work? Won't this 
affect them as well? How can it make an exception for d3d9/dxgi?

And frankly, dxgi is way more important than d3d8—frankly, I didn't even 
want to fix the d3d8 behavior, just wanted to add some tests to show 
that it is different than ddraw—so the ddraw regression can be fixed 
(starting with patch 4).

And IMO if we're going to test or fix the d3d8 behavior it's best to 
look at old Windows versions (which are consistent, until Win8) since 
it's a very old API and, if any apps really depend on this behavior, 
it's for sure the old one.

> Musing 2: Is it the foreground thread that matters or that the foreground thread belongs to the current process?
> 

Ah, I had missed that, but not sure how important it is to test, it 
would complicate the test a bit since it would require spawning a new 
thread and some synchronization...

> And sorry that this is all so complicated. Window management and window flags are a pain :-(
> 

No problem, as you can see I already found corner cases I didn't think 
of. :-)