zlacker

>>pjmlp+(OP)
Windows 8 and UWP weren't ever popular, but Microsoft is having a little more success parcelling up UWP:

* .appx became .msix; the latter also works for Win32 apps

* UWP XAML/GUI evolved into WinUI, v3 of which doesn't target UWP

* Win32 app isolation—this news—grew out of AppContainers, which were used by UWP apps

That said, what's new here? You could package (.msix) Win32 apps with partial trust, IIRC. Does this remove the need for packaging?

>>orra+V5
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.

>>mike_h+Pd
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...

>>Avery3+Tg
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.