It was (is) an ABI, more stable than something available through a C/C++ compiler. It’s been years since I’ve lived in a Windows world, but as I understand it, it’s still very much alive and well. It didn’t fail because it was complicated, although it was, but it continued to evolve and was eventually superseded by .net. I worked with win32 & mfc quite a bit and had to interface with Com/activex a little, usually through wrappers of some kind, but it was always under the covers. I also wouldn’t say that it failed because not enough apps did it. I can’t speak to drivers or system components, but if you were distributing windows apps prior to and early into .net, you dealt with com directly or indirectly.
I remember some things being very tiresome, esp. from a C or C++ view of the world. There weren't any default implementations for most things, as you would find in Java. So for Java you might have an abstract class that got you 95% there, in COM/OLE you needed to do that 95% yourself, and this was before you had lots of public domain things available. Later, we could go on Codeguru or whatever and get a good example.
Many things were designed at the level of Microsoft App 1 (e.g. Word), and then when they needed something different for another app (e.g. Shell) they extended the interface in a different interface, and so on. The only authority for interfaces was Microsoft. Nobody else was really able to come along and make a set of interfaces that would become universal for something new, so you had to wait for Microsoft's design, and then it would be designed to support the way it was implemented in Word, Excel, or Internet Explorer, and they would not release the implementation details, just an interface specification and some hastily-written documentation.
Naming things was hard for Microsoft, so they came up with idiotic names like "IClassFactory" because they couldn't decide if they wanted to call something a Class (Smalltalk-style) or a Factory.
It took forever to learn because the documentation was not oriented around practical things, it was toy examples that didn't even work within the system. As a young programmer, it took me a long time to understand how everything was registered, what the difference between a CoClass and an interface really was, where to get that initial IUnknown pointer, etc., because the books were so focused on vtables and toy examples, etc.
The system was mostly replicated by Netscape/Mozilla for XPCOM, so it had areas where you could apply the same principles on other platforms. It also had superficial similarity to SOM/CORBA so learning those systems (thankfully mostly gone now) was also somewhat easier after learning COM.
There were several categories of applications.
- Those that used COM/OLE fully, as the underlying basis of everything they did, used structured storage, and exposed components and automation to the rest of the world.
- Those that implemented some sort of automatability and things like shell preview.
- Finally, those that used the minimal amount to support drag and drop and the like.
After a while, Microsoft's habit of introducing the next big thing and mostly abandoning it a few years later caused Windows application development to decline. COM has always been around, but many related technologies come and go. .NET blurred the lines between COM and the .NET runtime, and then Microsoft started making substantial overhauls of the Windows runtime without, IMO, getting buy-in. Why write WPF when it's similar to but incompatible with UWP? Why write UWP when Win32 works just fine? I wonder if they're going to introduce yet another? Oh, sure, Windows App SDK. Should we use GDI+ or Direct2D? Which one is going to "win"? Why do any of this when Microsoft themselves is using Electron in VS Code?
