7 ms·

Creator of Rufus outlines the problems with Microsoft's UWP

95 points by onlyforthat 5y ago

pjmlp 5y ago
Reposting my comment from the Reddit discussion, He missed two important point that really puts me off. The continuous reboots since Windows 8 was introduced. The complete lack of respect for paying customers to deprecate C++/CX in name of ISO C++17 compatibility, with C++/WinRT, without any kind of Visual Studio tooling support, even after 4 years in development. So now any .NET Native developer that would be dealing with C++/CX for those APIs that the WinDev refuses to create WinRT bindings, needs to write IDL files without any tooling, copy and merge generated files into their projects. Wait for ISO C++ to get reflection and maybe we will do something about it they say. Sometimes I get the feeling WinDev requires Notepad as their IDE. Speaking of .NET Native, it is in maintenance, expect nothing beyond .NET Core 3.1 / C# 7.3.
- JackGreyhat 5y ago
  To be clear: thats the stuff that puts you off with UWP, not Rufus, right?
  - pjmlp 5y ago
    Yes, me and plenty of others disappointed how things turned out to be, most likely Rufus will also agree with these additional points.
- pianoben 5y ago
  > Sometimes I get the feeling WinDev requires Notepad as their IDE When I was involved with Win32 Office, this (or the moral equivalent with VS Code) was often the case. Proper Visual Studio support was kludgy and difficult to maintain, and many (myself included) did without. Most of the major desktop product groups have 30+ year old codebases and sure as hell aren't working off the latest C++, let alone C++/WinRT bindings. They've got other tools, or just put up with the drudgery because it's all they know.
  - pjmlp 5y ago
    Thanks for confiming this. How else can someone praise C++/WinRT versus the capabilities of C++/CX, which was finally something on the Microsoft side that could be compared with C++ Builder. Sure it is an uplevel from WRL, however almost no one outside Redmod ever cared that WRL existed. The only way to consider C++/WinRT on its present state as good is if the person in question never knew anything better, including MS own tooling.
serentty 5y ago
What's the point of posting this now? Pure UWP is practically dead. Microsoft has made most of the new APIs and GUI features originally meant for UWP available to all Windows programs through WinRT/COM. UWP is simply being absorbed into the wider Windows ecosystem. You only need to deal with the UWP sandbox these days if you're a masochist.
- pjmlp 5y ago
  What they are making available in Win32 still requires code rewriting, is incomplete, while throwing away the VS tooling support they have on the UWP side of the fence. Don't expect much adoption love.
  - mwcampbell 5y ago
    > Don't expect much adoption love. This is disappointing to me, even though I'm no longer at Microsoft, because it means that Windows is now the only major platform where there isn't an official modern platform-native UI toolkit that people are likely to use. Win32 isn't really a good choice for new applications because it uses an antiquated graphics implementation (GDI). Win32 also doesn't make it easy to tweak or extend the accessibility implementation of a standard control. All of this means that for developers of native applications, Windows makes it harder to do the right thing with regard to accessibility than, say, Mac or iOS. If WinUI 3 actually took off, it might fix this.
    - ripley12 5y ago
      I don’t particularly expect WinUI 3 to take off, sadly. I agree that it’s disappointing. The team still has a lot of work to do; unpackaged applications still aren’t supported, for one. And even once it’s production-ready (next year?), I’m not sure it will be good enough to use instead of web UI. I do quite like how easy it is to build UIs that work for both keyboard+mouse and touchscreens. But overall it’s basically WPF with a few improvements, and the worst parts of WPF (styling, verbosity) are still there.
      - 5y ago
jfkgktkrjt 5y ago
> At this stage, it'd probably be 2023 (Windows 8.1 formal end of support) before I can realistically look at transitioning away from tried and trusted (and universal) Win32/GDI to something else, especially considering that Microsoft is still promising that they might try to get their shit together in terms of allowing Win32 apps to use modern UI APIs with the NOT YET FINALIZED AND WAY TOO NEW TO TRANSITION TO WinUI 3.0 Electron Rufus confirmed.
FpUser 5y ago
I made tons of Desktop applications for Windows. Not a single one uses UWP. All are native Win32. Zero problems with acceptance / distribution for them not being UWP. Also probably worth mentioning that for Desktop Windows apps I use Delphi and its open source sibling - Lazarus. Those provide very nice GUI toolkits and are true RAD tools while producing reasonably fast native code.
ArkanExplorer 5y ago
I think Windows could succeed with UWP if they embraced 0% sales commission, and just charged a yearly fee per app (which could scale based on units sold, to cover credit card fees). They should allow developers to directly distribute the software from their own websites, and for 3rd-party stores to sell and distribute UWP apps.
- Sebb767 5y ago
  > which could scale based on units sold, to cover credit card fees Wouldn't that simply be a sales commission again, just billed yearly?
- thrower123 5y ago
  Regardless of any financial considerations with the Store around UWP, they really just screwed the pooch on the developer experience. Going back to Window 8, it's been a trainwreck for years. Nobody wants to chase their recommended newest thing when it is perpetually half-baked, so a fair number of people have thrown up their hands and decided to just stick with tried-and-true WinForms or WPF or raw Win32 forever.
  - pjmlp 5y ago
    The very fact that WinDev doesn't get it why using COM and dealing with IDL files without any kind of tooling support is a problem shows how they don't even make an effort to understand what Windows developers want. It is not like something like C++ Builder and Delphi don't exist for 25 years now.
lostmsu 5y ago
UWP is fine and in fact should be preferred for apps targeted at content consumption. E.g. you want your IM, Facebook app, media player, all the video games to be UWP so that you would know the companies making these apps are not stealing your data and not making your system too vulnerable to RCE attacks. This also applies for any professional apps that do not require extensive access to the file system. For the rest of the stuff like system tools, arbitrary file editors, user interface utilities you need to run in full trust UWP is currently not suitable.
- Koiwai 5y ago
  Those should be web apps.
  - lostmsu 5y ago
    Only a few of them can be web apps. Web is too restricted.
- iggldiggl 5y ago
  > media player Media players are already a somewhat iffy proposition because playlists, subtitles or multi-part (video) files for example are the kind of multi-file file formats that don't work well with heavily sandboxed file access because of the implicit relationships between separate files that the OS doesn't know anything about.
  - lostmsu 5y ago
    Usually they can be restricted to specific folders, e.g. music, video, photos.
bob1029 5y ago
We just started looking at building a new UWP app and have been wondering what reasonable alternatives may exist. I don't think anyone on our team is hellbent on authoring XAML documents, so maybe we start looking back at stuff like win32.
- pjmlp 5y ago
  Depends on which technlogy you want to use. For C++, the path to avoid XAML is to stay with legacy MFC, adopt Qt or C++ Builder. For .NET, there is really no way around XAML, other than keeping using Windows Forms, or doing everything by hand calling the .NET classes that map into XAML components, regardless of WPF, WinUI or MAUI. Then there is Delphi as well.

95 points by onlyforthat 5y ago

Reposting my comment from the Reddit discussion, He missed two important point that really puts me off. The continuous reboots since Windows 8 was introduced. The complete lack of respect for paying customers to deprecate C++/CX in name of ISO C++17 compatibility, with C++/WinRT, without any kind of Visual Studio tooling support, even after 4 years in development. So now any .NET Native developer that would be dealing with C++/CX for those APIs that the WinDev refuses to create WinRT bindings, needs to write IDL files without any tooling, copy and merge generated files into their projects. Wait for ISO C++ to get reflection and maybe we will do something about it they say. Sometimes I get the feeling WinDev requires Notepad as their IDE. Speaking of .NET Native, it is in maintenance, expect nothing beyond .NET Core 3.1 / C# 7.3.

JackGreyhat 5y ago
To be clear: thats the stuff that puts you off with UWP, not Rufus, right?
- pjmlp 5y ago
  Yes, me and plenty of others disappointed how things turned out to be, most likely Rufus will also agree with these additional points.
pianoben 5y ago
> Sometimes I get the feeling WinDev requires Notepad as their IDE When I was involved with Win32 Office, this (or the moral equivalent with VS Code) was often the case. Proper Visual Studio support was kludgy and difficult to maintain, and many (myself included) did without. Most of the major desktop product groups have 30+ year old codebases and sure as hell aren't working off the latest C++, let alone C++/WinRT bindings. They've got other tools, or just put up with the drudgery because it's all they know.
- pjmlp 5y ago
  Thanks for confiming this. How else can someone praise C++/WinRT versus the capabilities of C++/CX, which was finally something on the Microsoft side that could be compared with C++ Builder. Sure it is an uplevel from WRL, however almost no one outside Redmod ever cared that WRL existed. The only way to consider C++/WinRT on its present state as good is if the person in question never knew anything better, including MS own tooling.

serentty 5y ago

What's the point of posting this now? Pure UWP is practically dead. Microsoft has made most of the new APIs and GUI features originally meant for UWP available to all Windows programs through WinRT/COM. UWP is simply being absorbed into the wider Windows ecosystem. You only need to deal with the UWP sandbox these days if you're a masochist.

pjmlp 5y ago
What they are making available in Win32 still requires code rewriting, is incomplete, while throwing away the VS tooling support they have on the UWP side of the fence. Don't expect much adoption love.
- mwcampbell 5y ago
  > Don't expect much adoption love. This is disappointing to me, even though I'm no longer at Microsoft, because it means that Windows is now the only major platform where there isn't an official modern platform-native UI toolkit that people are likely to use. Win32 isn't really a good choice for new applications because it uses an antiquated graphics implementation (GDI). Win32 also doesn't make it easy to tweak or extend the accessibility implementation of a standard control. All of this means that for developers of native applications, Windows makes it harder to do the right thing with regard to accessibility than, say, Mac or iOS. If WinUI 3 actually took off, it might fix this.
  - ripley12 5y ago
    I don’t particularly expect WinUI 3 to take off, sadly. I agree that it’s disappointing. The team still has a lot of work to do; unpackaged applications still aren’t supported, for one. And even once it’s production-ready (next year?), I’m not sure it will be good enough to use instead of web UI. I do quite like how easy it is to build UIs that work for both keyboard+mouse and touchscreens. But overall it’s basically WPF with a few improvements, and the worst parts of WPF (styling, verbosity) are still there.
    - 5y ago

jfkgktkrjt 5y ago

> At this stage, it'd probably be 2023 (Windows 8.1 formal end of support) before I can realistically look at transitioning away from tried and trusted (and universal) Win32/GDI to something else, especially considering that Microsoft is still promising that they might try to get their shit together in terms of allowing Win32 apps to use modern UI APIs with the NOT YET FINALIZED AND WAY TOO NEW TO TRANSITION TO WinUI 3.0 Electron Rufus confirmed.

FpUser 5y ago

I made tons of Desktop applications for Windows. Not a single one uses UWP. All are native Win32. Zero problems with acceptance / distribution for them not being UWP. Also probably worth mentioning that for Desktop Windows apps I use Delphi and its open source sibling - Lazarus. Those provide very nice GUI toolkits and are true RAD tools while producing reasonably fast native code.

ArkanExplorer 5y ago

I think Windows could succeed with UWP if they embraced 0% sales commission, and just charged a yearly fee per app (which could scale based on units sold, to cover credit card fees). They should allow developers to directly distribute the software from their own websites, and for 3rd-party stores to sell and distribute UWP apps.

Sebb767 5y ago
> which could scale based on units sold, to cover credit card fees Wouldn't that simply be a sales commission again, just billed yearly?
thrower123 5y ago
Regardless of any financial considerations with the Store around UWP, they really just screwed the pooch on the developer experience. Going back to Window 8, it's been a trainwreck for years. Nobody wants to chase their recommended newest thing when it is perpetually half-baked, so a fair number of people have thrown up their hands and decided to just stick with tried-and-true WinForms or WPF or raw Win32 forever.
- pjmlp 5y ago
  The very fact that WinDev doesn't get it why using COM and dealing with IDL files without any kind of tooling support is a problem shows how they don't even make an effort to understand what Windows developers want. It is not like something like C++ Builder and Delphi don't exist for 25 years now.

lostmsu 5y ago

UWP is fine and in fact should be preferred for apps targeted at content consumption. E.g. you want your IM, Facebook app, media player, all the video games to be UWP so that you would know the companies making these apps are not stealing your data and not making your system too vulnerable to RCE attacks. This also applies for any professional apps that do not require extensive access to the file system. For the rest of the stuff like system tools, arbitrary file editors, user interface utilities you need to run in full trust UWP is currently not suitable.

Koiwai 5y ago
Those should be web apps.
- lostmsu 5y ago
  Only a few of them can be web apps. Web is too restricted.
iggldiggl 5y ago
> media player Media players are already a somewhat iffy proposition because playlists, subtitles or multi-part (video) files for example are the kind of multi-file file formats that don't work well with heavily sandboxed file access because of the implicit relationships between separate files that the OS doesn't know anything about.
- lostmsu 5y ago
  Usually they can be restricted to specific folders, e.g. music, video, photos.

bob1029 5y ago

We just started looking at building a new UWP app and have been wondering what reasonable alternatives may exist. I don't think anyone on our team is hellbent on authoring XAML documents, so maybe we start looking back at stuff like win32.

pjmlp 5y ago
Depends on which technlogy you want to use. For C++, the path to avoid XAML is to stay with legacy MFC, adopt Qt or C++ Builder. For .NET, there is really no way around XAML, other than keeping using Windows Forms, or doing everything by hand calling the .NET classes that map into XAML components, regardless of WPF, WinUI or MAUI. Then there is Delphi as well.