Microsoft brings WinUI to desktop apps: It's a landmark for Windows development, but it has taken far too long
(2020/05/26)
- Reference: 1590483613
- News link: https://www.theregister.co.uk/2020/05/26/microsoft_winui_to_desktop/
- Source link:
Hands On Microsoft has pushed out a preview of WinUI for desktop applications, making it possible for developers to adopt the look and feel of UWP (Universal Windows Platform) without having to adopt the UWP application model.
WinUI is Microsoft’s GUI framework for Universal Windows Platform (UWP), and the big news at the recent virtual Build event was the release of WinUI Preview 1 which also supports Win32, also known as desktop applications. This means developers can create a desktop application using visual components that previously only worked in UWP (leaving aside an existing hybrid option called XAML islands). What is the difference then between a UWP application and a Win32 application, if they now look the same?
The answer is that UWP and Win32 applications are different under the covers. UWP applications are sandboxed, for example with restricted access to the file system according to a [1]complex set of rules .
A desktop application, by contrast, has the file access permissions of the user. A UWP application has an [2]app lifecycle including a suspended state which kicks in if the user minimises it or switches away, whereas a Win32 application runs until the user closes it. Another issue is code that relies on Windows API code using window handles (HWND), which is how the operating system has worked since its first release. This code generally does not work with UWP applications, whereas it does work with WinUI for Win32.
In other words, UWP comes with a fair amount of baggage which is there for a good reason – such as security or power management or system protection – but which can also get in the way and break legacy code. The new WinUI is in effect Microsoft surrendering to compatibility above modernisation.
Under the hood
What was actually released in the preview though? WinUI 3 Preview 1 has lots of limitations, especially on the Win32 side. One of the biggest is a note that [3]says : "WinUI 3.0 content can only be in one window per process or one ApplicationView per app" – not so much Windows as Window.
The tools are also limited. We set up WinUI 3 on a virtual machine, and it needs the latest .NET 5.0 preview bits in both 32-b-bit and 64-bit guise and the latest preview of Visual Studio 2019 (Visual Studio 2019 has been released for ages, but this is a kind of insider build of a forthcoming update). Then one adds a WinUI extension to Visual Studio, start a new WinUI 32-bit application, and get a “Hello world” XAML page with no toolbox or visual designer. Documentation is limited, and the way to proceed is to download and inspect a project called the [4]XAML Controls Gallery which has example code for the controls that work. The master branch does not work, but there is another called winui3preview which does.
It is pretty rough. When can developers use this stuff for real? There are a couple of projected dates worth noting. The first is November 2020, when Preview 4 is scheduled. Despite the name, this will be supported for production "if it meets your needs", according to Microsoft's [5]Community Call presentation at Build. Spring 2021 will see Preview 5 and then general availability – with the further proviso that .NET 5.0 is not a long-term support release. For that, wait until November 2021 and .NET 6.0. Better news is that compatibility with older versions of Windows is not too bad; Microsoft is talking about reaching as far back as Windows 8.1 via compatibility code called polyfills.
[6]
The WinUI 3 roadmap. Patience is called for.
Nevertheless, WinUI 3 is a landmark release for Windows developers. It is not just the decoupling of the GUI API from UWP, but also the addition of needed features like input validation, which means it is maturing and better suited to business applications than before. In theory, it could bring more consistency to the Windows 10 ecosystem, currently a mish-mash of design styles including WPF (Windows Presentation Foundation, based on DirectX), old-style GDI+ Windows 7, UWP in various guises, and applications that do their own thing using cross-platform libraries – though in practice many will stay the same for as long as they continue to work.
There is also the question of the merits of Microsoft's [7]Fluent Design System , which is the look and feel that WinUI enables. In a [8]recent post , Microsoft's director of product design Benedikt Lehnert described the company's goals for Fluent Design, which includes cross-platform as well as Windows. "It can be frustrating when things work differently for no (or some unexplained) reason," he observed; but how do you get a user interface that works "the same" when there is an inherent contradiction between cross-platform consistency and offering a native experience for different operating systems?
Reading Lehnert's piece, it is apparent that Microsoft is focused more on getting Microsoft 365 products working consistently on Windows, macOS, iOS, Android and Web, than on fixing design issues in Windows. Third-party developers also have this problem, which is why Microsoft faces constant requests to make WinUI cross-platform, something which at Build the team said it was considering.
In this context it is worth mentioning the [9]Uno platform , a third-party project which has a measure of official Microsoft blessing in that it is mentioned frequently. Uno’s CTO Jerome Laban turned up in the WinUI community call mentioned above, where he described how this open source project enables WinUI 3.0 to run on iOS, Android, Web - via WebAssembly (Wasm) - and macOS, with plans to add Linux support. As an example, Uno offers something very like the Windows 10 calculator [10]for macOS and iOS . Under the covers Uno uses Xamarin technology, but with WinUI XAML rather than the unique and incompatible flavour of XAML used by Xamarin Forms. Uno has limitations, and currently some issues with Wasm including large download size. Still, you cannot help wondering whether Uno’s approach makes better sense than the MAUI (multi-platform app UI) [11]presented at Build - and not forgetting React Native, which will use WinUI on Windows and enables shared JavaScript code across all platforms, now including macOS.
Microsoft says it has shipped or installed Windows 10 on more than 1 billion devices, which suggests that it remains an important target for developers. Its appeal has been damaged though by too many changes of direction, failure to establish the Microsoft Store as the main route for application discovery and install, and the necessity of cross-platform for many types of application. WinUI and the associated Project Reunion looks promising as a means of modernising applications without forcing developers to adopt UWP, but will not be fully baked until, perhaps, 2021, nine years after [12]the release of Windows 8 . It has taken far too long. ®
[1] https://docs.microsoft.com/en-us/windows/uwp/files/file-access-permissions
[2] https://docs.microsoft.com/en-us/windows/uwp/launch-resume/app-lifecycle
[3] https://docs.microsoft.com/en-us/windows/apps/winui/winui3/#preview-1-limitations-and-known-issues
[4] https://github.com/Microsoft/Xaml-Controls-Gallery
[5] https://www.youtube.com/watch?v=TeS4rX3i_Ls
[6] https://regmedia.co.uk/2020/05/22/roadmap.jpg
[7] https://www.microsoft.com/design/fluent/#/
[8] https://medium.com/microsoft-design/how-fluent-ui-unlocks-the-next-generation-of-microsoft-365-experiences-8b24809faf06
[9] https://platform.uno/
[10] https://apps.apple.com/us/app/uno-calculator/id1464736591#?platform=mac
[11] https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/
[12] https://www.theregister.co.uk/2012/07/09/microsoft_windows8_release_date/
WinUI is Microsoft’s GUI framework for Universal Windows Platform (UWP), and the big news at the recent virtual Build event was the release of WinUI Preview 1 which also supports Win32, also known as desktop applications. This means developers can create a desktop application using visual components that previously only worked in UWP (leaving aside an existing hybrid option called XAML islands). What is the difference then between a UWP application and a Win32 application, if they now look the same?
The answer is that UWP and Win32 applications are different under the covers. UWP applications are sandboxed, for example with restricted access to the file system according to a [1]complex set of rules .
A desktop application, by contrast, has the file access permissions of the user. A UWP application has an [2]app lifecycle including a suspended state which kicks in if the user minimises it or switches away, whereas a Win32 application runs until the user closes it. Another issue is code that relies on Windows API code using window handles (HWND), which is how the operating system has worked since its first release. This code generally does not work with UWP applications, whereas it does work with WinUI for Win32.
In other words, UWP comes with a fair amount of baggage which is there for a good reason – such as security or power management or system protection – but which can also get in the way and break legacy code. The new WinUI is in effect Microsoft surrendering to compatibility above modernisation.
Under the hood
What was actually released in the preview though? WinUI 3 Preview 1 has lots of limitations, especially on the Win32 side. One of the biggest is a note that [3]says : "WinUI 3.0 content can only be in one window per process or one ApplicationView per app" – not so much Windows as Window.
The tools are also limited. We set up WinUI 3 on a virtual machine, and it needs the latest .NET 5.0 preview bits in both 32-b-bit and 64-bit guise and the latest preview of Visual Studio 2019 (Visual Studio 2019 has been released for ages, but this is a kind of insider build of a forthcoming update). Then one adds a WinUI extension to Visual Studio, start a new WinUI 32-bit application, and get a “Hello world” XAML page with no toolbox or visual designer. Documentation is limited, and the way to proceed is to download and inspect a project called the [4]XAML Controls Gallery which has example code for the controls that work. The master branch does not work, but there is another called winui3preview which does.
It is pretty rough. When can developers use this stuff for real? There are a couple of projected dates worth noting. The first is November 2020, when Preview 4 is scheduled. Despite the name, this will be supported for production "if it meets your needs", according to Microsoft's [5]Community Call presentation at Build. Spring 2021 will see Preview 5 and then general availability – with the further proviso that .NET 5.0 is not a long-term support release. For that, wait until November 2021 and .NET 6.0. Better news is that compatibility with older versions of Windows is not too bad; Microsoft is talking about reaching as far back as Windows 8.1 via compatibility code called polyfills.
[6]
The WinUI 3 roadmap. Patience is called for.
Nevertheless, WinUI 3 is a landmark release for Windows developers. It is not just the decoupling of the GUI API from UWP, but also the addition of needed features like input validation, which means it is maturing and better suited to business applications than before. In theory, it could bring more consistency to the Windows 10 ecosystem, currently a mish-mash of design styles including WPF (Windows Presentation Foundation, based on DirectX), old-style GDI+ Windows 7, UWP in various guises, and applications that do their own thing using cross-platform libraries – though in practice many will stay the same for as long as they continue to work.
There is also the question of the merits of Microsoft's [7]Fluent Design System , which is the look and feel that WinUI enables. In a [8]recent post , Microsoft's director of product design Benedikt Lehnert described the company's goals for Fluent Design, which includes cross-platform as well as Windows. "It can be frustrating when things work differently for no (or some unexplained) reason," he observed; but how do you get a user interface that works "the same" when there is an inherent contradiction between cross-platform consistency and offering a native experience for different operating systems?
Reading Lehnert's piece, it is apparent that Microsoft is focused more on getting Microsoft 365 products working consistently on Windows, macOS, iOS, Android and Web, than on fixing design issues in Windows. Third-party developers also have this problem, which is why Microsoft faces constant requests to make WinUI cross-platform, something which at Build the team said it was considering.
In this context it is worth mentioning the [9]Uno platform , a third-party project which has a measure of official Microsoft blessing in that it is mentioned frequently. Uno’s CTO Jerome Laban turned up in the WinUI community call mentioned above, where he described how this open source project enables WinUI 3.0 to run on iOS, Android, Web - via WebAssembly (Wasm) - and macOS, with plans to add Linux support. As an example, Uno offers something very like the Windows 10 calculator [10]for macOS and iOS . Under the covers Uno uses Xamarin technology, but with WinUI XAML rather than the unique and incompatible flavour of XAML used by Xamarin Forms. Uno has limitations, and currently some issues with Wasm including large download size. Still, you cannot help wondering whether Uno’s approach makes better sense than the MAUI (multi-platform app UI) [11]presented at Build - and not forgetting React Native, which will use WinUI on Windows and enables shared JavaScript code across all platforms, now including macOS.
Microsoft says it has shipped or installed Windows 10 on more than 1 billion devices, which suggests that it remains an important target for developers. Its appeal has been damaged though by too many changes of direction, failure to establish the Microsoft Store as the main route for application discovery and install, and the necessity of cross-platform for many types of application. WinUI and the associated Project Reunion looks promising as a means of modernising applications without forcing developers to adopt UWP, but will not be fully baked until, perhaps, 2021, nine years after [12]the release of Windows 8 . It has taken far too long. ®
[1] https://docs.microsoft.com/en-us/windows/uwp/files/file-access-permissions
[2] https://docs.microsoft.com/en-us/windows/uwp/launch-resume/app-lifecycle
[3] https://docs.microsoft.com/en-us/windows/apps/winui/winui3/#preview-1-limitations-and-known-issues
[4] https://github.com/Microsoft/Xaml-Controls-Gallery
[5] https://www.youtube.com/watch?v=TeS4rX3i_Ls
[6] https://regmedia.co.uk/2020/05/22/roadmap.jpg
[7] https://www.microsoft.com/design/fluent/#/
[8] https://medium.com/microsoft-design/how-fluent-ui-unlocks-the-next-generation-of-microsoft-365-experiences-8b24809faf06
[9] https://platform.uno/
[10] https://apps.apple.com/us/app/uno-calculator/id1464736591#?platform=mac
[11] https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/
[12] https://www.theregister.co.uk/2012/07/09/microsoft_windows8_release_date/
Robert Grant
Getting to be the same? MS are the past masters of this. Remember Kin? And Windows Mobile? And Windows RT? And
Warm Braw
I'm not that bothered about the appearance, but the reason that people continue to write Win32 based software is that it works, it works on previous versions of Windows and if Microsoft stop supporting it in future, Windows will be dead anyway. There's really no point in writing a UWP app, it simply restricts the platforms on which it can run.
And, as you say, there have been so many abandoned futures; the only survivor has been the past. Legacy has become Microsoft's USP.
Dan 55
The day ReactOS is up to Win7 level is the day we can stick a fork in MS.
Filippo
Yeah, it's not like web development based on all-open-source stacks is much better. The new shinies come and go even faster than MS's frameworks.
re: new shinies
Steve Davies 3
There is "Nothing like a 'shiny' that is like an MS shiny." (with apologies to M&S)
The PHB brigade will love this. "MS == Great, wonderful, do it today" in their eyes.
And here was me thinking
Neil Barnes
that there might be a time when every application on a W10 desktop would have the same look and feel, the same set of windows decorations, the same UI elements. And it might even look good.
Er, sorry, was in a parallel universe for a moment there. Blame the painkillers.
Sandbox
AMBxx
Why do we always end up with a Sandbox? It's fine for games, but any serious business application soon needs access to more.
Re: Sandbox
Stuart Castle
Depends what the Sandbox allows access to. The average business application might need access to the network, as well as access to it's own resources, and any documents the user has created or has access to. It shouldn't need access to write to any part of any other application, or any system file/folder. OK, the installer might (for adding features to the OS).
NiceCuppaTea
Does this mean i will be able to access the integrated webcam from a win32 app without jumping through UWP hoops now? I hope it does because its PITA at the moment.
Yay, just what we didn't want - yet another way to develop desktop apps with that fugly flat look that Microsoft will decide to delete and rewrite in a couple of years anyway.
This is why people are getting wary of Google - that feeling of the rug being pulled underneath them every five minutes. It's getting to be the same from Micros~1.