The strange history of DCOM

The strange history of DCOM
Many years ago, Microsoft began modularizing Windows and their Windows applications by breaking them into functional components with well-defined, "version safe" interfaces. The idea was to allow pieces of Windows and applications to inter-operate.

The name first given to this effort was "OLE", which stood for Object Linking and Embedding. OLE suffered nearly terminal birthing pains and developed a reputation for being a bad idea. Undaunted, Microsoft renamed it COM for "Component Object Model". This was still the same old OLE, but Microsoft appeared to hope no one would notice. COM fared somewhat better, but it wasn't until Microsoft gave it the sexy name "ActiveX", and built it into virtually everything, that developers finally gave up trying not to use it.

What does all this have to do with you?

Absolutely nothing . . . and that's the point. Somewhere along the bumpy road from OLE through COM to ActiveX, Microsoft's industry competitors began working on a distributed object system called CORBA. Microsoft's object system was not distributed, but as we know, if anyone else has one, Microsoft does too. So Microsoft looked around and quickly stuck a "D" (for Distributed) in front of COM to create DCOM, their Distributed Component Object Model. Then they crammed it into every version of Windows starting with Windows 98, even though no one needed it, wanted it, or was using it. That way they could say Windows already had a distributed component system built in.

What does DCOM do for you?

Well let's see . . . it attracts Internet worms and permits your system to be remotely compromised by malicious hackers. Other than that, it's of absolutely no practical use other than to adorn Microsoft's "We Have That Too" chart. There may be some custom corporate application developers who have managed to make some use of it, but mostly no one ever has. Nonetheless, it's there in Windows so that the competitors' CORBA isn't.
4,456 views 4 replies
Reply #2 Top
This is a very important article, which clearly and succinctly explains in authoritative and technical language what DCOM is, what it does, and why Microsoft has included it in the Windows operating system. Too bad Microsoft doesn't have experienced engineers and craftsmen like frogboy around, because then their operating systems and desktop apps would be as sophisticated and reliable as Window Blinds. And their web sites wouldn't be full of typos (try F7 - that's spell- and grammar-checking). And their registration database would actually work for their subscribers. The graphics on their websites would display consistently.

Kudos frogboy for giving us all an education! And Hats Off to mrbiotech for recognizing the whole situation as a typical MicroSoft maneuver.
Reply #3 Top
Thought I recognized the writing style of the story. That's from Steve Gibson, and the utility (as well as several others) can be found at www.grc.com.
Reply #4 Top
Well, DCOM is not all that bad. From a programmer's point of view, having all your data objects (objets that query your databse) stored in one DLL that can be used by different apps (let us say a PBX, an intranet, client/server apps, WAP pages) really does save you time and lines of code. No matter what you use on the presentation layer, the data given by your COM objects will always be the same. With the correct tuning, you can really take advantage of DCOM in many succesful ways. Oh well..