6 ms·

WinUI is an evolution of UWP which is an evolution of WinRT. WinUI has been around for years. MAUI is not exactly a competing product and is more about enablin

WinUI is an evolution of UWP which is an evolution of WinRT. WinUI has been around for years. MAUI is not exactly a competing product and is more about enabling cross platform UI development. Different intent. WinUI is actually ok tech. It’s evolved over the years through a few iterations, now on WinUI 3. Im mostly with you though. Until they rebuild the entire OS in it, including all of the administrative controls and tools, I don’t trust the longevity.

qcnguy 1y ago
WinRT came out of UWP I think. UWP was their first attempt to move beyond .NET
- cheschire 1y ago
  WinRT was windows 8. Remember the ARM-powered Surface RT had the same branding? UWP came along in windows 10.
  - tcfhgj 1y ago
    WinRT was introduced with windows 8, the WinRT APIs still exist in Windows 11.
    - cheschire 1y ago
      Yep! I was implying it was the same timeframe as windows 8, but I see where my wording could easily have been taken literally.
- DiabloD3 1y ago
  You have that backwards. WinRT is the managed languages runtime for Windows, introduced in Win8. Its sort of the replacement for COM/OLE but also defines the ABI dialect in a way that allows managed languages to call unmanaged code without an FFI penalty. UWP is built on WinRT, and acts as a fully managed app container, similarly to how phone apps exist on your phone. It allows WinRT apps to be deployed to any Microsoft platform, Windows, XBox, Windows Phone, etc, but also Android and iOS, and also as PWA, and are guaranteed to run identically on any of those platforms. UWP apps must be written a fully managed language that runs on the CLR (ex: C# runs on the CLR, but C++/WinRT does not). UWP also uses the second generation of WinUI-family XAML UIs, which means all UWP apps use completely native UIs, instead of slow non-native Javascript shit in a web canvas. The WinUI family of XAML UIs started with WPF, and a slightly incompatible version of it also appeared in Silverlight (WPF = WinUI 1.0), then was brought to UWP (= WinUI 2.0), and is now its own stand alone thing that any app can use, managed or not, as 3.0. WinRT is not an attempt to move beyond .NET, instead it is their way of allowing .NET to natively call code, and make .NET languages first class in Windows.
  - qcnguy 1y ago
    Yeah but I think when it was introduced it wasn't a thing you could use separate from the rest of UWP. What changed in Win10 was you could use WinRT APIs from regular Win32 apps too. They started breaking UWP up into independent pieces. Or not. I haven't thought about this stuff for years. Definitely possible I forgot the ordering of things.
    - DiabloD3 1y ago
      UWP most certainly did not exist when WinRT came into existence. WinRT, itself, is also more or less the third version of this attempt: Managed C++ came first, then C++/CLI, then the WinRT era and C++/CX. C++/CLI and C++/CX are semi-managed, you only need to use the extensions when interacting with WinRT, although you're free to write your entire app in that dialect.
  - cshokie 1y ago
    WinRT is not the same thing as managed .NET code. There is no requirement that a UWP is .NET. There are many examples of unmanaged C++ UWPs, including the open source Windows Terminal. WinRT is a mechanism to express APIs in a way that is amenable to cross-language usage. It is built on top of COM, and is not a replacement for COM.
    - DiabloD3 1y ago
      Windows Terminal is sort of a clusterfuck of multiple programs, only one of which is a UWP program (the actual visible WinUI shell that runs) which you're not allowed to do as a UWP-era Microsoft Store app, but they got internal permission to do that. Its now a WinUI 3.x program, apparently, and now the Store no longer requires UWP programs, so WT now only needs to make the "ships inside of Windows release images" guys happy, which apparently is harder than making the UWP-era Store guys happy.
crinkly 1y ago
Still writing win32 stuff like it’s 1995 here. We have bits of ATL/MFC hanging out which are throughly abandoned. I don’t trust WinUI at all. I was surprised, when I spoke to a former colleague, to find that an internal tool I wrote 25 years ago is still being maintained. Win32 as well.
- ffsm8 1y ago
  Software that solves an actual problem has the tendency to stick around, no matter how much time elapsed. Just remember, cobol is still in active use, today
- DougN7 1y ago
  MFC support is still in the latest Visual Studio, and it looks like ATL as well.
  - dh2022 1y ago
    I was surprised to see ATL/MFC received security updates such as Spectre mitigation. So there is still some support for these 30 year old components.
    - crinkly 1y ago
      That’s only because half office hangs off it. If it didn’t they wouldn’t have just left it.
  - pjmlp 1y ago
    Which so much better tooling than XAML C++ with C++/WinRT, it is a tragedy.
  - crinkly 1y ago
    It’s in there because it’s a cockroach. It is throughly abandoned though, frozen in time. You can observe this looking at the state of old outlook.
    - 1y ago
DiabloD3 1y ago
They already do, though. The big UI refresh in Win10 is all XAML, and the new Win11 taskbar (the one we all hate) is now a totally normal XAML app. WinUI 3's big changes (to get a 3.0 version number) is not with the XAML stack itself, but its new ability to be called by unmanaged apps as a normal UI toolkit, so it can finally be used by all apps. No more using Shell UI like we're writing Win 3.1 apps. And yes, some stuff in Win11 still isn't WinUI, which is kind of annoying, but some of those dialogs hidden away in Windows are at least 20 years old, and probably would need to be entirely rewritten, not merely have their UI's updated. Also, fun fact: The Win8/10 taskbar's code predates Avalon (the prototype/codename for WPF), and trying to change/fix it at all usually ended up breaking it. It's one of the few binaries on Windows that would not be recompiled to build a new release image in fear of breaking it. Rewriting the taskbar made sense, GETTING RID OF SMALL MODE DID NOT, GODDAMNIT MICROSOFT.
- Kwpolska 1y ago
  > The Win8/10 taskbar's code predates Avalon (the prototype/codename for WPF), and trying to change/fix it at all usually ended up breaking it. It's one of the few binaries on Windows that would not be recompiled to build a new release image in fear of breaking it. The taskbar that underwent a major redesign in Windows 7 (released after WPF)? Also, that binary is explorer.exe, surely it got rebuilt quite often for new ads. features, and fixes?
  - DiabloD3 1y ago
    The taskbar exists in its own timeline, apparently. (Ex-)Microsoft engineers working in the UI/UX team for Windows itself have spoken about how much of a nightmare dealing with that thing was. Also, the taskbar technically exists as a dll, not an exe, explorer.exe would link to it and run it if it was being ran as the UI shell. This is now split out to its own exe (Shell Experience Host iirc), and explorer.exe is now only File Explorer. Since it exists as a dll, btw, this is how the Win10 taskbar injectors work, they just call the dll (which still ships in Win11) instead of letting Shell Experience Host do the Win11 thing. The sane way of handling this, btw, is just use Shell Experience Host injectors to get the desired behaviors, such as using Windhawk and use m417z's taskbar height and icon size plugin (the third most popular Windhawk plugin); to match Vista/7 era small, set to height 32, icon size 16, taskbar button width 28.
tcfhgj 1y ago
I think only WinUI2 (deprecated) is an evolution of UWP (uses WinRT APIs). WinUI3 is something different.
- cheschire 1y ago
  WinUI 3 still supports WinRT. It ALSO supports more. It's an evolution of WinUI 2, not just a simple version bump, but also not a completely new tech. It's probably a closer evolution to go from WinUI 2 to 3 than it was to go from Angular 1 to 2. https://learn.microsoft.com/en-us/windows/apps/winui/winui3/xaml-templated-controls-cppwinrt-winui-3 https://learn.microsoft.com/en-us/windows/apps/winui/winui3/... https://learn.microsoft.com/en-us/windows/apps/develop/platform/csharp-winrt/authoring https://learn.microsoft.com/en-us/windows/apps/develop/platf...
  - tcfhgj 1y ago
    > WinUI 3 still supports WinRT. I think this is completely independent. You can simply use WinRT APIs, because Win32 Apps can use them now. WinUI3 apps are win32 apps. > but also not a completely new tech. Not sure about this. UWP APIs work out of the box. For WinUI3 you need the Windows App SDK, and it is much slower and heavy than UWP (out of curiosity I created a very simple app and it was fast just a few dozen kbs big)
pjmlp 1y ago
Hardly an evolution, that is how it is sold, reality is something else, trailing behind UWP with half the tooling.

qcnguy 1y ago

WinRT came out of UWP I think. UWP was their first attempt to move beyond .NET

cheschire 1y ago
WinRT was windows 8. Remember the ARM-powered Surface RT had the same branding? UWP came along in windows 10.
- tcfhgj 1y ago
  WinRT was introduced with windows 8, the WinRT APIs still exist in Windows 11.
  - cheschire 1y ago
    Yep! I was implying it was the same timeframe as windows 8, but I see where my wording could easily have been taken literally.
DiabloD3 1y ago
You have that backwards. WinRT is the managed languages runtime for Windows, introduced in Win8. Its sort of the replacement for COM/OLE but also defines the ABI dialect in a way that allows managed languages to call unmanaged code without an FFI penalty. UWP is built on WinRT, and acts as a fully managed app container, similarly to how phone apps exist on your phone. It allows WinRT apps to be deployed to any Microsoft platform, Windows, XBox, Windows Phone, etc, but also Android and iOS, and also as PWA, and are guaranteed to run identically on any of those platforms. UWP apps must be written a fully managed language that runs on the CLR (ex: C# runs on the CLR, but C++/WinRT does not). UWP also uses the second generation of WinUI-family XAML UIs, which means all UWP apps use completely native UIs, instead of slow non-native Javascript shit in a web canvas. The WinUI family of XAML UIs started with WPF, and a slightly incompatible version of it also appeared in Silverlight (WPF = WinUI 1.0), then was brought to UWP (= WinUI 2.0), and is now its own stand alone thing that any app can use, managed or not, as 3.0. WinRT is not an attempt to move beyond .NET, instead it is their way of allowing .NET to natively call code, and make .NET languages first class in Windows.
- qcnguy 1y ago
  Yeah but I think when it was introduced it wasn't a thing you could use separate from the rest of UWP. What changed in Win10 was you could use WinRT APIs from regular Win32 apps too. They started breaking UWP up into independent pieces. Or not. I haven't thought about this stuff for years. Definitely possible I forgot the ordering of things.
  - DiabloD3 1y ago
    UWP most certainly did not exist when WinRT came into existence. WinRT, itself, is also more or less the third version of this attempt: Managed C++ came first, then C++/CLI, then the WinRT era and C++/CX. C++/CLI and C++/CX are semi-managed, you only need to use the extensions when interacting with WinRT, although you're free to write your entire app in that dialect.
- cshokie 1y ago
  WinRT is not the same thing as managed .NET code. There is no requirement that a UWP is .NET. There are many examples of unmanaged C++ UWPs, including the open source Windows Terminal. WinRT is a mechanism to express APIs in a way that is amenable to cross-language usage. It is built on top of COM, and is not a replacement for COM.
  - DiabloD3 1y ago
    Windows Terminal is sort of a clusterfuck of multiple programs, only one of which is a UWP program (the actual visible WinUI shell that runs) which you're not allowed to do as a UWP-era Microsoft Store app, but they got internal permission to do that. Its now a WinUI 3.x program, apparently, and now the Store no longer requires UWP programs, so WT now only needs to make the "ships inside of Windows release images" guys happy, which apparently is harder than making the UWP-era Store guys happy.

crinkly 1y ago

Still writing win32 stuff like it’s 1995 here. We have bits of ATL/MFC hanging out which are throughly abandoned. I don’t trust WinUI at all. I was surprised, when I spoke to a former colleague, to find that an internal tool I wrote 25 years ago is still being maintained. Win32 as well.

ffsm8 1y ago
Software that solves an actual problem has the tendency to stick around, no matter how much time elapsed. Just remember, cobol is still in active use, today
DougN7 1y ago
MFC support is still in the latest Visual Studio, and it looks like ATL as well.
- dh2022 1y ago
  I was surprised to see ATL/MFC received security updates such as Spectre mitigation. So there is still some support for these 30 year old components.
  - crinkly 1y ago
    That’s only because half office hangs off it. If it didn’t they wouldn’t have just left it.
- pjmlp 1y ago
  Which so much better tooling than XAML C++ with C++/WinRT, it is a tragedy.
- crinkly 1y ago
  It’s in there because it’s a cockroach. It is throughly abandoned though, frozen in time. You can observe this looking at the state of old outlook.
  - 1y ago

DiabloD3 1y ago

They already do, though. The big UI refresh in Win10 is all XAML, and the new Win11 taskbar (the one we all hate) is now a totally normal XAML app. WinUI 3's big changes (to get a 3.0 version number) is not with the XAML stack itself, but its new ability to be called by unmanaged apps as a normal UI toolkit, so it can finally be used by all apps. No more using Shell UI like we're writing Win 3.1 apps. And yes, some stuff in Win11 still isn't WinUI, which is kind of annoying, but some of those dialogs hidden away in Windows are at least 20 years old, and probably would need to be entirely rewritten, not merely have their UI's updated. Also, fun fact: The Win8/10 taskbar's code predates Avalon (the prototype/codename for WPF), and trying to change/fix it at all usually ended up breaking it. It's one of the few binaries on Windows that would not be recompiled to build a new release image in fear of breaking it. Rewriting the taskbar made sense, GETTING RID OF SMALL MODE DID NOT, GODDAMNIT MICROSOFT.

Kwpolska 1y ago
> The Win8/10 taskbar's code predates Avalon (the prototype/codename for WPF), and trying to change/fix it at all usually ended up breaking it. It's one of the few binaries on Windows that would not be recompiled to build a new release image in fear of breaking it. The taskbar that underwent a major redesign in Windows 7 (released after WPF)? Also, that binary is explorer.exe, surely it got rebuilt quite often for new ads. features, and fixes?
- DiabloD3 1y ago
  The taskbar exists in its own timeline, apparently. (Ex-)Microsoft engineers working in the UI/UX team for Windows itself have spoken about how much of a nightmare dealing with that thing was. Also, the taskbar technically exists as a dll, not an exe, explorer.exe would link to it and run it if it was being ran as the UI shell. This is now split out to its own exe (Shell Experience Host iirc), and explorer.exe is now only File Explorer. Since it exists as a dll, btw, this is how the Win10 taskbar injectors work, they just call the dll (which still ships in Win11) instead of letting Shell Experience Host do the Win11 thing. The sane way of handling this, btw, is just use Shell Experience Host injectors to get the desired behaviors, such as using Windhawk and use m417z's taskbar height and icon size plugin (the third most popular Windhawk plugin); to match Vista/7 era small, set to height 32, icon size 16, taskbar button width 28.

tcfhgj 1y ago

I think only WinUI2 (deprecated) is an evolution of UWP (uses WinRT APIs). WinUI3 is something different.

cheschire 1y ago
WinUI 3 still supports WinRT. It ALSO supports more. It's an evolution of WinUI 2, not just a simple version bump, but also not a completely new tech. It's probably a closer evolution to go from WinUI 2 to 3 than it was to go from Angular 1 to 2. https://learn.microsoft.com/en-us/windows/apps/winui/winui3/xaml-templated-controls-cppwinrt-winui-3 https://learn.microsoft.com/en-us/windows/apps/winui/winui3/... https://learn.microsoft.com/en-us/windows/apps/develop/platform/csharp-winrt/authoring https://learn.microsoft.com/en-us/windows/apps/develop/platf...
- tcfhgj 1y ago
  > WinUI 3 still supports WinRT. I think this is completely independent. You can simply use WinRT APIs, because Win32 Apps can use them now. WinUI3 apps are win32 apps. > but also not a completely new tech. Not sure about this. UWP APIs work out of the box. For WinUI3 you need the Windows App SDK, and it is much slower and heavy than UWP (out of curiosity I created a very simple app and it was fast just a few dozen kbs big)

pjmlp 1y ago

Hardly an evolution, that is how it is sold, reality is something else, trailing behind UWP with half the tooling.