this post was submitted on 23 Sep 2024
-13 points (19.0% liked)
Games
32564 readers
2553 users here now
Welcome to the largest gaming community on Lemmy! Discussion for all kinds of games. Video games, tabletop games, card games etc.
Weekly Threads:
Rules:
-
Submissions have to be related to games
-
No bigotry or harassment, be civil
-
No excessive self-promotion
-
Stay on-topic; no memes, funny videos, giveaways, reposts, or low-effort posts
-
Mark Spoilers and NSFW
-
No linking to piracy
More information about the community rules can be found here.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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
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. ๐คทโโ๏ธ
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.