
COM vs SOM: The Component Object Model and Some Other Model (1999) - DonHopkins
https://web.archive.org/web/19990127184653/http://www.develop.com/dbox/COM_vs_SOM_Summ.htm
======
pjmlp
COM is pretty much alive on the Windows world.

After winning the war against the Longhorn team, the Windows team picked up
their .NET ideas and reimplemented them in COM.

So since Windows Vista the large majority of new Windows APIs got implemented
as COM.

With the Windows 8 release, an improved COM was released as WinRT, which
basically picked up on the ideas of COM Runtime before it got redone as CLR.

After that we got UAP with 8.1 release, as the phone, tablet and desktop APIs
got a bit closer.

Then with Windows 10, we UWP as the whole set of APIs (IoT, phone, tablet,
desktop and XBox) got the same common base.

Every single Windows 10 release has been closing the distance between legacy
Win32 and modern UWP, bringing the models together and merging the sandbox
models (old style Win32 and UWP).

At BUILD 2019, Microsoft also announced that they will be rewriting React
Native for Windows on top of UWP.

Meanwhile C++/CX was deprecated, and thanks to the work lead by Kenny Kerr, it
got replaced by C++/WinRT, a C++17 compliant framework for doing UWP
programming on Windows (aka Modern COM).

BUILD 2019: "Meet C++/WinRT 2.0: Faster and smarter in the open"

[https://www.youtube.com/watch?v=X41j_gzSwOY](https://www.youtube.com/watch?v=X41j_gzSwOY)

------
davidpolberger
If you're looking for a gentle and free introduction to COM and a few other
component and object models, you could do worse than my thesis from 2009
(licensed under a Creative Commons license):

[http://www.polberger.se/components/read/](http://www.polberger.se/components/read/)

When Ericsson's cell phone business split into Ericsson Mobile Platforms (EMP)
and Sony Ericsson (SEMC) back in 2001, they created an object model named
Ericsson Component Model (ECM/OPA), which was heavily inspired by COM. The
intent was to create an API separating the lower-level Ericsson software from
the user-facing software developed by Sony Ericsson.

Sony Ericsson then expanded upon ECM, calling it ECM Extended (or ECMX, though
the technology was universally known as "IDL" internally). ECMX was supposed
to enable their aging software stack to be modularized by providing an object
model for code written in C.

For the future, though, they wanted to switch to writing application code in
Java. Back in these feature phone days, Java games were written to Sun
Microsystems's MIDlet specification. Sony Ericsson expanded upon that
specification and created the SEMClet specification for their internally-
developed applications. By writing software in Java and not C, Sony Ericsson
not only wanted to use a modern, garbage-collected language, they also wanted
to break free of their monolith. All native code was linked together
statically as this monolith, and this process could take hours. MIDlets and by
extension SEMClets could be installed dynamically, significantly streamlining
development.

ECMX was the technology used to enable SEMClets to communicate with native
code. If you're familiar with Mozilla and XPCOM, this may all sound very
familiar -- and you'd be right.

All this was back in 2005, when I did my thesis work as part of Sony
Ericsson's software architecture group. As part of that work, I had to figure
out what COM was, what it really meant for COM to be a binary standard (and
how that differed from the approach taken by CORBA) and how all that fit
together with the Java component model OSGi, .NET assemblies and ECM/ECMX. I
felt that I had to have a handle on all that history in order to write my
thesis.

None of this is very fashionable today, but I still think that there's a lot
we can learn from this era.

------
chaoticmass
Reading about COM really takes me back to my VisualBasic (classic) days. I was
an inexperienced teenager at the time, and I remember the excitement I'd get
when browsing through the different COM controls I could add to my projects,
picking some just to see what they did and trying to figure out how to use
them (pre-Google and mostly didn't have internet at home at the time).
Learning to make my own COM controls and distribute them was highly
instructional, if also maddening at times when trying to get the right version
of a .DLL registered and installed.

~~~
aitchnyu
I was 11, but I managed to make a HTML page which played Shrek trailer from
filesystem on loop (with audio of course) and mount that as wallpaper in
Windows 98. Frontpage, IIRC.

------
kazinator
> _Object enabling technology consisting of an simple yet elegant object model
> and a lightweight runtime support system sufficient for implementing
> language-independent objects on virtually any platform that supports dynamic
> linking._

I don't know about elegant, but circa 2001, I ported some COM objects to
Linux, including enough of the surrounding Win32 API's to make it work. I had
a fake registry based on text files, with CoCreateClass and all that junk
working. The shared libs continued to have a DllMain, and DllCanUnloadnow and
so on.

------
pjmlp
One thing from SOM that made me envy was that SOM had metaclasses, just like
Smalltalk, so it was possible to do some interesting designs.

COM Type libraries and now UWP metadata aren't really the same.

------
DonHopkins
This article comparing SOM and COM was written by Don Box. (first archived in
January 1999, but doesn't say when published):

The Component Object Model and Some Other Model: A comparison of technologies
revisited yet again:

[https://web.archive.org/web/19990127184653/http://www.develo...](https://web.archive.org/web/19990127184653/http://www.develop.com/dbox/COM_vs_SOM_Summ.htm)

[https://en.wikipedia.org/wiki/Component_Object_Model](https://en.wikipedia.org/wiki/Component_Object_Model)

It was in response to IBM's somewhat misleading article comparing their SOM
with Microsoft COM, last updated July 1994:

The System Object Model (SOM) and the Component Object Model (COM): A
comparison of technologies summarized

[https://web.archive.org/web/19990117055950/http://www.develo...](https://web.archive.org/web/19990117055950/http://www.developer.ibm.com/library/ref/SOM_vs_COM_Summ.html)

[https://en.wikipedia.org/wiki/IBM_System_Object_Model](https://en.wikipedia.org/wiki/IBM_System_Object_Model)

Don Box wrote an excellent in-depth book about COM: "Essential COM": "Nobody
explains COM better than Don Box" -Charlie Kindel, COM Guy, Microsoft
Corporation.

[https://en.wikipedia.org/wiki/Don_Box](https://en.wikipedia.org/wiki/Don_Box)

[https://archive.org/details/essentialcom00boxd](https://archive.org/details/essentialcom00boxd)

Unfortunately COM had the most un-googlable name possible (even before there
was a Google), so Microsoft renamed it ActiveX.

For more comtext, here are some notes I wrote about Win32, COM, OLE, OLE
Controls, and ActiveX in 1996:

[https://donhopkins.com/home/interval/pluggers/win32.html](https://donhopkins.com/home/interval/pluggers/win32.html)

[https://donhopkins.com/home/interval/pluggers/com.html](https://donhopkins.com/home/interval/pluggers/com.html)

[https://donhopkins.com/home/interval/pluggers/ole.html](https://donhopkins.com/home/interval/pluggers/ole.html)

[https://donhopkins.com/home/interval/pluggers/olecontrols.ht...](https://donhopkins.com/home/interval/pluggers/olecontrols.html)

[https://donhopkins.com/home/interval/pluggers/activex.html](https://donhopkins.com/home/interval/pluggers/activex.html)

Here's a synopsis of COM I wrote in response to "Can someone link to a
synopsis describing what "COM" is? It's hard to search for. (e.g. microsoft
com visual studio)":

[https://news.ycombinator.com/item?id=12975257](https://news.ycombinator.com/item?id=12975257)

Don't get me wrong: I'm not advocating everybody jump on the COM bandwagon! I
just think it's interesting and useful to know where it came from, how it
evolved, what different layers were built on top of it, and how it compared to
the alternatives at the time it was designed. And it's still pretty widely
used, and will probably never go away.

It certainly had a lot of problems and limitations, and
OLE/ActiveX/DCOM/DirectX/etc took it way too far, then Mozilla XP/COM cloned
it and also took it way too far (and then back again: see "decomification" and
"decomtamination"), but it really was a pretty elegant and successful solution
to the problems it was designed to address at the time.

[https://wiki.mozilla.org/Gecko:DeCOMtamination](https://wiki.mozilla.org/Gecko:DeCOMtamination)

[https://news.ycombinator.com/item?id=12968830](https://news.ycombinator.com/item?id=12968830)

[https://bugzilla.mozilla.org/buglist.cgi?query_format=specif...](https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=&content=decomify&comments=0&comments=1)

It's always good to study history to avoid repeating the mistakes of the past!

WebAssembly is going through a similar evolution, and might benefit from some
of the lessons of COM and SOM.

~~~
optimiz3
> Unfortunately COM had the most un-googlable name possible (even before there
> was a Google), so Microsoft renamed it ActiveX.

All ActiveX components are COM components, but the opposite is not true.

------
pvg
There's also a (deliberately provocative) bit Rob Pike wrote - "There has been
much talk about component architectures but only one true success: Unix pipes"

~~~
pjmlp
COM has been a success on Windows.

Plenty of companies live from selling ready made components to integrate into
Windows applications.

How many are making a business from selling UNIX pipes?

~~~
pcwalton
This is a silly framing, but I'll bite: All Chromium and Gecko browsers are
based on Unix pipes (and Windows named pipes) for IPC. Chrome and Firefox
together bring in billions of dollars of advertising revenue.

~~~
DonHopkins
Ironically, Firefox is also based on XP/COM (though less and less over time,
thanks to deCOMification and deCOMtamination).

~~~
pcwalton
Right. Note that at the time Gecko was initially developed, it wasn't at all
clear that JS would win. Having to support VBScript in addition to JS was a
very real possibility. So COM made a certain amount of sense as a way to
expose Web APIs to multiple languages simultaneously.

Thankfully, the Web avoided VBScript, and later Dart.

~~~
pjmlp
Given market share of Chrome, WebAssembly and Flutter, you should hold on to
that "thankfully".

Also from BUILD React Native talks regarding React Native vs Electron
performance on Windows, I wouldn't be surprised if VSCode eventually moves
away from Electron into React Native.

~~~
pcwalton
> Given market share of Chrome, WebAssembly and Flutter, you should hold on to
> that "thankfully".

WebAssembly doesn't need COM because it's integrated into the JS engine and
uses the same JS engine bindings.

I don't think anyone, even Googlers, seriously thinks that native Dart is
going to make it onto the Web at this point.

~~~
pjmlp
Chrome never used COM as part of its implementation.

My reply had nothing to do with it.

Naturally from Mozilla's employee point of view it is easier to ignore what I
actually meant.

------
DonHopkins
"First there were VBXs. Then there were OCXs. Then, Microsoft wanted us to
call them OLE Custom Controls, but we persisted in calling them OCXs. So they
must have figured that we wouldn't accept any control technology that didn't
have a name ending in X." -Curt Hagenlocher

