Guess not, but as far as I ever knew, M$ has been known to try to maintain backwards compatibility for longer than most users would even consider necessary.

XP supported DirectX 7/8/9

I would have figured that would have continued on with future versions of Windows, but I guess Satya Nadella decided to scrap backwards compatibility.

Oh well, all the more reason I switched to Linux as my main daily runner after Windows 8 came out. 🤷‍♂️

[–] FeelzGoodMan420@eviltoast.org 7 points 1 month ago* (last edited 1 month ago)

But it IS backwards compatible in the way you are describing. You can play a dx9 game on windows 11. So it is backwards compatible. What you cannot do (usually) is force a game built with dx9 features to use dx11/12 features. If the game wasn't built with new API features (because it released before those features even existed) then you cannot expect it to be able to just "be dx12" all of a sudden.

[–] computergeek125@lemmy.world -2 points 1 month ago* (last edited 1 month ago) (1 children)

DirectX 12 was released in 2015 with Windows 10, so it's unlikely to have been ported back to 8.1 and lower.

MS usually only does current+ with compatibility - so for example FF11 (DirectX 8.1 I think) still works (mostly) on Windows 11, but DX12 won't work on W7

[–] over_clox@lemmy.world -2 points 1 month ago (1 children)

I wasn't suggesting that I'd expect newer DirectX to work on older versions of Windows. I was suggesting that I would have expected newer DirectX standards to still be backwards compatible with older DirectX standards.

Sigh, I guess Satya Nadella decided to scrap backwards compatibility. Oh well, I switched to Linux after Windows 8 came out anyways. 🤷‍♂️

[–] computergeek125@lemmy.world 6 points 1 month ago* (last edited 1 month ago)

I mean... DX 9, 10, and 11 were all released prior to Nadella being CEO/chairman.

But in software, it's very commonplace for library versions not to be backwards compatible without recompiling the software. This isn't the same thing as being able to open a word doc last saved on a floppy disk in 1997 on Word 365 2024 version, this is about loading executable code. Even core libraries in Linux (like OpenSSL and ncurses) respect this same schema, and more strongly than MS.

Using OpenSSL as an example, RHEL 7 provides an interface to OpenSSL 1.0. But 1.1 is not available in the core OS, you'd have to install it separately. 1.1 was introduced to the core in RHEL 8, with a compatibility library on a separate package to support 1.0 packages that hadn't been recompiled against 1.1 yet. In RHEL 9, the same was true of OpenSSL 3 - a compatibility library for 1.1, and 1.0 support fully dropped from core. So no matter which version you use, you still have to install the right library package. That library package will then also have to work on your version of libc - which is often reasonably wide, but it has it limits just the same.

Edit because I forgot a sentence in the last paragraph - like DirectX, VC++, and OpenGL, you have to match the version of ncurses, OpenSSL, etc exactly to the major (and often the minor) version or else the executable won't load up and will generate a linking error. Even if you did mangle the binary code to link it, you'd still end up with data corruption or crashes because the library versions are too different to operate.