Date: Sat, 30 Aug 2025 15:30:36 -0700
> On Aug 30, 2025, at 1:54 PM, zxuiji via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> I assure you windows will never "rewrite" their existing APIs, they'll provide new ones maybe but never would they break compatibility with older programs unless they had absolutely
This isn’t more complicated than: many OS providers consider system provided APIs to be ABI stable. It’s not a matter of exterior motivations - for platforms that do not consider requiring every update to require developers to rebuild all of their software changing any API in a way that is not ABI compatible is a non-starter because it definitionally breaks existing software.
Such operating systems also include mechanisms to deal with cases where software essentially depends on _non-API_ implementation details [and bugs] - i.e the software is wrong - specifically because ABI stability is considered something that is valuable. Some platforms don’t consider that to be relevant, and some consider “semver” to be something that permits ABI breakage. Different platforms make different trade offs, and the ones that care about ABI stability cannot change ABI for no reason (and if they do have to change the ABI, they have jump through hoops to maintain backwards compatibility).
Even source/API changes that are ABI stable are not trivial: it means developers try to build for a new platform and they have to change code just to maintain existing behavior - or continue to specify the old release target so that the API changes aren’t exposed (apple’s toolchains provide the build targets info to compilers - os version, etc - so API declarations and definitions present the API definitions for a specific release via the wonders of #if, etc. I assume windows/MSVC provides similar mechanisms).
Outside of individual OS’s C and C++ both consider ABI stability critical so the language and library specifications are similarly not likely to change ABIs, and that necessarily includes the default behaviors, representations, and APIs, of library types.
—Oliver
>
> I assure you windows will never "rewrite" their existing APIs, they'll provide new ones maybe but never would they break compatibility with older programs unless they had absolutely
This isn’t more complicated than: many OS providers consider system provided APIs to be ABI stable. It’s not a matter of exterior motivations - for platforms that do not consider requiring every update to require developers to rebuild all of their software changing any API in a way that is not ABI compatible is a non-starter because it definitionally breaks existing software.
Such operating systems also include mechanisms to deal with cases where software essentially depends on _non-API_ implementation details [and bugs] - i.e the software is wrong - specifically because ABI stability is considered something that is valuable. Some platforms don’t consider that to be relevant, and some consider “semver” to be something that permits ABI breakage. Different platforms make different trade offs, and the ones that care about ABI stability cannot change ABI for no reason (and if they do have to change the ABI, they have jump through hoops to maintain backwards compatibility).
Even source/API changes that are ABI stable are not trivial: it means developers try to build for a new platform and they have to change code just to maintain existing behavior - or continue to specify the old release target so that the API changes aren’t exposed (apple’s toolchains provide the build targets info to compilers - os version, etc - so API declarations and definitions present the API definitions for a specific release via the wonders of #if, etc. I assume windows/MSVC provides similar mechanisms).
Outside of individual OS’s C and C++ both consider ABI stability critical so the language and library specifications are similarly not likely to change ABIs, and that necessarily includes the default behaviors, representations, and APIs, of library types.
—Oliver
Received on 2025-08-30 22:31:09