COM is essentially a formal way of using C++ vtables [1] from C and other languages, so you can create and consume components in any language, and call back and forth between them. It's a way of expressing a rational subset of how C++ classes work and format in memory, in a way that can be implemented in other languages.
It was the outcome of the C / C++ / Visual Basic language wars at Microsoft.
The original 16 bit version of Visual Basic version 1 through 3 had a plug-in extension mechanism called VBX -- Visual Basic Extensions [2].
They were extremely popular and became a victim of their own success, after a whole industry grew up around them, and people started using them for all kinds of things they weren't intended for, and wanted to use them from other languages and frameworks like Borland. Microsoft had to do something about that to mitigate the success disaster of VBX, so they invented COM.
At the time, Microsoft was transitioning from Win16 to Win32, so they came up with the 32 bit COM definition, also known as OCX's, or OLE Controls, which they later called ActiveX, because COM was so hard to search for, and they wanted to take the spotlight away from Java with a new buzzword.
So they brewed up a bunch of ugly C macrology that enabled C programmers (or Visual Studio wizards) to define COM interfaces in header and implementation files that just happened to lay out memory in the exact same way as vtables of C++ pure virtual classes.
While C++ programs would use other ugly macros to declare actual honest-for-god C++ classes to implement COM interfaces.
And Visual Basic programmers would ... do whatever it was that Visual Basic programmers did.
COM's IUnknown::QueryInterface [4] method is essentially like C++'s dynamic_cast [5]. But it also adds some object aggregation features [6] that let you compose multiple sub-objects together by aggregation instead of using monolithic inheritance. You could implement "tear off interfaces" [7] that lazily create aggregated sub-objects on demand, useful for implementing callback interfaces.
MFC (Microsoft Foundation Classes) is a set of C++ wrappers around the lower level Win32 interfaces, plus a huge framework for implementing GUI widgets and dialogs on top of Win32, and for wrapping rube-goldbergesque OLE Automation interfaces around C++ classes. For some time MFC was the primary way of implementing COM interfaces in C++, but it was infamous for being horribly complex, with all its ugly macros, Hungarian notation, and bizarre programming conventions.
Later on Microsoft came out with the C++-only ActiveX Template Library (ATL) [8], which, although it was still necessarily quite ugly, was a more elegant and powerful way of implementing COM components in C++, didn't have the baggage of supporting C, and let you implement COM/OLE/ActiveX components without the hideous MFC framework. ATL was popular for implementing all kinds of Internet Explorer plug-ins.
OLE was actually a layer of COM interfaces and MIDL (Microsoft Interface Definition Language) on top of COM, which adds the IDispatch interface for dynamically querying and invoking methods and properties at runtime, and variant types [9]: tagged unions for representing polymorphic data (i.e. VB data types) and passing parameters to OLE IDispatch functions.
OLE was the glue necessary for integrating COM components into the Visual Basic runtime, so it directly supported Visual Basic data types, calling conventions and semantics like indexed properties.
OLE also provided an interface definition language (ILD) you could compile into binary type libraries, use to generate boilerplate C and C++ interfaces, and OLE also had COM interfaces and structures for providing those type libraries at runtime. It also had a lot of persistence, runtime reflection, and user-interface related stuff for plugging components and dialogs together in windows, providing property sheets, editing and configuring controls, etc.
MIDL supported defining components with "dual interfaces" [10]: both an OLE IDispatch interfaces taking variant type parameters, and also more efficient lower level COM interface taking primitive types. Runtimes like Visual Basic knew how to integrate dual interfaces and could bind to the more efficient underlying COM interfaces, instead of going through the slower generic dynamic IDispatch interfaces.
IDL also described the intricacies of DCOM [11] interfaces (for in-process and networked remote procedure calls), parameter marshalling [12], and all kinds of other bizarre stuff. DCOM is where COM went off the deep end.
At its core, COM was essentially a very simple and ingenious idea that elegantly solved some real world problems, but it eventually evolved into something extremely complex that attempted to solve many other unrelated problems, and which required a massive amount of tooling, and that depended on Microsoft's Visual Studio and Win32 environment.
Microsoft actually ported ActiveX to the Mac using ATL and Metrowerks Code Warrior, in order to implement Microsoft Internet Explorer for Mac [13] (which was actually the best web browser on the Mac at the time, by far). But not a lot of third parties (except for me and a few other crazy people) ever used ActiveX on the Mac.
However it did become quite fashionable for other organizations to create portable COM knock-offs to solve some (hopefully fewer) of the same problems, but which were incompatible with Microsoft's tooling and COM itself (which kind of missed the main points of COM, but hey).
For example, Macromedia came up with MOA (Macromedia Open Architecture) [13], their COM-like plug-in extension mechanism for Director and other products.
And Mozilla came up with XP/COM [14], for implementing components in Mozilla/Firefox/XULRunner/etc, enabling programmers to implement and consume XP/COM components in C++ or JavaScript. Of course it has its own IDL and tooling, and suffers from many of the same problems that COM did.
Mozilla didn't go nearly as far down the rabbit hole as Microsoft did, and later backtracked in their valiant "deCOMification" aka "deCOMtamination" and "outparamdelling" efforts [15].
At this point in history, I think it's best to skip the "component technology" middleman and integrate extensions directly into the JavaScript engine itself. Which brings us back to the sub-topic of VSCode!
Thanks! By essentially I did mean actually, or literally (in the literal sense (in the literal sense (in the literal sense ...))). ;) http://www.thesaurus.com/browse/essentially
COM is essentially a formal way of using C++ vtables [1] from C and other languages, so you can create and consume components in any language, and call back and forth between them. It's a way of expressing a rational subset of how C++ classes work and format in memory, in a way that can be implemented in other languages.
It was the outcome of the C / C++ / Visual Basic language wars at Microsoft.
The original 16 bit version of Visual Basic version 1 through 3 had a plug-in extension mechanism called VBX -- Visual Basic Extensions [2].
They were extremely popular and became a victim of their own success, after a whole industry grew up around them, and people started using them for all kinds of things they weren't intended for, and wanted to use them from other languages and frameworks like Borland. Microsoft had to do something about that to mitigate the success disaster of VBX, so they invented COM.
At the time, Microsoft was transitioning from Win16 to Win32, so they came up with the 32 bit COM definition, also known as OCX's, or OLE Controls, which they later called ActiveX, because COM was so hard to search for, and they wanted to take the spotlight away from Java with a new buzzword.
So they brewed up a bunch of ugly C macrology that enabled C programmers (or Visual Studio wizards) to define COM interfaces in header and implementation files that just happened to lay out memory in the exact same way as vtables of C++ pure virtual classes.
While C++ programs would use other ugly macros to declare actual honest-for-god C++ classes to implement COM interfaces.
And Visual Basic programmers would ... do whatever it was that Visual Basic programmers did.
COM's IUnknown::QueryInterface [4] method is essentially like C++'s dynamic_cast [5]. But it also adds some object aggregation features [6] that let you compose multiple sub-objects together by aggregation instead of using monolithic inheritance. You could implement "tear off interfaces" [7] that lazily create aggregated sub-objects on demand, useful for implementing callback interfaces.
MFC (Microsoft Foundation Classes) is a set of C++ wrappers around the lower level Win32 interfaces, plus a huge framework for implementing GUI widgets and dialogs on top of Win32, and for wrapping rube-goldbergesque OLE Automation interfaces around C++ classes. For some time MFC was the primary way of implementing COM interfaces in C++, but it was infamous for being horribly complex, with all its ugly macros, Hungarian notation, and bizarre programming conventions.
Later on Microsoft came out with the C++-only ActiveX Template Library (ATL) [8], which, although it was still necessarily quite ugly, was a more elegant and powerful way of implementing COM components in C++, didn't have the baggage of supporting C, and let you implement COM/OLE/ActiveX components without the hideous MFC framework. ATL was popular for implementing all kinds of Internet Explorer plug-ins.
OLE was actually a layer of COM interfaces and MIDL (Microsoft Interface Definition Language) on top of COM, which adds the IDispatch interface for dynamically querying and invoking methods and properties at runtime, and variant types [9]: tagged unions for representing polymorphic data (i.e. VB data types) and passing parameters to OLE IDispatch functions.
OLE was the glue necessary for integrating COM components into the Visual Basic runtime, so it directly supported Visual Basic data types, calling conventions and semantics like indexed properties.
OLE also provided an interface definition language (ILD) you could compile into binary type libraries, use to generate boilerplate C and C++ interfaces, and OLE also had COM interfaces and structures for providing those type libraries at runtime. It also had a lot of persistence, runtime reflection, and user-interface related stuff for plugging components and dialogs together in windows, providing property sheets, editing and configuring controls, etc.
MIDL supported defining components with "dual interfaces" [10]: both an OLE IDispatch interfaces taking variant type parameters, and also more efficient lower level COM interface taking primitive types. Runtimes like Visual Basic knew how to integrate dual interfaces and could bind to the more efficient underlying COM interfaces, instead of going through the slower generic dynamic IDispatch interfaces.
IDL also described the intricacies of DCOM [11] interfaces (for in-process and networked remote procedure calls), parameter marshalling [12], and all kinds of other bizarre stuff. DCOM is where COM went off the deep end.
At its core, COM was essentially a very simple and ingenious idea that elegantly solved some real world problems, but it eventually evolved into something extremely complex that attempted to solve many other unrelated problems, and which required a massive amount of tooling, and that depended on Microsoft's Visual Studio and Win32 environment.
Microsoft actually ported ActiveX to the Mac using ATL and Metrowerks Code Warrior, in order to implement Microsoft Internet Explorer for Mac [13] (which was actually the best web browser on the Mac at the time, by far). But not a lot of third parties (except for me and a few other crazy people) ever used ActiveX on the Mac.
However it did become quite fashionable for other organizations to create portable COM knock-offs to solve some (hopefully fewer) of the same problems, but which were incompatible with Microsoft's tooling and COM itself (which kind of missed the main points of COM, but hey).
For example, Macromedia came up with MOA (Macromedia Open Architecture) [13], their COM-like plug-in extension mechanism for Director and other products.
And Mozilla came up with XP/COM [14], for implementing components in Mozilla/Firefox/XULRunner/etc, enabling programmers to implement and consume XP/COM components in C++ or JavaScript. Of course it has its own IDL and tooling, and suffers from many of the same problems that COM did.
Mozilla didn't go nearly as far down the rabbit hole as Microsoft did, and later backtracked in their valiant "deCOMification" aka "deCOMtamination" and "outparamdelling" efforts [15].
At this point in history, I think it's best to skip the "component technology" middleman and integrate extensions directly into the JavaScript engine itself. Which brings us back to the sub-topic of VSCode!
[1] Virtual Method Table: https://en.wikipedia.org/wiki/Virtual_method_table
[2] VBX: https://en.wikipedia.org/wiki/Visual_Basic_Extension
[3] Variant Type: https://en.wikipedia.org/wiki/Variant_type
[4] IUnknown::QueryInterface: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
[5] dynamic_cast: https://msdn.microsoft.com/en-us/library/windows/desktop/ff4...
[6] Aggregation: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
[7] Tear Off Interface: http://www.codeguru.com/cpp/com-tech/atl/performance/article...
[8] ActiveX Template Library: http://www.drdobbs.com/windows/the-activex-template-library/...
[9] Variant Types: https://en.wikipedia.org/wiki/Variant_type
[11] Distributed COM: https://en.wikipedia.org/wiki/Distributed_Component_Object_M...
[12] Marshalling: https://en.wikipedia.org/wiki/Marshalling_(computer_science)
[13] Macromedia Open Architecture (MOA): https://www.adobe.com/support/xtras/info/moa.html
[14] XP/COM: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM
[15] deCOMtamination: https://wiki.mozilla.org/Gecko:DeCOMtamination http://taras.glek.net/blog/categories/decomtamination/ https://blog.mozilla.org/tglek/category/decomtamination/