Running Win32/WPF applications in a container like MSIX is different than when running installed in the traditional way. While there are benefits, the container also can cause issues with applications when you simply repackage them without making changes to the application source.
In The MSIX Report Card for 1809 , I took a look at the results of such vanilla repackaging in the currently available release. But, in addition to anticipated improvements in the MSIX packaging and runtime, Microsoft also has the MSIX Package Support Framework (PSF) , an open source project hosted on GitHub, available to us now.
The PSF, currently, is only available in raw source form, so it might not be in your wheel-house to download and build what you need. Maybe pre-built binaries will be put up on GitHub at some point, but maybe you’ll just use third party tooling that will keep you from having to deal with unmanaged C++ source code.
But if you use the PSF, you’ll need to understand how it works. And if you use third party tooling, they will probably be using a similar technique (possibly using software based on the PSF anyway). So here is how it works.
The PSF uses a library utility that was built many years ago by Microsoft Research called Detours. Detours makes it relatively easy for a programmer to built and inject a dll into a process to intercept Windows API calls and act on them, changing the nature of the call. The PSF binaries provide the framework around Detours so that you don’t have to program, and then provides sample “fixups” that you can use to address certain issues.
To implement this, you would perform a package capture into MSIX, and then add the appropriate PSF binaries to the package, followed by changing out a shortcut, and addding a configuration file that tells PSF what to do.
In essence, you are replacing the shortcut added by the application installer with a new one. The old shortcut pointed to a target executable (possibly with command line arguments, a working directory, and an icon). Your new shortcut will replace the target executable with a copy of PsfLauncher.exe.
The configuration file (config.json) is used to inform PSFLauncher what the real target application is and how to start it. It starts the real target and performs dll injection so that a fixup can be performed. This config file specifies what fixups should be injected into which target processes and also provides the configuration needed for the specific fixup. A utility dll called “PsfRuntime” is used by both the Launcher and injected into the target to make all this work. The startup sequence for this is depicted in the image below, where FileRedirectionFixup.dll is injected into the target executable process.
Adding launcher processes to perform dll injection isn’t anything new. For years Application Virtualization by Microsoft, Citrix, and Symantec all used launcher processes (although Microsoft did away with them in App-V 5 by using a combination of filter drivers and Windows Service). Citrix Published Applications (whether virtualized or not) also use a launcher process today. So while your initial reaction to a launcher process is overhead and/or complications, there isn’t much overhead and we have been doing this long enough that it is pretty simple.
So why would I want this in my package and what can I fix with it? We will be learning more over time, possibly improving the PSF as it stands, possibly improving the existing Fixups, and possibly adding new ones. But here are some simple things I do today. [Note: Some of this may require my own fork of the PSF code until the pull request into the mainline code is completed.]
- Use PSF Launcher to set the current working directory so that the application can find its dll files. MSIX shortcuts, currently, do not allow for specifying the working directory and default to the System32 folder. Even if your original shortcut didn’t try to set the working directory, it would have defaulted to the folder containing the exe instead. If this is all that is needed, no fixup shim is required to be injected into the target exe.
- Use PSF Launcher to supply command line arguments. Even if your original shortcut had command line arguments, shortcuts created by MSIX packages don’t have them (currently). MSIX does not copy your shortcut from the package, but instead uses that information to create a shortcut on-the-fly when the MSIX package is installed. This is so that they can use the correct pathing based on where the files get installed into (by default under the C:\Program Files\WindowsApps area). By adding PSF Launcher to the package we can configure the launcher to use the missing command line arguments for when it launches the target. If this is all that is needed, once again no fixup shim is required to be injected into the target exe.
- Use multiple PSF Launchers to solve multiple shortcuts to same target issues. Because the MSIX shortcuts drop command line arguments, then also merge all shortcuts pointing to the same target exe into a single shortcut. If you need different shortcuts with different arguments, we can accomplish this. You will need to have a differently named copy of the PSF Launcher for each shortcut to make this work. If this is all that is needed, once again no fixup shim is required to be injected into the target exe.
- Use PSF Launcher with the FileRedirectionFixup configured to perform Copy-on-write redirection to files in the package. I configure the fixup to filter based on a RelativePath with an empty base and a regex pattern of “.*”. To get this to work (currently), I have to specify an installation folder in the Microsoft Packaging Tool that is the folder of the target exe, and copy all PSF files there (so this isn’t working yet if you need multiple shortcuts to targets in different folders). For those fans of App-V, this fix is, in essence, a PVAD style capture with the “Allow writes to VFS files” checkbox selected.
Obligitory Plug:
PS: We cover MSIX packaging, including the latest techniques in detecting issues and use of our own PowerShell scripting to automate the creating and injecting of the fixup into your package for these kind of issues in our Packaging for AppV & MSIX class. I have classes scheduled both in the US and in Europe in 2019 if you’d like to learn more.
