zlacker

[parent] [thread] 2 comments
1. mike_h+(OP)[view] [source] 2023-05-24 16:53:08
The new stuff are basically new package (msix) capabilities that trigger new codepaths in classical Win32 APIs. Microsoft's previous app sandbox required the use of WinRT APIs that not many people have adopted.
replies(1): >>Avery3+43
2. Avery3+43[view] [source] 2023-05-24 17:04:54
>>mike_h+(OP)
AppContainers have supported win32 from the start, not just WinRT.

See:

https://learn.microsoft.com/en-us/windows/win32/secauthz/app...

https://learn.microsoft.com/en-us/windows/win32/api/userenv/...

https://scorpiosoftware.net/2019/01/15/fun-with-appcontainer...

replies(1): >>mike_h+Y4
◧◩
3. mike_h+Y4[view] [source] [discussion] 2023-05-24 17:11:14
>>Avery3+43
There are different kinds of app containers. The low level container tech doesn't care what high level APIs you use, it just blocks or redirects stuff, but if you want things like file brokering, implicit grants based on powerboxes and stuff like that then it wasn't previously available. That's what this project is adding to Windows.

edit: To clarify, all MSIX packaged apps run in an app container called Helium, but it's a very soft one that isn't meant to sandbox anything. It just redirects file IO to a special directory so installs/uninstalls are clean. You can make app containers stricter. The Chrome sandbox does that, UWP sandboxed apps do that, and now they're adding support for more strictly sandboxing ordinary Win32 apps which would otherwise break when they tried to open a file in the user's home directory.

[go to top]