Programming Windows: COM (Premium)

Dynamic Data Exchange (DDE) and the first version of its successor, Object Linking and Embedding (OLE), were implemented in early versions of Windows to enable cross-application communication and data sharing, bringing to life one of the biggest advantages of its Windows GUI. But because these technologies were based on the Windows messaging subsystem, which relied on the platform’s shaky cooperative multitasking capabilities, they were unreliable and hard for developers to use. So Microsoft went back to the drawing board to come up with something more sophisticated. Something that could serve as the foundation of more than just compound documents.

And this time, Microsoft hit one out of the park.

The result was the Component Object Model (COM), and it wasn’t just more sophisticated, it was a new platform in its own right. Initially—and secretively—COM served as the foundation for OLE 2.0, which replaced the message-based architecture of OLE 1.0 with a component-based architecture and added numerous additional capabilities related to compound documents. But COM wasn’t just built for compound documents.

Instead, Microsoft created a full-featured, object-oriented software architecture that put the firm at the forefront of a new era in software development. One that was based on components and binary-level reuse rather than classes of software code and programming language-based reuse.

Yes, this gets a bit dense, sorry. Let’s step back for a moment.

You may recall from Programming Windows: Object-Oriented Programming that one of the key aims of OOP is code reuse, so that developers didn’t need to keep recreating the same software code—scaffolding for a skeleton application, perhaps—each time they started a new project. Languages like C++ and developer frameworks like MFC provided code reuse. And MFC, in particular, allowed developers to reuse code that was written by others (in this case, at Microsoft) to create sophisticated scaffolding for complex application types.

But as the 1990s unfolded and developer excitement about OOP became more measured in the face of this paradigm’s top-heavy nature, Microsoft and other platform providers began investigating a better, more efficient form of OOP involving components and interfaces. In this paradigm, reuse occurs at the binary level, and not at the programming language/source code level. So there was no need for a developer to see or in any way access the source code that was used to create a software component. Instead, they could access the capabilities of a component using its public-facing interfaces. The component itself was like a black box.

This was a critical design decision. In cherry-picking from the best OOP, Microsoft was able to create a more lightweight platform that side-stepped the oppressive parts of OOP, like polymorphism and the versioning issues that often accompanied implementation inheritance (which relies on source code access to a base class). But it also created something more elegant: In a component-based system like COM, it was possible for software code to probe a component, discover what interfaces were available, and then act accordingly, all without knowing how that component was implemented internally.

There are other, highly technical advantages to this system. For example, the original design of Windows included support for software library files called DLLs (Dynamic Link Libraries) that contains functionality that applications could access at runtime. This design was more efficient for the early, resource-constrained PCs that ran early Windows versions. But for purposes of this discussion, the important bit is that DLLs ran in-process with the applications that used their functionality. What COM did was create a system in which components could run out-of-process, separate from the applications that utilized their functionality. They could also be on different machines, whereas DLLs could only be accessed on the same machine.

(Fun aside. Versioning issues with DLLs lead to what’s called DLL Hell, and Microsoft sought to solve this problem as much as possible with COM and its successors.)

Also, COM wasn’t language or platform dependent. Because components were black boxes, it didn’t matter what language or environment was used to create them. And it likewise didn’t matter what language or environment a developer used when they created applications that accessed those components. The trick being that programming language implementations had to be adapted to be COM-compatible and to provide COM functionality. Microsoft naturally did this for its top-tier environments like Visual Basic and Visual C++. Third-party environments quickly followed.

So, COM was a binary standard and thus was language independent. It allowed developers to call methods—functions—exposed publicly by interfaces in software components which could exist on the same machine, on a different machine on the same network, or, over time, anywhere in the world. And it provided basic versioning capabilities by making the methods in interfaces externally immutable; the internal implementation could change, and the components’ makers could always add new functionality through new methods and interfaces. COM solved a lot of problems.

The ability to access functionality in components on other machines meant that COM could be made available on other platforms. Microsoft’s early COM documentation suggests that this was always the plan, and it specifically calls out non-Windows platforms like Mac OS and Unix. (This was pre-Linux.) And there were some minor efforts in that regard, though COM on non-Windows platforms was always a small subset of the full functionality.

About that.

As I’ve noted so many times in this series, Microsoft has often in its history taken decisive steps to respond to exterior forces and events. In this case, yes, COM was clearly inspired by other industry efforts around components and component object models to simplify and de-stratify OOP. But COM is not a Microsoft version of something else. Instead, Microsoft created COM in tandem with a separate initiative called the Common Object Request Broker Architecture (CORBA), which would become a standard for binary-level interprocess communications between software components written in different languages and running on different computers, each of which could have been running different software platforms.

I know what you’re thinking. But if that sounds familiar, it’s because CORBA, which was originally released in 1991, two years ahead of COM, evolved after the fact to become more like COM, but just not from Microsoft and not as dependent on Windows. CORBA as originally envisioned did not serve as a high-level blueprint for the features that Microsoft would bring to COM and then add in the coming years, including such things as distributed components, transactions, and language mapping. These two initiatives arrived and evolved side-by-side, for the most part.

And COM was quite successful. Microsoft subsequently used it as the basis for OLE custom controls, which replaced Visual Basic Extensions (VBXs) as Windows transitioned to the 32-bit world. A more lightweight version of the technology aimed at the web and called ActiveX controls was introduced in 1996. And COM itself was evolved into DCOM (Distributed COM) and then COM+, adding much-needed features like a transaction server and message queuing along the way. By the time the 1990s ended, it seemed that COM and component-based software had taken over the software development world.

There was just one problem.

Though Microsoft had secured its dominance of the personal computing industry by the mid-1990s, it was so focused on bringing Windows 95 to market that it failed to notice new threats emerging from unexpected quarters: The Internet, Netscape, Java, and JavaScript.

Now that is a big story.