4 ms·

> C is the glue interface that connects all the different languages together. That's one of the issues in most UNIX systems. Windows sidestepped it with COM (a

by my123 5y ago

> C is the glue interface that connects all the different languages together. That's one of the issues in most UNIX systems. Windows sidestepped it with COM (and a much improved WinRT as a successor, with a .NET-y object model). On Apple systems, Obj-C is pretty much usable from other languages too, being the standard ABI to glue it all. My takeaway: bring one of those two options properly to Linux, which is needed hard by now, to not fall to the lowest-common denominator. (C++ isn't a solution because of a dubiously stable ABI on quite some platforms)

pjmlp 5y ago
Yes, people mistake OS ABI with C, not understanding that is only a reality on pure C OSes. You forgot mainframes or even Android (C ABI without JNI is of not much help), or ChromeOS (WASM yeah). Linux has such an option, D-BUS, now adopting it at scale is another matter.
- badsectoracula 5y ago
  D-Bus is for IPC not an ABI. If there was something similar it'd be gobject, but i don't think any language other than Vala speaks it "natively" (and considering how much Gtk cares about backwards binary compatibility, i don't think it'd be a good idea to target it anyway).
  - pjmlp 5y ago
    It can run in-proc and fits the scenarios being given on previous comment. I remeber Bonobo, DCOP and KPart days, so I know pretty well what D-Bus is capable of. In micro-kernels the IPC infrastructure is the userspace ABI, as it is the only way to call into OS services, beyond the little glue library to make it possible to do so.
    - marwis 5y ago
      Where did you see in-proc D-Bus? It would be wildly inefficient compared to COM/gobject anyway.
      - pjmlp 5y ago
        COM nowadays runs mostly out of process unless you like crashing the whole application, hence the reference to nano-COM for in-proc APIs that are basically OO ABI. That is why any modern Windows has plenty of COM Surrougate processes running at any given time. As for D-BUS, I stand corrected, I though it had such optimization in place, just as other mechanisms offer.
        marwis 5y ago
        There's a ton of new in-proc COM usage through WinRT.
        pjmlp 5y ago
        You mean the market failure that no one wants to use any more, even those of us that were early adopters? I am betting in 2 to 3 years we will have yet another reboot from WinUI and WinAppSDK. How things are, I wouldn't be surprised with Blazor with WebWidget2 as the new cool desktop UI.
    - badsectoracula 5y ago
      DBus is an IPC protocol, it is the first thing the specification[0] mentions, there isn't any way where it would make sense for it to be used in-process nor the spec provides for such functionality. Some higher level library could potentially provide an API for exposing and consuming (object) interfaces that can be accessed either in-process or out-of-process, though only the latter would really be using DBus and the former would bypass it (and both would be only really usable only by users of that library, not anything using DBus). DCOP is/was also an IPC protocol, though much simpler than DBus as it was essentially about passing arbitrary data between processes with some IDs attached (the higher level API did pretend that they were objects and method calls but the -still public- lower level API worked in terms of string identifiers and data streams), which makes it unsuitable for a cross-language ABI. KPart however (which is still being developed and part of KDE) is sort of a relative idea to COM in that it is really something similar (in concept) to ActiveX, so it could handle some uses (though it lacks the genericness of COM), except it being C++ based also makes it impractical for a cross-language ABI - which is the entire reason COM was brought up (and why IPC approaches like DBus and DCOP aren't relevant to what was discussed). [0] https://dbus.freedesktop.org/doc/dbus-specification.html https://dbus.freedesktop.org/doc/dbus-specification.html
      - pjmlp 5y ago
        2h30m before of your comment, I already acknowledged my mistake, you could have saved yourself some typing.
        badsectoracula 5y ago
        Oops, it was in another reply and i didn't notice it.
flohofwoe 5y ago
> Windows sidestepped it with COM Erm, isn't the whole point of COM that it is also just a "C glue interface"? Not how one would typically design C APIs, but COM APIs are C APIs nonetheless.
- marwis 5y ago
  But it's higher level. It lets you expose interfaces and defines memory management and threading vs using raw C functions where you have to manually encode all of that for every other language.

by my123 5y ago

pjmlp 5y ago

Yes, people mistake OS ABI with C, not understanding that is only a reality on pure C OSes. You forgot mainframes or even Android (C ABI without JNI is of not much help), or ChromeOS (WASM yeah). Linux has such an option, D-BUS, now adopting it at scale is another matter.

badsectoracula 5y ago
D-Bus is for IPC not an ABI. If there was something similar it'd be gobject, but i don't think any language other than Vala speaks it "natively" (and considering how much Gtk cares about backwards binary compatibility, i don't think it'd be a good idea to target it anyway).
- pjmlp 5y ago
  It can run in-proc and fits the scenarios being given on previous comment. I remeber Bonobo, DCOP and KPart days, so I know pretty well what D-Bus is capable of. In micro-kernels the IPC infrastructure is the userspace ABI, as it is the only way to call into OS services, beyond the little glue library to make it possible to do so.
  - marwis 5y ago
    Where did you see in-proc D-Bus? It would be wildly inefficient compared to COM/gobject anyway.
    - pjmlp 5y ago
      COM nowadays runs mostly out of process unless you like crashing the whole application, hence the reference to nano-COM for in-proc APIs that are basically OO ABI. That is why any modern Windows has plenty of COM Surrougate processes running at any given time. As for D-BUS, I stand corrected, I though it had such optimization in place, just as other mechanisms offer.
      - marwis 5y ago
        There's a ton of new in-proc COM usage through WinRT.
        pjmlp 5y ago
        You mean the market failure that no one wants to use any more, even those of us that were early adopters? I am betting in 2 to 3 years we will have yet another reboot from WinUI and WinAppSDK. How things are, I wouldn't be surprised with Blazor with WebWidget2 as the new cool desktop UI.
  - badsectoracula 5y ago
    DBus is an IPC protocol, it is the first thing the specification[0] mentions, there isn't any way where it would make sense for it to be used in-process nor the spec provides for such functionality. Some higher level library could potentially provide an API for exposing and consuming (object) interfaces that can be accessed either in-process or out-of-process, though only the latter would really be using DBus and the former would bypass it (and both would be only really usable only by users of that library, not anything using DBus). DCOP is/was also an IPC protocol, though much simpler than DBus as it was essentially about passing arbitrary data between processes with some IDs attached (the higher level API did pretend that they were objects and method calls but the -still public- lower level API worked in terms of string identifiers and data streams), which makes it unsuitable for a cross-language ABI. KPart however (which is still being developed and part of KDE) is sort of a relative idea to COM in that it is really something similar (in concept) to ActiveX, so it could handle some uses (though it lacks the genericness of COM), except it being C++ based also makes it impractical for a cross-language ABI - which is the entire reason COM was brought up (and why IPC approaches like DBus and DCOP aren't relevant to what was discussed). [0] https://dbus.freedesktop.org/doc/dbus-specification.html https://dbus.freedesktop.org/doc/dbus-specification.html
    - pjmlp 5y ago
      2h30m before of your comment, I already acknowledged my mistake, you could have saved yourself some typing.
      - badsectoracula 5y ago
        Oops, it was in another reply and i didn't notice it.

flohofwoe 5y ago

> Windows sidestepped it with COM Erm, isn't the whole point of COM that it is also just a "C glue interface"? Not how one would typically design C APIs, but COM APIs are C APIs nonetheless.

marwis 5y ago
But it's higher level. It lets you expose interfaces and defines memory management and threading vs using raw C functions where you have to manually encode all of that for every other language.