> I haven't really heard or seen much usage of it since.

I think COM is incomprehensible to most developers today--it certainly is to me, and I maintained a .NET application with COM components for several years! COM is so arcane and verbose.

Why invest hundreds of hours learning something with no clear benefit or future? The documentation introduces COM as:

https://docs.microsoft.com/en-us/windows/win32/com/component...

> COM is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM is the foundation technology for Microsoft's OLE (compound documents) and ActiveX (Internet-enabled components) technologies.

What does that even mean? It sounds obsolete.

When I read the headline it was a mix of WHYYYYYYYY and NOOOOOOO

Really, can't we just leave COM in the 90's?

Win32 is the one left in the 90's.

COM gets regularly new APIs.

Except the one without a bright future is Win32.

Since Vista all major APIs are based on COM.

My point is that for the vast majority of developers this does not matter one bit. The Windows API is not relevant to the work that most developers do today. In the cases where a developer actually needs to interact with Windows there are easier technologies available.

Yeah, if we are talking about web developers I guess.

How do you think those easier technologies are implemented?

Just to give an example, React Native for Windows uses UWP.

As for not being relevant, the software for a platform with 80% market share across desktop and laptops, does not write itself.

Marshaling COM objects for use among different threads was fun. Remember the function 'CoMarshalInterThreadInterfaceInStream'? :-)

I feel Windows' C API (i.e., Win32 API) was adopted at a larger scale than COM. It's much easier to use the Win32 C API than COM objects. You'd have to use COM if you wanted to program the shell or DirectX but most of everything else you could use the C API.

Only if you intend to use pre-Vista Win32 APIs only, afterwards most of the new stuff comes packaged as COM or .NET.

Since Windows Vista the large majority of new native APIs on Windows are based on COM.

You probably haven't heard much about it, because now it has the fancy name of UWP, or it comes with .NET wrappers on top.

UWP is ambiguously defined and the acronym's usage is on the way out. An evolution of UAP and Windows Store apps, it boiled down to a whitelist of APIs allowed on multiple devices (the U in Universal) and encompassed Win32, WinRT and COM APIs. UWP itself isn't an entity with APIs, is not a technology, and the original concept is dead thanks to new platform leadership at Microsoft. (Still in play on Hololens, Surface Hub, and other sandboxed devices for now...)

That said, "UWP" is confusingly also used to refer to Windows apps that tap into WinRT APIs, participate in the modern app lifecycle, are modeled and have identity, or generally tap into newer technologies such as AppContainer. You'll see this, for example, perpetuated in Visual Studio in its project templating. It's a BIG OL' MESS right now; I'm working with/pushing Microsoft to get this communicated clearly and mopped up but old habits die hard.

Well, it is quite clear actually.

https://docs.microsoft.com/en-us/windows/apps/desktop/choose...

These docs are outdated and incorrect, sadly. For example, nearly everything under the UWP heading can be done via traditional Windows apps. Current leadership seems to get it, "write an app, use any APIs you need" (rough paraphrasing). Just hasn't fully set internally and externally so these warts exists.

On a technical level, there are still some apps that can get CoreWindows, respond to PLM events, receive callbacks from contracts involving CoreWindow UI like Share target, as well as go into certain UI modes involving shell participation like modern fullscreen and CompactOverlay, and some that can't (without stapling them together with one that can via Desktop Bridge) ... aren't there? Maybe that will change in the future but it hasn't yet.

And then there are some OS editions where some apps can't run or can only run in a container environment.

Waiting to see that message at BUILD 2020 or the upcoming Ignite.

Until then, sorry to say but I follow up on what is available to us.

Yeah we're on a bit of a purge right now to remove a lot of MS Office automation. We're just reading data from files - nothing fancy - but it's all over the place and apparently technically outside of licensed usage so compliance is cracking down on us.

COM is an interesting concept. If it were never invented I have a feeling native apps would be spinning up a simple REST API server instead, since that's what we all do now apparently.

DirectX is COM based. Which means that pretty much every Windows game, and many applications (like Chrome) use COM, at least in part.

I've done a fair amount of work with DirectX, and I've never particularly had to be cognizant that it used COM.

That's probably more a reflection of DirectX being reasonably well designed.

It's mostly a reflection of the fact that you don't have to implement COM interfaces to use DirectX—you only have to call them. Also, the constructors are wrapped in functions like D3D11CreateDevice() so that you don't have to use raw functions like CoCreateInstance().

If you're using an API like DirectWrite (at least older versions) that requires you to implement interfaces to do basic things like load fonts from memory, then the COM underpinnings of the APIs become very apparent.

That's because there are two COMs:

1. The good COM, which is just a class-like ABI.

2. The horrible OLE COM, which allowed you to embed Word docs in Excel and the like which is what most people associate with COM.