4 ms·

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.

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.

pjmlp 5y ago
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.
- sirwhinesalot 5y ago
  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.
  - pjmlp 5y ago
    > 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.
    - sirwhinesalot 5y ago
      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.
      - pjmlp 5y ago
        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.
        sirwhinesalot 5y ago
        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?

pjmlp 5y ago

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.

sirwhinesalot 5y ago
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.
- pjmlp 5y ago
  > 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.
  - sirwhinesalot 5y ago
    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.
    - pjmlp 5y ago
      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.
      - sirwhinesalot 5y ago
        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?