COM is (IMHO) one of the great underrated technologies. Registering all the classes, interfaces etc. in the registry - not so much. But IDL's, versioned interfaces etc. etc. are all reinvented every five years or so. And it's fast as hell.
I like COM as concept, what is awful beyond explanation is why it being so central to WinDev, it keeps having pre-historic support on Visual Studio.
IDL files still lack code completion and syntax highlighting, 25 years later, and they cannot settle on any kind of framework that makes it easier to use.
From .NET side there are still gotchas to this day, and from C++ side it seems we cannot just have nice tools.
Now as a concept it is quite cool, execution could be so much better.
Oddly enough if you used COM in VB6 it had autocomplete and tight integration with it. Building the objects in c++ was a nightmare, but it did work for great reusable components.
From Microsoft history of programming languages, VB 6 was definitly the best COM experience so far, for a little while .NET Native and C++/CX got it back, but they are now deprecated.
Registering all the classes, interfaces etc. in the registry - not so much
The core idea behind COM is to allow programs expose objects that implement various interfaces in a way that would allow these objects be both implemented and used by different languages and applications without each one knowing about the other aside from the common ABI that is COM.
So with that in mind, how would an image viewer application know about the implementations of the image fileformat-agnostic IImageReader interface (that could also be used by, e.g. an offline 3D renderer, a presentation editor, a game engine texture importer, etc) if these implementations weren't registered somewhere so that it can load PNG, Jpeg, GIF, suckless' image format or basically any of the -quite limited- list of file formats shown in Wikipedia[0] without having to explicitly implement support for it and perhaps even allow for filters and generators? Similarly for IImageWriter or anything else that could be reused (not even necessarily from the same language).
I think the issue wasn't the registration (otherwise why bother with COM and not use/define some application-specific plugin API) but that it always felt kludgy to do it.
Though FWIW Microsoft added "registration-free" COM in XP SP2 but AFAIK all that it does is to look for some manifest file for the same data that would be in the registry. This feels mainly like a workaround for applications that use specific COM objects they cannot use in any other way, these COM objects aren't being provided by the OS itself and they cannot use an installer, so they're essentially like bundling them like any other DLLs with the EXE. Weird that it took them so long considering that it'd be classic VB apps that would benefit the most from this approach.
I think the issue wasn't the registration but that it always felt kludgy to do it.
That, exactly. The registry was almost human readable until it became completely overrun with COM registrations. It needed a less kludgy way of doing it.
I worked on a project around the early 2000s that had a mixture of DCOM and Corba in it. Relatively speaking, DCOM was a dream. It reminded me a lot of the original RPC generated stubs on Solaris.
Corba reminded me that some people should never write network code: sometimes the interface would start, sometimes it wouldn't (this system was a consumer of something the Corba system was generating). The Corba guys had an elaborate startup procedure that resembled praying to the gods of Java that it would
work this time, Bullwinkle pulling a rabbit out of a hat style. The DCOM stuff just worked / was able to reconnect when something failed.
Corba was possibly the worst tech I have ever had the displeasure of using and while I don't remember DCOM especially fondly, it wasn't terrible.
Corba was a spec that had a number of implementations. Some Orbs were great while others were crap. Unlike DCOM however it was an open standard. For some reason at some point it was declared highly uncool. And now is being reinvented hard yet again by the hipsters of today with grpc etc. Looks like every generation of programmers has the urge to reinvent RPC.
But IDL's, versioned interfaces etc. etc. are all reinvented every five years or so.
And it's happening again right now, albeit for a better reason than normal. The WebAssembly Component Model (currently in development) draws heavily on lessons from all these generations of reinvention, and especially from COM itself.
Wasn't that awful ;) In some sense it's maybe a precursor to gRPC. DCOM let us (EDIT: us being some old project/team I worked on) take a component and make it distributed with very little work (COM -> DCOM) almost seamlessly.
Agree. Also, while I was working with MSVC6, I made a couple of ActiveX libraries and when I saw my 3D controls actually work EVERYWHERE from C programs to word documents and HTML pages, I was amazed. The whole "custom control" ecosystem was very intriguing at that time. I remember Borlnd competing with their "components", too :) Still love the portability of COM.
It's been many years for me, but I remember it having nice interop with .NET as well. Back then I worked with several APIs that were just COM objects brought into .NET.
Comments
COM is (IMHO) one of the great underrated technologies. Registering all the classes, interfaces etc. in the registry - not so much. But IDL's, versioned interfaces etc. etc. are all reinvented every five years or so. And it's fast as hell.
DCOM was awful.
I like COM as concept, what is awful beyond explanation is why it being so central to WinDev, it keeps having pre-historic support on Visual Studio.
IDL files still lack code completion and syntax highlighting, 25 years later, and they cannot settle on any kind of framework that makes it easier to use.
From .NET side there are still gotchas to this day, and from C++ side it seems we cannot just have nice tools.
Now as a concept it is quite cool, execution could be so much better.
Oddly enough if you used COM in VB6 it had autocomplete and tight integration with it. Building the objects in c++ was a nightmare, but it did work for great reusable components.
From Microsoft history of programming languages, VB 6 was definitly the best COM experience so far, for a little while .NET Native and C++/CX got it back, but they are now deprecated.
I’d guess very little people are touching COM directly and more commonly using whatever various abstractions MS built on top.
The only abstractiosn that exist are .NET libraries, when they don't exist, then COM is all that there is, nothing else.
The core idea behind COM is to allow programs expose objects that implement various interfaces in a way that would allow these objects be both implemented and used by different languages and applications without each one knowing about the other aside from the common ABI that is COM.
So with that in mind, how would an image viewer application know about the implementations of the image fileformat-agnostic IImageReader interface (that could also be used by, e.g. an offline 3D renderer, a presentation editor, a game engine texture importer, etc) if these implementations weren't registered somewhere so that it can load PNG, Jpeg, GIF, suckless' image format or basically any of the -quite limited- list of file formats shown in Wikipedia[0] without having to explicitly implement support for it and perhaps even allow for filters and generators? Similarly for IImageWriter or anything else that could be reused (not even necessarily from the same language).
I think the issue wasn't the registration (otherwise why bother with COM and not use/define some application-specific plugin API) but that it always felt kludgy to do it.
Though FWIW Microsoft added "registration-free" COM in XP SP2 but AFAIK all that it does is to look for some manifest file for the same data that would be in the registry. This feels mainly like a workaround for applications that use specific COM objects they cannot use in any other way, these COM objects aren't being provided by the OS itself and they cannot use an installer, so they're essentially like bundling them like any other DLLs with the EXE. Weird that it took them so long considering that it'd be classic VB apps that would benefit the most from this approach.
[0] https://en.wikipedia.org/wiki/Image_file_format
That, exactly. The registry was almost human readable until it became completely overrun with COM registrations. It needed a less kludgy way of doing it.
I worked on a project around the early 2000s that had a mixture of DCOM and Corba in it. Relatively speaking, DCOM was a dream. It reminded me a lot of the original RPC generated stubs on Solaris.
Corba reminded me that some people should never write network code: sometimes the interface would start, sometimes it wouldn't (this system was a consumer of something the Corba system was generating). The Corba guys had an elaborate startup procedure that resembled praying to the gods of Java that it would work this time, Bullwinkle pulling a rabbit out of a hat style. The DCOM stuff just worked / was able to reconnect when something failed.
Corba was possibly the worst tech I have ever had the displeasure of using and while I don't remember DCOM especially fondly, it wasn't terrible.
Corba was a spec that had a number of implementations. Some Orbs were great while others were crap. Unlike DCOM however it was an open standard. For some reason at some point it was declared highly uncool. And now is being reinvented hard yet again by the hipsters of today with grpc etc. Looks like every generation of programmers has the urge to reinvent RPC.
I wish I could remember which implementation of Corba it was, an Irish company I think...hello Google it was Iona and "Orbix". Dreadful thing.
And it's happening again right now, albeit for a better reason than normal. The WebAssembly Component Model (currently in development) draws heavily on lessons from all these generations of reinvention, and especially from COM itself.
Wasn't that awful ;) In some sense it's maybe a precursor to gRPC. DCOM let us (EDIT: us being some old project/team I worked on) take a component and make it distributed with very little work (COM -> DCOM) almost seamlessly.
Interesting, I was obviously doing something very wrong (back in the day).
Agree. Also, while I was working with MSVC6, I made a couple of ActiveX libraries and when I saw my 3D controls actually work EVERYWHERE from C programs to word documents and HTML pages, I was amazed. The whole "custom control" ecosystem was very intriguing at that time. I remember Borlnd competing with their "components", too :) Still love the portability of COM.
It's been many years for me, but I remember it having nice interop with .NET as well. Back then I worked with several APIs that were just COM objects brought into .NET.