Programming Windows: Clipboard and DDE (Premium)

Graphical user interfaces (GUIs) were originally derided by the tech elite, who referred to users of these environments as WIMPs, a reference to the term “windows, icons, menus, pointer” that was then considered synonymous with GUI. The theory was that one needed to master arcane command lines to truly understood how computers worked.

That view was always wrong. And it betrayed a curious lack of insight from a group of self-described experts that should have known better: GUIs didn’t just hide the complexity of the underlying computer systems while making more approachable to a wider audience. They also provided advanced system-wide functionality that abstracted hardware and standardized user interface elements, making it easier for developers to create consistent applications more easily.

Key among this system-level functionality was the notion of cross-application communication and data sharing.

Consider, briefly, the MS-DOS world, where a WordPerfect user might want to insert some written text into a VisiCalc spreadsheet. In this environment, it was essentially impossible to run both applications simultaneously, and task-switching between the two was tedious and time-consuming. Worse, the developers of one or both applications would need to have created some way to export (from WordPerfect) or import (into VisiCalc) the data; that solution would have to be hand-tailored for the other application, too; if the user wanted to use a different word processor or spreadsheet, the solution would have to support that product explicitly as well. (If formatting wasn’t an issue, the user would have to figure out a way to export and then import the data in a plain text format.)

Application developers worked around this limitation in interesting ways. Lotus 1-2-3 is gone forever, but I assume most readers understand that it was the most popular spreadsheet application in the 1980s and early 1990s. What many probably don’t remember, however, is that the product’s name isn’t just about numbers, it’s a reference to the fact that this product combined three previously separate applications—a spreadsheet, a database, and a graphical chart maker—into one. It was a very successful attempt at bypassing the problem noted above, since you could move data between these three integrated modules easily. (At a technical level because it was all implemented as a single MS-DOS application.)

But as an MS-DOS application, Lotus 1-2-3 was as confined by the limitations of the platform as any other application. Its charting capability, for example, required Lotus to manually support individual graphics cards with internally-created drivers, so the list of these drivers—and the number of install disks they required—increased over time as the PC market evolved and exploded in size. (WordPerfect had an even worse problem with printer drivers, which it had to likewise manually create to bridge the gap between its application and the exploding market for printers of all kinds.)

Among their many other advantages, GUIs solve this problem. Windows, for example, has always provided system-level graphics card and printer support, abstracting the underlying hardware for developers, who were then free to focus on their applications’ inherent functionality. But Windows, like other GUIs, also eliminated the need for users to choose integrated solutions like Lotus 1-2-3 to achieve cross-application compatibility. Thanks to platform-level cross-application communication and data sharing capabilities, it suddenly became possible for any application to communicate, and share data, with any other application.

Windows wasn’t the first GUI, of course. And it wasn’t the first to implement this kind of functionality. But based as it was on the Mac—literally to the point where internal Mac features, including their errors, were outright copied into the first version of Windows—Windows supported the same basic cross-application communication and data sharing capabilities as its inspiration. And this included the notion of using commands like copy, cut, and paste to copy or move data between applications using a system-wide clipboard.

We take this functionality for granted today. But imagine how freeing it was to run one application, select some text or other data, copy it to the clipboard, task-switch to a second application, and then paste it into a document there. It was like magic. It was something that was (almost) literally impossible to do with most MS-DOS applications.

As an aside, the Mac implementation of the clipboard was interesting because Apple provided a Clipboard window that the user could optionally open at any time to display the contents of the clipboard. You would open this window by selecting Edit in the system-wide Mac menu and then “Show Clipboard.”

“The Clipboard holds whatever is cut or copied from a document,” the original version of Inside Macintosh, Apple’s developer documentation, read. “Its contents stay intact when the user changes documents, opens a desk accessory, or leaves the application. An application can show the contents of the Clipboard in a window … The Clipboard window looks like a document window, with a close box but usually without scroll bars or a size box. The user can see its contents but cannot edit them … Every time the user performs a Cut or Copy on the current selection, a copy of the selection replaces the previous contents of the Clipboard. The previous contents are kept around in case the user chooses Undo.”

It’s not clear from Inside Macintosh, but I suspect that the Clipboard window literally existed to assure developers and Mac users that what they had copied would indeed persist in memory as they closed the first application and then opened a second. It is somewhat humorous to realize that this window continued forward well into the next decade, too. In a 1995 entry to the Inside Macintosh series called Macintosh Human Interface Guidelines, you can see this functionality still working as before. Apple’s description of the clipboard in 1995 closely mirrored its original decade-ago explanation too.

So, Windows also supported a clipboard, which Microsoft also formally capitalized as Clipboard. It worked identically to the clipboard functionality on the Mac, but without the window. (And without the system-level menu, too.) And because even the first version of Windows was technically superior in many ways to the Mac, you could run applications side-by-side and switch between them using cooperative multitasking. (With the Mac, you had to close an application before you could run another application.) You could even run two or more instances of the same application—RAM and resources permitting—side-by-side.

You may recall that Windows was architected such that the system would send messages to applications so that they could respond to events. As such, copy, cut, and paste events were handled using WM_COPY, WM_CUT, and WM_PASTE messages (where WM stands for “Windows message”) that could be handled according to the developer’s wishes and dependent on the capabilities of the control that was receiving these events. (For example, a text edit box could receive only text-based data in CF_TEXT—where CF stands for “Clipboard format”—format.)

Using a clipboard had/has its limitations, of course. Key among them is that there was no connection between the copied data (from the original application) and the pasted data (from the second, or destination, application). If you copied data, pasted it, and then changed the original copy of the data in the first application, the pasted version in the second application didn’t change. They were separate and isolated from each other. Put simply, the Mac and Windows clipboards both supported what’s called static data sharing.

But early versions of Windows, starting with Windows 2.0 in this case, exceeded the Mac, again, by also supporting supported basic dynamic data sharing, courtesy of a Microsoft-developed protocol called Dynamic Data Exchange (DDE).

(Fun aside: On the Mac, this functionality was eventually added in System 7 via a system service called the Edition Manager.)

“Using DDE, a spreadsheet would notify a graphing program each time a cell’s content changes so the associated graph is kept current,” a June 1987 Byte Magazine review of Windows SDK 1.03 explains. “Similarly, the graphing program would notify the word processor each time the graph changes. In this way, changing a spreadsheet would automatically update the graph in a word-processing report. The DDE protocol is not described in the Windows [SDK] manuals, but the definition of the standard is available from Microsoft.”

So, good luck with that, in other words.

What Byte was describing there was more theory than reality for all Windows applications, save Microsoft Excel, until Microsoft shipped Windows 3.0 in 1990. Indeed, reading through the documentation that accompanied the exact version of the Windows SDK that Byte reviewed above—and there is a ton of it—I see no references at all to Dynamic Data Exchange or DDE, confirming Byte’s review. Instead, the Clipboard is only Windows data exchange technology that’s documented.

I haven’t been able to get my hands on the DDE documentation to which Byte alludes. But it was originally implemented by Microsoft in Excel 2.0 for Windows, which was released in 1987 and was the original version for that platform. (Excel 1.0 debuted on the Mac in 1985.)

This was, perhaps, an early example of Microsoft accessing secret or undocumented APIs for its own use before making them available to third parties. But it’s equally likely that Microsoft wasn’t being nefarious. Because once DDE was publicly documented, it was immediately obvious that it was even more poorly designed than the original Windows SDK. Even the Microsoft Systems Journal, an official Microsoft publication, referred to it as “the protocol from hell.”

No matter. DDE would soon be replaced by a more sophisticated—if equally complex—technology called Object Linking and Embedding, or OLE. We’ll examine that next.