Most Windows shops could not care less about WinRT. Nobody is going to develop libraries that expose a WinRT interface besides Microsoft, nobody is going to use it unless they must, just as almost nobody exposes COM APIs unless they need to run within Office or something. WinRT is so unpopular that all language support was developed by Microsoft themselves.
I think we're talking over each other. I'm not following your point. Do you believe WinRT is going to become the new standard for cross-language interoperability, even on Windows?
Libraries are either OS libraries, in which case something wraps the "platform ABI" and hides the interface (see SDL on Android for example), language specific (.NET libs are only for .NET languages), have custom tailored language A <-> language B binding generators (e.g. Shiboken to expose C++ Qt to Python), or expose a C API.
Even tools like Xamarin to expose Android APIs to .NET rely heavily on intermediate C glue because that's the only alternative (besides IPC, which is not desirable) to avoid running on the JVM.
You just don't get the point, WinRT and COM are exactly the same thing.
COM with .NET metadata files + IInspectable in addition to IUnknown => WinRT
Since Windows Vista all major APIs are COM, you cannot avoid them unless you stuck in pre-historic Windows XP.
SDL on Android works, because Google has exposed the required APIs for game development to NDK, everything else requires a JNI call, or having Java code being called via Android IPC (binder).
Xamarin performance is quite bad versus Java/Kotlin, because they have to cross two layers to do anything meaningfull,
.NET => NDK => JNI and then for every Android event that gets triggered Java/Kotlin => JNI => .NET
Xamarin runs on ART (there is no JVM on Android) anyway, because the only kind of binaries that NDK allows for in proper Play Store applications are shared libraries loaded by Zygote process that owns ART.
All of what you just said is true and yet at the same time utterly pointless to this conversation :| so no I do not get the point.
Yes to talk to the platform you need to use the platform ABI, whatever that may be. OS devs obviously can force people use these ABIs to talk to the platform, otherwise it is literally impossible to talk to the platform. That's true on Linux as well btw, if I want native Desktop notifications across Desktop Environments I need to use the freedesktop standard (based on D-Bus).
I can ignore that, same way I can create a pseudo "notification" with the old Windows API instead of the proper WinRT APIs (heck, even Microsoft Teams does), but that's irrelevant because it's not what we're talking about.
This discussion started from a post on Swift <-> C++ interoperability. Swift has a stable ABI. C++ could directly implement that ABI, but Apple does not have the power to enforce that.
Teams is Electron junk using Web APIs for PWAs, again not C.
Apple has the power to enforce whatever they feel like doing on their own platform, that is why watchOS has a forked LLVM bitcode as executable format, regardless of how unstable the LLVM one is, C ABI matter zero there.
Just like they have a Safe C compiler for iBoot firmware, or have extended C language for lambdas (blocks).
Clang on Apple is different enough from upstream. that it warrants their own column on cppreference.
We are done here, there is no point getting across anyway.
I have no clue what you're on about and why you insist on telling me things I already know that are unrelated to the topic.
Indeed this conversation is not helpful for either of us, I still don't know what you're trying to discuss. If you're under the impression that I claimed OS providers have no power over their own platform, I never once claimed that.
I claimed they cannot enforce their crap as a standard outside of their platform (sometimes not even on the platform, UWP died for all intents and purposes), which is demonstrably true.
Were you under the impression that I was not aware Microsoft Teams is an Electron app? And how its old non-native notifications work and how Electron wraps OS APIs that aren't web standards exposed in Chromium?
Honestly you've not only repeatedly insulted my intelligence in this thread, but you've also ignored all of my attempts at having an on-topic conversation. Normally that would make me label you as a troll, but you've had many valuable contributions across this website so I'll just assume you had a shitty day and leave it at that.
I think we're talking over each other. I'm not following your point. Do you believe WinRT is going to become the new standard for cross-language interoperability, even on Windows?
Libraries are either OS libraries, in which case something wraps the "platform ABI" and hides the interface (see SDL on Android for example), language specific (.NET libs are only for .NET languages), have custom tailored language A <-> language B binding generators (e.g. Shiboken to expose C++ Qt to Python), or expose a C API.
Even tools like Xamarin to expose Android APIs to .NET rely heavily on intermediate C glue because that's the only alternative (besides IPC, which is not desirable) to avoid running on the JVM.