After the whole political disaster that was Longhorn, the Windows team decided to rebuilt Longhorn ideas, originally based on .NET, and redo them with COM.

So while many outside Windows have considered COM dead, actually since Vista all major Windows APIs have been provided as COM interfaces, the large majority of Win32 surface has been frozen since Windows XP.

With WinRT/UA/UAP/UWP they have gone back to the roots, while pursuing this idea one level up.

Basically they replaced COM type libraries with .NET Metadata, added support for generics, structured data types and implementation inheritance, bringing it to what .NET would have been like if they did not decided to copy Java.

So while the implementation of this reboot has been somewhat clusmy, COM is not going anywhere on Windows.

Also, this isn't a Windows only thing, Linux has gathered around DCOP, Android has AIDL, Fuchsia FIDL, macOS/iOS has XPC, then there is gRPC and plenty of other variants.

As for COM, yes there are multiple models, in-process, external process and across the network (with DCOM).

GObject and KParts would be the in-process variant, with D-BUS for the other execution models.

Disclosure: I work on the Windows team

Granted, it was pretty painful in C and somewhat in C++, but all the other languages (VB and C# mostly, but plenty of others) really unlock the power of COM.

Nothing like that remotely exists on Linux or macOS.

I recall that it was very awkward, and somehow prone to memory leaks, and unclosed resources. To this day, I still don't really understand what COM is, or is supposed to be. But I still have a negative visceral reaction.

Maybe some excerpts from the documentation[1]:

"COM specifies an object model and programming requirements that enable COM objects (also called COM components, or sometimes simply objects) to interact with other objects. These objects can be within a single process, in other processes, and can even be on remote computers. They can be written in different languages, and they may be structurally quite dissimilar, which is why COM is referred to as a binary standard; a standard that applies after a program has been translated to binary machine code."

"The only language requirement for COM is that code is generated in a language that can create structures of pointers and, either explicitly or implicitly, call functions through pointers."

"Besides specifying the basic binary object standard, COM defines certain basic interfaces that provide functions common to all COM-based technologies, and it provides a small number of functions that all components require."

[1]: https://docs.microsoft.com/en-us/windows/win32/com/the-compo...

Edit: I should add that C# isn’t the best language for COM because it doesn’t release objects when they go out of scope so you either have to release everything manually or wait for the GC to kick in which can cause memory problems. VB and C++ and even PHP are better that way.

I thought COM was meant to communicate between processes?

Any enlightenment is appreciated...

https://developer.apple.com/library/archive/documentation/Co...

All operating systems have some sort of object model and sharing API's, but neither macOS nor Linux have anywhere near the thriving ecosystem and actual cooperation model between applications that Windows has.

Rather unfortunate, because with GIR you could easily have a program written in a mix of Rust, C, Go, C++, Vala, etc. all playing nicely if they were all able to expose to the common object model.

When I was a kid, I used to make VB6 applications, and I'd be able to get custom widgets from the Internet, and import them into my VB6 project seamlessly. It was truly amazing, and mind-expanding.

The JS/React/etc web ecosystem doesn't come anywhere close, in terms of the ease-of-use that VB6 had.

Native would have chased the declining native GUI market.

If Delphi never managed much on the server side, it has more to do with the downfall from Borland than anything else.

So ASP + COM would be ASP.NET with COM+ Runtime instead.

It needed to be an open source cross-platform compiler to be truly viable in the Linux ecosystem, and Linux would be needed to compete with Windows and its licensing fees. Anything other than C# is always a step or two behind on .NET, and .NET was the best route to web apps on Windows.

The only reason AOT is coming back for web apps is FaaS, IMO. FaaS works best with minimal boot-up latency, and FaaS delivers operationally as a way to scale out stateless compute on demand, which optimally means acquiring those compute resources just for the duration of a request or job, and no longer.

https://fuchsia.googlesource.com/docs/+/ea2fce2874556205204d...