3 ms·

I didn’t even realize that widgets were so under-developed? I legit thought I’d look into writing one today as I suddenly had a use case. Apparently at the mome

I didn’t even realize that widgets were so under-developed? I legit thought I’d look into writing one today as I suddenly had a use case. Apparently at the moment the only way to write one is Win32 flavored C++ and a bunch of COM Black Magic. One would assume from their marketing that they’d have at least started at .NET. But instead it’s C++ and Someday(TM) PWAs (via Edge I assume) can provide widgets. That just runs completely counter to all the Dev Experience marketing you get from them. It feels like Widgets were slapped together by the kernel team at the last minute.

pjmlp 4y ago
When Longhorn failed, mostly due to WinDev sabotage[0], they doubled down on using COM, hence why since Vista all major Windows APIs are COM based, and if we are lucky there are some .NET bindings as well. WinRT is basically the evolution of this, going back to the design board as if .NET never happened, hence .NET Native and C++/CX abstracting what is basically COM + IInspectable + .NET metadata instead of TLB + App Identity. WinRT eventually became UWP, as they improved the developer experience, only to kill .NET Native, replace C++/CX with C++/WinRT (similar dev experience as using ATL), and move that infrastructure on top of standard COM on Win32 side. So now you have classical COM, and Windows Runtime components are the modern COM. Meanwhile DevDiv seems to have had enough of this and decided to focus on .NET with cross platform experience, and Web technologies, hence why even Visual Studio is quite lacking on WinUI tooling. [0] - If they really cared they would have doubled down on it like Android and ChromeOS did, and all those C# 7 - 11 performance improvements would have been done at the time.