Re: DLL Vs. COM
From: David Mair (mairdanot_at_nothotmail.com)
Date: 07/04/04
- Next message: Anjali: "Re: Painting Problem"
- Previous message: Ganesh Okade: "IE Toolbar (deskband) created on BHO does not come on a new row"
- In reply to: Vengidi: "DLL Vs. COM"
- Next in thread: Ben Rush: "Re: DLL Vs. COM"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 04 Jul 2004 11:45:45 -0600
Vengidi wrote:
> Hi,
> I have a nagging question now. When I can reuse features with exported
> functions from a DLL, then why COM ? How does COM Outweigh a simple dll in
> this regard ?
I would guess at interface consistency (standardised interfaces like
IMalloc for example). This allows for things that are different to
appear to be the same, or appear to have some aspects that are the same.
A perfect example from my own work is that all video sources that are
DirectShow compatible can be handled using the same code (this includes,
TV tuners, capture cards, webcams, etc). Common interfaces only need to
be published in one header file (often in Microsoft SDKs) whereas
multiple DLLs, even if using the same interfaces would have to publish
their own class definitions, especially if they came from different
vendors. One thing I'm not certain about but I think is the case is
that a class declaration would have to publish the internal interfaces
as well as the external ones in order for a C++ compiler to be able to
use it. With COM the exposed interfaces don't need to indicate anything
about implementation. COM also supports interfaces with other processes
(the shell, for example). In the case of the shell I can be the DLL
running in the shell's address space, as in the case of a shell
extension (e.g. context menu handler) and I don't have to tell the shell
what my interface is because it is a standard and the shell doesn't need
to be re-compiled in order to use my DLL. The same goes for custom
controls, they can be used in another application without that
application habing to know anything about them. The use of unique
identity that is external to the source that uses COM objects is another
nice detail in the implementation of COM. You can iterate the set of
installed COM objects and create instances of them without having to
re-compile or know much about them (at best just the interfaces they
implement: IUnknown::QueryInterface() IIRC).
COM can be very complicated to use, it took me a lot of research and
testing to write a webcam app with Windows Media video capture but the
nice thing is that it should be portable through at least several
iterations of DirectShow (support multiple video sources including some
that don't yet exist) and Windows Media without the need for me to
re-compile. Source using COM can be ugly to look at but I find it to be
very powerful (two of the things I like most about Windows programming
are UI messages and COM so I guess I'm biased).
For the conspiracy theorists it was just a way to offset the potential
effect of CORBA but even if that was true it has developed in a rather
impressive manner.
- Next message: Anjali: "Re: Painting Problem"
- Previous message: Ganesh Okade: "IE Toolbar (deskband) created on BHO does not come on a new row"
- In reply to: Vengidi: "DLL Vs. COM"
- Next in thread: Ben Rush: "Re: DLL Vs. COM"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
