No, thats my point, its possible to shim say 3d sound into a driver/HW stack that doesn't support it via software. In the cases that you truly need a new HW feature, you assure the userspace API your providing to applications doesn't fail when that feature doesn't exist. AKA you don't make your entire software stack dependent on that feature, you provide fallbacks.
That way the old HW/driver that doesn't have the new feature continues to work.
AKA, like I said its a mindset, its hard to come up with a HW feature that has been invented in the last 40 years that is absolutely required to keep an OS/Application stack working. Sure your OS now has support for 3d headsets, that doesn't mean that it should fail to continue playing games when the user doesn't have that hardware, it just means they don't get that experience, or the games that only work in that environment aren't compatible.
Its not actually that hard, windows/linux on x86 prove that its possible to run newer OSs and frequently applications on old hardware, and in the case of windows frequently without upgrading drivers for decades because the underlying driver API/ABI is extended rather than replaced.
EX, there is hardly a game in place that requires the ray tracing features of the newer RTX/etc series GPUS, but there are plenty of games that support that feature at the same time they work without it.
> AKA, like I said its a mindset, its hard to come up with a HW feature that has been invented in the last 40 years that is absolutely required to keep an OS/Application stack working.
No no no, that's not the problem. The problem is that optional things are fragmentation, and that has a real impact to the application ecosystem.
Here's an extremely simple example (that also happened in the real world). Go back 20 years and make your camera driver abstraction layer. Let's say your API ends up being:
Image takePicture(bool useFlash)
Then a few years later suddenly flash light apps are all the rage, and someone realizes that hey the camera flash would make for a great LED light! So you update the API for apps to include:
void setFlashEnabled(bool enable)
But wait a sec, you can't possible implement that new API for apps on top of the old driver API! No amount of shimming can make it work. So now you have to also have:
so that the new application API can work on both old drivers that haven't updated and new drivers. Bam, fragmentation. Now you not only need to be on the latest OS release, but also on the latest driver stack. And not because of laziness or any other stupid bullshit excuses, but rather simple because of the inescapable fact that hardware abstractions remove flexibility and limit evolution, combined with that nobody can predict the future.
Of course it's "not hard" to make things optional - Android (and the web platform for that matter) are full of examples of that (this is in fact the adopted policy of Android's hardware abstraction layer with Treble - it's been something Android's been doing in practice for real for over 5 years now). The problem it it's fragmentation and is what Android (and web) devs constantly rant about vs. their iOS counterparts. Your argument is essentially that the answer to fragmentation is fragmentation. That's the part where I was saying far above that it's the easy non-answer. It doesn't address the actual complaint of fragmentation. It's something nobody has come up with a good solution to, but that doesn't make it an invalid complaint.
That way the old HW/driver that doesn't have the new feature continues to work.
AKA, like I said its a mindset, its hard to come up with a HW feature that has been invented in the last 40 years that is absolutely required to keep an OS/Application stack working. Sure your OS now has support for 3d headsets, that doesn't mean that it should fail to continue playing games when the user doesn't have that hardware, it just means they don't get that experience, or the games that only work in that environment aren't compatible.
Its not actually that hard, windows/linux on x86 prove that its possible to run newer OSs and frequently applications on old hardware, and in the case of windows frequently without upgrading drivers for decades because the underlying driver API/ABI is extended rather than replaced.
EX, there is hardly a game in place that requires the ray tracing features of the newer RTX/etc series GPUS, but there are plenty of games that support that feature at the same time they work without it.