OLE Object Linking And Embedding  

OLE stands for Object Linking and Embedding. OLE 1 was the first step toward implementing one of the most important concepts in data-centric computing: the idea that a document can contain different types of objects. The linking and embedding term suggests the possible locations for objects that are part of a document. They can be embedded within a document, or linked, in which case the document simply contains the name of a file or other reference to the location where the object is stored.

OLE 1 also provided a way for applications to work with these compound documents. Any application could display a document consisting of many different types of objects, and you could double-click on the object in order to edit it using the application associated with the object. Consider the example in Figure 2.7. The document contains a text object and a spreadsheet object. If you opened the document using a word processor, you would see the text and the spreadsheet. The word processor would be able to handle the text directly, but if you wanted to edit the spreadsheet, you would double-click on the spreadsheet object. This would launch the spreadsheet application to edit the object. When you closed the spreadsheet, the object in the document would be updated with any changes you made.

This approach differs in two significant aspects from the application-centric techniques described earlier. First, no conversion takes place. The spreadsheet object remains a spreadsheet, even though it is in some unknown manner being displayed within a word processing application. Because no conversion takes place, no data is lost, and all of the original spreadsheet formatting is preserved. Second, because there is only one spreadsheet object, any changes made to the object from within the word processing application (if such a thing were possible) would affect the actual spreadsheet data. The problem of converting information back from the text document to the spreadsheet does not exist.

OLE 1.0 suffered from one major problem: it was a software technology that was ahead of the available hardware. This was the Windows 2.x and 3.0 era, an age where the 640K base memory limit was still quite real (even 3.0, with its virtual memory, required the lower 640K for many purposes). Attempting to run a large word processing application, such as Microsoft Word, at the same time as a large spreadsheet application, such as Excel, was a slow, frustrating, and often dangerous process. Truly, it was the age of the Unrecoverable Application Error, as compared to the Windows 3.x era, which was the age of the General Protection Fault, as compared to the modern era which is the age of the Exception, or "Your program has performed an illegal operation," which comes in many different flavors.

Despite these limitations, OLE 1.0 was the first real step towards data-centric computing under Windows. And though it did not truly succeed, that's not surprising when you consider for a moment the challenge that implementing a data-centric environment presents.

A data-centric environment requires:

  • A way for an application to display objects that it knows nothing about, since a true data-centric application must allow a document to contain any type of object, including those not even imagined when the application was created.
  • A way for an application to load and save documents containing objects it knows nothing about.
  • A way for an application to provide a visual interface that makes it possible to edit objects it knows nothing about.

And while we're at it, wouldn't it be nice to add:

  • A way for an application to execute commands that manipulate objects it knows nothing about.
  • A way for an application to support drag-and-drop capability on objects it knows nothing about.

Now, even a beginning programmer knows it's hard enough to work with program data when you know what it is. Manipulating data that your application doesn't even recognize is an intimidating, if not incomprehensible idea. But that's exactly what was needed, and the answer to that challenge was called OLE 2.0