Skip to content

COM (Component Object Model)

The Object-Oriented Disaster that Windows can't live without!

The Origin Story nobody asked for:

Picture these my guys: It's 1993 (History time again xD), some innovative engineers at Redmond got their asses deep into that desk chair for quite a few hours today, and tens of hours this month. Now, I will tell you a big secret... Don't share it with anyone! Keeping those chairs warm actually enlighted them. Guess what? A new idea pops in their mind! "Let's make software be able to talk to each other!"

Thus, COM aka Component Object Model arises... Legends are written, poems are sung, but nobody thought that years later, if someone wanted to remove the damn COMs out of Windows, it would kill the OS in an instant... It got so deep into the OS's architecture, that removing it is the same like... uhm... trying to remove your skeleton while running a marathon.

COM started innocently enough, an idea from the Gods themselves. The beautiful simplicity:

Create a binary standard that lets software interact with each other independent of their language. It's like creating an universal translator, except the translator is drunk, speaks in GUIDs and has commitment issues with memory management!

What Microsoft did engineer was a framework so fundamental to Windows that literally everything depends on it. Your start menu? COM. Your calculator? COM. Your attachment preview in Outlook? You guessed it, another COM! It's like discovering everything in your house, including the house itself is made out of the same material, nobody f&n fully understands.

The Architecture: A Beautiful Nightmare in Binary

The COM Philosophy: "Everything is an Object, Nothing Makes Sense"

Application: "I need to create an object"
     ↓
CoCreateInstance(): "What's the CLSID?"
     ↓
Registry: "Oh, {GUID}? That's in this DLL"
     ↓
DLL: "Here's your object's interface"
     ↓
Object: "Please kill me when you're done"
     ↓
Reference Counting: "Did someone say kill? Let me check my math"
     ↓
Memory: *confused screaming*

The Core Components of Our Tragedy:

The IUnknown Interface: The Mother of All Interfaces

interface IUnknown {
    QueryInterface();  // "What else can you do?"
    AddRef();         // "I'm using you now"
    Release();        // "I'm done with you (maybe)"
}

Every COM object inherits from IUnknown. It's like saying every person is human - technically true, practically useless, philosophically questionable.

CLSIDs: The Social Security Numbers of COM

  • Format: {12345678-1234-1234-1234-123456789ABC}
  • Stored in: Registry under HKEY_CLASSES_ROOT\CLSID
  • Purpose: Unique identifier for each COM class
  • Reality: 50,000+ GUIDs that nobody remembers

The Registry: COM's Phone Book From Hell

HKEY_CLASSES_ROOT\
├── CLSID\
│   ├── {GUID-1}\
│   │   ├── InprocServer32: "C:\Windows\system32\something.dll"
│   │   ├── LocalServer32: "C:\Program Files\whatever.exe"
│   │   ├── ProgID: "Word.Application.16"
│   │   └── TypeLib: {ANOTHER-GUID}
│   └── {GUID-2}\ ... {GUID-50000}\
├── Interface\
│   └── {MORE-GUIDS}\
└── TypeLib\
    └── {EVEN-MORE-GUIDS}\
It's a hierarchy where every node has a GUID, every GUID has a purpose, and every purpose is obscured by another GUID.

COM Threading Models: Choose Your Confusion

Single-Threaded Apartment (STA): "Only one thread can touch me. I'm delicate."

Multi-Threaded Apartment (MTA): "Multiple threads welcome! I hope you like race conditions!"

Both: "I'm flexible! (Translation: I'm unpredictable)"

Free-Threaded: "YOLO! Thread safety is for cowards!"

Neutral: "I don't care about threads. Threads are a social construct."

The Security Model: "What Security Model?"

COM Permissions: The Bouncer Who's Always on Break

COM security is configured in the most user-friendly way possible: deep in the registry with binary ACLs that nobody can read without a decoder ring.

Launch Permissions: Who can create the object?

Access Permissions: Who can use the object?

Authentication Level: How paranoid should we be?

Impersonation Level: How much should we trust the client?

The default answer to all these questions? "Sure, why not!"

The Authentication Disaster

COM supports multiple authentication levels:

  1. None: "Come on in, stranger!"
  2. Connect: "Show ID once, then we're best friends"
  3. Call: "Show ID sometimes, when I remember to ask"
  4. Packet: "Show ID frequently, but not obsessively"
  5. Packet Integrity: "ID plus a pinky promise you didn't change anything"
  6. Packet Privacy: "Full encryption, because we're paranoid now"

Most COM objects default to "Connect" because checking authentication is hard and developers have deadlines.