What is the difference between COM and OLE?

Question

What is the difference between COM and OLE, if any?

Rabat

Answer 1

• OLE = Object Linking and Embedding
• DDE = Dynamic Data Exchange
• COM = Component Object Model

OLE: This is a method of linking parts of one document to parts of another. For example, having a PowerPoint slide with an Excel chart embedded into it. When the Excel spreadsheet is updated, the chart should update too. When you reopen PowerPoint, magically it has! (This example is a linked object.) Embedded objects are the same only the Excel spreadsheet doesn't exist in an external file, the data for the spreadsheet is contained within the PowerPoint file.

You can embed Excel, Word and PowerPoint documents into each other with linked objects. Other applications were written specifically to support being embedded into Word, such as Microsoft Equation Editor.

OLE 1 was built on DDE, which used window messages to notify applications when source data changed, and typically passed data around by using HGLOBAL global memory handles.

OLE 2 was built on COM.

COM is an language neutral, object-oriented component model and ABI based on DCE RPC. As an RPC system it supported remote calls between processes on the same machine, and later, with DCOM, on different machines. Initially COM was used as part of the architecture of MAPI (which uses the COM object model but not the COM registration services) before being formally launched on its own as a general object model complete with registry and object activation and other services. (Monikers and structured storage for example.)

OLE Automation has nothing to do with OLE - it's a branding connection only. OLE Automation is a Visual Basic-compatible subset of COM which supports basic datatypes only (for example no unsigned integers or structs) but including objects (COM interfaces).

OLE Controls however ARE related to OLE. They are visual components primarily targeted at Visual Basic users from VB 4 onwards, but the visual elements are provided using the embedding facilities of OLE 2. They can also be hosted (in theory, if properly written) by anything capable of hosting an OLE 2 embedded object, and were often used in C++ applications too. They typically use OLE Automation compatible interfaces for programming at runtime.

ActiveX control is a marketing term for COM objects, from the time when Microsoft were attempting to popularise the technology for extending web applications.

Prescience

"OLE Automation has nothing to do with OLE" - :( thanks Microsoft – Schroder

Answer 2

COM is OLE evolved. OLE was a set of interfaces and data storage mechanisms to facilitate sharing data between applications. COM was the natural extension of using interfaces not only to share data, but runtime functionality - where the data was fronted by actual mechanisms to facilitate use. I've always pictured it roughly as the difference between C and C++, where with C, you can share header files and structures, and with C++ you share encapsulated objects.

As a bit of a soapbox, I still miss OLE Structured Storage, since there is something nice about sharing opaque data storage between collaborating systems. Seeing as drag-and-drop/clipboard still depends on it, I wonder what the .Net replacement will be?

Abaxial

OLE is not COM evolved. Ole 1 pre-dates COM. OLE2 is built on COM however. OLE structured storage still exists and always will, and you can use it from .Net if you want to. Note that a lot of the design motivation for OLE structured storage versus something like ZIP was to allow in-place modification of on-disk data structures. That has largely gone away with the end of floppy disks and slow HDs. – Prescience

"Ole 1 pre-dates COM. OLE2 is built on COM however." Yea... kind of like it evolved. The idea of using interfaces between interacting data, and then data + behavior came from OLE and was the germ of COM. – Abaxial

@Prescience - You reversed the order of COM and OLE in your quote from what the answer actually says. – Shaker

@MartinSmith, Yes, a typo. – Prescience

@Prescience I repeated the typo since it appears you were confused about what I was saying in the answer. If you weren't then how can you not see that COM interfaces came from the imperative to drive OLE2's embedding to the next step of componentized software? – Abaxial

@codekaizen, unfortunately your answer is just wrong! What can I say more? I wish it wasn't! – Prescience

@Prescience - A quick google search leads me to Wikipedia which has the same claim: "OLE 1.0 later evolved to become an architecture for software components known as the Component Object Model (COM), and later DCOM." – Abaxial

@codekaizen, Did Wikipedia give a citation for that claim? No. Still, I guess you could edit it to give your answer here as the citation, then use Wikipedia to support your answer here... isn't that how Wikipedia works? :-) – Prescience

@Prescience - it does, but fortunately the article history preserves changes. The very oldest version of the page from 2002 supports the idea that it evolved: en.wikipedia.org/w/…. I think perhaps you're missing some significant usage of OLE beyond just structured storage back in early Office days which made COM become the obvious next step. – Abaxial

Obvious next step != evolved. COM is the building material, OLE is the structure built with it. DDE = Wood planks. OLE 1 = A wooden shed. COM = Bricks. OLE 2 = brick house. But bricks are not sheds evolved. OLE2 is OLE1 evolved but bricks are not wood evolved. – Prescience

While it doesn't necessarily need to, the germ of COM was started due to understanding the needs of OLE. The term 'Object' here was just becoming widely understood to MS devs to mean state and behavior, and while OLE 1.0 had the state part down, the need to embed functionality inside a host program made it clear that structured interfaces were needed, too. To me, this is evolution of thought. This is my point. – Abaxial

Answer 3

The OLE technology predates COM as a separate entity by a significant amount of time. Before that, OLE was implemented as a way of Embedding and Linking Objects. The classic example is that of embedding a spreadsheet within a word document. The underlying technology of COM was enabled so that other languages such as VB could interact with those objects as well.

Then, historically, we had a lot of server type programmers which were looking on these cool things like language independence, reference counting and threading models with envy, but really didn't care too much about the embedding technology at all. The logical thing to do was to split out the underlying server functionality as COM - this was a more naturally low-level API.

Both technologies still exist. OLE is kind of linked up with or may be the same as ActiveX these days.

Flaxseed