On Sat, 30 Aug 2025 at 23:31, Oliver Hunt <oliver_at_[hidden]> wrote:

>
>
> > 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
>

As a s side note, even if for some reason the C/C++ libraries did decide to
use utf-16 instead of utf-8 it wouldn't change the need to deal with rando
encodings since there ARE characters not encoded by unicode.

https://commons.wikimedia.org/wiki/Category:Unencoded_characters

https://stackoverflow.com/questions/6276681/what-characters-are-not-present-in-unicode

https://unicode.org/standard/unsupported.html

I'm sure there are more references that can be dug up but I'm stopping
there.