Object Linking and Embedding
Object Linking & Embedding is a proprietary technology developed by Microsoft that allows embedding and linking to documents and other objects. For developers, it brought OLE Control Extension, a way to develop and use custom user interface elements. On a technical level, an OLE object is any object that implements the
IOleObject interface, possibly along with a wide range of other interfaces, depending on the object's needs.Overview
OLE allows an editing application to export part of a document to another editing application and then import it with additional content. For example, a desktop publishing system might send some text to a word processor or a picture to a bitmap editor using OLE. The main benefit of OLE is to add different kinds of data to a document from different applications, like a text editor and an image editor. This creates a Compound File Binary Format document and a master file to which the document makes reference. Changes to data in the master file immediately affect the document that references it. This is called "linking".OLE is also used for transferring data between different applications using drag and drop and clipboard operations.
History
OLE 1.0
OLE 1.0, released in 1990, was an evolution of the original Dynamic Data Exchange concept that Microsoft developed for earlier versions of Windows. While DDE was limited to transferring limited amounts of data between two running applications, OLE was capable of maintaining active links between two documents or even embedding one type of document within another.OLE servers and clients communicate with system libraries using virtual function tables, or VTBLs. The VTBL consists of a structure of function pointers that the system library can use to communicate with the server or client. The server and client libraries, OLESVR.DLL and OLECLI.DLL, were originally designed to communicate between themselves using the WM_DDE_EXECUTE message.
OLE 1.0 later evolved to become an architecture for software components known as the Component Object Model, and later DCOM.
When an OLE object is placed on the clipboard or embedded in a document, both a visual representation in native Windows formats is stored, as well as the underlying data in its own format. This allows applications to display the object without loading the application used to create the object, while also allowing the object to be edited, if the appropriate application is installed.
The Object Packager, a component of OLE, shipping from Windows 3.1 up to Windows XP allows a non-OLE object to be "packaged" so it can be embedded into an OLE client.
OLE 2.0
OLE 2.0 was the next evolution of OLE, sharing many of the same goals as version 1.0, but was re-implemented on top of the COM instead of using VTBLs directly. New features were OLE automation, drag-and-drop, in-place activation and structured storage. Monikers evolved from OLE 1 object names, and provided a hierarchical object and resource naming system similar to URLs or URIs, which were independently invented. Windows now has merged the two technologies supporting a URL Moniker type, and a Moniker URL scheme.OLE custom controls
OLE custom controls were introduced in 1994 as a replacement for the now deprecated Visual Basic Extension controls. Instead of upgrading these, the new architecture was based on OLE. In particular, any container that supported OLE 2.0 could already embed OLE custom controls, although these controls cannot react to events unless the container supports this. OLE custom controls are usually shipped in the form of a dynamic link library with the.ocx extension. In 1996 all interfaces for controls were made optional to keep the file size of controls down, so they would download faster; these were then called ActiveX Controls.Technical details
OLE objects and containers are implemented on top of the Component Object Model; they are objects that can implement interfaces to export their functionality. Only the IOleObject interface is compulsory, but other interfaces may also need to be implemented if the functionality exported by those interfaces is required.To ease understanding of what follows, some terminology has to be explained. The view status of an object is whether the object is transparent, opaque, or opaque with a solid background, and whether it supports drawing with a specified aspect. The site of an object is an object representing the location of the object in its container. A container supports a site object for every object contained.
What follows is a list of interfaces, grouped by the object that usually needs to implement them. Interfaces usually implemented by the OLE object are usually called on by the OLE container, and vice versa. Note that in the following list indentation indicates interface inheritance. All non-indented interfaces derive from IUnknown.
OLE object
;DataObject;ObjectWithSite
;OleCache
;OleCacheControl
;OleDocument
;OleDocumentView
;OleWindow
;OleLink
;OleObject
;ViewObject
OLE container
;IAdviseSink;IOleClientSite
;IOleDocumentSite
;IOleContainer
;IOleWindow
;IOleUILinkContainer
;IOleUndoManager
Other
;IDataAdviseHolder;IOleAdviseHolder
;IDropSource
;IDropTarget
;IOleCommandTarget
;IOleUndoUnit
;IOleWindow
Competition
technology tried to compete with OLE. Some of Microsoft's competitors considered OpenDoc to be more robust and easier to use; however, OpenDoc does have some known problems. OpenDoc allowed users to view and edit information across applications, directly in competition with Microsoft's proprietary OLE standard. In 1993 some Microsoft competitors established a consortium called the Component Integration Laboratories to develop OpenDoc as an open standard for cross-platform linking and embedding.Microsoft required OLE compatibility as a condition of Microsoft's certification of an application's compatibility with Windows 95. Microsoft initially announced that applications using OpenDoc would be deemed compatible with OLE, and would receive certification for Windows 95. Microsoft later reversed the decision and said that applications using OpenDoc might not receive certification at all. Microsoft withheld specifications and debugged versions of OLE until after it had released its competing applications.