4 ms·

I'm probably the only person who started learning UWP in 2020; when the pandemic hit and I suddenly had a lot of time on my hands, I spent months building a UWP

I'm probably the only person who started learning UWP in 2020; when the pandemic hit and I suddenly had a lot of time on my hands, I spent months building a UWP application for my own use. 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.

WorldMaker 5y ago
The distribution escape hatch has existed for a long time: Windows 10 has supported sideloading-by-default and double-click to install for APPX and then MSIX since the Anniversary Update. 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".
- ripley12 5y ago
  I've spent a lot of time trying to make MSIX sideloading work (and it is how I "distribute" my app to myself and friends). Unfortunately it's not nearly good enough for broad distribution of applications. 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.
  - easton 5y ago
    MSIX installation doesn't even work in Windows containers (well, server containers, since client containers aren't available outside of the Sandbox). The error is literally "error text missing". 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.
    - ripley12 5y ago
      > There is tons of Microsoft software that cannot even be packaged via MSIX (Office, Visual Studio) 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.
- iggldiggl 5y ago
  While I can see some of the appeal of sandboxing file access, it also breaks a lot of use cases. 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.
  - WorldMaker 5y ago
    Those specific issues were not a problem with UWP. UWP has/had multiple solutions for these problems. Applications could request access to entire folders, including when presenting the UI of a single file access. Not at first (Windows 8 focused more on single-file workflows to start with), and never by default (always opt-in requests and increased permissions grants required). 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.
pjmlp 5y ago
They were also quite good killing C++/CX with C++/WinRT, a framework that to this day lacks VS tooling support beyond a couple of bare bones project templates.

WorldMaker 5y ago

The distribution escape hatch has existed for a long time: Windows 10 has supported sideloading-by-default and double-click to install for APPX and then MSIX since the Anniversary Update. 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".

ripley12 5y ago
I've spent a lot of time trying to make MSIX sideloading work (and it is how I "distribute" my app to myself and friends). Unfortunately it's not nearly good enough for broad distribution of applications. 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.
- easton 5y ago
  MSIX installation doesn't even work in Windows containers (well, server containers, since client containers aren't available outside of the Sandbox). The error is literally "error text missing". 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.
  - ripley12 5y ago
    > There is tons of Microsoft software that cannot even be packaged via MSIX (Office, Visual Studio) 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.
iggldiggl 5y ago
While I can see some of the appeal of sandboxing file access, it also breaks a lot of use cases. 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.
- WorldMaker 5y ago
  Those specific issues were not a problem with UWP. UWP has/had multiple solutions for these problems. Applications could request access to entire folders, including when presenting the UI of a single file access. Not at first (Windows 8 focused more on single-file workflows to start with), and never by default (always opt-in requests and increased permissions grants required). 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.

pjmlp 5y ago

They were also quite good killing C++/CX with C++/WinRT, a framework that to this day lacks VS tooling support beyond a couple of bare bones project templates.