Comment by pjmlp

8 hours ago

It 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.

10 comments

pjmlp

Reply
antiloper  6 hours ago

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.

  • nxobject  6 hours ago

    For that matter, AppKit was first released on a NeXT with a 25 MHz 68030 and 8MB of RAM.

  • pjmlp  6 hours ago

    Of course they cause problems as well, you not believing it doesn't change profiler facts.

    I can also easily point you on CppCon, C++Now and WWDC talks, where presenters spend valuable time of their lifes speaking about matters you don't believe.

Yoric  5 hours ago

> 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.

  • pjmlp  5 hours ago

    Of course you were it predates all the way back to OLE in Windows 3.x, but not the extent it is pervasive in modern Windows past Vista.

    After Longhorn's failure, Windows team vouched to replicate all the .NET based ideas for Longhorn, as COM in Vista, followed by the Hilo code sample in Windows 7, how modern Windows applications should look like.

    https://learn.microsoft.com/en-us/previous-versions/msdn10/f...

    Best quote from Hilo, to show how Windows team sees .NET,

    > So overall C++ is a good choice for writing Windows 7-based applications. It has the correct balance of the raw power and flexibility of C, and the sophisticated language features of C#. C++ as a compiled language produces executable code that is as close to the Windows API as is possible and, indeed, the C++ compiler optimizer will make the code as efficient as possible. The C++ compiler has many of options to allow the developer to choose the best optimization, and Microsoft’s C++ compiler is one the best ways to produce small, fast code. WinRT was the next step, coming back to the ideas that predated .NET as the COM evolution, before Microsoft got distracted with J++ and the project pivoted.

    https://arstechnica.com/features/2012/10/windows-8-and-winrt...

    https://web.archive.org/web/20190111203733/https://blogs.msd...