Open JaiganeshKumaran opened 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.
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.
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