Those OS solutions aren't cross platform (obviously) so they're only used reluctantly for the smallest amount of code necessary to interface with the platform. Microsoft went out of their way to support WinRT in Rust because sure as heck nobody else was going to.

That said, if IPC solutions count (which to me they don't), then the Linux standard would be D-Bus.

For me they count, because it is a way to improve overall application security.

icrosoft went out of their way to support WinRT in Rust, because they want to use Rust themselves, it wasn't out of love.

Same applies with Google's support for Android IPC and Fuchsia IDL for Rust.

Naturally the platforms with headless management like UNIX FOSS clones will never adopt those solutions at scale, hence why nobody cares about D-BUS.

Oh don't get me wrong, for platform APIs IPC is probably the way to go. Microkernels are built entirely around IPC after all.

But I don't want to have to start a separate process and serialize data across a socket to call functions in every library that's packaged with my software, it's too expensive.

Even if the same IPC approach is used in-process and we accept the serialization costs (which is fine), why would library X use this approach and not another one? Specially if it needs to also run on macOS? Different IPC solutions per platform? Nah.

My point about Microsoft is that, had they not supported Rust themselves, it's likely nobody would have bothered with Rust projection for WinRT. That shows that even the OS devs lack the "strength" to enforce these things.

C is the glue everyone uses and will continue to be so for the foreseeable future.

> My point about Microsoft is that, had they not supported Rust themselves, it's likely nobody would have bothered with Rust projection for WinRT. That shows that even the OS devs lack the "strength" to enforce these things.

Nope, it shows that Rust would be irrelevant for most Windows shops, and Microsoft wants to use Rust instead of C++ in certain workloads like they are already shipping on Azure IoT.

Same thing with Android and Fuchsia, good luck using your C glue there.

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.

So what point are you trying to get across to me?

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.