Discussion: Opportunities to add value to WinRT

[jtorjo]

Discussion: Opportunities to add value to WinRT

Why am I writing here? Because it's the only place I think (and hope!) someone will actually listen...

I've been developing Windows apps for as long as I know myself (22.5 years). But in the last few months, while porting an app from WPF to UWP I've constantly found myself, to put it mildly, just wanting to give it all up.

So lets start with the positive:

• For the UWP team and WinUI team - nothing but respect. I love you guys!
• Another awesome thing is AppCenter, that is beyond awesome!

For the WinRT side, lets start with the positive:

• nothing comes to mind.

But on the negative side, the following are beyond blockers - if there was a word stronger than blocker, these would be it:

The Querying for files API Is Beyond slow

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html This has been known for years. It's simply beyond my capability to understand how this hasn't been fixed by now. How can you possibly develop non-trivial apps when we have this issue? I've spent days working around this issue, and none of my solutions properly fix it. They alleviate it a bit, but the issue still remains. And who's suffering because of this? Me, because my users think my app is slow...

The broadSystemAccess API

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html (see my answer to that question) I'm not gonna critique the whole "I need to request full HDD access" (which is stupid, anyway). I will critique this, which is beyond stupid:

1. When you request broadSystemAccess, your application, by default, does not have that access.
2. You need to make your app resilient to this change (which is time consuming, btw), and handle "Access Denied" requests. In such a case, you should point your user to open "File System Privacy Settings" (there is a rather simple way to do it)
3. The user ends up in that settings window, and he'll toggle your app ON...
4. .. at which point, Windows closes your application.
5. The user needs to restart your application

The point 4. is simply beyond stupidity - it's the worst UI design flow anyone could come up with. Do you think users will happily do the above? No they won't - in fact, 79.8% don't do it (my AppCenter data backs this up). Leaving me with either users not using my app, or just having my app look subpar to other native apps.

Creating apps for sideloading outside MS store

https://docs.microsoft.com/answers/questions/4027/uwp-cant-install-signed-application-non-ms-storeco.html This is beyond insane - it's like everyone at MS doesn't want people to create apps to distribute outside the MS store. And, to develop for MS store is like running on a bike with cuffs on your legs. Why do you allow for sideloading outside MS store, but make it close to impossible to actually do it?

The .appinstaller file, that I spent countless hours to finally find a solution and have it actually work, this should be part of the "Deploy" process - Visual Studio should auto generate it. And document it -- there's a small doc somewhere on github that I spent quite a while to find. This should be in the docs!

Also, creating .appinstaller files - is something I found out the hard way - you create the file, put it on the server, download it from there, and then execute it. Modifying it locally and running it will be ignored. This is not written anywhere, something I had to find the (really) hard way.

The "New certificate" issue

https://docs.microsoft.com/answers/questions/6112/updating-existing-app-with-new-certificate-uwp.html This is what made me snap. How can anyone in their right mind think that when I create a new certificate for the same company, and I deploy my UWP app with it, it will be seen by Windows as another app? How can I explain that to my users? Oh, you just updated my app, and lost ALL YOUR SETTINGS. How can this happen? Or even worse, the user will see two apps with the same name, same icon -> how can he know which is which?

Clearly there are countless other issues (like, compilation times are insanely slow!), but they simply pale in comparison to the above. The fact that us, developers, have simply no say in this is very very very sad. We'll slowly move where someone will listen... Which sadly, doesn't seem to be MS anymore...

And a bonus:

Interoperability: Zero

The restrictions of WinRT are so antiquated and stupid, they're beyond my capability to understand them. Not even when you were targeting mobile as well, did they make sense. Let alone now -- Please Microsoft, understand this: BEFORE I will make my app run on a thousand platforms (Hololens, Xbox, whatever), I want to develop a desktop app. STOP WITH THE LIMITATIONS.

I'm one of the very very few that actually tried to develop a UWP app - most people give up really really fast, but I didn't have that luxury, because I need win2d.

[robloo]

I was at your frustration level a few years ago when I first started porting over WPF apps. So I certainly understand your sentiments. There has been some progress since then and as you said the WinUI team is really trying on their end.

From my viewpoint there is a fundamental design issue we can't work around: WinRT was technically handicapped because it has to interop directly with C++ and JavaScript (here is an example, and another). It really doesn't play nice with a lot of the high-level concepts either such as generics. Of course there is one big benefit with this architecture as well: All of Windows can now share the same WinRT API's.

WinRT was also done by the Windows team under Sinofsky I believe which means, yes, they lived in their own world and had no experience working with the existing end-user developer ecosystem. We ended up with a 'least common denominator' API that both native and managed developers don't enjoy working with. This is fundamentally one of the main reasons Windows Phone died -- developers couldn't develop/port apps easily. Without Apps there were no customers. Microsoft did learn this lesson.

So we have lost several of the perks of managed code that we've grown accustomed to over the years. It definitely still seems like a step back from WPF -- I find bugs and incomplete features all the time. I think #1830 would never happen in the WPF days. We still have to move forward somehow.

WinUI 3.0 is clearly a step in the right direction to try to fix this on the frontend at least. Though, I would prefer Microsoft implements a more robust development process and more testing before releasing new controls... I know development is now push changes, fix later. While that may work for apps, it's not a good pattern for a platform where once things are set it's very hard to change them later. (TreeView, NumberBox, etc... have so many issues on first release that never would get out the door, let alone planning stages, 15 years ago).

It is sad for me to see what was once the most powerful UI platform WPF evolve into this. But Microsoft is now, slowly but surely, listening to feedback and fixing things. It is understood there is a lot more work to do.

[kmgallahan]

Do you think users will happily do the above? No they won't - in fact, 79.8% don't do it (my AppCenter data backs this up). Leaving me with either users not using my app, or just having my app look subpar to other native apps.

Perhaps you aren't considering the fact that your users are actually stopping to think: "wait, do I really want to grant this app access to my entire drive?" That is a red-light warning for people not familiar with the app/developer/company.

You're blaming the process users need to go through to grant your app access to their entire drive for the low retention rate. Perhaps you should reconsider your "need" for broadFileSystemAccess in the first place, and rather just have users manually select the folders they feel comfortable giving you access to.

FYI, if I wanted to try an app out and after installation it was like "hey, give me permission to access everything, everywhere", I'd run too.

When you request broadSystemAccess, your application, by default, does not have that access.

Obviously... You only made a request, your users actually have to grant you access if they feel comfortable doing so.

[kmgallahan]

Also, based on the disrespectful title alone that breaks the Microsoft Open Source Code of Conduct, and the content not being about WinUI, this issue should be closed. @jevansaks @jesbis

[kmgallahan]

One last thing to add. I think Rich Lander said it best at the Jan 15th .NET Community Standup (starting @ 1:12:40).

@verelpode You ride the line mentioned in the above video, but you stay constructive and on-topic for the most part, so I value your contributions to the WinUI repo - even if you feel they are fruitless sometimes, as I saw in your recent comment(s).

[jtorjo]

When you request broadSystemAccess, your application, by default, does not have that access.

Obviously... You only made a request, your users actually have to grant you access if they feel comfortable doing so.

That's not the issue: at least on Android/iOS, you get asked that stuff while your app tries to access the HDD, and it does not get closed, as is in our case.

[kmgallahan]

Your app wouldn't close if you presented file picker(s) that let the user choose what they want to give your app access to.

Instead you want it all, are complaining about a minor one-time extra step users have to take, and are blaming your retention rate on this step.

[jtorjo]

Also, based on the disrespectful title alone that breaks the Microsoft Open Source Code of Conduct, and the content not being about WinUI, this issue should be closed. @jevansaks @jesbis

It's really hard to be respectful, when I'm almost going out of my mind. Not to say - I've said this before, there's no place to write about the WinRT. I'd happily use a different tone, if I actually could write, and someone would be listening. All the above cries should simply not exist - WinRT should be mature enough. Yet... no...

Where can the community actually talk to the WinRT team? Is there anyone listening?

[jtorjo]

Your app wouldn't close if you presented file picker(s) that let the user choose what they want to give your app access to.

Instead you want it all, are complaining about a minor one-time extra step users have to take, and are blaming your retention rate on this step.

My app is allowing users to edit photos and videos, and I want the user to easily preview as he chooses, not use an old style file picker. So yeah, it's really important that I get access to all the HDD. And no, those "Pictures" and "Videos" virtual folders are what Microsoft thinks users keep their photos and videos. That's not reality.

[kmgallahan]

I've said this before, there's no place to write about the WinRT.

As your links indicate, you've already been ranting about WinRT on the UWP Q&A forums, which is where you've been directed to go.

So by posting here it seems you just want a larger audience, rather than to actually accomplish anything (since the WinUI team doesn't work on WinRT).

[jtorjo]

As your links indicate, you've already been ranting about WinRT on the UWP Q&A forums, which is where you've been directed to go.

Yet, there's no resolution to any of my issues. On a Q & A, you ask questions, and receive answers. But you can't really suggest anything to change (unfortunately).

[kmgallahan]

My app is allowing users to edit photos and videos, and I want the user to easily preview as he chooses, not use an old style file picker. So yeah, it's really important that I get access to all the HDD.

No its not. Your users don't have photos and videos all over the drive, they are in specific locations that might not be the special folders.

Have the users pick those folders once, then you can always have access via the FutureAccessList. Don't make them give you access to all of their files, and then they won't run away.

[robloo]

@kmgallahan Sure, the tone can be dialed back a bit, but we've all been frustrated before. It's even more frustrating to think that obvious issues aren't being addressed. I think it's sometimes constructive to vent those frustrations in a forum where people can validate them and also offer potential solutions. His technical points are valid, it's just for WinRT and a bit UWP -- both not WinUI XAML controls which this repo represents. For that reason, this probably should be closed as off topic.

I think we can keep these types of discussions professional knowing they originate from frustration and a lot of vested interest in the success of the development ecosystem.

[jtorjo]

Sure, the tone can be dialed back a bit, but we've all been frustrated before. It's even more frustrating to think that obvious issues aren't being addressed.

Thanks :)

[jtorjo]

No its not. Your users don't have photos and videos all over the drive, they are in specific locations that might not be the special folders.

Have the users pick those folders once, then you can always have access via the FutureAccessList. Don't make them give you access to all of their files, and then they won't run away.

Clearly, they are not in those specific locations....

Sure, I can use that FutureAccessList and have users remember where they keep their photos/videos, because we all know where we keep all of our photos/videos, right?

Instead of (what my app does) nicely previewing folders and showing you the folders where you have photos/videos.

[jesbis]

A few notes:

Thanks @jtorjo for taking the time to write about your experiences and feedback, and also for your time on the Q&A page too.

As @robloo and @kmgallahan mentioned most of this isn't directly related to WinUI and you may be pushing the code of conduct a little 🙂

However we also recognize that engagement on the Q&A site and Feedback Hub could be better when it comes to different areas of the Windows developer platform. We really are actively trying to improve that but I get that it's frustrating to find a good place to provide feedback and see whether anything's happening.

For example we really do see everything that comes through Feedback Hub but there isn't a good way to respond or continue a discussion. So, as long as it stays constructive and is related to Windows app UX/development then we're okay with discussing some general platform feedback here if a topic doesn't currently fit well elsewhere.

For what it's worth, these topics also get serious internal attention. We reached out to some WinRT experts today to see if there's any update on these areas that we can share since you neatly summarized some of the top issues with the overall platform and tools.

---

For desktop app development: WinUI 3 is a big part of our effort to decouple the Windows developer platform to remove those interoperability barriers and make it easier to incrementally adopt WinUI and UWP. We know we need to better enable desktop apps with modern UX without requiring all the current restrictions. We have lots of experts including some of the main creators of WPF working on it.

In particular, we're spending a lot of time on Xaml islands and on WinUI for desktop apps and we're looking forward to the next step which will be releasing a preview of that for people to try later this year. We're trying to be more feedback-driven and transparent and that should get easier as we move things like the full Xaml platform (i.e. WinUI 3) to open source.

If people are interested in the current state of the desktop plans then we could also go into a bit more detail in one of the monthly Community Calls - feel free to suggest topics here:

WinUI Community Call (January 22, 2020) #1857

[jtorjo]

Hi @jesbis,

Thanks for looking at my issues!

As @robloo and @kmgallahan mentioned most of this isn't directly related to WinUI and you may be pushing the code of conduct a little 🙂

Yeah, really sorry about that, I just felt I was going out of my mind. The things I mentioned here are critical - I'm really passionate about this, since all of the above I ran into. They all take a huge toll, a lot of people simply just give up even trying.

However we also recognize that engagement on the Q&A site and Feedback Hub could be better when it comes to different areas of the Windows developer platform. We really are actively trying to improve that but I get that it's frustrating to find a good place to provide feedback and see whether anything's happening.

Totally agreed. As a side note, I actually tried to report the broadSystemAccess on Feedback Hub, and after providing all the details, and spending about 15 minutes on it, I ended up somehow probably pressing a hotkey that was the equivalent of "Back" - thus, I lost all my work (no undo, no text being copied to clipboard, nothing). Clearly, I was insanely frustrated and just gave up.

For what it's worth, these topics also get serious internal attention. We reached out to some WinRT experts today to see if there's any update on these areas that we can share since you neatly summarized some of the top issues with the overall platform and tools.

Cool!

For desktop app development: WinUI 3 is a big part of our effort to decouple the Windows developer platform to remove those interoperability barriers and make it easier to incrementally adopt WinUI and UWP. We know we need to better enable desktop apps with modern UX without requiring all the current restrictions. We have lots of experts including some of the main creators of WPF working on it.

That's awesome! I'm definitely looking more that forward to it. It's very likely that I'll update my app once this is done, but until then I'm stuck with a lot of issues.

If people are interested in the current state of the desktop plans then we could also go into a bit more detail in one of the monthly Community Calls - feel free to suggest topics here:

WinUI Community Call (January 22, 2020) #1857

Can I suggest the WinRT topics I mentioned here?

Thanks again!

[Felix-Dev]

For example we really do see everything that comes through Feedback Hub but there isn't a good way to respond or continue a discussion. So, as long as it stays constructive and is related to app development then we're okay with taking some general platform feedback here if a topic doesn't currently fit well elsewhere.

@jesbis This is great news! Many thanks to the WinUI team to show this flexibility and trying to mitigate the (perceived) WinRT-feedback-system issues even though they don't have to!

[verelpode]

@kmgallahan

I think Rich Lander said it best at the Jan 15th .NET Community Standup (starting @ 1:12:40).

So Rich Lander says there that he prefers people with a little bit of aggression but nice at the same time. I think one of the biggest problems in society is that many people are so very "polite" that their behavior becomes extremist and flips over to disrespect and rudeness while superficially appearing "polite". Very "polite" people speak indirectly and vaguely, and this makes their communication difficult to understand and easy to misinterpret. Very "polite" people are disrespectful and rude because they're effectively saying the equivalent of:

"I believe that you can't handle the direct truth, therefore I'll handle you with thick fluffy cotton gloves, and pack you in bubble wrap, and speak to you very politely, indirectly, and vaguely, because if I treat you as a mature adult and express my honest opinions, you'll flip out and explode and go nuts. You're a very fragile, delicate person, and you're immature, thus I must speak extremely politely and indirectly to you, because you can't handle the direct truth."

In that way, when so-called "politeness" is taken to an extreme (as many people do), it becomes disrespectful and rude while still appearing to be "polite". In other words, misunderstanding of politeness and respect is one of the biggest problems in society. Many people do not realize that excessive politeness is disrespectful, and causes projects to fail, etc. This problem of false politeness causes yet another communication failure every second of every hour of every day somewhere in the world -- it happens constantly -- and society suffers greatly because of it.

[verelpode]

@jtorjo Here's the origin of the problem:

Repetition of Nokia's catastrophic mistake

WinRT/UWP accidentally repeated the same mistake as Nokia, BlackBerry, Apple at one point, and other companies. The Nokia story: Nokia was a very successful giant, but later Nokia realized that they had fallen behind in smartphone tech. In order to solve this problem, they needed to make it top priority to realize a series of improved versions of their preexisting system. Instead of doing that, they tried to switch to a new system, and it killed them. Literally killed them -- Nokia Mobile was forced to accept being bought-out by Microsoft.

So then you'd expect that Microsoft would learn from Nokia's mistake and not repeat the same problem. Unfortunately Microsoft did repeat the same mistake as Nokia. Microsoft embarked on WinRT/UWP instead of producing new versions of WPF and .NET Framework. Guess what happened? The same catastrophic disaster as Nokia: It killed them. Windows Mobile is dead and was cancelled by Microsoft executives. Thus unfortunately Microsoft didn't learn from Nokia's catastrophic mistake. Now all the smartphones are running either Android or Apple instead of WinRT/UWP, thus WinRT/UWP was a catastrophic failure that caused Microsoft to completely lose their place in a multi-billion dollar smartphone industry. WinRT/UWP caused multi-billion dollar losses for Microsoft.

BlackBerry made the same mistake as Nokia and Microsoft. BlackBerry was very successful, but later BlackBerry realized that they had fallen behind in smartphone tech. In order to solve this problem, they needed to make it top priority to realize a series of improved versions of their preexisting system. Instead of doing that, they tried to switch to a new system. BlackBerry originally used BlackBerry OS, and then around the year 2013, they switched to the QNX system. What happened? The same as WinRT and Nokia. It killed them. In 2016, BlackBerry announced it would cease designing its own phones.

It also happened with Apple at one point in the past. Apple nearly collapsed and was very lucky to survive. A number of years later, Apple eventually made a strong recovery via smartphones. Lucky to be alive after the catastrophic mistake.

Breaking Changes

Microsoft claims they couldn't continue WPF development; couldn't use WPF for smartphones/tablets because of breaking changes, but that's a case of extreme fear of breaking changes. Yes it's wise to be very careful in regards to breaking changes, but if it's taken to an extreme, then it kills projects and companies. The reality is that breaking changes can in fact be introduced. Microsoft could have released "WPF 5" with support for smartphones/tablets/touchscreens, and announced that it includes breaking changes but no developer is forced to upgrade to it immediately. Preexisting apps don't break because they continue to run with WPF 4 until the app developer is comfortable and ready to switch to WPF 5. Thus the breaking changes don't cause chaos or failures.

It's the same principle as a new version of a NuGet package that includes breaking changes. Your app doesn't suddenly break when the new version of the package is released. Your users continue to use your app and don't experience any problems because your app continues to use the old version of the package until you're comfortable and ready to upgrade your app to use the latest version of the NuGet package. Thus breaking changes can be introduced.

Reversal of standpoint on managed code

Microsoft said managed code provides excellent advantages, and it was absolutely true in my experience using both managed and unmanaged code. I began my career writing unmanaged code. Later I tested Microsoft's claims and I switched to managed code and I experienced excellent improvements in productivity and reliability. Later, Microsoft bizarrely reversed their standpoint and produced WinRT with a basis on unmanaged code, and the ancient Component Object Model (COM) from the year 1993, and excessive use of Win16 (also known as Win32). The basis of WinRT is tech that is decades out-of-date: Native code, COM, and Win16 AKA Win32. It shouldn't be surprising that most app developers were reluctant to switch to WinRT/UWP.

Android is now the market leader. Microsoft can learn from Android. Android apps are typically written using managed code. Although I dislike Java and prefer to use C#, I have to say that Java is much better than native Win16 and COM.

Multiple Microsoft staff members still continue saying "native" as if that's a good thing. I began my career with "native" and I know from years of experience that "native" is a bad thing. Legions of Android developers also know that native is a bad thing, but too many UWP staff members say it as if it's great. To use the words of @jtorjo, the WinRT team was and is "out of touch with reality". The WinRT team continues to behave as if WinRT was a success, despite the fact that it failed catastrophically and Windows Mobile was already cancelled by Microsoft executives.

I have to keep repeating those words again and again: WinRT/UWP was a catastrophic failure. I've forced to keep repeating those words because the WinRT team is "out of touch with reality" in the sense that they refuse to acknowledge that WinRT/UWP was a catastrophic failure and that Microsoft shouldn't continue to repeat the same mistakes of WinRT as if nothing happened.

For example, currently DataGrid is written in modern managed code, but the WinUI teams wants to rewrite DataGrid to use "native" code and believes this is an "upgrade" when in reality it is a downgrade and regression to practices that are decades out-of-date. In general, WinRT/UWP is plagued with mix-ups between modern and obsolete software engineering practices. Thus @jtorjo's use of the words "out of touch with reality" could be interpreted as impolite, but I believe it is an accurate description, even if it wasn't the best choice of words.

For another example of "out of touch with reality", look at the design of WebView2 -- it is like taking a time travel back to the start of my career, decades ago, when we used obsolete concepts such as HRESULT instead of modern exception handling. It is astonishing to see WebView2 being released as a new project in the year 2020 yet still using ancient techniques such as HRESULT and LPCWSTR. The design of WebView2 is out of touch with modern software engineering practices.

[verelpode]

So, along the lines of what Rich Lander said, my previous message demonstrates my respect for the WinUI team, because if I disrespected the WinUI team, then I would always be very polite to the team, or say nothing at all. If I disrespected the team, I'd write off and ignore WinUI: I wouldn't bother writing any messages at all -- I would view WinUI as "hopeless" and a "lost cause" and I wouldn't give any feedback at all. The fact that I give detailed feedback demonstrates that I respect the team. Many people don't give any feedback -- that's disrespectful to the team. It's disrespectful to view the team as being so hopeless that it's not worthwhile writing any feedback for them.

If you were in court, you'd very politely say "Your Honor" to the judge even if you hate his guts. Extreme politeness is rudeness. Judges interpret "Your Honor" as respect but it's actually disrespect.

[jtorjo]

Microsoft embarked on WinRT/UWP instead of producing new versions of WPF and .NET Framework. ...

Agreed. I've been developing UWP for quite a few months now... There are quite a few limitations, but I've done my best to be "zen" about it, and more or less, move on. But the more I would work, the more I realized - that the limitations were in fact WinRT, not UWP.

The thing is, this is what we have, and clearly, we need to move forward with it. In my mind, this should be:

1. UWP needs to hide as much as possible the fact that it uses WinRT and
2. WinRT should strive to remove as many (unneeded) limitations as possible
3. The main focus should be Desktop, and then the other platforms (Hololens, xbox etc)

(p.s. The fact that, for a file, to get its properties, I need to call an async function, still makes me twitch)

Reversal of standpoint on managed code

Why we'd need to deal with COM in WinRT is indeed beyond my understanding. Seems they wrapped some old DCOM code or something, but that should be 100% hidden from users of WinRT. The fact that we need to be aware of COM is really really bad. That, once again, should be as much as possible, hidden from me, the user of the library(ies).

[later edit] Now come to think of it, we'd at least need COM to deal with DirectX. Still, it should be as hidden as possible from the users of libraries.

Multiple Microsoft staff members still continue saying "native" as if that's a good thing.

Native, in the context of "compile to .net native", I do think is a good thing, however, I don't like its limitations. My project fails to compile to .net native, because it uses another lib that I ported to UWP, and uses some APIs, that the powerful Store guys believe is "unacceptable". The lib in question is https://github.com/naudio/NAudio - an awesomely powerful library. For this reason alone, I simply said - I will NOT publish my app to MS store.

For another example of "out of touch with reality", look at the design of WebView2 -- it is like taking a time travel back to the start of my career

I'm not 100% sure, but you're probably right. I do know that WebView is said to be a wrapper over a Win32 control, and I know of a weird bug, that WebView links would not work when the WebView was on top of another control.

[jtorjo]

Hi @robloo ,

Sorry for the late reply

I was at your frustration level a few years ago when I first started porting over WPF apps. So I certainly understand your sentiments. There has been some progress since then and as you said the WinUI team is really trying on their end.

Yes, totally agree. Back in 2016-2017, I wouldn't even touch UWP.

From my viewpoint there is a fundamental design issue we can't work around: WinRT was technically handicapped because it has to interop directly with C++ and JavaScript (here

That is beyond sad, to say the least ... Why of why would we want JS interoperability?

... is an example, and another). It really doesn't play nice with a lot of the high-level concepts either such as generics. Of course there is one big benefit with this architecture as well: All of Windows can now share the same WinRT API's.

There are many things I hate about WinRT - what's one more to the list?

The fact that I even need to know about this, is bad. In fact, I needed to create such 2 small projects, and it was all trial and error, to understand what I'm actually allowed to use.

So we have lost several of the perks of managed code that we've grown accustomed to over the years. It definitely still seems like a step back from WPF -- I find bugs and incomplete features all the time. I think #1830 would never happen in the WPF days. We still have to move forward somehow.

Yup, we do...

WinUI 3.0 is clearly a step in the right direction to try to fix this on the frontend at least. Though, I would prefer Microsoft implements a more robust development process and more testing before releasing new controls... [...]

Agreed 100%.

It is sad for me to see what was once the most powerful UI platform WPF evolve into this. But Microsoft is now, slowly but surely, listening to feedback and fixing things. It is understood there is a lot more work to do.

Yes, there are clearly awesome people at MS that are listening. Lets hope we can turn this around...

[jtorjo]

The Querying for files API Is Beyond slow

Apparently, someone did find a workaround to this. Clearly, it's really really sad this took so long - and this is not preferred way I would like to deal with searching for files, but at least it actually works. https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment-575987737

So, many thanks to @duke7553 !

[lukeblevins]

@jtorjo Happy to help!

[AndrewPawlowski]

I find this discussion very interesting and actually very relevant to the future of Windows UI. That's because WinUI is not sitting in a vacuum. This whole repo has very little value unless it's useful for creating apps that run on something other than WinRT/UWP. WinUI 3.0 could not come soon enough.

We have a vision and a roadmap for the UI on windows, but that sits on the very top of the stack and there is no vision for what's under that surface layer: Is WinUI looking good? YES Can you make modern, good looking apps on Windows now (JAN2020)? NO Can you make a good app with UWP? HELL NO!

We can't really move forward without addressing the elephant in the room: mentioned earlier fact that WinRT and UWP were total failures, not only business-wise but also technologically. I'm personally among the body count. I stopped developing my hobby project when I couldn't figure out how to play a sound when my app lost focus. Trivial. Do trivial things has to be as hard as they are in UWP? Can you call a platform great when trivial things are impossibly difficult? WinUI is just part of a platform, isn't it?

Another elephant in the room. If someone asks: I want to make a new Windows program, what's the best way to do it? There is no straight answer in JAN2020! If you try putting UWP into the answer - you WILL have a bad time. (Is there a single comment, blog post, YouTube video where somebody said: I made a great app with UWP and I liked the process? We all know there isn't. No one is writing about making app with UWP, it literally doesn't exist on the Internet). WPF? No modern controls - dead tech, not a good idea (still better than UWP, though). The honest answer would have to be: try electron, maybe? VSCode is made with that, so you know you can make a good app with it.

And this idea that you can make an app for windows with any language you like is just a cop-out. We are in a situation where you can make a very bad UWP app with any language you want. Bot not at least ONE excellent way of doing it.

The navie thing mentioned before in the thread? Completely agree. Visual Studio - The Juggernaut itself (UI) is made with managed code - WPF. It's great, fantastic even. While even Microsoft can't make OK apps with this supposed superion native code. I see unexpected behavior every single day with OneNote, Weather, and even Start/Search/Taskbar. It feels wonky and sometimes focus doesn't work as it should.

This is a rich and important topic. Very much relevant to WinUI, and sadly there is no better place to talk about it. These topics need to be handled in an open way by Microsoft.

[jtorjo]

We have a vision and a roadmap for the UI on windows, but that sits on the very top of the stack and there is no vision for what's under that surface layer: Is WinUI looking good? YES

Yes it is!

Can you make modern, good looking apps on Windows now (JAN2020)? NO

I do believe you can - but it's really really hard. Trivial things are insanely hard to do (I'm living proof it's possible, but you need nerves of steel for sure):

• on the UI front, there will be issues, but usually you'll get the hang of it
• on the "anything else" front, things are pretty dim.
• dealing with files on UWP is complete hell, due to the StorageFile/Folder API, which, to put it midly, I hate with all my heart

We can't really move forward without addressing the elephant in the room: mentioned earlier fact that WinRT and UWP were total failures, not only business-wise but also technologically. I'm personally among the body count. I stopped developing my hobby project when I couldn't figure out how to play a sound when my app lost focus. Trivial. Do trivial things has to be as hard as they are in

Agreed. Indeed, playing system sounds, which in WPF is like SystemSounds.Beep.Play(), it's not available on UWP.

Basically, there's no sound library on UWP, due to the "great" WinRT restrictions, which basically means - you can't import any functions from DLLs that are win32. So pretty much, every decent library can't be ported to UWP. No libraries, no apps.

On the "sound library" on UWP, naudio has tried its best to work on UWP. Clearly, it fell flat. I did a fork, removed a lot of #ifdefs, and it now works for my needs. I will never be able to publish my app to MS Store, nor do I ever want to.

The best step in the right direction, on my mind, is for MS to

1. Finally focus on Windows Desktop FIRST. Stop going after a thousand platforms, like Hololens, Xbox and the like. Sure, there will be people wanting to develop for those platforms, but the percentage is minuscule.
2. Remove all restrictions API wise - so people can actually compile libs to UWP
3. Once you request broadSystemAccess, just give it and stop being so overprotective.
4. Once you request broadSystemAccess, allow System.IO over all HDD
5. Make it easy to distribute outside the MS store (+ fix the "New Certificate" issue)

Another elephant in the room. If someone asks: I want to make a new Windows program, what's the best way to do it? There is no straight answer in JAN2020! If you try putting UWP into the answer - you WILL have a bad time. (Is there a single comment, blog post, YouTube video where somebody said: I made a great app with UWP and I liked the process? We all know there isn't. No one is writing about making app with UWP, it literally doesn't exist on the Internet). WPF? No modern controls -

Yes, I concur - finding good resources on UWP is close to zero. A lot of issues, you'll just have to tackle and fix on your own.

dead tech, not a good idea (still better than UWP, though). The honest answer would have to be: try electron, maybe? VSCode is made with that, so you know you can make a good app with it.

About WPF I only have words of praise. I've developed for quite a few years. and while the learning curve is quite steep, once you get the hang of it, it's amazing! I did find a few hardcore bugs, which I knew would never get fixed, but that's that.

I was forced to move to UWP, since in order to make my app fast enough, I had to use win2d. There are things that are missing from UWP when it comes to UI (like, at the time I began porting, there's no native way to define the Cursor for a control), but all in all, I always found workarounds.

The navie thing mentioned before in the thread? Completely agree. Visual Studio - The Juggernaut itself (UI) is made with managed code - WPF. It's great, fantastic even. While even Microsoft can't

Clearly, I bet my a**, that you could not create Visual Studio in UWP for the life of me -- and I'm not talking about the UI, you could match and exceed the UI of Visual Studio, but the rest....

This is a rich and important topic. Very much relevant to WinUI, and sadly there is no better place to talk about it. These topics need to be handled in an open way by Microsoft.

100% agreed!

[AndrewPawlowski]

Can you make modern, good looking apps on Windows now (JAN2020)? NO

I do believe you can - but it's really really hard. Trivial things are insanely hard to do (I'm living proof it's possible, but you need nerves of steel for sure):

• on the UI front, there will be issues, but usually you'll get the hang of it
• on the "anything else" front, things are pretty dim.
• dealing with files on UWP is complete hell, due to the StorageFile/Folder API, which, to put it midly, I hate with all my heart

We are like beaten dogs here. It is actually soo hard to make a new modern app for Windows desktop! Shouldn't there be at least one excellent way of doing apps? When you go to Microsoft Store on windows and try to scroll apps category you won't find any decent app made with UWP. Btw I can't check it myself because ...

Yep, "modern", "native" app ladies and gentlemen. Since Windows is now practically free shouldn't the main source of monetization be the most solid app on the system, but I digress. You actually don't need to research the app to know what tech it was made with. Just one look and you can tell if it was built with UWP. There are no serious commercial projects build with UWP, and what is built with it is ... you know ...

And that is because it IS soooo hard. Window10 is the biggest platform after The Internet and Android!!! But No One is making apps for it with the tools that were supposedly made for that purpose! Just contemplate on that. It's easier to build an Electron app for 3 operating systems than just for Windows with UWP!

Is it OK for us, beaten dogs, that just want to build Windows desktop apps to demand excellent tools? I say unapologetically yes! But all we have is radio silence from Microsoft. Who wants to hear a fairy tale that your app might work on Holo Lens or a Windows Phone or Xbox? Nobody. After 5 years there has been no commercial app that works on 2 fo those platforms promised for UWP. (Mostly because those platforms don't exit). Again, ponder that! The best thing that has happened to us is WinUI is being ported BACK to old win32.

I love Windows desktop, I learned to program doing C# on WinForms and WPF. And it was easy and excellent for a noob like I was. Today I am salivating looking at those juicy controls in WinUI, but somebody has to come clear on the big picture for the platform. We need a clear message about practical technology leadership and not about the market aspirations of some MS business execs.

[jasonwurzel]

Hi, I'm a bit late to this discussion but wanted to give my humble opinion anyway. Concerning commercial UWP Apps: One that comes to my mind is Adobe XD. This one is UWP and feels very mature and complete. My own experiences with UWP, being a .Net developer for 13 years: Of course you can create a good looking, performant app with it. But... it is not a beatiful experience. We're in the process of creating a medical application and many of the things already mentioned here and elsewhere were encountered by us also:

• Unbelievable slow file API
• Very slow "F5 time". So going into debug to build/start the application to try out something is at least 10 x slower than in WPF. (think approx. 2 minutes on a Surface Book 2)
• In general, being restricted by the sandbox. These are just the ones from the top of my head. In the end when XamlIslands was released we chose to host our complete UWP UI in a WPF Window, having fast .net core behind everything. I don't think many people used XamlIsland in this magnitude (concluding from the github issues/PRs we created). Yet this technology also has some very serious limitations. Just as an example, compile time goes up even higher. Losing the ability for live editing Xaml. Creating an installer for a serious WPF/XamlIsland/UWP app? It hurts. etc... So to sum it up, creating beautiful UWP apps can of course be done. But it is so unproductive and slow. And restricted. So as many others we are excitedly awaiting the release and maturing of WinUI 3, being able to have "UWP" frontend and .net core (or .net 5 ;-) ) backend without tricks.

[jasonwurzel]

@jasonwurzel those are some very good points

• The file API is slow but for the meantime @duke7553 posted a workaround in #1465 (comment) That is true, yet we didn't know about it back then. Redundant to say, it is somehow crazy to implement this workaround just to get fast file I/O...
• F5 time does slow things down and I think that can use some improvements
• I am curious what limitations you ran in to by trying to develop a regular UWP app as opposed to going the xaml islands route? I am working on a few apps right now and I was able to solve any limitations by including Win32 processes, but I understand that it isn't always the ideal way to create an app. I guess in the end it was the sum of the obstacles we met, no doubt some of which could have been solved with external processes. In no particular order:
• Observing the CD tray/USB ports for inserted media
• observing some user-chosen directory anywhere on the local PC and having the App/Windows remember the access right when updating
• demanding broadFileSystemAccess, getting the exception, opening the corresponding Windows Settings Page, user checks the App's toggle, boom App closes without warning, no chance to intervene.
• same domain: letting the user choose a directory without having to open a Windows-style FolderPicker (no we do not want to style our fullscreen app in a nice and streamlined manner and then the Windows Dialog jumps into the user's face)
• chicken-and-egg problem: availability/support of nuget packages (many more people are still using WPF, so finding solutions to small problems is just much more quicker)
• controlling the install location

[jtorjo]

@AndrewPawlowski I am surprised you would say that when there are plenty of great UWP apps that are both modern and good looking, including a handful that are open source on GitHub. Just because you gave up on creating an app because you didn't figure out how to do something does not mean a platform failed, it means your app failed. If you look around you can see many developers who worked hard and created some really good apps including apps that continue playing sound when the app loses focus.

I'm not saying it's not possible, but it's very very hard. And I'm not talking about a simple "Notepad-like" app, I'm talking about a very complex app which deals with UI / video editing / sound editing / loading/saving lots of stuff to disk / (trying and not succeeding) launch stuff (and please don't tell me about the fullTrust API). I'm talking about a 50-100K+ lines-of-code app.

That is waaaay harder.

And the fact that you can play a sound when the app loses focus - no one is saying that you can't, but it should be waaay easier than is now.

You ask if there is anyone who enjoys the process of developing UWP apps and the answer is that there are many and in recent months I have been getting lots of requests from other developers for help on their apps, the platform is clearly gaining interest.

I agree, that's why I actually embarked on porting my app to UWP. But it's been a very bumpy road, and still is.

You also claim that there is nobody writing about developing UWP apps and I have to say that is just false, @rudyhuyn, Martin Zikmund are just two examples of developers writing about UWP but there are many others as well.

I totally agree, but compare that with people writing about wpf. It's a drop in the water.

Just do a simple github search - "c# wpf" (3701 results) vs "c# uwp" (337 results). I'm sure if you would search for the same thing, and filter by "number of commits > 500" (which kinda' means - user stuck with the project) -> you would find a waaay dimmer picture.

This pretty much shows that you can create both good looking apps in 2020 as well as modern UWP apps and that many of your statements are not accurate.

I beg to disagree - in order to be able to develop a UWP complex app and be happy doing it -> we're a long way from that.

[jtorjo]

• I am curious what limitations you ran in to by trying to develop a regular UWP app as opposed to going the xaml islands route? I am working on a few apps right now and I was able to solve any limitations by including Win32 processes, but I understand that it isn't always the ideal way to create an app.

On my end, I tried to use win2d using Xaml Islands back in Sept - did not work one bit. I tried some of MS's examples and they didn't work either. At that point, I realized I really need to port my app to UWP or otherwise this will never work.

As for a more recent test - https://github.com/microsoft/Win2D/issues/731

[jtorjo]

• Very slow "F5 time". So going into debug to build/start the application to try out something is at least 10 x slower than in WPF. (think approx. 2 minutes on a Surface Book 2)

Oh yes! I didn't even mention this, but yeah, it's insanely slow. I've gotten around it by tweaking what projects I compile and which I don't - and depending on which part of the app I'm working on, this is decent or horrible (and by decent, I mean, roughly 10-15 seconds most of the time)

• In general, being restricted by the sandbox.

Oh yeah :)

[jtorjo]

• The file API is slow but for the meantime @duke7553 posted a workaround in #1465 (comment)

Agreed, but just think of how long it took for someone to find that workaround -- that clearly existed, but was deeply buried in the docs. And right now, probably a very few people are aware of it (including myself).

If you do a google search, you won't find any of the posts that show that workaround, so it will probably be a few months before most developers will be aware of it.

[Felix-Dev]

@jasonwurzel

So as many others we are excitedly awaiting the release and maturing of WinUI 3, being able to have "UWP" frontend and .net core (or .net 5 ;-) ) backend without tricks.

Just want to point out that MS said that once .NET 5 lands, you will be able to use it for your UWP projects just fine. No need for any "tricks" or a situation like .NET Core 3.x. Here is the .NET 5 announcement post again: https://devblogs.microsoft.com/dotnet/introducing-net-5/

[jasonwurzel]

yeah, that's what I was refering to 👍

[verelpode]

I think the word "completely" in "completely out of touch with reality" was unfair and inaccurate, but @jtorjo was very frustrated for understandable reasons. If Microsoft was completely out of touch with reality, then the WinUI team would not be working on separating WinUI from UWP. Overall the WinUI team seems to be more in-touch than other departments of UWP/WinRT. I think an accurate description would be that some degree of out-of-touch exists in some teams at the current time.

Significance of a list-with-columns GUI

Although the WinUI team is probably the best-performing team out of all teams related to UWP/WinRT, I think some mistakes were still made in the project management of WinUI. A list-with-columns GUI (such as DataGrid) is an essential mainstream feature that every customer uses on a daily basis (such as in Windows Explorer and various other examples such as Spotify etc). Since the start of WinRT, it has been 8 years without official support for a list-with-columns GUI! I find this situation to be shocking. For that reason and others, I say that UWP is still an alpha version today (it's not yet feature-complete thus not a true beta). It's unsurprising that most app developers never took UWP seriously, and hence Windows Mobile ended up being cancelled.

An official version of WinUI's DataGrid has been overdue for the last 8 years. DataGrid became overdue the minute when WinRT 1.0 was released because Microsoft should have never started a new system (as I explained in my previous message re Nokia etc). 8 years with missing fundamentals, 8 years overdue, and now the WinUI team wants to make DataGrid even more overdue by wasting even more time by downgrading it to native code. For multiple reasons, it's difficult to take UWP seriously and difficult to trust it.

C++/CX was recently replaced by C++/WinRT

Here's another example of being "out of touch with reality":
Obviously software needs to be written in a sane manner (I mean "sane" as terminology, not an insult such as "You're insane"). "Sane" as terminology means you shouldn't use obscure convoluted black magic to accomplish a simple straightforward task. C++/CX was recently replaced by C++/WinRT. C++/WinRT uses the so-called "curiously recurring template pattern" for function-calling via static dispatch. That's a really terrible design because it's not a sane design because it's a case of using obscure convoluted black magic to accomplish a simple straightforward task. Furthermore, the CLR/C# already solved this issue decades ago, therefore why is the WinRT team still messing around and wasting time with very old and primitive topics that were already solved decades ago? Why is the WinRT team re-inventing the wheel?

I browsed the NEW source code of C++/WinRT and my impression of it is that it's a terribly low-quality piece of software, but the WinRT team views it as wonderfully advanced. Thus "out of touch with reality" is an accurate description.

UWP file system is still alpha version

@jtorjo and other people have mentioned the performance problems of UWP's file system API's. The performance is below the level necessary to describe it as a feature-complete beta version. Another reason why the UWP FS API is still an alpha version is the lack of the ability to move a folder. 25 years ago, Windows 95 had the ability to move folders, but UWP is still missing this fundamental ability. In some ways, Windows 95 is more powerful than UWP. In various ways, WPF and .NET Framework are still more powerful than UWP. Microsoft expected app developers to take UWP seriously but this was very unreasonable (or "out of touch with reality") because Microsoft never progressed UWP from alpha to beta stage.

[mdtauk]

Windows made the assumption that mobile like "App Dev" was the booming market, and was modern in that it had security and battery life at it's heart.

They were pushed out of the Mobile market due to market forces. Devices like Hololens and Xbox are trying to remove Win32 legacy support - to make development simpler for them, and a leaner more performant OS codebase.

These bets have not totally paid off, but the ideals for a modern app delivery and security model, are laudable goals.

So after some soul searching Microsoft have decided to disentangle the modern app framework, from the UI framework.

WinUI 3.0 should be the best of both worlds, allowing access to most modern APIs which benefit from language projection, modern coding standards, and mobile familiarity. But also allowing apps to use the less secure but more powerful Win32 and .NET runtimes.

Of course relying on Win32 access, will restrict what platforms they will run on - and who knows where the market will move to in the years to come.

---

I would suggest instead of belabouring the same old grounds and complaints - this community be used to ask for what developers want going forward, and not to lay blame or ranting in a way that doesn't move the project forward.

[verelpode]

@mdtauk wrote:

They were pushed out of the Mobile market due to market forces.

Various UWP/WinRT staff members would like to believe that explanation very much, in order to feel better about what happened. I don't believe that explanation. I believe that UWP failed because of:

1. Mismanagement, and
2. Failure to address the problem of app developers perpetually postponing the UWP versions of their apps because of the impression that UWP wasn't ready and still isn't ready for prime time, and
3. Excessive usage of unproductive old software engineering techniques, and
4. Failure to win the trust of the majority of app developers, and
5. Things that made UWP look silly such as promoting use of JavaScript instead of Java, meaning the failure to recognize the difference between a scripting language versus a programming language.

Sadly, considering that mismanagement is the main reason for UWP's failure, it's ironic that UWP is written in unmanaged code because the word "unmanaged" really sums up the reason for the failure: Mismanagement of both the source code and the project management.

@jtorjo wrote:

Native, in the context of "compile to .net native", I do think is a good thing

I agree. The difference is in automatic versus manual generation of native code. When native code is produced automatically by a compiler or tool, then it's usually a good thing, whereas if native source code is manually written source code, then productivity, feature-set, and reliability suffers substantially.

If you look at the timeframe of WPF development versus the timeframe of WinUI development, then WPF's development was much faster (much better productivity), despite the fact that WinUI should have been easier/faster to develop than WPF because WinUI reuses many of the same concepts that were already created for WPF. Unfortunately, Microsoft chose to engage in excessive use of old software engineering techniques that contradicted their own prior standpoint and sabotaged their own productivity and led to app developers perpetually postponing UWP app development.

What can be done now to solve the past mistakes? Stop repeating the same mistakes that led to failure of UWP. Don't continue as if nothing bad happened. I'll use DataGrid as an example here: Add new features to DataGrid instead of delaying DataGrid even further. Don't make DataGrid even more than 8 years overdue by doing a useless manual rewrite/conversion to native code.

End-users couldn't care less whether DataGrid is written in managed or unmanaged code, and they don't know what those terms mean, thus what is far more important and sensible is to keep it with managed code as-is and improve the functionality/features of DataGrid. The amount of manually-written native code in UWP is already a disasterous situation, so why make the situation even worse by writing even more native code and even more obsolete code based on Win16/32 and COM?

I understand that you cannot just throw away all of the obsolete code, but you CAN stop making the situation worse than it already is. Meaning, cease writing even more antique native code. Make a policy that from now on, all new code/projects will be written using modern software engineering techniques. Don't downgrade preexisting managed code such as DataGrid etc.

[jtorjo]

UWP file system is still alpha version @jtorjo and other people have mentioned the performance problems of UWP's file system API's. The performance is below the level necessary to describe it as a feature-complete beta version. [...]

I mentioned this before and I'll mention is again - the StorageFolder/StorageFile API is one of the worst APIs I've seen. We're way in the 21st century, and I need to ask "oh please please, can I have access to this? and to that? and then add them to the great FuturesAccessList?"

And I need to asynchronously ask for basic properties, such as file's size? I don't care what rationale this might have had, but it's waaay out of touch with reality right now.

[jtorjo]

These bets have not totally paid off, but the ideals for a modern app delivery and security model, are laudable goals.

I totally agree...

[....] Of course relying on Win32 access, will restrict what platforms they will run on - and who knows where the market will move to in the years to come. [...]

I completely agree, but, thinking too much into the future can also be a pain... By that I mean - if you restrict Win32 access from the get go, porting libraries will be pretty much a "no-go", so you won't have a present, let alone a future.

By allowing us to also use Win32 code, yes we may not be able to port to another (upcoming) platform, but at least we'll have code for today. And tomorrow, that will be another day, and when we get there, we'll figure a way to port our code if we really want to.

But I do what to be given to choice, and I will understand the risks.

I would suggest instead of belabouring the same old grounds and complaints - this community be used to ask for what developers want going forward, and not to lay blame or ranting in a way that doesn't move the project forward.

Not sure if this was targeted at me or anything, I'm not a native english speaker. Having said that, I definitely want this project going forward, but I do think it's important we address some issues that stop us from deploying - today.

[mdtauk]

I would suggest instead of belabouring the same old grounds and complaints - this community be used to ask for what developers want going forward, and not to lay blame or ranting in a way that doesn't move the project forward.

Not sure if this was targeted at me or anything, I'm not a native english speaker. Having said that, I definitely want this project going forward, but I do think it's important we address some issues that stop us from deploying - today.

I am not targeting anyone, but the discussion title is a little negative and people don't tend to respond and address legitimate issues, if they are wrapped around insults and accusations.

Also now we know that a Win32/.NET app framework will be coming with WinUI 3.0 - there is little point in still criticising them for being WinRT only in the past. 😁

[marcelwgn]

@jtorjo

We're way in the 21st century, and I need to ask "oh please please, can I have access to this? and to that? and then add them to the great FuturesAccessList?"

The fact that apps have to ask the user is in my opinion a step in the right direction. The fact that unlike Winforms and WPF apps, the app can not simply scan all of my files and I have the control over which folders it can access is very important security wise. If you think that it is bad that we limit the resources apps can access to protect the user, than I guess that's your view, but I do not want every app to do what it wants with my files.

And I need to asynchronously ask for basic properties, such as file's size? I don't care what rationale this might have had, but it's waaay out of touch with reality right now.

I guess the rationale was that it should not block the UI thread since the worst thing that can happen from a UX point is that the app does not respond anymore because the developer forget that disc operations may take a bit. Using await you can get around the problem and it forces you to unblock the UI thread at some point. (At least that is how I understand async await).

---

As @mdtauk correctly pointed out, the discussion title is indeed a little negative, and instead of keeping repeating the same old complains, such discussions should be used to come up with ideas to solve such issues.

I think we all should keep in mind to adhere the Microsoft open source code of conduct, keep a professional discussion and be respectful to everyone regardless if they are present or not.

https://opensource.microsoft.com/codeofconduct/

[jtorjo]

The fact that apps have to ask the user is in my opinion a step in the right direction. The fact that unlike Winforms and WPF apps, the app can not simply scan all of my files and I have the control over which folders it can access is very important security wise. If you think that it is bad that we limit the resources apps can access to protect the user, than I guess that's your view, but I do not want every app to do what it wants with my files.

So we start with a huge disadvantage compared to WPF apps. That's one thing - the other thing is

1. I'm already asking that at installation.
2. Even if users may not pay attention, Windows could once again show the user "This app wants access to your files" and the user could say Yes/No. I would be totally fine with that. However, this is FAR from what is happening.

And I need to asynchronously ask for basic properties, such as file's size? I don't care what rationale this might have had, but it's waaay out of touch with reality right now.

I guess the rationale was that it should not block the UI thread since the worst thing that can happen from a UX point is that the app does not respond anymore because the developer forget

The file size should be pre-fetched (same as, last access date/ last write date) - it is so important, that it should be pre-fetched when you do a query for files.

As @mdtauk correctly pointed out, the discussion title is indeed a little negative, and instead of keeping repeating the same old complains, such discussions should be used to come up with ideas to solve such issues.

I totally want these to be solved, nothing else.

I think we all should keep in mind to adhere the Microsoft open source code of conduct, keep a professional discussion and be respectful to everyone regardless if they are present or not.

This discussion would not have happened here, had we actually had a place to ask these questions, and for WinRT to listen for feedback elsewhere.

[jtorjo]

I am not targeting anyone, but the discussion title is a little negative and people don't tend to respond and address legitimate issues, if they are wrapped around insults and accusations.

I agree it's a little negative, once again, this would not have happened, had there been somewhere else to give feedback on WinRT issues.

Also now we know that a Win32/.NET app framework will be coming with WinUI 3.0 - there is little point in still criticising them for being WinRT only in the past. 😁

Honestly, I really hope this is the case. I will certainly wait for these issues to be resolved, and personally can't wait for that non-sandbox platform to be available. But until then, I am still working on an app, and still facing the issues I outlined in the first place.

[marcelwgn]

So we start with a huge disadvantage compared to WPF apps. That's one thing - the other thing is

Just to be clear, leaving the use a choice to deny apps from accessing all file is a disadvantage in your opinion? We as developers have to develop the software for the users not against them. And leaving the user no choice on what data your app sees is a security disadvantage for users, in my opinion.

1. I'm already asking that at installation.

Do you mean the "broadFileSystemAccess" capability? In my opinion there are very very few apps that have a legitimate reason to have this capability. (as @kmgallahan already pointed out) Just look at all the apps you use on a day to day basis. How many of those need access to all files all the time? Probably not so many, if there are even any.

As you said in your initial comment:

Do you think users will happily do the above? No they won't - in fact, 79.8% don't do it (my AppCenter data backs this up).

I think there probably is a reason users are not happy to do this (beside the fact that this is a security setting that they have to change).

However I may not know all business cases that would require access to all files, so if there are any I am happy to hear them. At the end of the day we are not here to fight but to enrich each others points of view (hopefully) 😅

Edit:

The file size should be pre-fetched (same as, last access date/ last write date) - it is so important, that it should be pre-fetched when you do a query for files.

Oh right, yes some of those should definitely be pre fetched. I agree that this is somewhat inconvenient for us developers.

This discussion would not have happened here, had we actually had a place to ask these questions, and for WinRT to listen for feedback elsewhere.

Officially the feedback hub is for that (I think) but yes it feels a bit unresponsive sometime. Hopefully the feedback hub improves. From what I can see, they already made some changes to it over the course of time, so I think that this will hopefully change too.

[verelpode]

@Felix-Dev

Here is the .NET 5 announcement post again

Thanks for linking to that. I especially found this part interesting, and I believe this is positive news:

"Java interoperability will be available on all platforms.

There's also a bit of Java discussion in the comments at the end of that webpage, where Rich Lander confirms two-way interop. I interpret this as a positive sign that Microsoft is getting back in touch with reality. I'm no fan of Java (I prefer C#), but nevertheless I acknowledge that Java interoperability is highly beneficial and should have been the focus in UWP/WinRT from the beginning. If UWP/WinRT had given top priority to Java and C# (managed code) instead of clunky old native code (C++/CX, Win16/32, COM), and if UWP hadn't mixed-up the purpose of JavaScript versus Java, then UWP would have attracted many more app developers, and Windows Mobile might well be alive today.

Like it or not, it's necessary to wake up and acknowledge the reality of the situation: The market leader is Android with its focus on Java app development. Java and C# mean managed code. Microsoft made a hugely costly mistake when it reversed its standpoint on managed code.

Even though I don't really like Java, it's clear to me that Android's Java techniques are much better than the clunky old way in which Microsoft is developing WebView2 with its use of antique Win16 programming techniques such as 16-bit versus 32-bit pointers, and HRESULT instead of modern exception handling, etc. WebView2 uses LPCWSTR and the L means "long pointer" meaning a 32-bit pointer as opposed to the 16-bit "short" pointers in Win16. The W means "wide characters" meaning Unicode (UTF-16) as opposed to 8-bit ASCII/ANSI characters. In comparison, Android's use of Java is far more professional, modern, and trust-inspiring than what some departments of Microsoft are doing.

So on a positive note, it's really great news to hear that Microsoft will support Java (even though personally I prefer C# over Java). Android app developers will increase their interest in Windows as soon as good reliable Java interop is released.

[AndrewPawlowski]

Also now we know that a Win32/.NET app framework will be coming with WinUI 3.0 - there is little point in still criticising them for being WinRT only in the past. 😁

1. The future is bright, I love what I see is being developed in WinUI.
2. The past was pretty bleak, for a platform with 900 MILLION devices the poor prevalence of UWP is hard to defend. EDIT: the past is the only place we can learn from, so it is important to discuss.
3. The present is, I think, is the main point of this thread and it is not being addressed. If someone wants to start today a nontrivial app that will take 1-1.5 years to develop, what honest advice can be given? My answer would be: experiment with WinUI, make your libs in dotnet Core, and wait for WinUI3.0 to come out to really start making your app. Don't bother with UWP because you will want to throw it out of your app anyways, you probably don't want different platforms as the 900milion one is plenty big. The questions about the present are not trivial, business decisions need to be made today.

What is not being said, but what is really happening is that UWP and modern UI are not being extended to win32, but actually UWP is being refactored OUT of the stack. Why anyone would want to deal with UWP when they could use the power of dotnet standard 2 and dotnet core 3 and all the libs that are available with that?

About sandboxing and other good ideas introduced in UWP: they were good ideas, but could have been executed much better. I hope they will come back and there will be a possibility of OPT-IN into a sandbox or OPT-IN into state management similar to UWP. As developers we want to serve the users but in UWP we were threated as the problem that the platform needed to contain.

What honest advice can be given? Wait?

[Felix-Dev]

@AndrewPawlowski If you've determined that UWP and the sandbox doesn't work for you, I think writing a MSIX-packaged WPF app is a good choice until WinUI 3 lands. You can already call Windows 10 exclusive APIs, provide the user with a modern install/uninstall experience and generally pick from the Windows 10 API surface what you like and what not (i.e. you can start using Windows 10 Shell APIs). Some WinRT APIs are really a joy to work with compared to past win32 ways and some scenarios I believe are even done best on DesktopBridge rather than pure UWP. Case in point: Registering an app for automatic start at log-in, see this post for a comparison of UWP vs DesktopBridge behavior. In the case of DesktopBridge, you still, ultimately, leave the user in control, but the user won't constantly be asked twice (first, a toggle in the app, then a system prompt asking for confirmation) when enabling start at log-in in the app.

Unfortunately, many parts of the WPF APIs are really showing their age now when compared to UWP UI APIs so you will just have to live with that a few more months (at least). The many available WPF toolkits will mitigate this fact, but if you truly want a native look and feel for your Windows desktop app (and a modern XAML development experience!), you really won't be able to escape the UWP UI APIs (and later the WinUI 3 APIs). That means, even if you can re-use some of the WPF UI code for WinUI later, modernizing the UI will still be a rather big work item I believe.

That's the state of native windows app development I currently see for you if you cannot wait until WinUI 3 ships and UWP is not an option for you.

[jtorjo]

@AndrewPawlowski

1. The future is bright, I love what I see is being developed in WinUI.

Concur

2. The past was pretty bleak, for a platform with 900 MILLION devices the poor prevalence of UWP is hard to defend. EDIT: the past is the only place we can learn from, so it is important to discuss.
3. The present is, I think, is the main point of this thread and it is not being addressed. If someone wants to start today a nontrivial app that will take 1-1.5 years to develop, what honest advice can be given? My answer would be: experiment with WinUI, make your libs in dotnet Core, and wait for WinUI3.0 to come out to really start making your app. Don't bother with UWP because

My initial thought was the same, but I did not wait....

About sandboxing and other good ideas introduced in UWP: they were good ideas, but could have been executed much better.

Agreed 100%

[jtorjo]

However I may not know all business cases that would require access to all files, so if there are any I am happy to hear them. At the end of the day we are not here to fight but to enrich each others points of view (hopefully) 😅

Anywhere where you want to preview stuff, you'll want fast access to files. In my case, I want to preview folders to visually show the user where the photos/videos are at, and for videos, I want the user to preview the video before selecting it. The whole point is: the file picker offers a pretty sub-par experience, and I wanted to enrich that.

Officially the feedback hub is for that (I think) but yes it feels a bit unresponsive sometime. Hopefully the feedback hub improves. From what I can see, they already made some changes to it over the course of time, so I think that this will hopefully change too (^∇^)

Personally I don't like the feedback hub - it's too unspecific, among other issues.