7 ms·

Microsoft's UWP = Unwanted Windows Platform?

35 points by sanqui 5y ago

ripley12 5y ago
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.
988747 5y ago
UWP is obsolete, because desktop applications are obsolete. 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.
- no_time 5y ago
  >UWP is obsolete, because desktop applications are obsolete. 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 https://sixtyfps.io
  - donmcronald 5y ago
    > 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 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.
    - pjmlp 5y ago
      It is ironic that "bloated" Swing apps are now a much better performance alternative than Web and Electron apps.
mikewarot 5y ago
Now if we could just get them to drop the .NET nonsense, things could then possibly return to being as stable as NT4 used to be.
- pjmlp 5y ago
  Indeed, lets write everything in pure Win32 C, with windowsx message crackers and STRICT mode, lets make Windows safe again.
  - mikewarot 5y ago
    That would be silly... they could use Rust, if it can compile to native code.
    - pjmlp 5y ago
      Ah another RIR team member.
      - mikewarot 5y ago
        I have zero idea what RIR stands for. I myself would have everything programmed in Pascal. 8)
donmcronald 5y ago
One of the biggest problems developing for Windows is the way code signing works and Microsoft's SmartScreen. I see tons of web apps where I think they'd make more sense as a desktop app and I prefer both JavaFX and Microsoft's platforms over web development, but the web wins for everything in my mind because it's an open platform that no one can take away from me. 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.
pjmlp 5y ago
Yes, big disappointment how everything was managed. 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.
- HeyLaughingBoy 5y ago
  > feels like using Visual C++ 6.0 with ATL 3.0, four years after their introduction Great. Now I'll have nightmares again!
  - pjmlp 5y ago
    Sorry about that, I really don't get how the Windows team can with a straight face call such experience "modern", unless it is some kind of revivalism or Stockholm syndrome.
- popotamonga 5y ago
  Is MFC still a thing?
  - pjmlp 5y ago
mbrodersen 5y ago
Not disappointed or surprised at all. Microsoft routinely promote new frameworks promising the world, and then drop it years later after the faithful have spent $ millions investing in the new platform. I still remember Microsoft trying to convince the world to rewrite billions of lies of C++ in C#. And then after a number of years suddenly doing a 180 and making C++ high priority again. I highly recommend ignoring pretty much everything Microsoft hypes and instead look at what is still working well and being supported 10 years after it was introduced.
- vb6sp6 5y ago
  Even vb6 still works pretty good :p

35 points by sanqui 5y ago

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.

988747 5y ago

UWP is obsolete, because desktop applications are obsolete. 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.

no_time 5y ago
>UWP is obsolete, because desktop applications are obsolete. 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 https://sixtyfps.io
- donmcronald 5y ago
  > 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 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.
  - pjmlp 5y ago
    It is ironic that "bloated" Swing apps are now a much better performance alternative than Web and Electron apps.

mikewarot 5y ago

Now if we could just get them to drop the .NET nonsense, things could then possibly return to being as stable as NT4 used to be.

pjmlp 5y ago
Indeed, lets write everything in pure Win32 C, with windowsx message crackers and STRICT mode, lets make Windows safe again.
- mikewarot 5y ago
  That would be silly... they could use Rust, if it can compile to native code.
  - pjmlp 5y ago
    Ah another RIR team member.
    - mikewarot 5y ago
      I have zero idea what RIR stands for. I myself would have everything programmed in Pascal. 8)

donmcronald 5y ago

One of the biggest problems developing for Windows is the way code signing works and Microsoft's SmartScreen. I see tons of web apps where I think they'd make more sense as a desktop app and I prefer both JavaFX and Microsoft's platforms over web development, but the web wins for everything in my mind because it's an open platform that no one can take away from me. 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.

pjmlp 5y ago

Yes, big disappointment how everything was managed. 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.

HeyLaughingBoy 5y ago
> feels like using Visual C++ 6.0 with ATL 3.0, four years after their introduction Great. Now I'll have nightmares again!
- pjmlp 5y ago
  Sorry about that, I really don't get how the Windows team can with a straight face call such experience "modern", unless it is some kind of revivalism or Stockholm syndrome.
popotamonga 5y ago
Is MFC still a thing?
- pjmlp 5y ago

mbrodersen 5y ago

Not disappointed or surprised at all. Microsoft routinely promote new frameworks promising the world, and then drop it years later after the faithful have spent $ millions investing in the new platform. I still remember Microsoft trying to convince the world to rewrite billions of lies of C++ in C#. And then after a number of years suddenly doing a 180 and making C++ high priority again. I highly recommend ignoring pretty much everything Microsoft hypes and instead look at what is still working well and being supported 10 years after it was introduced.

vb6sp6 5y ago
Even vb6 still works pretty good :p