zlacker

> Also, one at the time controversial decision which worked really well in hindsight was that D3D was an entirely new API in each new major version, which allowed to leave historical baggage behind quickly and keep the API clean (while still supporting those 'frozen' old D3D versions in new Windows versions).

This is interesting. I have always wondered if that is a viable approach to API evolution, so it is good to know that it worked for MS. We will probably add a (possibly public) REST API to a service at work in the near future, and versioning / evolution is certainly going to be an issue there. Thanks!

>>moring+(OP)
It’s a COM based API and so everything is an interface described via an IDL. You add a new member or change the parameters to a method, you must create a new version of the interface with a new GUID descriptor. You can query any interface for other interfaces it supports, so it’s easy for clients to check for newer functionality on incremental versions of DirectX.

In practice for DirectX you just use the header files that are in the SDK.

>>moring+(OP)
I've never had to migrate between DirectX versions but I don't imagine it's the easiest thing in the world due to this approach. Somewhat related I saw a library to translate DirectX 9 function calls to DirectX 12 because apparently so much of the world is still using DirectX 9.

>>jamesf+yd2
That's what the drivers for the new Intel GPUs have to do, since the GPUs were only designed for DX12, and need earlier versions to be emulated

>>kalleb+Wp2
Ah yeah, and it looks like this is what they're using: https://github.com/microsoft/D3D9On12 And it looks like DirectX 11 to DirectX 12 translation exists as well: https://github.com/microsoft/D3D11On12