When the applications in MSIX packages are run, they run inside a specialized Windows Container, which was based on the same technology used for running Docker containers on Windows Servers.
The use of the container helps secure our systems:
- Protecting the OS from unwanted changes made by the application.
- Protecting the application from unwanted changes by other applications, users, and even software that has root system admin privileges.
- Providing more stability, and a chance to automatically update (or control updates) of applications.
This, however, means that applications cannot do some of the things that they have been used to doing. To overcome these restrictions, Microsoft created the Package Support Framework, known as the PSF, which may be added into MSIX packages to remediate those behaviors and provide additional features often needed in a business environment.
The PSF is an Open Source project originally created by Microsoft and made available through GitHub. While Microsoft created the original PSF, much of what we use today has been enhanced by others. The primary contributor to this effort has been Tim Mangan, which has his own GitHub open-source fork containing the latest version of the PSF. Many vendors have private forks they have created for the PSF version included in their products, and these derive either from the original Microsoft Source, or Tim's fork.
The PSF is essentially software that is used to launch applications within the container and also parts that get injected into processes running in the container. The parts that get injected will intercept calls into the Windows APIs that are made by the application. The intercept will determine if a change is necessary, and modify the call, for example to redirect a file write that would be disallowed to a safe area on the system.
In addition to the intercepts, PsfLauncher has capabilities beyond just starting the application and performing injections into the application processes. Modern app shortcuts are much more limited than traditional ones, lacking command line arguments and control over the application working directory. Also, because MSI custom actions are no longer available, the PsfLauncher can also run a script (for first launch only or every launch) to configure the environment for the application based on local conditions. There is even a trace utility and PsfMonitor, a Process Monitor like utility that traces application calls into the same API locations that the intercepts might change. It can be very useful to understand what the application is asking (and how the container responded) before implementing the PSF fixups.
The PSF has a configuration file, called config.json, that is used to control when and how the PSF does it's job.
If you want to know more about the specific components of the PSF and how they are configured, IT Pros should look at The PSF Wiki in Tim's fork.