Hacker News Reader

Comment by pjmlp | Hacker News Reader

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.

View on HN

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.

I'm not disagreeing, but I will point out that COM reference counting is an atomic integer operation. That's expensive. boost::local_shared_ptr exists because std::shared_ptr does sometimes cause performance problems. std::shared_ptr must be used sparingly. It's unlikely to matter in a UI scenario with long-lived objects because it, indeed, does use reference counting sparingly.

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

Yes, and it doesn't do COM style reference counting to the level like WinUI does, so the point being?

My graduation thesis was porting NeXT software to Windows 95, no need for heads up.

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.

Can I see the profiler data that shows AddRef/Release being a performance bottleneck?

Yes, learn to use one and point it to a C++ Github project full of shared pointers.

While I agree that shared pointer are problematic (I almost never use them in C++), I don't think they're ever really the reason for performance issues in GUI apps. I've been doing GUI programming for more than a decade now and the overwhelming majority GUI performance issues come down to issues like poor use of concurrency (blocking GUI thread), unoptimised algorithms (e.g. for layouts), overdrawing, GPU/CPU sync issues or inefficient input handling.

I have never encountered a performance issue that was to due to reference counting (in fact I'm a big user of the CoW idiom when it comes to UI).

Which of those GUIs have you used where everything was a COM element?

I don’t believe it’s Limiting factor in UI frameworks. I’ve profiled a lot of c++ and a lot of UI code. UI problems tend to come from too much churn and object creation, or doing too much work in the UI thread so it gets laggy, not just doing some reference counting.

embarrassing

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

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

Eh... not exactly.

MinWin was the response to Longhorn. When most of the major goals of Longhorn failed to ship and those that did resulted in Vista, Microsoft did a reset. The MinWin project was a massive cleanup effort that promoted cleaner API boundaries and layer separation that defined a minimal bootable NT core at the bottom with reduced overall dependencies.

WinRT was introduced as an alternative API/runtime layer alongside Win32. Both WinRT and Win32 used COM concepts and ran ontop of the NT executive. WinRT was a modern async first object oriented natively sandboxed capability-based runtime that supported built-in projections over manual COM.

Microsoft tried to encourage everyone to adopt WinRT and the new sandboxed App Model on Windows 8, Windows RT, and Windows Phone. It used modern concepts and was more secure than the uncontrolled legacy surface area that Win32 exposed. They shipped those devices with Metro, a new "desktop" interface and didn't allow Win32 Apps. Unfortunately they shot themselves in the foot by shipping full Win32 based Office on Windows RT. This demonstrated that yes Win32 could run on ARM. After that, things fell apart and Microsoft decoupled many WinRT features from the WinRT/UWP model.

WinUI is an interesting UI framework that sits on top of this stack and is decoupled from it. This allows it to be updated independent of the operating system.

MinWin was a kernel refactoring mostly, still during Windows 7 days.

Missed the parts about the multiple reboots of the WinRT API surface between 8, 8.1 and 10.

The deprecation of .NET Native and C++/CX, replaced by tooling without feature parity to this day.

The set of Win32 APIs not available in UWP, even after the 8 and 8.1 (UAP) reboots.

WinUI 2.0 features not yet available on WinUI 3.0.

The pivot from Project Reunion, that six years later hasn't yet delivered on the goals from the BUILD 2020 announcement.

Microsoft is its worst enemy when it turns the hardest advocates in tale tellers from past wars.

Reply on news.ycombinator.com