On 21/01/2022 11:41, Stefan Dösinger wrote:
Am 20.01.2022 um 19:51 schrieb Gabriel Ivăncescu gabrielopcode@gmail.com:
I don't mind, they're at the end of the patch series anyway so can simply be dropped / are independent.
Just to note that d3d8 is a very old API, it's not inconceivable that newer Windows versions can break some apps. Though very unlikely they care about this, so yeah. I don't think d3d8 is even available in 64-bit, looking at testbot results.
Yeah, e.g. ddraw apps tend to get worse and worse on Windows over time. d3d8 on the other hand did away with the worst offenses of ddraw, e.g. being able to lock the front buffer and just draw to the screen, ignoring any windows.
They do care about these things. For the past 20 years backwards compatibility has been Windows' entire raison d'être. Their QA might not find bugs though or fixing things might be harder than telling users to use virtual machines. As such d3d8 is available on 32 bit Windows, but as you've observed it is not available as a 64 bit DLL.
(Interestingly ddraw.dll is available as a 64 bit DLL, but 64 bit ddraw doesn't support the d3d parts. I assume the reason for this is that Internet Explorer and its third party plugins used ddraw a lot, and without a 64 bit ddraw a 64 bit IE would have been impossible)
Let's see if we run into any applications that need specific inactive window behavior in d3d8 or newer. We can always dust of your tests then :-)
Yep. By "unlikely they care" I was referring to d3d8 apps, i.e. caring about this focus behavior.