alt Hacker NewsIt is quite easy to know why.
WinRT is the Windows team final response to Longhorn, but lets do it with COM and C++, which started in Vista.
This is why all major new APIs since Vista are COM based.
So you get an UI framework with reference counting all over the place, and application identity, which is a kind of sandboxing, for the capabilities like in mobile OSes or macOS.
On the UWP subsystem, you get .NET Native and C++/CX, whose runtimes are WinRT aware and can elide those RC calls.
Whereas using WinRT on Win32, means regular .NET and C++, via interop frameworks CsWinRT and C++/WinRT, plain libraries.
So there is no elision, it is AddRef/Release all over the place.
Replies
> WinRT is the Windows team final response to Longhorn, but lets do it with COM and C++, which started in Vista.
Not sure what you mean, I was using COM and C++ for Windows development in the late 90s.
> So there is no elision, it is AddRef/Release all over the place.
...and constructing an object is an insanely complex (and expensive) operation.
I don't believe it.
Reference counting is a virtual function call + an integer operation. It doesn't happen that often either because objects in UI frameworks are very long lived. C++'s shared_ptr, Rust's Rc, and Swift, don't typically cause performance problems either.