[ColinDabritz]

COM is the Component Object Model: https://en.wikipedia.org/wiki/Component_Object_Model

This was how a lot of system and third party libraries provided large amounts of functionality in the windows ecosystem for quite some time. These are usually in the form of a DLL (Dynamic Link Library), libraries of COM components, packaged as a ".dll" file. This is related to the re-use and versioning issues known informally as "DLL hell". Most COM components are native C and C++ based, exposing a standardized COM interface for component reuse.

Dot net was a new ecosystem, but much of the Win32 related dot net API is wrappers over existing native COM components. There are also extensive dot net facilities for repackaging and working with existing COM libraries through a Com Interop layer. https://msdn.microsoft.com/en-us/library/ms173184.aspx

The COM system provided an approach to interoperability and reuse for a long time, but compared to our current generation of cross platform compatibility, the venerable COM system components are proving to be a significant legacy challenge for cross platform implementations.

[72deluxe]

I don't think COM is going away either, despite the cross platform ideas. The entire Windows system is built on COM, and the new UWP apps are COM apps but they do not inherit directly from IUnknown - they inherit from a child of IUnknown (if only I could remember what the interface is called, sorry).

[pjmlp]

Why are you speaking in the past tense?

COM usage on Windows only increased after Windows Vista and is at the heart how UWP works and user space drivers.

[ColinDabritz]

Yes, good point. It was discussing in past test in the context of "DeCOMification" mainly. It would be interesting to have some insight into new component creation vs use of existing components.

[pjmlp]

Well it is just plain old COM, with a new base interface IIspectable that inherits from IUnknown and using .NET metadata instead of TLB files.

Using it from C++/CX is quite painless compared with the old ways, as it is quite similar to .NET, Delphi and C++ Builder ways of using COM.

For a little pain ATL style, you can use Windows Runtime Library.

Kenny Kerr and his team are pushing for C++/WinRT, a new C++ projection (language binding), based on pure Modern C++, with the goal to eventually replace C++/CX. Currently WIP, though.

For those that really like to suffer, the old way of using MIDL compiler with C is still possible for UWP applications.

From our projects, I would say most UWP developers use .NET for UWP controls and only resort to C++/CX if integration is C++ code is required.