4 ms·
The more time passes, the more I feel like dynamic linking of anything but plain C interfaces is just a bad idea.
by wheybags 3y ago
The more time passes, the more I feel like dynamic linking of anything but plain C interfaces is just a bad idea.
- criddell 3y agoWould you consider using runtime things like Microsoft’s Component Object Model (COM) to be a form of dynamic linking?
- rezonant 3y agoThe real question is probably "Is COM a bad idea?" And I don't think it is. But COM itself was such a pain to deal with. Notably all of my time with it was spent from within .NET so maybe it was less painful in C++-- but .NET was at least partially designed to work well with COM. Insert crying emoji. (Of course I think Microsoft intended us to stop using COM and instead use SOAP, but that didn't happen)
- alternative_a 3y agoSOAP is an object access protocol. COM is an component object model. How is SOAP providing a component model?
- flohofwoe 3y agoThe only really important and surviving part of COM isn't the "component model idea", but that COM enables versioned interfaces and dynamic linking with a stable ABI for high level languages that usually don't have a stable ABI (like C++) by defining a standard of how high level language concepts can be tunneled through a regular C API.
- pjmlp 3y agoWhich is even overlooked is how similar ideas have been adopted in Apple and Google platforms (XPC, IO/Driver Kit, AIDL/Binder, FIDL/zircon), less so in GNU/Linux as not all distributions rely on D-BUS for similar ideas.
- pjmlp 3y agoSince Vista that COM is the main delivery mechanism for new Windows APIs.
- pjc50 3y agoCOM (a) requires dynamic linking underneath and (b) uses C interfaces underneath, or at least used to.
- pjmlp 3y agoOnly In-Proc COM requires dynamic linking, COM servers rely on processes. DCOM, nowadays out of fashion also uses processes, and in case of exposing In-Proc COM to the network, a wrapper server process is required.
- deleted 3y ago[deleted]