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.