Swift Achieved Dynamic Linking Where Rust Couldn't

Re:Swift Achieved Dynamic Linking Where Rust Couldn't by zdimension on Monday January 30, 2023 @02:45AM (#34576963)

The result of Microsoft developers in the 90s drunkenly making up an object model on top of C with the goal of it being cross-language and cross-platform (in theory). The idea being that you can define an interface and implement it in any language and consume it in any language. A good idea in theory. In practice, DLL hell often made the experience unpleasant. A big part of Windows's APIs are COM-based. For historical reasons it's also used at the core of a few macOS system components, hence the grandparent comment

[ Parent | on HN ]

Re:Swift Achieved Dynamic Linking Where Rust Couldn't by pjmlp on Monday January 30, 2023 @03:00AM (#34577048)

COM is the main way Windows APIs are exposed since Windows Vista, as the .NET ideas for Longhorn were rebooted as COM.

While plain old bare bones Win32 APIs are still coming up in every release, they aren't the main ones.

Also COM as concept wasn't something designed by Microsoft, it rather build up on the ideas of what Sun, IBM and co were doing with distributed objects protocols.

It is no coincidence that COM IDL language is based on DCE RPC.

[ Parent | on HN ]

Re:Swift Achieved Dynamic Linking Where Rust Couldn't by int_19h on Tuesday January 31, 2023 @03:17AM (#34592638)

At the most basic level (IUnknown), COM doesn't care about DLL loading at all, so DLL hell is not in the picture. Many Windows libraries are actually like that - you call a single global exported function that gives you an "entrypoint" COM object, and from there you call methods on that and/or on other things that it returns. This is the extent of COM that you would usually see in cross-platform code (e.g. Mozilla's XPCOM, or COM Interop in Mono when running on Linux or Mac).

Beyond that, if we're talking about coclasses etc, one of the things about Win32 COM was kinda sorta solving DLL hell by using UUIDs as primary identifiers for those classes - CLSIDs - and mapping them to actual files on disk via the registry. Thus, you could have things installed wherever, including DLLs with identical names in different folders. A new version of the class would get the new CLSID, so multiple versions could be installed and correctly resolved at runtime.

Of course, that just made it a registry hell instead, where messing up those (global!) entries would break apps that depended on the affected classes. So Windows XP (IIRC) added the ability to register CLSIDs and map them to DLLs directly in the app manifest, allowing for a fully self-contained solution.

[ Parent | on HN ]