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