The difference between traditional DLL and COM DLL

Question

I am currently studying COM. I found that COM DLL is kind of built upon the traditional DLL infrastructure. When we build COM DLLs, we still rely on the traditional DLL export methods to lead us to the internal COM co-classes.

If COM is for component reusing at the binary level, I think the traditional DLL can achieve the same thing. They both expose functions, they are both binary, so what's the point of turning to COM approach?

Currently, I have the feeling that the traditional DLL expose methods in a "flat" manner, while the COM DLL expose methods in an "OOP" hierarchy manner. And the OOP manner seems to be a better approach. Could this be the reason why COM prevails?

Many thanks.

Answer 1

The best way to think of COM is to imagine it as a contract between you and the person using the object you create.

COM handles

1. how to version your object across releases
2. how to discover your object, even if your object is in a DLL that gets renamed or came from a different source
3. how to reference and destroy your object (with respect to heaps)
4. how you expect threading to work, and the rules surrounding threading/locking for your object

COM has become a standard because while you could make a traditional DLL that handles each of the above items you'd have to articulate the expected contract when you ship your DLL

by using the rules of COM, this articulation is done for you

you are also correct that COM exposes objects while more traditional DLLS just expose functions. you'll often see developers try to emulate the contracts found in COM in straight C, usually you'll see them clone aspects of COM in their DLL (for example you'll see methods that return structs of function pointers)... my experience is if you dont use COM for making a public DLL you're increasing the odds of miss some cases, especially when versioning is in the picture

Answer 2

In addition to the answers already posted, COM interfaces expose binary data objects in a programming language independent manner, that allows memory for these objects to be allocated in one process address space and freed in another. Lookup marshalling and unmarshalling.

It also allows strings to be passed without paying attention to details of encoding to determine where a null-terminator might be. COM strings are counted UNICODE strings.

Throw in IDL and compile the type library into the DLL, and you have self-describing interfaces. With plain DLLs, you have to know from the external docs what methods they have and the parameters they take.

The COM standard can be cross-platform, as well. Mac versions of Office support COM, and there have been implementations for Unix and Unix-like systems, although they have never been popular.