Is COM one type of DLL interface or DLL interface of one type of COM interface?
Yes and no. Per-se COM has nothing to do with exporting DLLs per se, but it is often implemented through one or more DLL entry points for inproc servers.
In this case, the registry contains some storage information to locate the DLL (which should not be named *.dll ), and the entry point DllGetClassObject can be called implicitly whenever you create an instance of a COM object through. So when you call CoCreateInstance or CoCreateInstanceEx and provide a CLSID / GUID, what happens behind the scenes is that the registered COM classes are looked in the registry to find out which mechanism (of which the DLL is one) to use, and then in In the case of a DLL, the DllGetClassObject function will be called to create the instance you requested. Theoretically, you can do all this manually. COM just provides a good way to hide gory details and give you that single layer of abstraction on top.
Note. COM DLLs are DLLs on Windows, but DLLs have nothing to do with COM at all. DLLs provide only one way to implement COM objects — specifically for InProc COM servers.
Often there are four functions in such a DLL:
DllCanUnloadNowDllGetClassObjectDllRegisterServerDllUnregisterServer
If I call the Native (not.net) C ++ DLL from Python using ctypes, is that what using COM?
No. To my knowledge, there are separate Python mechanisms for COM on Windows. See here .
Edit: COM vs ActiveX
COM, ActiveX, and OLE are all names mainly for the same basic mechanisms that have slightly changed focus (for example, in the case of ActiveX).