
Staring into the COM Abyss - todsacerdoti
https://cmpct.info/~calvin/Articles/COMAbyss/
======
x87678r
20 years ago I knew COM inside out and it was great, it was really powerful
way to integrate your own code with the big applications Excel, ASP, IE. Its a
great way to do SOLID programming long before it became fashionable. It also
did things like let you build components in a single threaded language and use
from a multi thread process - stuff people still can't do today.

I know MS technology was never popular in SV, but people never even looked at
it, which to me is weird when developers spend a lot of time investigating
other languages and frameworks.

Anyway its mostly dead now I guess, except for these random archaeological
digs.

~~~
marcus_holmes
Same. I miss how awesome COM was too.

DCOM was a couple of orders of magnitude more fiddly to get working. But
amazing once it worked. Create an object on another server, call its methods,
side effects happen on that server, results are returned to your process.

When I was learning Go the similarity between COM interfaces and Go interfaces
really helped me grok them quicker.

~~~
cesarb
DCOM was also amazing, in how much surface area it exposed to the network.
Random COM objects which were never intended to be called remotely, and were
poorly secured, could be exposed by accident.

So in the infamous Windows XP SP2 (not a major release of the operating
system, but a mere service pack), DCOM got locked down hard. If you have a
legitimate use for DCOM (like an OPC-DA server), you have to toggle several
obscure settings to make it work again (see [https://www-
bd.fnal.gov/controls/opc/Using_OPC_via_DCOM_with...](https://www-
bd.fnal.gov/controls/opc/Using_OPC_via_DCOM_with_XP_SP2_v1.10.pdf) for a
fourteen-page tutorial).

~~~
marcus_holmes
yeah, MS had a hard time with security around then. Lots of stuff that was
open had to be locked down.

------
pjc50
> We can cast it to an IWebBrowser (a remnant of when Internet Explorer and
> Windows Explorer were welded together)

Aargh. For a while I maintained an app which embedded IE (technically
"IHTMLDocument2") on Windows CE, which meant dealing with a lot of this
madness. It spawned all kinds of background threads and didn't take kindly to
being interrupted, and control over it was limited - ended up drawing a window
over its control bar and passing clicks through ourselves.

He mentions "the cultural defeat of Microsoft", which is absolutely right;
developers no longer _choose_ the Windows platform, they are only ever forced
to by circumstance, and have developed tools like Electron which allow them to
ignore the platform entirely.

For whatever reason, the "developer community" of Microsoft was very weak, at
least post-dotcom era. You couldn't find many people talking about it openly
to learn from. And only recently have they responded to that, especially with
Roslyn and the buyout of Github.

[https://www.devever.net/~hl/windowsdefeat](https://www.devever.net/~hl/windowsdefeat)

~~~
biggestdecision
I think a main reason Microsoft lost their development community is because
they charged for access to Visual studio (which is the gateway to the entire
ecosystem). People didn't talk about it openly, because no one was building
for the microsoft platform outside of work.

Meanwhile a whole community of competing free alternatives appeared - students
learnt Java and Python because C# was a paid product that was also not cross
platform.

~~~
addicted
Visual Studio was/is super expensive and also necessary for MS development.

With .Net core you can get by with never touching VS. But that wasn’t always
the case.

I also don’t believe MS had a free livense of Visual Studio like they do now.

~~~
pjmlp
That free license was called Express, was available per language variant, so
you needed on VS Express install per workload and exists since around 2005,
until Community made its appearance.

Also the Windows SDK was always available for free, just you needed to get a C
compiler yourself.

~~~
mschaef
> Also the Windows SDK was always available for free, just you needed to get a
> C compiler yourself.

Not quite _always_... For the first few versions of Windows, the SDK was a
fairly expensive separate product you had to buy in addition to the compilers
itself. I'm pretty sure it was MS C/C++ 7 that was first available bundled
with the SDK. IIRC, the product was $700-800 (in 1990 money), took a couple
feet of shelf space, and shipped with seven or eight thousand pages of
documentation.

Visual C++ (really MS C/C++ _8_) democratized it a bunch by shipping with the
libraries/tools needed to develop for Windows and offering a basic product at
a <$200 price point. That was also the first version of Microsoft C that
shipped with a Windows-based debugging UI.

The early 90's also saw the introduction of MSDN - the Microsoft Developer
Network. At the time, this was a subscription CD based library of essentially
all of Microsoft's developer documentation (as well as a few tools, etc.) It
was essential... and to put the timeline in perspective, Microsoft sold a
version of MSDN that was bundled with a CD-ROM drive, since they were as
uncommon as they were at the time. They quickly added a premium version of
MSDN that got you the full tooling also.

Ten or fifteen years after all that, the full version of Visual Studio was a
$10k/seat proposition. Between that and all of the API churn, they lost sight
of their original goal of staying developer friendly, and it was to their
deteriment. (Particularly given the concurrent ascendence of the Web, OS X,
Mobile, Linux, and the like.)

~~~
teh_klev
> subscription CD based library

Back in the 90's I used to be the custodian and curator of our great big box
of MSDN CD's ensuring that updates and replacements were properly seen to. Oh
the memories :)

In fairness you didn't just get the development tools, you also got copies of
just about every MS server and office product on what were fairly generous
developer licenses. Many of these things didn't even require phoning home for
"activation" and MS turned a blind eye to partners sharing one copy amongst
10-15 devs; after all the real money was where the fruit of our efforts would
be deployed, stuff running in banks and other corporates paying serious coin
for server licenses and direct support. Ultimately all this stuff was about
capturing developers mindsets with a view to selling production licenses.

~~~
mschaef
> In fairness you didn't just get the development tools, you also got copies
> of just about every MS server and office product on what were fairly
> generous developer licenses.

It didn't start out that way... they added a premium level later, and that was
the version that included all the free tooling. I still have volumes 3 and 5
(April 1993 and Fall 1993), and it's a single CD product that was mostly
focused on just the documentation. (This is actually how I got my first CD-ROM
drive... IIRC, the whole package, a one year subscription and a proprietary
interface CD-ROM was $400).

------
xg15
I remember stumbling over shell and namespace extensions (without knowing the
names of those concepts) back when I was coding in VB in high school - and
being impressed how deep programs were apparently able to integrate into "the
OS". (Nevermind that it was just the shell).

So it's really amazing to see giving step-by-step examples of how a namespace
extension could be implemented.

I remember in particular that MS Outlook implemented their desktop icon as a
namespace extension instead of an ordinary shortcut. I never understand why it
was done this way, as the icon didn't behave particularly different than a
normal shortcut: The only practical differences were that it did not allow you
to look up the exe path and that you could not remove it from the desktop
short of uninstalling Outlook.

I wonder if this was done purely for nerd cred in much the same manner as the
author of the OP - or if some overzealous manager had an irrational fear of
users deleting the "Outlook" icon and ordered their team to do anything in
their power prevent that...

~~~
derefr
> and being impressed how deep programs were apparently able to integrate into
> "the OS". (Nevermind that it was just the shell).

I’ve always been annoyed that all the major OSes have all this GUI-shell-level
virtual folders and namespaces stuff, but none of them bother to “push it
down” such that it’s accessible by the command-line, or better, by syscalls.

I feel it would have made a lot of sense to do this in Windows: just replace
“shell” objects with NT kernel objects, and allow the writing of (userland)
NT-kernel-object-namespace extensions. Like FUSE, but without the filesystem
part.

~~~
ComputerGuru
The whole point is the decoupling of userland from the kernel. Windows doesn’t
really have syscalls in the Linux sense, but has an even more stable interface
in the various core dlls (kernel32, user32, shell32, etc) (and of course the
Nt* “syscalls” for speaking with the kernel directly).

COM was always the real api for interacting with the desktop
environment/shell, even from cli applications. The problem is that COM is
strictly object oriented (unlike the user32 api and co) but both C and C++
used the same bindings to interface with it, which were written at the lowest
common denominator giving us C++ com wrappers were ugly as hell when they
could have been so much nicer. Microsoft finally fixed that in the past couple
of years with the new winrt api for C++ but the world would have been
different if such COM bindings for C++ had existed twenty years ago.

~~~
pjmlp
They exist, when you use alternatives like C++ Builder.

C++/CX was the closer that they got to it, and it remains to be seen how much
complains are they willing to keep taking until C++/WinRT matches C++/CX
tooling.

And I fully agree with you, C++ Builder and also Delphi have proven that such
bindings were already possible 20 years ago, but for whatever reason there are
some key devs (or management) at Microsoft that keeps pushing back for such
productivity and brings out stuff like ATL/WRL instead.

I like COM/UWP, but boy some of the decisions just don't make sense.

------
tragomaskhalos
A common pattern for COM projects, in my experience, was a VB front end
talking to a C++ back end. This was usually a pretty brutal experience TBH,
even with ATL, because there were many fiddly details that intruded,
specifically:

\- reference counting

\- string incompatibilities, exacerbated by the tendency of every man and his
dog at Microsoft with an internet audience writing their own COM string class
for C++ and publishing it; IIRC BSTR, _bstr_t, CCOMBStr but there were surely
others, none of which really succeeded in bridging the very large gap that
exists between what COM things a string should look like (length encoded at
the front, two bytes per char) and the C / C++ view.

~~~
sclangdon
I'm currently working on a VB6 front-end (I say front end, but it 450,000
lines so probably a bit more to it!) with C++ back-end (and it's old C++ that
uses MFC containers instead of std). We also have a lot of C# extras that are
called from the VB6 and also consume the C++ stuff.

Oh, and there is Python scripting in there somewhere too.

Ungh.

------
non-entity
Not a lot of software really feels like "magic" to me anymore, which is
unfortunate, but system programming on Windows often still feels like some
arcane art.

~~~
parasight
I was a junior back then but COM felt like magic to me. I think MS made COM
more arcane than necessary. It was not until I read the book Essential COM by
Don Box that I understood COM.

~~~
PaulHoule
"Essential COM" is one of the top computer books ever written and I'd
recommend it to anyone who is interested in object systems even if they don't
code for Windows. (e.g. I think better than "The Art of the MetaObject
Protocol")

~~~
teh_klev
I have my copy from before the days when they tarted it up to add to the
Developmentor series. I kinda miss Don Box doing his thing, quite an
entertaining showman (who remembers Box sitting in a bath on stage talking
about SOAP?) and tremendous technical writer.

------
taylodl
This takes me back! I was a COM expert in the late 90's/early aughts. It was
important technology to master for building desktop applications for Windows.

Nowadays we don't typically build desktop applications and even when we do we
typically employ cross-platform technologies. So COM has pretty much fallen by
the wayside - which isn't a bad thing! We've moved on.

~~~
mattgreenrocks
The idea of an app being a graph of polyglot components lives on, however, in
the guise of microservices. The good part is you _know_ everything exists out
of process and you don't have to worry about things like COM's threading
apartment. The bad thing is, of course, everything is out of process.

Everything old is new again.

------
barrkel
> _The real sad part is for things like this, because the documentation is so
> lacking /missing, is that you may run into issues where not even Stack
> Overflow can help you._

This is how we used to write code, back in the day. If you had a particularly
hard time and experimentation wasn't working well, you traced through the
disassembly in the debugger.

------
Traubenfuchs
One can use SharpShell for this to do it in C#. Development and deployment
remain unwieldy though.

[https://github.com/dwmkerr/sharpshell/issues/197](https://github.com/dwmkerr/sharpshell/issues/197)

~~~
ygra
I thought shell extensions in managed code were pretty much a no-go. [0]

Has that changed by now?

[0]
[https://devblogs.microsoft.com/oldnewthing/20061218-01/?p=28...](https://devblogs.microsoft.com/oldnewthing/20061218-01/?p=28693)

~~~
hyperrail
This is Microsoft's most recent advice about in-process Explorer shell
extensions: [https://docs.microsoft.com/previous-
versions/windows/desktop...](https://docs.microsoft.com/previous-
versions/windows/desktop/legacy/dd758089\(v=vs.85\))

The advice is still "don't use .NET managed code for your in-proc shell
extension", but the given reasons are not necessarily specific to the .NET
runtime:

1\. The .NET framework CLR takes too long to load for an extension that could
be loaded by any app that pops up shell UIs.

2\. There are seams between .NET and COM even with interop. These seams open
traps for you because the COM-era shell APIs (Windows 95 to Windows 7) were
designed for people who write their shell extensions in C++ and so can deal
with all the tricky details of COM.

~~~
ComputerGuru
Point 1 was temporarily obviated by .NET Native, but that has now been
abandoned with no explicit replacement, leaving a hole only somewhat filled by
a combination of Mono and CoreRT.

~~~
WorldMaker
The explicit replacement was CoreRT. It's built in to the options of the
dotnet CLI tool as of .NET 5, and supposed to get more complete as the Mono
merger finishes early in .NET 6.

------
growlist
A good while back Esri rearchitected their whole software suite into a COM
based technology known as ArcObjects, with the aim of providing developers a
single environment in which to code across all Esri SDKs. I remember a couple
of things about it: firstly it was reputedly the largest COM library in
existence, and secondly it was so horrendous that hardly anyone used it.

Don't even get me started on the Java wrappers for ArcObjects... Thank god
things have moved on.

