Not only, there is also XPC and IO/DriverKit on Apple, Android IPC, D-BUS, FIDL on Fucshia,....

Also C ABI also does not exist, people keep mistaking the ABI of their favourite C compiler with the OS ABI, which only overlap if the OS was written in C to start with.

For example on mainframes and micros, naturally not written in C, it is either a bytecode based ABI like TIMI on IBM i, or language environments like on z/OS, ClearPath MCP, OS 2200 and so forth.

And as a reminder, from a famous WG14 and WG21 member, and former Rust contributor,

"To Save C, We Must Save ABI"

https://thephd.dev/to-save-c-we-must-save-abi-fixing-c-funct...

And Delphi came along and used the same layout, so an interfaced Delphi object has beautiful COM interop.

> and a very specific vtable layout for COM objects

Fun fact: Microsoft developed COM based on how Zortech C++ virtual functions worked. (It predated Microsoft C++ by years.)

And COM enforces lifecycle rules, transparent remoting, uniform activation (constructors basically), security primitives, marshalling, transparent async calls (yes, you can call any method asynchronously), and a ton of other things. It's actually very good and it's a shame most don't know about it and most of the rest sneer at it.

COM designers were inspired by C++ but their goals were different. They were designing a language-neutral binary standard (aka ABI) and hence took C++'s approach and tweaked it for their specification.

Here is an earlier comment of mine with some details - https://news.ycombinator.com/item?id=49142987

Given OOP, the only ABI for an object is a vtable and that is left unspecified (for good reason) by the C++ standard.

COM said, "objects are cool and modules are cool so we need an ABI for objects" and specified a vtable. It isn't the only programming model which continued from the same observation: Python did too with its absolutely abysmal leaky PyObject ABI