Hubbry Logo
Object Linking and EmbeddingObject Linking and EmbeddingMain
Open search
Object Linking and Embedding
Community hub
Object Linking and Embedding
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Object Linking and Embedding
Object Linking and Embedding
Object Linking and Embedding
View on Wikipedia
from Wikipedia

Object Linking and Embedding (OLE) is a proprietary technology developed by Microsoft that allows embedding and linking to documents and other objects. For developers, it brought OLE Control Extension (OCX), 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

[edit]

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.[1] 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" (instead of "embedding").

OLE can also be used to transfer data between different applications using drag and drop or clipboard operations.

History

[edit]

OLE 1.0

[edit]

OLE 1.0, released in 1990, was an evolution of the original Dynamic Data Exchange (DDE) 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 (COM), 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 (such as a bitmap or metafile) 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

[edit]

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 2.0 introduced UUID to label API objects.[2]

OLE custom controls

[edit]

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 (except IUnknown) were made optional to keep the file size of controls down, so they would download faster; these were then called ActiveX Controls.

Technical details

[edit]

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

[edit]
DataObject
When implemented, enables the transfer of data, and notification of data changes. It must be implemented by objects that are to support drag-and-drop, being copied to or pasted from the clipboard, or being linked or embedded in a containing document.
ObjectWithSite
Allows the caller to inform the OLE object of its site. This functionality is also provided by OleObject, but ObjectWithSite can be used, when supported, if OleObject is not used for other matters.
OleCache
Allows visual presentations from a DataObject to be cached. This allows an embedded object to store its visual representation, thus enabling it to be displayed later without needing to start the application that was used to create the object.
Usually the stock implementation is used.
OleCache2
Provides more fine-grained control over caching.
Usually the stock implementation is used.
OleCacheControl
This interface is not called by the container, but internally by the object to allow it to receive notifications of when its DataObject is running, thereby allowing it to subscribe to notifications of data changes of that object and thus allowing it to update the cached presentation properly.
Usually the stock implementation is used.
OleDocument
Allows the OLE object to support multiple views of its data, as well as a few related functions.
OleDocumentView
A document object (an object that implements OleDocument) implements this interface for every view. It allows the caller to set the site of the object, query and set the size of the object and to show and activate it, as well as some related functions.
OleWindow
OleInPlaceActiveObject
Called by the outermost container of an object to interact with it while it's active, e.g. to process accelerator keys in the container's message queue that are meant for the contained object.
OleInPlaceObject
Called by the container to activate or deactivate the object.
IOleInPlaceObjectWindowless
A windowless object is an object that doesn't have its own window but it instead displayed in its container's window. It is used by the container to relay messages received by the container's window that are intended for the contained object. For example, if the mouse is moved over a window, Windows places a mouse move message along with the mouse coordinates in the message queue of the window. If this window contains windowless embedded objects, the message may have to be relayed to such an object if the coordinates of the mouse-pointer are over this object. For similar reasons this interface also provides access to the object's DropTarget interface.
OleLink
Allows the object to support linking, e.g. by allowing the container to set the source of a linked object.
Usually the stock implementation is used.
OleObject
Arguably the most important interface for an OLE object. For example, it allows the container to inform the object of its site, initialize the object from data, to open and close it, to query and set the size of the object, to ask for notifications on the container's AdviseSink and to execute objects defined as "verbs" on the object. These verbs often include "Open" or "Edit", but can also include other verbs. One of the verbs is defined to be the principal verb, and it is executed when the user double-clicks an object.
ViewObject
Allows an object to draw itself directly, without passing a DataObject to the container. For objects that support both DataObject and this interface, the underlying implementation is usually shared.
ViewObject2
Additionally allows the caller to query the size of the object.
ViewObjectEx
Adds support for flicker-free drawing of transparent objects, hit-testing for objects with irregular shapes and setting the size of an object.

OLE container

[edit]
IAdviseSink
Allows the implementer to receive notifications when the object is saved, closed, or renamed, or when its data or visual presentation changes.
IAdviseSink2
Additionally allows the implementer to receive notifications when the link source of the OLE object changes.
IAdviseSinkEx
Additionally allows the implementer to receive notifications when the view status of the OLE object changes.
IOleClientSite
This interface allows the caller to obtain information on the container and location of an object, as well requesting that the object be saved, resized, shown, hidden, et cetera.
IOleDocumentSite
Allows the caller to ask for the object on this site to be activated immediately. If this interface is implemented, IOleClientSite, IOleInPlaceSite and IAdviseSink must be implemented as well.
IOleContainer
This interface allows the caller to enumerate embedded objects in a container, or to find such objects by name. It is primarily useful if the container wishes to support links to embedded objects.
IOleWindow
IOleInPlaceUIWindow
Enables embedded objects to negotiate space for toolbars on the container's window.
IOleInPlaceFrame
Allows the caller to ask the container to insert its menu items in an empty menu that will become the cooperative menu. Also allows the caller to ask the container to show or hide this menu, to show or hide dialog boxes, and to process accelerator keys received by the contained object intended for the container.
IOleInPlaceSite
If a container implements this interface, it allows embedded objects to be activated in place, i.e. without opening in a separate window. It provides access to the container's IOleInPlaceUIWindow.
IOleInPlaceSiteEx
If a container implements this interface, it allows embedded objects to check whether they need to redraw on activation or deactivation. It also allows them to request their UI to activate.
IOleInPlaceSiteWindowless
If a container wishes to support windowless embedded objects, it needs to provide functionality to embedded objects to replace the functionality normally provided by an embedded object's window. For example this interface provides a way to access the container's window's device context, thereby enabling the embedded object to draw in the container's window.
IOleUILinkContainer
Contains the methods that the standard OLE dialog boxes that manage linked objects use to update linked objects in a container, or to query and change their sources. Used by the "Links", "Change source", "Update links" and "Object properties" dialog boxes.
IOleUILinkInfo
Additionally allows the dialog boxes to query when linked objects were last updated, and whether this was done automatically or manually.
IOleUIObjInfo
Contains the methods needed by the "Object properties" dialog box. For example if the user opens the "Object properties" dialog box and asks for the object to be converted to another type, a method on this interface is called.
IOleUndoManager
Provides a centralized undo service to both the container itself and to embedded objects. When an undoable action is performed, an IOleUndoUnit is created and added to the IOleUndoManager

Other

[edit]
IDataAdviseHolder
The methods of IDataObject that pertain to data change notifications can be implemented by calling the methods of this interface.
Usually the stock implementation is used.
IOleAdviseHolder
The methods of IOleObject that pertain to notifications can be implemented by calling the methods of this interface.
Usually the stock implementation is used.
IDropSource
Implemented by objects that can be dragged, i.e. that can be the source of a drag-and-drop operations. When implemented it allows the object to draw drag-and-drop effects, and to specify when the object is dropped, or the drag-and-drop operation is cancelled.
IDropTarget
Implemented by objects that accept dropped objects, i.e. that can be the target of drag-and-drop operations. When implemented it allows the target to specify if a dropped object will be accepted, and what happens to an object after it is dropped.
IOleCommandTarget
Can be implemented by objects (OLE objects, OLE containers, and other objects) that wish to support certain standard commands. It allows callers to query if commands are supported, and to execute commands. Commands that an object might typically wish to implement may include things like "delete", "cut", "copy", "paste", "undo", "find", "print", "save", "zoom", and so on. Currently 58 standard commands have been defined, and they include commands commonly used by office software, web browsers and similar applications.
IOleUndoUnit
Represents an action that can be undone. It contains all information necessary to undo an action. It is created by objects and containers, so that undoable actions can be added to the container's IOleUndoManager.
IOleParentUndoUnit
Allows an undo unit to contain other undo units. In essence this allows the undo unit to act as an undo stack, grouping undo units together. For example, if a macro is run, all undo-able actions performed by the macro may be grouped together in one undo unit.
IOleWindow
This interface represents a window of a container or contained object. It allows callers to obtain the handle of the window, and to toggle the context-sensitive help function. When the context-sensitive help function is turned on, typically the mouse-pointer changes to an arrow with a question mark to indicate that clicking a user interface element will result in opening a help window.

Competition

[edit]

OpenDoc technology tried to compete with OLE. Some of Microsoft's competitors[who?] considered OpenDoc to be more robust and easier to use. 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 ("CIL") 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.

Interoperability

[edit]

Use of OLE objects limits interoperability, because these objects are not widely supported in programs for viewing or editing files outside of Microsoft Windows (e.g., embedding of other files inside the file, such as tables or charts from a spreadsheet application in a text document or presentation file).[3][4][5][6] If software that understands an OLE object is not available, the object is usually replaced by a picture (bitmap representation of the object) or not displayed at all.[7][8][9]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Object Linking and Embedding

View on Grokipedia
from Grokipedia
Object Linking and Embedding (OLE) is a Microsoft-developed that enables the storage or referencing of from one application (known as the server or component application) within a created by another application (the application), allowing for the seamless integration of diverse content types such as spreadsheets, images, or charts into compound documents. This protocol supports two primary methods: , where the object's is fully stored within the for independent editing and portability, and linking, where only a reference or path to the original in a separate file or application is stored, enabling dynamic updates if the source changes. Originally introduced in 1990 as OLE 1.0, the technology evolved from Microsoft's earlier (DDE) mechanism, which facilitated basic inter-application communication in Windows environments. By the early 1990s, OLE 2.0 marked a significant advancement, introducing support for in-place activation—allowing users to edit embedded objects directly within the container application without switching programs—and laying the foundation for more complex compound documents. At its core, OLE relies on the (COM), a binary standard that provides the underlying infrastructure for object communication, automation, and reusability across applications. Over time, OLE expanded beyond its initial focus on linking and embedding to encompass broader capabilities, such as for scripting and controls, which were later rebranded under the umbrella in the mid-1990s to promote web and desktop component integration. Despite its age, OLE remains integral to legacy applications and Windows-based systems for handling embedded objects like charts from Excel within Word documents or linked images from external sources. Its use has declined with the rise of modern standards like and cross-platform APIs, though it persists in scenarios requiring and structured document , amid ongoing security concerns such as the critical CVE-2025-21298.

Introduction

Definition and Purpose

Object Linking and Embedding (OLE) is a proprietary technology developed in the early that enables the integration of reusable, editable objects from various applications into compound documents. It serves as a framework for inter-application communication, allowing users to incorporate and manipulate elements such as charts, spreadsheets, or images created by source applications directly within a host document, while preserving the original object's functionality and editability. This approach promotes seamless collaboration across software tools, reducing the need for redundant and enhancing document . The primary purpose of OLE is to facilitate the creation of dynamic, multifaceted documents where embedded or linked objects retain their native behaviors, such as double-click activation to edit in the source application. For instance, a user can insert an editable Excel spreadsheet into a document, enabling real-time updates without exporting static copies. OLE evolved from earlier mechanisms like (DDE), a simpler messaging protocol for Windows applications, by providing more robust support for object-oriented and . First released in , it marked a significant advancement in desktop productivity by standardizing how applications exchange and persist complex data structures. In its basic workflow, OLE supports two main operations: embedding, where the object's data is fully stored within the host document for standalone portability, and linking, where only a reference to the source file is maintained for dynamic synchronization. These are typically performed via the Windows Clipboard—using "Paste" for embedding or "Paste Special" with the Link option—or through direct menu insertions like "Insert Object," which prompts selection of the source application and data type. OLE is founded on the Component Object Model (COM), which provides the underlying binary standard for object interaction.

Key Features

Object Linking and Embedding (OLE) distinguishes itself through several core operational capabilities that enable seamless integration of diverse content types across applications, surpassing basic copy-paste functionality by allowing interactive and dynamic manipulation. A primary feature is in-place , which permits users to edit embedded objects directly within the host using the source application's , such as double-clicking an embedded Excel in a Word to invoke Excel's tools inline without launching a separate . This merges the component application's menus, toolbars, and commands into the container's interface, facilitating fluid while maintaining the overall context. In contrast to static embedding, OLE supports linking for dynamic updates, where objects reference external source files rather than storing a self-contained copy, ensuring that changes to the original file—such as updating data in a linked —automatically propagate to all linked instances across documents. This mechanism relies on a persistent connection to the source, allowing for real-time synchronization while preserving the flexibility to break or update links as needed. Drag-and-drop support further enhances by enabling users to transfer OLE objects between applications or within the same window through intuitive direct manipulation, leveraging a uniform data transfer protocol to handle the embedding or linking process natively. This feature streamlines workflows, such as dragging a from a software into a , where it can then be activated and edited in place. Automation capabilities provide programmatic control over embedded or linked objects, allowing client applications or scripts to manipulate server objects via exposed properties, methods, and events, thus enabling advanced scripting and inter-application without manual intervention. For instance, a macro in one program can query or modify data in an embedded object from another, fostering extensible compound documents that combine multimedia and interactive elements like charts, bitmaps, or sound clips. OLE's versatility extends to supporting a wide array of object types, from simple static elements like images to complex, interactive components such as editable spreadsheets or media players, all unified under a standardized format that ensures compatibility and editability across participating applications. This broad support underpins the creation of rich, multifaceted documents where diverse content coexists and interacts cohesively.

History

Origins and OLE 1.0

Object Linking and Embedding (OLE) originated as an extension of Microsoft's Dynamic Data Exchange (DDE) protocol, which had been used since the mid-1980s to enable basic inter-application data sharing but was limited to simple text or numeric exchanges without support for richer, structured objects like graphics or formatted content. OLE addressed these shortcomings by introducing mechanisms for embedding entire objects from one application into another, allowing for more complex compound documents while maintaining a connection to the source for updates in linked scenarios. Released in 1990, OLE 1.0 marked Microsoft's initial push toward standardized object integration in the Windows ecosystem. Key features included basic embedding and linking capabilities, facilitated through virtual tables (VTBLs) that defined interface calls between client and server applications, enabling servers to render and manage embedded objects such as charts or drawings. Server applications could thus provide native rendering of their objects within a container document, promoting reusability across programs. Despite these advances, OLE 1.0 had notable limitations that hindered seamless user interaction. It lacked in-place editing, requiring embedded or linked objects to open in separate, full windows launched by the server application, which disrupted workflow in compound documents. Additionally, it relied on proprietary formats for storing object data as simple byte sequences within the container file, without the structured storage system that would later enable and multiple streams. Initial adoption of OLE 1.0 was concentrated within early productivity applications, such as Word and Excel, where it enabled basic object insertion and linking to enhance document . This integration laid the groundwork for broader use in Windows-based environments, though third-party support remained limited due to the technology's nascent stage and 16-bit architecture constraints.

OLE 2.0 and COM Integration

OLE 2.0 represented a significant evolution in Microsoft's object technology, released in 1992 and providing enhanced support in 3.0 (1993) for and database connectivity. This version built upon the foundations of by introducing a more robust framework for inter-application communication, shifting from the earlier DDE-based mechanisms to a component-oriented model. Central to OLE 2.0 was its deep integration with the (COM), marking it as the first major implementation of this binary standard for software components. COM provided a language-independent where objects were identified using Universally Unique Identifiers (UUIDs), and interfaces adhered to strict binary standards derived from the Microsoft Interface Definition Language (MIDL). This allowed developers to create reusable components that could interact seamlessly across processes and applications, without regard to the underlying programming language. Key innovations in OLE 2.0 included in-place activation, enabling users to edit embedded objects directly within the host document without switching applications—a feature known as visual . It also introduced structured storage, a within files using the OLE Compound File format to manage compound documents efficiently. OLE Automation extended scripting capabilities, allowing applications to expose and control objects programmatically, while drag-and-drop enhancements facilitated intuitive data transfer between windows and documents. The adoption of OLE 2.0 profoundly impacted by promoting seamless , serving as the bedrock for subsequent technologies like controls. Microsoft aggressively positioned OLE 2.0 as an industry standard, mandating its support for applications seeking "Designed for " certification to ensure consistent user experiences in the upcoming operating system.

Development of OLE Controls

In 1994, Microsoft introduced OLE Custom Controls, commonly known as OCXs, as reusable user interface components built upon the OLE 2.0 framework. These controls served as a successor to the earlier Visual Basic Extension (VBX) controls, providing enhanced capabilities for integrating modular UI elements into Windows applications. OCXs were designed to enable developers to create embeddable components that could be easily incorporated into container applications, promoting reusability and simplifying software development. OCXs were event-driven, allowing them to respond dynamically to user interactions and container events through a defined set of properties, methods, and events. Properties controlled the control's appearance and behavior, methods enabled programmatic actions, and events facilitated communication between the control and its host. They also supported design-time editing in development environments like Visual Basic, where developers could visually manipulate and configure controls during application design without runtime execution. A significant milestone occurred in 1996 when rebranded OLE Custom Controls as Controls, broadening their scope beyond traditional OLE applications to include internet-based content and wider COM integration. This shift emphasized their role in while maintaining compatibility with desktop environments. ActiveX Controls saw widespread adoption in Windows throughout the late , particularly for building forms, dialog boxes, and interactive applets in tools such as and MFC applications. Their modularity accelerated the creation of rich user interfaces in enterprise and consumer software. By the late , however, their popularity waned due to escalating vulnerabilities, as ActiveX Controls could execute arbitrary code with full system privileges when hosted in browsers, leading to frequent exploits. The rise of cross-platform web technologies like applets, Flash, and eventually further diminished their relevance, prompting a shift toward safer, standards-based alternatives.

Core Concepts

Embedding and Linking Mechanisms

Object Linking and Embedding (OLE) distinguishes between two primary mechanisms for incorporating objects from one application into another: embedding and linking. These processes enable compound documents to integrate diverse content types, such as spreadsheets, charts, or images, while preserving editability through the originating application, known as the server. In the embedding , the complete object data is copied and stored directly within the container document, creating an independent, self-contained instance. This occurs typically via a "Paste Special" command selecting the object type, which transfers the native data format—such as formulas, layouts, or pixel data—into the host file without relying on external sources. The embedded object retains its original structure and can be edited by activating the server application, but changes made do not propagate back to the source, ensuring portability for scenarios like archived reports where static, bundled content is essential. For instance, embedding an Excel into a Word document allows the chart to be viewed and modified solely within the Word file, independent of the original spreadsheet. Conversely, the linking process establishes a dynamic connection by storing only a , such as a file path or , to the external source rather than the full data. Initiated through a "Paste Link" option, this mechanism embeds a lightweight pointer in the , often accompanied by a cached preview for display purposes, while the actual content resides in the separate source file. Updates to the source automatically reflect in the linked object upon refresh, making it suitable for collaborative environments requiring real-time synchronization, such as linking live data from a shared Excel into a . However, this approach carries risks, including broken links if the source file is relocated or deleted. The storage differences underscore these mechanisms' trade-offs: embedded objects include the full native data, increasing but guaranteeing , whereas linked objects rely on pointers and optional caching, minimizing overhead but necessitating the source's . Each object is identified by a Class Identifier (CLSID) that specifies its type, such as a worksheet or image, facilitating proper handling by the server. Activation of either mechanism begins with user interaction, typically a on the object within the , which triggers the OLE framework to invoke the server application for editing. For embedded objects, this often employs in-place , integrating the server's —such as menus and toolbars—directly into the for seamless modification without leaving the host . Linked objects, however, generally activate in a separate of the source application, as the must be edited at its origin to ensure updates propagate correctly; users then close the server to return to the , with changes reflected upon refresh. This flow leverages OLE's verb commands, like "Edit," to initiate the process while maintaining .

Compound Documents

Compound documents in Object Linking and Embedding (OLE) represent hierarchical containers that integrate diverse objects—such as text blocks, images, charts, and spreadsheets—into a unified file structure, enabling each object to remain independently editable via its originating application's tools. This design allows users to assemble complex, multifaceted documents from components created across different software environments, preserving the native functionality and appearance of each element without requiring or reformatting. By treating the document as a composite entity, OLE facilitates seamless interaction between disparate data types, promoting a modular approach to content creation where objects function as self-contained units within the larger whole. The primary benefits of this lie in its promotion of reusability and ; individual objects can be revised, replaced, or updated in isolation, eliminating the need to regenerate or overhaul the entire document. For instance, changes to an embedded data visualization can propagate automatically if linked, or be saved directly if embedded, ensuring consistency and efficiency in collaborative or iterative workflows. This modularity also reduces , as shared objects can be referenced across multiple documents, enhancing and simplifying maintenance for complex reports or presentations. Structurally, OLE organizes these objects using streams for linear data sequences and storages for nested hierarchies, all encapsulated within a single file to mimic a . This setup supports versioning by allowing storages to maintain historical snapshots or incremental updates, while metadata—such as object properties, authorship, and timestamps—is stored in dedicated property sets for easy access and . Such ensures that the compound file remains portable and self-contained, with objects retrievable without external dependencies. Representative examples include a embedding tabular data from a application alongside linked graphical elements from a tool, allowing in-place of each while maintaining integrity. However, in practice, compound documents can encounter performance overhead due to the activation of multiple servers—where each object's editing session launches or loads its corresponding application instance—potentially leading to increased usage and slower response times in documents with numerous diverse components.

Technical Architecture

Foundation in Component Object Model

The (COM) serves as the foundational binary standard for Object Linking and Embedding (OLE), providing a platform-independent, distributed, object-oriented system for creating and interacting with software components through binary interfaces. Introduced by in 1993, COM enables reusable components that can operate across different programming languages, processes, and even machines, using a distributed architecture that supports in-process, local, and remote interactions via proxies and stubs for cross-process calls. In this model, components expose functionality through well-defined interfaces, each identified by a unique globally unique identifier (GUID), allowing clients to invoke methods without knowledge of the underlying implementation. OLE 2.0 was entirely rebuilt on COM to leverage its robust infrastructure for embedding and linking objects within compound documents, marking a shift from the earlier OLE 1.0's more limited approach. Central to this integration is the IUnknown interface, from which all COM interfaces derive, which manages object lifetime through via the AddRef and Release methods, ensuring proper memory allocation and deallocation. Additionally, the QueryInterface method of IUnknown enables dynamic binding, allowing clients to query an object for support of specific interfaces at runtime, facilitating polymorphic behavior essential for OLE's interoperable object manipulation. Key principles of COM underpinning OLE include location transparency, where clients interact with objects identically regardless of whether they are in the same process, a different process, or on a remote machine; , which restricts communication to contract-defined methods; and marshaling, the process of packaging interface calls into a standard wire format for transmission across boundaries, handled by proxy objects on the client side and stubs on the server side. These mechanisms ensure seamless operation in distributed environments, directly supporting OLE's goal of integrating diverse application data without tight coupling. COM's evolution was specifically driven by the requirements of OLE 2.0, as developed it to provide a stable foundation for advanced features that OLE 1.0 could not adequately support. This binary compatibility standard guarantees that OLE objects can function across varied implementations and vendors without access to , promoting reusability and reducing versioning issues through immutable interface contracts defined in Interface Definition Language (IDL).

Key Interfaces and Data Structures

Object Linking and Embedding (OLE) relies on a set of core (COM) interfaces to manage the lifecycle, persistence, and rendering of embedded and linked objects, enabling seamless integration between containers and servers. The IOleObject interface serves as the primary mechanism for handling an object's basic functionality within a container, including methods for and deactivation, which allow the object to transition between states such as loaded, running, or active. For instance, enables the object to interact with the user, while deactivation releases resources to return control to the container. Complementing this, the IPersist interface provides foundational support for saving and loading an object's state, exposing the object's class identifier (CLSID) to facilitate instantiation and persistence across sessions. Rendering is managed through the IViewObject interface, which allows an object to draw itself directly to a device context without relying on data transfer mechanisms, supporting efficient visual representation in the container's window. OLE employs specific data structures to identify and reference objects, ensuring reliable management and linking. The OLE object descriptor typically includes the CLSID, a globally (GUID) that specifies the object's class for creation via COM, and the ProgID, a human-readable mapped to the CLSID in the registry for easier programmatic access. These identifiers enable containers to instantiate appropriate servers and verify object types during embedding or linking operations. For linking, moniker structures provide a flexible way to external objects or data sources, encapsulating binding information such as location, item, and context to allow deferred resolution and updates without storing the full data inline. Monikers support composition, enabling complex links like file-based or URL-based references, which are resolved at runtime to fetch the latest data. Interaction between containers and servers in OLE follows a defined flow mediated by the IOleClientSite interface, which the container implements to provide services to the embedded or linked object. This interface allows the server to query details about its display site, ambient properties, and context, facilitating coordinated behavior such as resizing or context menu integration. A key aspect of this communication is verb execution, where the container invokes actions on the object via the IOleObject::DoVerb method; verbs represent predefined operations like "edit" for opening an editor or "play" for content, with the primary verb typically triggered by double-clicking the object. This bidirectional flow ensures that servers can request resources from containers while containers can direct object behavior, supporting in-place activation where editing occurs within the container's frame. To optimize performance, particularly during in-place editing, OLE incorporates caching mechanisms through the IOleCache interface, which manages stored representations of the object's visual aspects. Persistent caches retain formatted data (e.g., metafiles or bitmaps) across sessions for quick redisplay without re-rendering from the source, reducing latency in compound documents. Scratch caches, in contrast, provide temporary buffers for dynamic updates during active editing sessions, allowing servers to compose changes off-screen before committing to the container's view, thereby minimizing flicker and resource overhead. These caches are controlled via methods like IOleCache::Cache to specify formats and update notifications, ensuring efficient handling of aspect changes such as content or scale. Error handling in OLE operations utilizes HRESULT codes, the standard 32-bit return values in COM, with facility codes dedicated to OLE-specific conditions (FACILITY_ITF = 4). Common OLE errors include OLE_E_NOTRUNNING (0x80040000), indicating an attempt to invoke methods on an unloaded object, and OLE_E_NOCONNECTION (0x80040003) for failed link bindings, allowing containers and servers to gracefully recover or notify users. These codes, defined in oleerr.h, integrate with COM's IUnknown base for queryable error details, promoting robust interoperability.

Structured Storage and File Format

The Compound File Binary Format (CFBF), also known as structured storage, serves as the foundational for Object Linking and Embedding (OLE) in and later, enabling the of multiple objects and metadata within a single file such as a .doc or .xls document. This format emulates a by using a hierarchical structure composed of storages, which function like directories, and , which act as files containing the actual . The storage at the top level contains child storages and streams, allowing nested that supports complex compound documents with multiple embedded or linked OLE objects. In OLE, embedded objects are persisted as dedicated storages within the compound file, each containing specific that hold the object's data. The \001CompObj stream stores information, including the object's class identifier (CLSID) and user-type details for rendering. The \001Ole stream holds the native data, which is the proprietary format of the embedded object's content as saved by its server application. Additionally, streams like \001ObjInfo provide object metadata, such as positioning and sizing, while streams offer a compact preview image for quick display in the container application. For linked objects, the storage includes moniker streams that encapsulate the and binding information needed to reference and retrieve the external source data dynamically. Programmatic access to this structure is facilitated through the IStorage and IStream COM interfaces, which allow applications to create, enumerate, and manipulate the hierarchy of storages and streams. The IStorage interface supports operations like opening child storages or streams, renaming entries to prevent naming conflicts, and committing changes to the file. The IStream interface provides sequential read/write access to stream contents, enabling efficient handling of object data without loading the entire file into memory. These interfaces integrate with OLE's persistence model, where the IOleObject interface's Save method serializes objects into the appropriate streams within a storage. The format supports versioning through directory entry timestamps and storage properties, allowing multiple versions of an object to coexist by appending version-specific streams or updating metadata without overwriting prior data. Renaming mechanisms in IStorage ensure unique names within a parent storage, resolving potential conflicts during object insertion or updates. Files are divided into 512-byte sectors for allocation and management, providing efficient storage for varying object sizes while maintaining compatibility with disk-based file systems. Backward compatibility with OLE 1.0 is achieved through conversion tools that transform the simpler metafile-based format into CFBF storages, preserving embedded objects during upgrades to OLE 2.0 documents.

Applications and Implementations

Usage in Microsoft Office Suite

Object Linking and Embedding (OLE) became a core feature of the suite with the release of Office 4.0 in 1994, enabling seamless embedding and linking of content across applications such as Word, Excel, and PowerPoint to create integrated compound documents. This integration allowed users to incorporate objects from one Office application into another, facilitating dynamic data sharing and editing without leaving the host document, which marked a significant advancement in document within the suite. In practical applications, OLE supports inserting Excel charts into Word documents through the Insert > Object > Create from File menu, where users can embed or link the chart to maintain synchronization with the source file for real-time updates. Linked objects can be converted to embedded objects by right-clicking the object, selecting options such as "Linked Object" > "Links" > "Break Link," or using the Edit Links to Files dialog, which stores a copy of the object's current data within the host document. For images, the Insert > Pictures command embeds the file by default, while linking can be achieved via the Insert > Object dialog with the "Link to file" option. Similarly, OLE enables linking to external databases in applications like Excel for generating dynamic reports, such as pulling live from OLE DB sources to populate tables or charts that refresh automatically upon query execution. These mechanisms rely on OLE's linking protocols to ensure and responsiveness in business reporting workflows. Automation of OLE objects in the Office suite is commonly achieved through (VBA) scripts, which allow programmatic control over embedded or linked items. For instance, VBA code can access and update an embedded Visio diagram within a Word or Excel document by invoking methods, such as activating the object and modifying its properties via the Visio Application object. This scripting capability extends to tasks like refreshing or reshaping diagrams in response to changes in source files, enhancing efficiency in document maintenance. Regarding performance, OLE's use of compound files in enables the handling of large documents containing multiple embedded objects by structuring data into streams and storages, which minimizes overhead compared to separate flat files, though complex files with numerous OLE objects may experience slower load times due to the file system's emulation. 365 maintains legacy support for OLE through backward compatibility features, including the Compatibility Checker that identifies potential issues with older OLE objects during file conversion, ensuring that documents created in prior versions, such as those using OLE , can be opened and edited without loss of functionality. A representative case study of OLE in action involves creating sales presentations in PowerPoint that incorporate mixed objects from multiple Office applications, such as embedding an Excel chart for quarterly revenue data and linking a Word table for product descriptions, allowing sales teams to update figures dynamically during client meetings while maintaining a cohesive narrative. This approach leverages OLE's embedding and linking to produce professional, interactive slides where edits to the source Excel file propagate to the presentation upon refresh, streamlining preparation for sales pitches.

Adoption in Other Software

Object Linking and Embedding (OLE) found adoption in (CAD) and engineering software, enabling the integration of drawings and models across applications. , developed by , has supported OLE since 1994, allowing users to embed drawings or other objects from AutoCAD into container applications like word processors or spreadsheets while retaining editability in the source application. This functionality facilitated the inclusion of vector-based drawings in compound documents, with OLE objects inserted via copy-paste or the Insert Object dialog, though limitations such as non-uniform scaling in older versions persisted. Similarly, Bentley's incorporated OLE support starting with MicroStation SE in 1997, with significant enhancements in version V8 (2003), permitting the linking of 3D models from external sources into files for enhanced interoperability in design workflows. Users could link or embed 3D elements, such as solid models, ensuring updates in the source application propagated to the MicroStation design, though both source and container applications needed to be OLE-compliant and installed locally. In database tools, OLE enabled the attachment of binary objects like images or documents before native attachment fields became standard. For instance, older versions of utilized the OLE Object data type to embed or link files directly into records, supporting items such as scanned images or spreadsheets for relational data management. This approach preserved object editability but contributed to database bloat due to embedded content, prompting a shift to more efficient attachment types in later releases. Other design applications adopted OLE on a limited basis for object exchange. Adobe Photoshop acted as an OLE 2.0 server, allowing images to be embedded or linked into container applications like or , where double-clicking reopened the image for editing in Photoshop. However, limitations included the inability to link pasted selections and inconsistent handling of clipping paths across containers. provided OLE support for importing linked or embedded objects from source applications, enabling exchange while maintaining source formatting, though editing was restricted to the originating software in most cases. Adoption faced challenges from vendor-specific extensions, which led to inconsistent implementations and compatibility issues across software ecosystems. Post-2000, OLE usage declined as web-based alternatives like embedding, PDF standards, and XML for exchange offered simpler, cross-platform without the need for Windows dependencies. Despite this, OLE persists in niche Windows-based enterprise environments, particularly for document in legacy systems such as industrial control software and engineering tools, where tools like the OLE Automation wrapper enable continued integration with modern office suites.

Competition and Alternatives

OpenDoc as a Rival Technology

was initiated in 1992 by Apple Computer as an alternative to Microsoft's proposed OLE II framework, following Apple's decision to pursue an independent path for technology. Development was soon transferred to the nonprofit Component Integration Laboratories (CI Labs), founded that year by Apple, , and Corporation (later acquired by ), with the goal of creating a platform-agnostic system for building and editing s across multiple operating systems. The consortium expanded to include additional members such as SunSoft, fostering collaborative advancement of the standard to ensure vendor neutrality and broad interoperability. OpenDoc employed a part-based , where documents consisted of modular "parts" such as text, , or spreadsheets that could be embedded and edited collaboratively within a single container, mirroring OLE's approach but emphasizing cross-platform compatibility for Macintosh, Windows, , and Unix environments. A key feature was in-place editing, allowing users to activate and modify individual parts directly within the host document without launching separate full applications, supported by of part code only when needed to minimize resource overhead. This design promoted seamless integration and reusability, with parts capable of communicating via standardized interfaces and supporting scripting for across distributed systems. The rivalry between and OLE intensified in the 1990s, as 's dominance in the Windows ecosystem created significant barriers; specifically, the Logo Program required applications to support OLE for drag-and-drop functionality to achieve official certification, effectively marginalizing OpenDoc-compatible software in the dominant market. This certification mandate, combined with aggressive marketing at Microsoft developer conferences promoting OLE 2, limited OpenDoc's adoption despite its cross-platform ambitions, while broader legal scrutiny of Microsoft's practices in antitrust cases highlighted the competitive tensions of the era. OpenDoc's decline culminated in its discontinuation in March 1997, when CI Labs dissolved and Apple, under returning CEO , terminated the project amid criticisms of its architectural complexity, which complicated development and integration for third-party vendors. Ultimately, the overwhelming market dominance of OLE and COM on Windows platforms sealed its fate, as few major applications adopted OpenDoc, leading to insufficient ecosystem momentum. Despite its failure, OpenDoc's emphasis on modular, embeddable components influenced subsequent standards for compound documents and modern that enable reusable, interoperable UI elements in browsers.

Evolution to Modern Standards

As the became the dominant platform for document sharing and collaboration in the late 1990s and early , OLE's embedding and linking mechanisms faced challenges from emerging web technologies. , an extension of OLE built on the (COM), was initially designed to enable similar object integration in web browsers, allowing dynamic content similar to OLE in desktop applications. However, severe security vulnerabilities, including the ability for malicious sites to execute arbitrary code without user consent, led major browsers to disable or deprecate support by the mid-. Modern web standards like iframes and APIs have since supplanted these approaches, providing safer mechanisms for embedding interactive content, as seen in tools like , which uses iframes for linking and embedding documents across web pages. Within Microsoft ecosystems, OLE's principles of component-based integration evolved toward .NET frameworks, which offer improved interoperability with objects while enabling more modular application development. By the early , Windows Presentation Foundation (WPF), introduced in .NET Framework 3.0 in 2006, provided a successor for richer UI composition, using XAML for declarative markup to assemble complex interfaces from reusable components, reducing reliance on OLE's binary embedding for visual elements. This transition supported more scalable, vector-based graphics and animations, aligning with broader shifts away from OLE's structured storage for new Windows desktop applications. The adoption of open standards further diminished OLE's role in compound documents. (OOXML), standardized as ECMA-376 in 2006 and ISO/IEC 29500 in 2008, emerged as a successor to OLE's binary compound , using ZIP-based packaging with XML parts to enable interoperable without proprietary binary dependencies. This format, implemented in , allowed for relationships between embedded objects like images and charts via XML metadata, promoting cross-application compatibility over OLE's COM-centric model. Cross-platform alternatives have also filled gaps left by OLE's Windows-specific limitations. Adobe PDF, leveraging its portable document format since the 1990s, supports embedding multimedia and interactive elements in a platform-agnostic way, widely used for compound reports without OLE's runtime dependencies. Similarly, Jupyter Notebooks, developed from 2011 onward, offer a modern, web-based environment for linking executable code cells with outputs, serving as an interactive successor for data-driven compound documents in scientific and collaborative workflows. By the 2010s, the rise of web graphics standards like (standardized in 2001) and (introduced in 2011) accelerated OLE's obsolescence for new development, as these enabled scalable, hardware-accelerated embedding in browsers, rendering OLE's desktop-focused approach outdated for internet-era applications.

Interoperability and Limitations

Cross-Platform Compatibility

Object Linking and Embedding (OLE) was designed with a strong emphasis on the Windows operating system, exhibiting deep integration with Win32 APIs, the (COM), and the for object registration and activation. This architecture ensures seamless operation within Windows environments but precludes native support on non-Windows platforms such as macOS, , or mobile operating systems. Apple's ecosystem, for instance, lacks OLE implementation, and has not extended COM-based OLE to these systems, rendering it inherently Windows-exclusive. When OLE objects are encountered in unsupported applications or platforms, they typically fallback to static representations, such as , icons, or embedded packages, which display the object's visual content but forfeit editability and dynamic linking capabilities. For example, in for Mac, OLE objects fail to render properly unless converted to bitmap formats during insertion, resulting in non-interactive visuals. Similarly, applications on macOS cannot activate OLE 2.0 objects, displaying them as uneditable placeholders instead of allowing in-place editing or server activation. Partial implementations exist through compatibility layers like Wine on , which emulates COM and OLE interfaces to run Windows applications, but these suffer from significant functionality gaps, including registration errors and incomplete support. Emulators or virtual machines can host full Windows instances for OLE usage, yet they introduce performance overhead and do not provide true native portability. To achieve interoperability across platforms, users often resort to workarounds such as exporting OLE content to universal formats like PDF, which captures static snapshots but eliminates linking and embedding features. In for Mac, partial support is achieved through translated object representations or native Mac alternatives like Publish and Subscribe in earlier versions, though these do not fully replicate OLE's behavior and require separate development paths. Web-based Office add-ins offer a modern cross-platform alternative, enabling similar embedding via browser technologies without relying on OLE. Historically, explored cross-platform extensions for OLE through announcements of UNIX support in the mid-1990s and the development of Distributed COM (DCOM), which aimed to enable remote object communication but remained tied to Windows without fully porting OLE's compound document features. These efforts, including DCOM's platform dependencies, ultimately failed to deliver comprehensive non-Windows compatibility, reinforcing OLE's Windows-centric legacy.

Security Vulnerabilities

Object Linking and Embedding (OLE) has been a vector for numerous security vulnerabilities due to its ability to embed and execute external within documents, particularly in applications. These flaws often enable remote code execution (RCE) when users interact with malicious files, such as those containing crafted OLE objects. A primary exploit vector involves , which allows embedded objects—like VBA macros in Word or Excel documents—to execute arbitrary upon activation, potentially leading to infection without explicit user consent. For instance, attackers can embed malicious OLE objects in (RTF) files, exploiting the technology to link to external payloads or trigger buffer overflows in components like the Equation Editor. Historically, OLE-related exploits have powered significant campaigns. The worm in 1999 leveraged VBA macros enabled by to propagate via , infecting documents and Outlook, which resulted in widespread network disruptions and economic losses estimated in millions of dollars. More recently, CVE-2017-11882, a in the Equation Editor, has been actively exploited in attacks to deliver infostealers like LokiBot, affecting versions from 2007 to 2016 and enabling RCE with a CVSS score of 7.8. This , patched in , continues to be targeted due to unpatched legacy systems, as noted in analyses of wild exploits by groups. Key design flaws in OLE exacerbate these risks, including automatic activation of embedded objects without sufficient user prompts and the compound file format's capacity to hide malicious payloads in binary streams. The OLE architecture blurs trust boundaries between host applications and third-party components, relying on minimal input validation during dynamic module loading, which allows crafted Class Identifiers (CLSIDs) to invoke unintended COM objects. For example, corrupted OLE storage in documents can carry exploitable data that bypasses basic parsing checks, leading to memory corruption or DLL preloading attacks. Microsoft has implemented several mitigations to address OLE vulnerabilities. Protected View opens potentially unsafe documents—such as those from the or —in a read-only sandbox, disabling editing and OLE object activation by default to prevent execution of embedded content. Administrators can further block OLE/COM components via registry settings or in , such as using the ActivationFilterOverride key to restrict specific CLSIDs, while Windows Defender employs sandboxing for isolated execution. Security updates, like those for MS14-060, modify OLE object handling to validate memory properly. Despite these measures, ongoing risks persist due to OLE's legacy support in and applications, where older documents can still trigger exploits if is bypassed or disabled. Vulnerabilities like CVE-2025-21298, a zero-click RCE in Windows OLE affecting systems from Server 2008 onward, highlight continued exposure in enterprise environments handling legacy files. Enterprises remain vulnerable to attacks via unpatched systems or shared documents, as evidenced by the routine exploitation of OLE flaws in campaigns as of 2025.

Legacy and Successors

Transition to ActiveX and COM Extensions

In 1996, Microsoft rebranded OLE Controls as Controls to expand their applicability beyond document embedding into web and desktop applications, introducing features such as security zones and controls marked as safe for scripting to mitigate risks in browser environments. This rebranding facilitated the integration of reusable software components into pages, with 3.0 providing native support for hosting controls starting that year. Building on COM, the foundation of OLE, Microsoft extended the technology through DCOM in 1996, enabling distributed OLE objects to communicate across networks via remote procedure calls, thus supporting enterprise-scale applications. Announced in 1997 and released with in 2000, COM+ further enhanced these capabilities by incorporating built-in transaction support, security services, and message queuing, allowing for more robust, scalable component-based development. ActiveX found prominent use in as a plugin mechanism for embedding interactive content, such as and forms, on web pages. For distribution, developers packaged ActiveX controls into cabinet (.cab) files, which compressed and self-installed components over the internet, streamlining deployment in browser-based scenarios. This evolution marked a pivotal shift from OLE's document-centric focus to a broader of general-purpose component software, profoundly influencing Windows scripting environments like the by enabling language-neutral automation and extensibility. However, by the early 2000s, escalating vulnerabilities in controls prompted browser vendors, including , to implement default blocks and enhanced filtering in to curb exploitation risks.

Current Status and Deprecation

As of 2025, Object Linking and Embedding (OLE) functions primarily as a legacy technology within the ecosystem, maintained for rather than active innovation. and fully support OLE, allowing users to open, view, and edit legacy documents containing embedded or linked objects from older applications. This persistence ensures that historical files remain accessible without immediate disruption, though interactions are increasingly restricted to prevent exploitation. Deprecation efforts by emphasize security and modernization, including the disablement of automatic OLE object activation across applications to address remote code execution risks. For instance, updates to Excel in 2022 and PowerPoint in 2025 explicitly block automatic loading and instantiation of OLE objects, requiring manual user intervention. Additionally, OLE support has been removed from the browser, which does not natively accommodate controls—an extension of OLE/COM—outside of legacy compatibility mode. continues to issue security patches for OLE vulnerabilities, such as the critical CVE-2025-21298 addressed in January 2025, but promotes contemporary alternatives like Power BI embeds and integrations for data and object incorporation in new workflows. In niche sectors like (CAD) and engineering, OLE retains practical utility for embedding external content; AutoCAD 2025, for example, integrates OLE to link or embed data from compatible source applications, supporting workflows in technical documentation. Surveys on enterprise IT indicate broad reliance on legacy systems overall, with many organizations spending significant resources on maintenance, though specific OLE dependency appears minimal in modern document sets due to migration trends. Tools for converting OLE objects to static images or hyperlinks, such as third-party utilities like Access OLE Export or VBA methods in Word, facilitate these transitions by extracting embedded content without preserving interactivity. Looking ahead, OLE's role is expected to diminish further with the end of extended support for Office 2021 on October 13, 2026, potentially leading to fuller deprecation by 2030 as enterprises complete migrations and older versions retire. Ongoing security vulnerabilities, including those enabling zero-click exploits, underscore the urgency of these shifts, with no new OLE features developed in recent years.

References

  1. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-oleds/554a69b6-497a-4fef-a0fe-792d0dcf50fb
  2. https://learn.microsoft.com/en-us/cpp/mfc/ole-background-linking-and-embedding?view=msvc-170
  3. https://cio-wiki.org/wiki/Object_Linking_and_Embedding_%28OLE%29
  4. https://learn.microsoft.com/en-us/cpp/mfc/tn041-mfc-ole1-migration-to-mfc-ole-2?view=msvc-170
  5. https://learn.microsoft.com/en-us/cpp/mfc/ole-background?view=msvc-170
  6. https://support.microsoft.com/en-us/office/linked-objects-and-embedded-objects-0bf81db2-8aa3-4148-be4a-c8b6e55e0d7c
  7. https://www.offsec.com/blog/cve-2025-21298/
  8. https://peer.asee.org/using-object-linking-and-embedding-ole-as-an-integration-tool
  9. https://www.dyalog.com/uploads/conference/dyalog11/presentations/C05_using_excel_under_apl/html/understanding_ole.html
  10. https://learn.microsoft.com/en-us/cpp/mfc/activation-cpp?view=msvc-170
  11. https://learn.microsoft.com/en-us/cpp/mfc/drag-and-drop-ole?view=msvc-170
  12. https://learn.microsoft.com/en-us/cpp/mfc/automation-clients?view=msvc-170
  13. https://learn.microsoft.com/en-us/windows/win32/com/linking-and-embedding
  14. https://learn.microsoft.com/en-us/archive/msdn-magazine/2000/july/under-the-hood-happy-10th-anniversary-windows
  15. https://ftp.zx.net.nz/pub/Patches/ftp.microsoft.com/MISC/KB/en-us/86/008.HTM
  16. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-oleds/fdc5e702-d09e-4344-a77f-eb079d41f23f
  17. https://www.objs.com/x3h7/ole2.htm
  18. https://learn.microsoft.com/en-us/windows/win32/com/com-technical-overview
  19. https://www.lexjansen.com/nesug/nesug95/NESUG95074.pdf
  20. https://jacobfilipp.com/DrDobbs/articles/DDJ/1994/9403/9403j/9403j.htm
  21. https://www.lexjansen.com/pnwsug/1996/PNWSUG96014.pdf
  22. https://learn.microsoft.com/en-us/archive/msdn-magazine/2000/october/visual-programmer-server-side-controls-in-active-server-pages
  23. https://learn.microsoft.com/en-us/cpp/mfc/ole-control-classes?view=msvc-170
  24. https://learn.microsoft.com/en-us/office/vba/api/overview/activex-control
  25. https://news.microsoft.com/source/1996/03/12/microsoft-announces-activex-technologies/
  26. https://www.howtogeek.com/717016/remembering-activex-controls-the-webs-biggest-mistake/
  27. https://learn.microsoft.com/en-us/windows/win32/com/compound-documents
  28. https://learn.microsoft.com/en-us/windows/win32/stg/structured-storage-start-page
  29. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-oleps/3496eeff-ff17-4e2b-8972-7f8318289f8a
  30. https://www.cs.umd.edu/~pugh/com/
  31. https://learn.microsoft.com/en-us/windows/win32/learnwin32/module-2--using-com-in-your-windows-program
  32. https://learn.microsoft.com/en-us/windows/win32/api/oleidl/nn-oleidl-ioleobject
  33. https://learn.microsoft.com/en-us/windows/win32/api/objidl/nn-objidl-ipersist
  34. https://learn.microsoft.com/en-us/windows/win32/api/oleidl/nn-oleidl-iviewobject
  35. https://learn.microsoft.com/en-us/windows/win32/com/monikers
  36. https://learn.microsoft.com/en-us/windows/win32/api/oleidl/nn-oleidl-ioleclientsite
  37. https://learn.microsoft.com/en-us/windows/win32/api/oleidl/nf-oleidl-ioleobject-doverb
  38. https://learn.microsoft.com/en-us/windows/win32/api/oleidl/nf-oleidl-iolecache-cache
  39. https://learn.microsoft.com/en-us/windows/win32/com/structure-of-com-error-codes
  40. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cfb/53989ce4-7b05-4f8d-829b-d08d6148375b
  41. https://download.microsoft.com/download/0/b/e/0be8bdd7-e5e8-422a-abfd-4342ed7ad886/windowscompoundbinaryfileformatspecification.pdf
  42. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cfb/bc33425a-fbb9-4f73-911f-2662c7a14060
  43. https://b2xtranslator.sourceforge.net/howtos/The_Storage_of_Macros_and_OLE_Objects.pdf
  44. https://scholarworks.lib.csusb.edu/cgi/viewcontent.cgi?article=1102&context=jiim
  45. https://www.informit.com/articles/article.aspx?p=170392&seqNum=163
  46. https://support.microsoft.com/en-us/topic/how-to-use-ole-automation-in-visio-6ac57fad-e300-95ca-7e86-67fe953081ee
  47. https://learn.microsoft.com/en-us/office/vba/api/visio.oleobject
  48. https://learn.microsoft.com/en-us/cpp/mfc/containers-compound-files?view=msvc-170
  49. https://support.microsoft.com/en-us/office/check-file-compatibility-with-earlier-versions-d9856881-5875-4c58-915f-06859b2943a7
  50. https://support.microsoft.com/en-us/office/insert-an-object-in-your-excel-spreadsheet-e73867b2-2988-4116-8d85-f5769ea435ba
  51. https://forums.autodesk.com/t5/autocad-forum/attached-image-scale-non-uniformly/td-p/10381993
  52. https://bentleysystems.service-now.com/community?id=kb_article_view&sysparm_article=KB0112272
  53. https://support.microsoft.com/en-us/office/attach-files-and-graphics-to-the-records-in-your-database-d40a09ad-a753-4a14-9161-7f15baad6dbd
  54. https://www.devhut.net/ole-object-data-type-just-dont-ever-do-it/
  55. https://helpx.adobe.com/photoshop/using/placing-photoshop-images-applications.html
  56. https://product.corel.com/help/CorelDRAW/540223850/Main/EN/Documentation/CorelDRAW-Object-linking-and-embedding.html
  57. https://www.huntress.com/cybersecurity-101/topic/what-is-object-linking-embedding
  58. https://www.collaboraonline.com/coleat/
  59. https://fortune.com/2014/07/15/apple-and-ibm-fourth-times-a-charm/
  60. https://support.novell.com/techcenter/articles/dnd19941101.html
  61. https://dl.acm.org/doi/pdf/10.1145/238215.238259
  62. https://techshelps.github.io/MSDN/BACKGRND/html/msdn_win95app.htm
  63. https://www.wired.com/1997/03/closing-opendoc-a-great-leap-backward/
  64. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/p545-guo.pdf
  65. https://www.ebsco.com/research-starters/computer-science/compound-document
  66. https://mskb.pkisolutions.com/kb/159621
  67. https://learn.microsoft.com/en-us/dotnet/desktop/wpf/overview/
  68. https://www.ecma-international.org/publications-and-standards/standards/ecma-376/
  69. https://support.microsoft.com/en-us/office/open-xml-formats-and-file-name-extensions-5200d93c-3449-4380-8e11-31ef14555b18
  70. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-oleds/85583d21-c1cf-4afe-a35f-d6701c5fbb6f
  71. https://www.graphpad.com/support/faqid/1291/
  72. https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/Cannot-embed-or-display-OLE-objects-in-AutoCAD-for-Mac.html
  73. https://forums.autodesk.com/t5/autocad-for-mac-forum/ole-visibility-in-autocad-autocad-lt-2021-for-mac/td-p/9775360
  74. https://learn.microsoft.com/en-us/answers/questions/5115778/mac-word-cannot-load-the-ole-2-0-or-docfile-librar?forum=msoffice-all&referrer=answers
  75. https://forum.winehq.org/viewtopic.php?t=36694
  76. https://www.perlmonks.org/?node_id=430194
  77. https://terrycrowley.medium.com/taking-office-cross-platform-from-inside-the-windows-company-42c39fa638f5
  78. https://stackoverflow.com/questions/74311611/is-there-anyway-to-embed-an-ole-object-in-word-under-macos-and-use-an-external-p
  79. https://peer.asee.org/using-object-linking-and-embedding-ole-as-an-integration-tool.pdf
  80. https://wirexsystems.com/resource/protocols/dcom/
  81. https://www.ndss-symposium.org/wp-content/uploads/2025-547-paper.pdf
  82. https://learn.microsoft.com/en-us/security-updates/securitybulletins/2014/ms14-060
  83. https://nvd.nist.gov/vuln/detail/CVE-2017-11882
  84. https://www.techtarget.com/searchsecurity/definition/Melissa-virus
  85. https://unit42.paloaltonetworks.com/unit42-analysis-of-cve-2017-11882-exploit-in-the-wild/
  86. https://support.microsoft.com/en-us/office/what-is-protected-view-d6f09ac7-e6b9-4495-8e43-2bbcdbcb6653
  87. https://learn.microsoft.com/en-us/troubleshoot/microsoft-365-apps/office-suite-issues/control-block-ole-com
  88. https://censys.com/advisory/cve-2025-21298
  89. https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-133a
  90. https://cwe.mitre.org/data/definitions/623.html
  91. https://cybercultural.com/p/1996-microsoft-activates-the-internet-with-activex-jscript/
  92. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dcom/4a893f3d-bd29-48cd-9f43-d9777a4415b0
  93. https://news.microsoft.com/source/1997/09/23/microsoft-announces-com/
  94. https://news.microsoft.com/source/2000/02/17/windows-2000-the-next-generation-of-pc-computing-available-worldwide-today/
  95. https://learn.microsoft.com/en-us/windows/win32/com/activex-controls
  96. https://learn.microsoft.com/en-us/cpp/mfc/upgrading-an-existing-activex-control?view=msvc-170
  97. https://documentation.alphasoftware.com/documentation/pages/Guides/Desktop/Design/OLE/ActiveX%2520and%2520OLE%2520Overview.xml
  98. https://www.itprotoday.com/devops/using-activex-objects-to-extend-wsh-s-functionality
  99. https://www.sei.cmu.edu/documents/312/2000_019_001_52716.pdf
  100. https://learn.microsoft.com/en-us/security-updates/securitybulletins/2003/ms03-042
  101. https://support.microsoft.com/en-us/topic/microsoft-excel-security-enhancements-in-the-january-2022-update-kb5010321-6c925c6f-e5a0-4698-860d-2d75e70e970a
  102. https://support.microsoft.com/en-us/topic/january-7-2025-update-for-powerpoint-2016-kb5002632-14dc8b3a-b2ca-4ae7-b732-29f6760c4908
  103. https://www.tenable.com/blog/microsofts-january-2025-patch-tuesday-157-cves-cve-2025-21333-cve-2025-21334-cve-2025-21335
  104. https://learn.microsoft.com/en-us/deployedge/microsoft-edge-frequently-asked-questions
  105. https://help.autodesk.com/view/ACD/2025/ENU/?guid=GUID-8D74BAD2-B564-4C7C-A732-8AB0FC271155
  106. https://www.yohz.com/blogs/2017/04/23/exporting-images-from-ole-object-fields/
  107. https://www.ciodive.com/news/legacy-technology-technical-debt-costs-enterprise-data-AI/721885/
  108. https://endoflife.date/office
Add your contribution
Related Hubs
User Avatar
No comments yet.