Microsoft's UWP = Unwanted Windows Platform?
theregister.com
theregister.com
For me, .NET Native and C++/CX felt great, one was what .NET should have been all along, and the other finally felt like Microsoft was catching up with C++ Builder 25 years later.
The Windows team with their politics, bombed both of them, they let .NET Native lose compatibility with regular .NET improvements, while a team managed to kill C++/CX with C++/WinRT, with the caveat that the tooling for C++/WinRT feels like using Visual C++ 6.0 with ATL 3.0, four years after their introduction.
The github repositories are full of endless bug tickets and improvement requests for WinUI 3.0, WinUI 2.x on UWP, lack of VS tooling for C++/WinRT, lack of bindings for .NET that require developers to write their own boilerplate bindings,....
It is depressing to have advocated this, and now they clearly show not getting it, proven by a discussion I had today how lowlevel App SDK is for .NET devs versus what is available on Apple and Google platforms for managed languages.
Forms, WPF and MFC are really the technologies to play safe on Windows native applications, anything else is getting ready for another rewrite.
Those doing C++ on Windows, maybe adopt Qt or C++ Builder, or just stay with MFC even if it sounds awful to use it in 2021, unless you enjoy editing IDL files without VS support for your XAML bindings, and then manually merge the generated C++ code into the existing project.
Great. Now I'll have nightmares again!
The current Windows C++ folks either push for bare bones Win32 with C++, using WIL, or C++/WinRT writing IDL files with a Notepad like experience.
In this context MFC is way more productive.
Well now they lost even those of us that were hard advocates for the platform reboot moving away from Win32.
I think this is the right call on Microsoft's part. UWP has been semi-abandoned for a while now and it's nice to get some clarity on its future (or lack thereof).
UWP had many pain points (the .NET Native compiler, installation, filesystem access, sandboxing, longstanding XAML limitations), but it wasn't all bad. You can tell that the Windows team spent a lot of effort trying to make UWP/WinRT/WinUI successful, and it's a little sad that most developers never got to see the good parts of UWP. Among other things, UWP made it remarkably easy to build interfaces that "just work" with both touch input and keyboard+mouse.
It's unfortunate that UWP was hobbled from the start with so many restrictions. I think it would have seen much more adoption if it had been built with an escape hatch from the draconian distribution+sandboxing requirements.
The sandboxing requirements and hard opt-out based model made a lot of sense to clean up decades of Windows app development bad habits. I appreciate that you can still opt-in to the sandboxing post-Project Reunion, but as a developer I expect almost no one to bother to opt-in (because it's "optional" and more work) and as a user I mourn that we're looking at just more decades of application security being an untrustworthy mess in Windows because doing the right thing was "too hard".
It's poorly documented and unreliable compared to tried-and-true installation mechanisms like MSI and Inno Setup. I've had MSIX installations fail on nearly-fresh Windows 10 installs with zero useful information presented to the user or logged in the event log.
Don't even get me started on the registry+filesystem virtualization; I've seen it cause bugs in multiple first-party applications when they're installed via the Store.
It's so frustrating, because we really need an installer that can compartmentalize everything, but every time Microsoft tries to do it they either kill the project (Win32 containers on Windows 10X) or make it not work right for 90% of stuff (MSIX). There is tons of Microsoft software that cannot even be packaged via MSIX (Office, Visual Studio), I have no idea how they thought third party devs would be able to do it.
Yup. Office tried MSIX for a little while and then gave up because it broke many things, including the software I work on professionally. It's a mess.
None of the sandboxing implementations I've seen so far properly caters for multi-file file formats [1] for example. The user expectation is that they'll be able to open the respective main file just as they used to (whether through a file picker inside the program or by launching the file from the desktop or a file explorer window) and then everything should just work.
Under strict sandboxing however, the OS takes that request literally and just grants the program access to that one file the user picked, as the OS of course cannot possibly know each and every file types peculiarities regarding companion files that need to be accessed as well in addition to the one file the user explicitly selected.
So the result is either making it impossible to easily opening that kind of files, or else weakening of the sandbox up to a point where it is possibly almost pointless.
(Android unfortunately seems to have opted for "making it impossible" and even goes one step further in breaking things, because Google's preferred way of launching files in other apps actually actively tries to obscure the file system location of the file that's being opened [2], so even if the receiving app already had the proper access rights for the corresponding file(s)/directory or else was prepared to request them itself, it might not actually be able to determine which file in which directory it is that it needs to look at)
[1] Multi-part archives, multi-part video files, playlists, videos with separate subtitle files, HTML documents containing links to other local HTML documents or referencing various sub-resources (images/videos/audio/style sheets/scripts/...), Audacity projects, images with metadata in external sidecar files, ditto for georeferenced images, QGIS projects, AutoCAD's lock file implementation, DWG files as such actually now that I think of it, ...
[2] In practice, the default implementation for sharing files with other apps does leak the file system path in the URI that's being passed to the receiving app, but according to the documentation the URI is supposed to be treated as an opaque value and so you cannot fully rely on this behaviour for reverse engineering the file system path.
UWP was rather well designed as a sandbox from a file access standpoint. It was just hard to use, especially with the "too many learning curves at once" thing where using the sandbox meant using an entire new GUI and dealing with entire new process isolation models etc.
That'd indeed help somewhat, but where is this documented? Skimming through the UWP documentation I didn't really see anything like that being mentioned. And would that also work when a file is being launched from elsewhere or being dragged-and-dropped? What little is mentioned in the documentation indicates that you only get access to that single file and nothing else.
The only thing I found (other than giving up and simply requesting "broad file system access") is that console apps can get permission to automatically access the current working directory and all subfolders.
Plus this still doesn't cover all file formats, because some of them (e.g. playlists, HTML files, DWG files, etc. etc.) can reference additional files in arbitrary other directories. Also to some extent this is already a case of "weakening of the sandbox up to a point where it is possibly almost pointless" – if a file happens to reside in the top-level documents folder and I want to open it under that model, "this folder and all subfolders"-style access means access the the whole Documents folder.
The way AppGet worked where I could click a button on a webpage and launch an app was something that I really liked. Microsoft could make a better version of that by allowing domain validated code signing for sandboxed apps. Of course, they'd need to give up control over curation for it to be any good and I'd be surprised if they'd do that.
The Fortune 100 company I currently work for had UWP application for some internal needs. The main pain point was that it was distributed to some private instance of Microsoft AppStore, which meant every time we released new version it had to undergo certification process, and then it would take days to actually push it to user's laptops.
We rewrote the app as the Angular web application, and never looked back. Now every time we deploy the new version all users get the update immediately.
You have a point that for some applications, mainly the "some textboxes and buttons" variety used in things like data entry are better served by a webapp. As for other things every time I scroll up in a html5 chat application and the fans of my laptop go WHIRR I'm reminded that for anything non trivial you are still better off getting your hands dirty and start using a good GUI framework from the language of your choice.
For a while I thought that WASM will bridge this gap and bring a future of near native performance to webapps then results like the ironically named sixtyfps[0] toolkit having trouble pushing 20fps on my 2 year old flagship phone made me skeptical whether it will ever happen.
[0]: https://sixtyfps.io
I remember writing GUIs in (Java) Swing where you could dump 50-100k items in a table and sort/filter them without much effort. Translate that into a modern webapp and it's probably 50k round trips while melting a high end CPU. Lol.
Not everything can be done as PWAs, as proven by Electron garbage.