Programming Windows: OLE (Premium)

Most readers probably remember the introduction of the original iPhone, when Steve Jobs famously teased the product as “an iPod, a phone, and an Internet communicator.” But the introduction of Windows 3.0 almost 30 years earlier was even more impressive and immediately impacted a far bigger percentage of the personal computing public. It bundled “a graphical environment, a suite of desktop applications, a DOS program switcher, a Windows multitasking executive, a V86 multitasker, and a virtual memory manager into a single package,” in the words of Byte’s Jon Udell.

OK, that probably sounds really techy. But in that very different era, Windows 3.0 really did consummate “the Windows/DOS marriage,” and it changed the face of computing forever by pushing the mainstream to the GUI. Windows 3.0 was a monumental release, and in a bit of latter-day Apple-like marketing of its own, Microsoft claimed that it shipped with “over 1,000” new features.

Key among those features was a foundational technology that was either ignored or simply misunderstood by most reviewers and users. It was called Object Linking and Embedding, or OLE. And it would set Microsoft on a path towards software componentization that continues to this day.

OLE (pronounced “oh-lay”) was created in response to the issues with Dynamic Data Exchange (DDE), which was one of two core cross-application communication and data sharing technologies in previous Windows versions. (The other being the Windows Clipboard.) Like DDE, OLE allowed developers to create applications that could dynamically share data with other applications—or, conversely, host dynamic data shared by other applications—while maintaining a link between them such that any changes in one instance of the data would impact the other.

(Fun aside: OLE is no longer an acronym and is now just the name of this set of technologies.)

DDE had all kinds of problems. It was poorly—or, from the perspective of most developers, not at all—documented, and Microsoft had rushed it out the door as a proof of concept of sorts that was really only used by a few of its own Office applications. DDE also didn’t initially work across networks, so that the two applications that were dynamically sharing data had to be on the same machine. (Microsoft briefly tried to fix this issue with a short-lived technology called Network DDE, but it was so flawed that it was quickly abandoned.) And it was horribly complex, even if you did have the documentation.

DDE’s implementation might have been suspect, but the idea was sound. As noted in Programming Windows: Hello, DDE (Premium), DDE could be used to establish a so-called “client-server” relationship between two applications that wished to share data. The source of the data was considered the server and the destination application was considered the client. The two applications would establish a conversation using the DDE protocol, and at the time the conversation was instantiated, it could be configured as a one-time transfer, similar to using the Clipboard, or a persistent exchange. In the latter case, the sharing would be dynamic, and the shared data would be “live”: Any change to the data in the client would be reflected in the server and vice versa.

The original version of OLE was a reimplementation of this capability, and Microsoft finally documented the technology in a way that was accessible to developers. As important, it also expanded on what DDE could do to include the ability to embed chunks of the server application in the client application. This created, in effect, a compound document in which a host (client) application like Microsoft Word could contain not just a Word document but also document objects from other compatible applications. You might, for example, embed part of an Excel worksheet in that Word document. And when you selected it, you could edit it and interact with it as if you were using Excel, right from within Word.

But Microsoft wasn’t done tinkering, and the original implementation of OLE didn’t survive past Windows 3.0. By the time Windows 3.1 arrived in 1992, Microsoft had rearchitected this technology yet again for OLE 2.0. This release was significant for two reasons: It was finally available globally to any application via its inclusion in Windows 3.1, and it came with a lot of new features.

Previously, the OLE 1.0 libraries had to be included with any application that wished to use those features. But with Windows 3.1, OLE 2 was included with the operating environment. And that meant that even pedestrian, built-in Windows applications like Write and Paintbrush could participate in sophisticated object linking and embedding.

As for new features, several stood out.

The biggest, perhaps, was in-place activation, which built on the compound document functionality from OLE 1.0 by providing what’s called visual editing. In essence, it allowed developers to merge the user interface controls of the embedded (source) document when accessed from within the host (destination) document. As always, the canonical example involved Microsoft Excel: When you embedded an Excel worksheet in a Word document and selected it, the Word toolbars would expand to include Excel command buttons. When you selected the Word document outside of the Excel object, the Excel buttons would disappear.

At the time, Microsoft was betting big on compound documents and it saw this functionality as the future of its Office suite, where the individual applications could fade to the background and users would simply work with lots of different types of data in a single place. In use, this was complex and unwieldy for users, and while the capability never truly disappeared, it became much less of a focus over time.

OLE automation extended OLE 2.0’s capabilities to scripting languages, specifically Visual Basic for Applications (VBA), dramatically simplifying and expanding the automation of OLE objects. In tandem to this support, VBA became the common scripting language across the core Microsoft Office applications.

OLE 2.0 also supported drag-and-drop, so that users could drag objects between applications to create and configure OLE links. (Or drag them out to sever those links.) This made it easier for users, who were by then already getting overwhelmed by the myriad of ways in which you could share content between different applications.

And because compound documents and other embedded OLE-based objects were resource-intensive, OLE 2.0 also arrived with an optimized structured storage model that was more efficient and provided better performance; in OLE 1.0, all objects in a compound document loaded into memory every time you opened the document, but in OLE 2.0 this only happened when you needed to edit or otherwise use them.

If there was a downside to OLE 2.0, and there was, it was that it wasn’t initially any easier for developers to master than its predecessors. Where DDE was a mystery, and OLE 1.0 was documented but hard to implement, OLE 2.0 was … well, it was kind of a nightmare. The OLE 2.0 specification was over 330 dense pages long, and the OLE 2.0 API consisted of over 270 functions. As you may recall, the original Windows API, which provided the entirety of developer support for the OS, consisted of just 450 functions or so. The surface area for developers was exploding.

The good news? As an object-based technology, OLE 2.0 lent itself to object-oriented class libraries, like those for Visual C++, and to visual tools like Visual Basic. And those products were indeed quickly updated to fully support OLE 2.0 in simpler and more sophisticated ways than accessing the raw APIs.

But OLE 2.0 also arrived with a secret, something that, at the time, and was certainly not understood to be foundational to the future of both Microsoft and Windows. But it was: OLE 2.0 had been implemented using a new component-based infrastructure called the Component Object Model (COM).

And COM was about to change everything.