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.
Comments
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.