COM vs. DLL

[AAntix]

I am trying to learn about COM, and am a bit confused. My book defines COM as a binary object interoperability standard. So one can share common functions between applications without needing to worry about what language the COM was object was made with.
Well then, what makes this different than a DLL? I am so confused!
Any help is certainly appreciated.

[cflanman]

A COM object (or several of them) can be implemented as a DLL. Keep reading. It takes a while before it sinks in.

[AAntix]

I have kept reading, and I still don't understand. Why should I go through the headache of setting up this COM object, when I can write a DLL and share that library between my VB and VC++ apps. What advantages does COM offer over a standard DLL?

[Avinash]

You seem to be a DLL fan. It takes time to give up.
COM adds to DLL facilities by making it name independent and location independent. You can have multiple versions of an object in different DLLs without having to bother about where to keep them or how to name them. You dont have to care about loading and freeing libraries explicitly.

Keep reading....

Avinash

[Sunil.R]

Hi ...

Many C++ objects often can't even be used with other C++ objects produced by a different compiler, because of the implementation
dependencies left open by the C++ language specification. There is no binary standard for compiled C++ objects. One way to remedy
this is to use the DLLs. These allow run-time linking and have less language dependence. There are problems here too, though,
because they only export on a single-routine basis, rather than whole objects at once. And, of course, they're limited to Windows
platforms.

Draw backs of Dll

· DLL names and locations tend to be hard-coded. An application loads a DLL by name, and if the name changes, the DLL becomes
'invisible'. The DLL also has to reside in the application directory, in the Windows system directories, or on the path in order to be
found.
· Under Win32, DLLs are hard to share between processes, as they're loaded into the address space of each process that wants to use
them, which wastes time and resources. It's possible to load some DLLs, such as the Windows system DLLs, as subsystems so that
only one instance services the whole system, but they're expensive and not suited to application software.
· A multiple service DLL requires coordination of ordinal numbers or function names. DLLs have a fixed overhead, so it's often useful
to combine functionality (services) into a single DLL, but this may lead to problems if routines from different services have previously
been allocated the same ordinal numbers.
· DLLs don't support versioning. Since DLLs are only referenced by name, there's not necessarily any way to tell whether the XXX.dll
present on your system represents version 1.0, 1.1 or even 2.0. It is quite possible (and normal!) to have multiple copies of DLLs of
different versions present on one machine, and this can lead to problems which are sometimes very hard to solve.
Overwriting older DLL versions is a related problem.

How COM Works
-------------------

COM gives us a way to use objects like we do in C++, even when those objects don't live in the same program (perhaps not even on
the same machine), and aren't written in the same language. It does this by specifying how software objects should be laid out in
binary form (in other words, how they should be laid out in memory), and how they can communicate with one another, in a way that
doesn't depend on a particular machine or language, making them architecture-neutral.
The defined binary layout of a COM object governs how its tables of publicly-available functions are laid out, and
means that the format is independent of the language in which the object was written and the machine architecture on which it runs.
The tables, analogous to C++ virtual function tables, are known as vtables. In Visual C++, COM vtables and C++ virtual function tables
have the same structure, which is, I guess, only sensible of Microsoft. This may not be true of other compilers, which means they'd
have to do rather more work when representing COM objects in C++.


Hope this makes all clear,
Sunil
suneel_r@hotmail.com

[AAntix]

Thank you Sunil for such a thorough response. You cleared up many doubts.

= Jim =

[Steve Dwire]

The issue really isn't COM vs. DLL. It's COM DLL vs. exported function DLL. Check out Don Box's "Essential COM". Chapter 1 goes through several scenarios where developers can get into trouble relying on exported functions in DLLs, but implementing COM objects in those DLLs takes care of the problems. Chapter 1 is the sample chapter at www.fatbrain.com. Go to http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201634465, then, under "Details" in the left-hand column, click "Sample Chapter" for a detailed answer to your question.

They, buy the book! :-) It's definitely worth it!