none
Why do we cannot use COM interop for Win32 APIs like User32.dll? Why are we using DLLImport? RRS feed

  • Question

  • Are Win32 APIs not following COM? Are they not binary compatible (if so, what is the reason behind it)? Let us know what happens behind the scene when we use interop for COM and dllimport for Win32 APIs..

    Tuesday, October 7, 2014 2:33 PM

Answers

  • There's not really a reason apart from the fact that COM needs the Win32 API.  The Win32 API just precedes COM, and is quite a bit more fundamental.  In both cases the functions are just exported functions from DLLs.  DLLImport is a kind of interop with the DLL apis and COM interop is a kind of interop that uses COM (which itself uses DLL apis, plus the registry).

    COM is a whole layer on top of all that involving objects, lifetime management through reference counting, interfaces, a huge number of conventions, and much much more.  At a basic level COM in-process servers are still just DLLs with exported functions behind the scenes including

    • DllGetClassObject
    • DllCanUnloadNow
    • DllRegisterServer
    • DllUnRegisterServer

    The metadata for COM classes are stored in the registry.  To locate a COM dll, you first look up the class in the registry (by GUID or name) and then load the dll and get the class object.  Then once you have a class object, the rest is just function calls (to create instances of other objects or call their methods, for example.)

    When you use COM interop you create a managed object called a runtime callable wrapper (RCW) that manages a COM object in memory.  You also get access to all of the class loading and locating code in Ole32.dll via COM interop as well (often via a simple new call).  Reference counting of the COM object is managed by the RCW so that when the RCW is garbage collected, the reference to the COM object goes away too.  At the end of the day, COM interop just does all the traditional COM dll calls or communicates with the COM interfaces behind a layer of abstraction (including the RCW) that makes it convenient to use via managed code.

    The functions for accessing COM objects work like the Win32 API as well, including CoCreateInstance.  COM uses the Win32 API to access the registry to locate objects.

    If you wanted to, you could create an object that exposed any number of the Win32 API functions via a COM object.  You'd essentially just be putting a wrapper of cruft around a speedier interface though.

    There are actually a great many number of interfaces that basically do this.  GDI+ has a large number of functions that parallel the Win32 counterparts.  In a way, the entire .NET framework could be thought of as an augmented abstraction of the Win32 API with many bonus features.

    • Marked as answer by Dhinakar Raj Wednesday, October 8, 2014 11:34 AM
    Tuesday, October 7, 2014 3:00 PM

All replies

  • There's not really a reason apart from the fact that COM needs the Win32 API.  The Win32 API just precedes COM, and is quite a bit more fundamental.  In both cases the functions are just exported functions from DLLs.  DLLImport is a kind of interop with the DLL apis and COM interop is a kind of interop that uses COM (which itself uses DLL apis, plus the registry).

    COM is a whole layer on top of all that involving objects, lifetime management through reference counting, interfaces, a huge number of conventions, and much much more.  At a basic level COM in-process servers are still just DLLs with exported functions behind the scenes including

    • DllGetClassObject
    • DllCanUnloadNow
    • DllRegisterServer
    • DllUnRegisterServer

    The metadata for COM classes are stored in the registry.  To locate a COM dll, you first look up the class in the registry (by GUID or name) and then load the dll and get the class object.  Then once you have a class object, the rest is just function calls (to create instances of other objects or call their methods, for example.)

    When you use COM interop you create a managed object called a runtime callable wrapper (RCW) that manages a COM object in memory.  You also get access to all of the class loading and locating code in Ole32.dll via COM interop as well (often via a simple new call).  Reference counting of the COM object is managed by the RCW so that when the RCW is garbage collected, the reference to the COM object goes away too.  At the end of the day, COM interop just does all the traditional COM dll calls or communicates with the COM interfaces behind a layer of abstraction (including the RCW) that makes it convenient to use via managed code.

    The functions for accessing COM objects work like the Win32 API as well, including CoCreateInstance.  COM uses the Win32 API to access the registry to locate objects.

    If you wanted to, you could create an object that exposed any number of the Win32 API functions via a COM object.  You'd essentially just be putting a wrapper of cruft around a speedier interface though.

    There are actually a great many number of interfaces that basically do this.  GDI+ has a large number of functions that parallel the Win32 counterparts.  In a way, the entire .NET framework could be thought of as an augmented abstraction of the Win32 API with many bonus features.

    • Marked as answer by Dhinakar Raj Wednesday, October 8, 2014 11:34 AM
    Tuesday, October 7, 2014 3:00 PM
  • Thanks a lot.
    Wednesday, October 8, 2014 11:37 AM