I have good knowledge on the working of a "traditional" .dll. Also the differences between dynamic loading and static loading, etc.
But I have the following doubts about the working of COM objects,
regsvr32?COM object lying in the same/different directory?.dll and a COM object?1) No - it is NOT necessary to register COM objects. Registration is needed to create new COM objects. There are many interfaces (COM or native functions) that want a COM object. Their API tells you which interface your COM object should support. Since you pass in an existing COM object, they don't need registration information to create your COM object. A variation of this scenario is the RUnning Object Table, in which you can register created COM objects. Those objects are also created by you, and you don't need the registration info.
Example interface: IQueryCancelAutoplay.
2) A COM object exists in memory. You're probably thinking about a COM class, implemented in a DLL together with its COM factory. COM classes are registered by their GUID. You can have multipe classes=GUIDs per DLL, but only one DLL per class. Remember, the caller asks COM for an instance of your class. Which DLL would COM load if there would be two DLLs implementing the same class?! Of course, there can be two DLLs each implementing one class, where the two classes share some interfaces. They will always share IUnknown, for instance, often IDispatch, but rarely IAcmeCorpFooBarv2
3) A COM DLL is a normal DLL which (a) exposes some COM-specific functions and (b) is registered so the COM framewrok can call LoadLibrary on it. The DLL may also expose other non-COM functions. As a result, you can call LoadLibrary on a COM DLL yourself. This can occasionally be useful to reduce the latency involved in creating your first COM object.
Yes, COM assemblies are registered so that the COM infrastructure knows they exist. The DLLs are found by registration of a CLSID, not by path.
Two versions could co-exist if they have different names (you can't have the same named file in a folder, obviously).
All COM objects implement specific interfaces (IUnknown, many have IDispatch). How COM works really is a subject way beyond what we could post here. You might get a book like ATL Internals or run through some online COM tutorials.
1)It is mandatory to register it if you are not using something called Reg-Free COM
2)Two COM object with same CLSID to ProgID mapping can't be registered.
3)Ultimately both traditional dll and a COM dll contain machine code. If it was not for implementation of interfaces there's not much difference in the way you write your code either.
