[rbanffy]

> a way to do powerful automation without hiring a bunch of PhDs.

I remember writing Windows software with DCOM was difficult, but it was more on the painfulness side than a difficult intellectual endeavor. Sure you didn't need PhDs to automate things.

> So, yes, someone did ask for it - the IT industry.

The part of it stuck in Windows, that is. Vendor lock-in is a powerful thing.

[bluejekyll]

Yeah, DCOM was a task of fillout the correct fields with the correct values, and try again until you get it right. Anyone with passing C++ knowledge could do it through shear brute force.

It's one of the things which made me never want to program on Windows again.

[kazinator]

I ported a bunch of COM to Linux in the late 1990's. Not DCOM with the full RPC, but just in-process COM. I had .so shared libs with DllMain and DllCanUnload now in them, I had CoCreateClass, I had a significant part of the registry API implemented in terms of a text file store (HKEY_LOCAL_USER being in the home directory, HKEY_LOCAL_MACHINE somewhere in /etc, ...) and such. IUnknown, QueryInterface, AddRef, Release, ...

[MichaelMoser123]

Netscape did that with XPCOM [1] they once thought that this is a good idea - i guess for versioning of interfaces; nowadays firefox has moved on from this.

[1] https://en.wikipedia.org/wiki/XPCOM

[Quiark]

Haha, funny enough our company did this as well - we had lots of legacy C++ code using COM and wanted to port to Linux. It was not that hard after all.

[snaky]

That's nice, but having CORBA implementations - why?

[kazinator]

To port some code as-is.