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

Gain unlimited access to Premium articles.

With technology shaping our everyday lives, how could we not dig deeper?

Thurrott Premium delivers an honest and thorough perspective about the technologies we use and rely on everyday. Discover deeper content as a Premium member.

Tagged with

Share post

Please check our Community Guidelines before commenting

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

Thurrott © 2024 Thurrott LLC