search

microsoft / WindowsAppSDK

The Windows App SDK empowers all Windows desktop apps with modern Windows UI, APIs, and platform features, including back-compat support, shipped via NuGet.
https://docs.microsoft.com/windows/apps/windows-app-sdk/
MIT License
3.78k stars 319 forks source link

Proposal: Make existing Win32 file APIs brokered if possible #1827

Open JaiganeshKumaran opened 2 years ago

JaiganeshKumaran commented 2 years ago

Proposal: Make existing Win32 file APIs brokered if possible

One of the problems faced within the App Container is that for IO, you have to either use APIs in the Windows.Storage namespace or Win32 APIs that are intended for brokered access. You can still use non-brokered APIs however only to access certain locations. For app-level access, this is mostly fine however many libraries/runtime use traditional non-brokered APIs. You can't simply use File.WriteAllText like any other .NET app, you have to use FileIO.WriteTextAsyc. You can't simply use fopen, you need StorageFile.OpenAsync. One of the selling point of WinUI 3 desktop is that you can use all the libraries/frameworks you're already used to using even if they're not intended for a sandboxed environment. I faced such issues myself when trying to use native libraries that were made without AppContainer in mind. It may seem fine right now for all new modern Windows apps using WindowsAppSDK to be full trust however I strongly believe that in the long run, it's not a viable option. Partial trust should be encouraged but then you have the same issues as you had under UWP.

Instead, try to make all the non-brokered Win32 file APIs brokered when running under AppContainer/partial trust. It doesn't even need to be async. You should still be able to use libraries that use non-brokered file access and use runtime/language provided APIs (eg: fopen, std::filesystem, System.IO etc...) without writing to a location that you've access to and then copying it through brokered storage APIs while still being under user's control.

Rationale

Scope

Capability Priority
This proposal will allow developers to use existing file IO apps with brokered locations under AppContainer Must
This proposal will allow developers to perform brokered operations synchronously Should
This proposal will turn every IO call into a brokered call even if that location can be access without the need for brokering Won't
This proposal will allow developers to use APIs in the Windows.Storage namespace to access brokered locations without brokering under AppContainer Won't
sylveon commented 2 years ago

Brokering is a massive performance regression. Considering most people dislike Windows.Storage due to its poor performance, I don't think it's bright to make everything else slow as well.

JaiganeshKumaran commented 2 years ago

Brokering is a massive performance regression. Considering most people dislike Windows.Storage due to its poor performance, I don't think it's bright to make everything else slow as well.

That's right but this proposal isn't about brokering every IO call under user mode, rather when brokering is the only option to access that file/folder, use brokered access instead of failing because access denied when running under AppContainer.