Fog Creek Software
Discussion Board

I am nostalgic about the fuss over COM

I remember that sometime in the late late 90's when MS first started all this fuss about COM. COM was potrayed to be the final nirvana. An institute even sprung up to teach COM charging exorbitant fees. The founders quickly made  a lot of money and the institute went bankrupt. They cheated a lot of people who had paid their fees.

4-5 years later it has been given a quiet burial even without teaching full maturity. By "full maturity", i mean a technology that can be used, provably without fuss and pain. COM was always a pain. Millions of vendors, different development languages and unending hell. Same with ActiveX. I remember the hell i got when something worked with one version of excel and not another. Never figured out. Never did know how to figure out.

Joel is right. MS needs incremental changes. avalon could easily have been a bunch of DLL's.

Wednesday, June 23, 2004

.NET is a layer above COM. If you consider how events, collections, enumerators, etc. worked in COM, they've only been simplified in .NET, supplemented with a language which is a clone of C++ with garbage collection and built-in COM supporting constructs (properties, events, foreach).

Ofcourse we have an entire class library over it.

Green Pajamas
Wednesday, June 23, 2004

".NET is a layer above COM"

No, it's not. .NET is a combination of native code, interop with Win32, and interop with COM. It's not just "a layer above COM". There are tons of things in the Win32 API that have never, and probably will never, be exposed as COM objects.

Brad Wilson (
Wednesday, June 23, 2004

Microsoft is starting to make the Unix stack look pretty good.

Microsoft seems to be more than slightly skizophrenic.  "Were a desktop driven company."  "Shut up."  "Were an enterprise software company with the best servers."  "Get out, we make the best game consoles." 

As a sysadmin, I've always disliked how MS moved the management tools around or changed the names and or slight functional changes from release to release.  OTOH if you learned Unix 10 years ago, you are 90% up to speed today.

Software Assurance
Wednesday, June 23, 2004

I still have absolutely no idea what COM even stands for, much less what it is.  Some sort of framework, I've gathered that much.

muppet is now from
Wednesday, June 23, 2004

COM stands for Crappy Object Model.  If you don't know COM by now, don't bother learning. Learn .NET and WinForms instead.  Actually if you're a slow learner you might want to skip WinForms and just start learning Longhorn Avalon now.  Because by the time you learn WinForms it will be obsolete.

Wednesday, June 23, 2004

Right now I'm learning Swing, but also dabbling in C# so I suppose that means learning WinForms.  As I understand, WinForms is still supposed to work in Longhorn, so it seems that learning Avalon now is a somewhat pointless exercise (unless I had already learned the intermediate technologies, which I haven't).

muppet is now from
Wednesday, June 23, 2004

"I still have absolutely no idea what COM even stands for, much less what it is.  Some sort of framework, I've gathered that much."

Common Object Model. It is actually an extension on C++ to dynamically load objects. There is also a technology called DCOM that is distributed.

I would say it is a CORBA embrace and extend with Win specific stuff. The extend was in-proc objects IIRC.

Wednesday, June 23, 2004

In other words, waaaaaaaay before my time as a developer.  ;-)

muppet is now from
Wednesday, June 23, 2004

".NET is a layer above COM." should have been ".NET is a step above COM."

I don't know what I was thinking at that time. :)

Green Pajamas
Wednesday, June 23, 2004

COM is a simple, highly efficient (dramatically more efficient than .NET remoting), elegant method of IPC across process and machine boundaries, as well as for in-proc objects.

The problem with COM was one that it was mish-mashed in with a lot of tentacle technologies (like .NET really), leading to a confused public. Furthermore I've never seen a half-decent bit of documentation on COM, and even expert COM programmers (with glasses and beards) often didn't know what was going on, or worse where to look for concise documentation. "So I'm marshalling this out-of-proc punk from my MTA through DCOM to a STA component runing in dllhost....".

Dennis Forbes
Wednesday, June 23, 2004

"expert COM programmers (with glasses and beards)"

Damn, now I see why I never mastered it - I have neither!

Wednesday, June 23, 2004

I always hated the term "apartment threading."  It means nothing.  I think what it means is calls are serialized through an event loop, but I'm not sure.  I hate it when people pretend to understand what apartment threading is.  If you can't explain it in clear, well understood, computer science terms, you don't understand it, and nobody does that.

I've written one production COM object for use with ASP.  Yea that old one that used that crappy VBScript.  The only thing I cared about was how to turn off their thread safety.  If you use the single threaded model then I hope you didn't have high performance requirements as all calls to your object are serialized. 

COM the idea wasn't bad.  Interface aggregation is the way to go.  COM the implementation and documentation and marketing FUD that I could never understand is what sucked. 

christopher baus (
Wednesday, June 23, 2004

BTW that isn't to say my COM object wasn't thread safe.  It was, or is I should say.  I just implemented thread safety myself using good ole WaitFor*Objects and EnterCriticialSection and the like. 

That reminds of a day I almost totally lost it and was ready to quit as a software engineer.  I was stress testing the said COM object in debug mode with ATL logging on.  I kept getting failures that looked a lot like a race condition.  I went through every line of code trying to figure out what the problem was.  I had other engineers look at it.  It drove me nuts.  Then I found out it is was bug in ATL.  I almost totally lost it.  I felt like a beta tester for Microsoft.  Finding bugs in Microsoft code drives me nuts for some reason.  Unfortunately I find them all the time.

christopher baus (
Wednesday, June 23, 2004

When I first looked at COM it was all "we made this completely object oriented-ish, except VB can't handle that so we added IDispatch to make it messier." and I though "this is stupid" and never looked at it again, except for the occasional Excel automation.  I pretty much think of COM as "how you do VBA" and that's that.  Sort of like someone looked at C++ and said "that's too easy."

Keith Wright
Wednesday, June 23, 2004

> Sort of like someone looked at C++ and said "that's too easy."

Things you can do with COM but not C++ include ...

- Invoke a DLL written with a different compiler (C++ doesn't define binary compatibility between executables)

- invoke code in a different process

- release memory that was allocated in a different module (even if all modules are compiled with the same C++ compiler, perhaps they're not all using the same run-time heap manager)

- explore interfaces (like reflection)

- register interfaces and classes (in the system registry)

- interoperate with non-C++ compiler (e.g. VB)

Of course, COM might be implemented using C++.

Christopher Wells
Wednesday, June 23, 2004

I was just wondering...

Did anyone implement or use something like smart pointers withing COM pointer/reference assignment to automatically keep track of the reference count?  Did ATL do this for you?  That would have made life so much easier.

Wednesday, June 23, 2004

Yes, Don Box suggested that in his book _Essential COM_ (which I used to access COM from C++ code).

Christopher Wells
Wednesday, June 23, 2004

I think COM stands for Component Object Model, not Common Object Model.

Wednesday, June 23, 2004

Yes, ATL did have smart pointers. Then, to make it twice as good, the C++ compiler team implemented their OWN set of smart pointers, which were almost, but not quite, identical!

The real undoing of COM in my mind was this: the goal was to build a system out of separate components, from separate vendors, using separate tools. However, with COM as defined, in order for things to work, everybody involved had to do everything exactly right all the time. Just one component does memory management wrong, and BOOM! the whole thing fell down.

Add to that the usually low level of C++ mastery the typical developer displayed, and all the crap the VB team forced on the world, and no wonder it fell apart.

I like .NET simply because it lets me do the same sort of stuff (build & use components) without dealing with all the persnickety details anymore.

Chris Tavares
Wednesday, June 23, 2004

Thank you wayne.... my mistake... :) although I've seen both.

Wednesday, June 23, 2004

Just as I was discovering what COM was about by reading fantastic articles like "What OLE Is Really About"*, it went away and I felt quite sad about that.


John Topley (
Wednesday, June 23, 2004


Bartosz Milewski has an article here where he discusses 'Smart OLE,' wrapping OLE.

His insider rant about OLE is entertaining reading

Ged Byrne
Wednesday, June 23, 2004

COM is not 'common object model'

it is:

Component Object Model (COM)

An open architecture for cross-platform development of client/server applications. COM is based on object-oriented technology as agreed on by Digital Equipment Corporation and Microsoft Corporation. COM defines the interface, similar to an abstract base class, IUnknown, from which all COM-compatible classes are derived.

cross platform only sort of and very very rarely used that way.

hard to use, hard to explain, hard to not make mistakes with it.

thats why a COM programmer, when needed, makes the bucks. And why employers are probably working hard to eliminate the need for those positions.

david howard
Wednesday, June 23, 2004

Yes, the only way I managed to implement COM components or clients is by reading Bartosz Milewski's writings.

Wednesday, June 23, 2004

Years ago, I was thinking about reimplementing a project to use COM. I guess I'm glad I didn't.

I suspect that many projects were implemented using COM because it was "cool', "the latest thing", and the "last thing you'll ever need", not because it was "necessary".

Wednesday, June 23, 2004

An old fart writes...

I remember when, in the days of OS/2, Microsoft (or IBM, I forget) were touting DLLs as the Great New Thing (TM). They would let you write code reusable from multiple programs, cut down on the memory and disk footprint of the software, allow abstraction etc. etc.

Dear dead days!

Harvey Pengwyn
Thursday, June 24, 2004

> I always hated the term "apartment
> threading."  It means nothing.  I think what it
> means is calls are serialized through an event
> loop, but I'm not sure.

That depends on what you mean by "means". 

I don't think Apartment Threading means that calls are serialized through an event loop -- though cross-thread marshaled calls ARE serialized through an event loop, that's not what "apartment threading" means, that's how apartment threading is _implemented_.

Rather "apartment threading" is a contract, just like Pascal Calling Convention is a contract.  It's a list of rules for how you agree to use an object, and how the object agrees to behave itself. 

You agree that you'll only call the object from the thread on which you created the object, and that you'll marshal calls from other threads to the correct thread using the COM marshaler. 

The object agrees that it will let you create multiple instances on multiple threads, and the object will implement any locks necessary to maintain consistency of its global data.

It's called "apartment" threading because its like people (objects) living in an apartment building (a process) containing apartments (threads).  You can put as many people into a given apartment as you'd like.  You can put different people in different apartments.  But you may not move people from apartment to apartment, and you may not shout through walls.  If you want to talk to someone, you have to go to their apartment yourself (call from the right thread), or have the postman deliver your message (marshal through a message loop to the right thread.)

Does that clear things up?

Eric Lippert
Thursday, June 24, 2004

Thanks Eric. All the tech stuff I have read elsewhere just seemed to gloss over giving a fitting analogy to clearly see the true point of apartments.
Perhaps I should get my head examined, but I still see value in learning COM & ATL, as understanding their concepts and inner workings will always put you in good stead for anything they plan to unleash upon us in the near future. All the sugar coating in the world won't ease the headaches when stuff doesn't work as Redmond says it does.
The existence, or at least "influences" of COM will live hauntingly on for us to feast upon.
Can you recommend any good sources for getting a better understanding of some of COM more cunning nuances. :)

Friday, July 9, 2004

*  Recent Topics

*  Fog Creek Home