COM is everywhere on Windows, specially since Vista, as the WinDev regained the control they thought Longhorn was going to take away from them.
One of Powershell strengths is the easy access to COM, just like .NET, frameworks.
Linux could do the same with D-Bus, but alas so is the distributions wars, and hate on anything like proprietary OSes, that it only has a minor role on systemd, GNOME and KDE.
Imagine writing a huge complex program that is dependent of communication between smaller existing programs. Either you use the default programs that where shipped with all the different versions of OS'es with different distro's (never going to work, too many different versions of programs and their communication interfaces) or you ship certain fixed versions of all of the small programs that form your bigger program.
In case of the latter: why not just use libraries? It's basically the same thing with an easier API?
Maybe I'm missing something...
I’d guess the trick is that you’re not thinking small enough. GNU coreutils, etc. are not minimal by any means, but compared with even late-90s graphical desktop software they are still fairly compact, and you’re rarely using each and every tool at once. And the smaller the tool and the problem it targets, the more likely it is that the problem is mostly a solved one, so interface churn is less necessary.
I’m not sure every problem area is amenable to this—GUIs and things best expressed as GUIs seem particularly stubborn. (It would be sad if OLE/ActiveX was the best possible solution.) But some are, and few enough people are trying to expand the simplicity frontier for their real-world tasks in recent years that I don’t believe the state of the art of the 1980s is the farthest it can reach, either.
Except at the end of the day, the interface can be as simple as a stream of bytes over a socket. If I want a h264 decoder in my application I could just pipe a stream to a specific program made to decode it. That could be written in Python, in Rust, in C, in Go, etc. whereas dynamic libraries don't give you that freedom as you have to abide by the ABI defined by the host application.
Also there's the old viewpoint of "let's put everything in XML. Everything can read and write XML", and that seems similar to the argument of "everything can be an object that is exposed to other programs". The problem in both cases, objects have requirements for function call names, function arguments, nuanced conventions, as XML has specific tree structures. Interfacing programs must be wise to these conventions and sometimes nuances so it doesn't "just work". Windows is like - programs CAN share objects and interface BUT it needs developer work for program A to work with program B. Unix is like "programs X and Y, whatever they are, work together with no additional work". The magic of unix is that if there are 1000 programs, now there are 1,000,000 combinations that "just work" vs. 1,000,000 developer hours
Unix on the other hand recognizes that it's a lot easier to just say "everything is a text stream, and all programs are responsible for inputting and outputting only fairly clean text streams without extraneous output" . This is extended to "everything is a file", a file also typically made to be read into a clean text stream so it can feed into that whole ecosystem.
