I understand that the basic problem COM solves is the issue with binary compatibility of software libraries. That is why a lot of (low level) windows services are exposed through the COM system. But why is the Windows API itself not exposed through COM? It seems that the DLLs implementing the Windows API have somehow managed to stay binary compatible with all sorts of compilers and as such the Windows API has no need to be exposed through COM.

>Solution :

The basic Windows ABI is stable and is as compatible as COM. If a compiler supports COM it supports the basic API as well, on x86 they are both stdcall functions.

Exposing everything as a COM interface does not make sense for many reasons.

• Windows 95 minimum requirement was 4 MiB RAM and COM everything would bloat the registry too much. Each instance of a COM object will also require memory where as a function call only needs a little bit of stack space.
• A COM method call is slower. V-table lookup and one extra function parameter. Wasting time calling CoCreateInstance way too much. Pointless reference counting overhead.
• Low-level things like CreateFile and CreateProcess can only ever be implemented by Microsoft and it does not make any sense for 3rd-party software to provide/override implementations of low-level functions.

The only positive would be that high-level scripting code could call these functions but in practice most COM interfaces are not dual and do not support IDispatch and therefore cannot be scripted. The exceptions are Internet Explorer, Office and some of the shell stuff (Shell.Application).

For things that are extensible or runs out-of-process, COM makes a lot of sense. It is easy to define the interfaces and IPC is taken care of for you.

With the introduction of UWP/WinRT you are somewhat getting your wish…