MSIX: containerized or not?

[memeplex]

I find the assertions in the following articles hard to make sense together:

https://docs.microsoft.com/en-us/windows/msix/msix-container

Apps that are packaged using MSIX run in a lightweight app container. The MSIX app process and its child processes run inside the container and are isolated using file system and registry virtualization

Then the article links https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes:

Packages that you create for your desktop application are desktop-only, full-trust applications and are not virtualized or sandboxed.

Each package folder contains a manifest (named AppxManifest.xml) that contains a special XML namespace for packaged apps. Inside that manifest file is an element, which references the full-trust app. When that application is launched, it does not run inside an app container, but instead it runs as the user as it normally would.

Could you clarify how both emphasized assertions are true? Even if this makes sense I believe those documents should be made less confusing in this regard because prima facie they seem to contradict each other.

[AdamBraden]

Looks like a doc bug. I made a PR to update the message. MSIX container does provide virtualization as explained later on the page.

[wjk]

Each package folder contains a manifest (named AppxManifest.xml) that contains a special XML namespace for packaged apps. Inside that manifest file is an element, which references the full-trust app. When that application is launched, it does not run inside an app container, but instead it runs as the user as it normally would.

I would like to bring to your attention the fact that the term "AppContainer" has a very specific meaning in Windows app development. It means the kind of low-trust, very-controlled-access sandbox that UWP apps run in. It has extremely limited access to the filesystem, will be involuntarily suspended (all threads shutdown) when the window is minimized, etc.

Regular MSIX apps do not run in an AppContainer. What the docs are trying to say is that your app will not be sandboxed (it can access any file and perform any action the user’s account can, whenever and however it wants), but Registry writes and certain filesystem writes are redirected into a location private to that package, so that the package can be uninstalled cleanly. Hope this helps!

[wjk]

@DrusTheAxe Can you give me a bit more information on what would happen if I put my Windows Forms app into a packagedClassicApp + appContainer runtime using the syntax you used above? The concept of AppContainers is a good one, but they are currently tied to the UWP CoreWindow. Building apps that use the CoreWindow has… let’s say less than stellar Visual Studio support (cf #58, #105). Reunion was supposed to help with this, but there’s been lots of talk and no code actually implementing anything discussed. I’d like to know if (a) if a WinForms app would run at all in an AppContainer, (b) how filesystem access would be granted under these circumstances, and (c) how the CoreWindow suspend/resume behavior would interact with a classic Win32 event loop.

(b) is especially important because the UWP pickers are extremely stunted compared to their Win32 equivalents (cf #88), but their Win32 equivalents (IFileOpenDialog and IFileSaveDialog) are not aware of the AppContainer AFAIK, so I don’t think I would be able to use them to grant my app access to a file or folder.

If anything else seems relevant, feel free to add it. Thanks!

[DrusTheAxe]

@wjk >The concept of AppContainers is a good one, but they are currently tied to the UWP CoreWindow.

A common misconception. AppContainer is a core Windows technology created in Windows 8. It's most easily used via MSIX but it's not restricted to MSIX. Anyone can create and run processes in an AppContainer. Not-packaged apps who used LowIL in the past have added support or switched to AppContainer, as a better isolation solution. You can find good info net e.g. here describes what's involved to use AppContainers without MSIX. Or just make an MSIX package and let Windows do the grunt work ;-)

(a) if a WinForms app would run at all in an AppContainer
If you mean "can you use WinForms in an AppContainer?" I'd like to say yes as a GUI framework shouldn't bump into the AppContainer's isolation constraints but there may be implementation details I'm not aware of. @jevansaks would you know definitively?

If you mean "can apps using WinForms run in an AppContainer?" That's a much broader question than does the WinForms library work in an AppContainer. It depends on what the app uses and does, other than WinForms.

(b) how filesystem access would be granted under these circumstances
Same as it's granted for a Universal app running in an AppContainer. One can use fopen(), RegOpenKeyEx() and other APIs not traditionally thought of as for use by Universal apps. The questions are (a) does the API care if it's called in an AppContainer and (b) is the resource ACL'd to permit access to your packaged process running in an AppContainer?

Some APIs explicitly check if they're called in an AppContainer and fail, as the author knows the implementation won't work or would go squirrely if called in an AppContainer. These obviously won't work in an AppContainer and you'd need to find alternatives (or ask if the API author can change the API to support it).

Assuming the API can work in an AppContainer it's a question of if the resource is ACL'd to permit it. A package's installed location (e.g. C:\Program Files\WindowsApps\...pkgdir...) is ACL'd to permit access to (among other things) apps in the package. Framework packages (e.g. VCLibs) are ACL'd with the ALL_APPLICATION_PACKAGES SID, granting access to all packaged processes. Whether you can access particular files, registry keys or other resources depends on the resource's permissions.

An AppContainer process can't access everything a MediumIL process can (that's kinda the point after all :-). This is why some Windows APIs exist. If you're in an AppContainer your process can't directly touch certain resources, but perhaps you should be able to. In this case a brokered API can provide the appropriate access. For instance, if you're a MediumIL process and create a Windows.Storage.StorageFile object it's created inproc but if you're an AppContainer it's created out-of-proc. You may not have access to resources so the StorageFile object's created in in a RuntimeBroker.exe process which runs MediumIL as the user. That process helps do work on the AppContainer process' behalf which the AppContainer process can't directly do for itself.

BTW RuntimeBroker.exe is merely an instance of a broker process, it's not requried for a process to act as a broker. If you create an OOP server and define your ACLs appropriately it can be instantiated by AppContainer processes and do work on their behalf too. This was a common pattern in Windows so rather than many teams creating their own broker exe to host their object a common implementation was created. It's fair to say RuntimeBroker.exe is to brokered WinRT objects as svchost.exe is to NT services :-)

The usual answer to filesystem access to packagedClassicApp/appContainer apps is the same as to windowsApp/appContainer apps -- capabilities. For instance, if you declare the picturesLibrary capability in your appxmanifest.xml your app will have access to the files in the picture library, regardless if your a windowsApp or packagedClassicApp.

(c) how the CoreWindow suspend/resume behavior would interact with a classic Win32 event loop
If you're a packagedClassicApp you have no CoreWindow.

RuntimeBehavior=windowsApp has a CoreWindow (among other things). RuntimeBehavior=packagedClassicApp is a classic WinMain application without a CoreWindow.

Some functionality currently isn't available to apps without a CoreWindow. Project Reunion is working to provide solutions to these discrepancies, for example App Lifecycle #111.

Are you asking how can a packagedClassicApp get Suspend/Resume behavior similar to a windowsApp? @andreww-msft would be better able to answer that.

UWP pickers are extremely stunted compared to their Win32 equivalents (cf #88)
A recognized issue Project Reunion aims to address. I don't personally know much about the Win32 pickers. This would be better discussed on the New File/Folder picker for Reunion
#88 thread as it's on point and has subject matter experts already engaged.

[memeplex]

Regular MSIX apps do not run in an AppContainer

@wjk why do you say "regular MSIX apps" here? Regular in the sense that they are still more frequent or in the sense that there is an expectation or intention (or resignation) for them to be the norm?

[wjk]

@memeplex What I meant by that is that the default behavior for an MSIX app is to not use the AppContainer. You must explicitly opt into (or manually create) an AppContainer in your MSIX manifest if that is what you wish.

[DrusTheAxe]

@wjk There's no default. Though there's 1 exception proving the rule (and that default is AppContainer).

<Application> must have Id and one of...

1. Executable, EntryPoint="windows.fullTrustApplication"
2. Executable, EntryPoint="windows.partialTrustApplication"
3. Executable, EntryPoint="...anything else..."
4. Executable, RuntimeBehavior="packagedClassicApp"
5. Executable, RuntimeBehavior="win32App" TrustLevel="mediumIL" (also requires unvirtualizedResources capability)

That's the minimum information you can specify.

Reminder...

• EntryPoint="windows.fullTrustApplication" is synonymous with RuntimeBehavior="packagedClassicApp" TrustLevel="mediumIL"
• EntryPoint="windows.partialTrustApplication" is synonymous with RuntimeBehavior="packagedClassicApp" TrustLevel="appContainer"
  You must specify EntryPoint or RuntimeBehavior+TrustLevel. You can specify both, but if you do they must not contradict e.g. EntryPoint="windows.fullTrustApplication" TrustLevel="appContainer" is an error.

If you specify Executable + RuntimeBehavior="windowsApp" (no EntryPoint) it's an error. Universal activations require EntryPoint. Plus if EntryPoint is present then RuntimeBehavior is redundant as EntryPoint != windows.full/partialTrustApplication implies windowsApp.

If you specify Executable + RuntimeBehavior="packagedClassicApp" (no TrustLevel) then TrustLevel defaults to appContainer. This is the exception proving the rule of no default.

I'm a little surprised packagedClassicApp doesn't require TrustLevel (let alone that it defaults to appContainer). That's probably an implementation mistake but changing it at this point would be a breaking change so I expect it'll stay this way forever.

BTW Windows currently supports all permutations of RuntimeBehavior+TrustLevel except win32App/appContainer. If that's something you'd like to see please create a new Issue for further discussion.

The reason why the syntax is so, well, messy...

• MSIX was born in Win8 and only supported Universal apps in AppContainer (item 3 above)
• DesktopBridge was added in RS1 as a winmain/fulltrust alternative (item 1 above)
• DesktopBridge/PartialTrust support was added later (RS3?) (item 2 above)
• Supporting more permutations wasn't viable via more-magic-EntryPoint-values so we added RuntimeBehavior + TrustLevel in 20H1 to cleanly decouple the syntax, support more permutations and offer a clean extensibility point for future enhancements

Backwards compatibility matters so you can still use the old (pre-RuntimeBehavior/TrustLevel) syntax. And in fact you have to if you install on <20H1 (these uap10 attributes aren't visible to older systems that support them). Personally (when I have a choice) I prefer RuntimeBehavior+TrustLevel as they provide a clearer way to express developer intent but to each their own.

A core philosophy of MSIX is "be explicit". We generally try to avoid implicit behavior to provide a better (clearer) developer experience. That's also true in general for Windows these days e.g. if CreateFile() were added today it would never pass review, in favor of something like CreateOrOpenFile() :P

P.S. Don't confuse Visual Studio templates with Windows behavior. VS templates offer a variety but subset of Windows features, and not always in the permutations you may desire. If so please let us know. Adding new templates is (relatively) easy, if there's a clear need.

P.P.S. I cite codenames because I can never remember Windows 10 release build numbers. There's several lists cross-referencing this information e.g. Wikipedia has a nice one