I didn’t expect to write this article so soon! More on that later, let’s get to the juicy stuff.
The Package Support Framework, or PSF, is an open source project hosted by Microsoft up on GitHub. The PSF is useful when building MSIX packages for older Win32 and .Net based applications. It allows you to build in Detours based shims to alter the behavior of the application without needing access to the app source code.
Open to community contributions, the PSF is growing in capabilities. I discussed my initial contribution last week in this article. But now my second and third pull requests have been merged into the mainstream code, so we have improved options to handle more things that existing applications do and need help to deploy via MSIX. What’s new?
- We can now specify command line arguments for the target application in config.json.
- We can now specify non-executables as the target application in config.json.
I’ll explain each in more detail here.
Command Line Arguments: Modern applications (UWP, Centennial, and MSIX) don’t allow command line arguments to be set in shortcuts (well, at least not yet). Often applications make use of command line arguments as it allows a simple means the enterprise can use to customize application usage, or to use a single target exe for two different purposes. With these changes, the applications section of the config.json syntax used by PsfLauncher now allows you to specify the command line arguments for the target executable with a new ParameterName called “arguments”. For example, an application block might look like:
"applications": [
{
"id": "PSFLAUNCHERSixFour",
"executable": "PrimaryApp.exe",
"arguments": "/AddedArg"
"workingDirectory": "",
}
]The PsfLauncher will run PrimaryApp.exe using the contents of arguments as command line parameters. If at some point command line parameters get added to shortcuts, the code is written to append command line arguments given to PsfLauncher to those specified in this file. Thus when a shortcut is allowed like “PsfLauncher64.exe /newarg” and the file above, PrimaryApp.exe will be run with arguments “/AddedArg /newarg”.
When converting an old app that has a shortcut with command line arguments, you add the appropriate bitness of PsfLauncher to the package and make that the target of the shortcut. Then you add reference to the launcher app, and configure the launcher using the config.json as shown above. If additional remediation in the PrimaryApp is needed, like the FileRedirectionFixup, this detail is configured in the processes section of the config.json file.
Keep in mind that if you have more than one shortcut needing this behavior, you’ll need multiple, uniquely renamed, copies of PsfLauncher in the package – as an entrypoint creates only one shortcut.
Non-Executables: Many existing application installers use shortcuts that have document oriented files as targets. In native shortcuts, these files are processed by Shell launching, which involks the local default application associated with the file type in the registry, referred to as a File Type Association (or FTA for short). The goal is to have have the installer NOT decide on the external application to use, but to use whatever is configured in the end-user’s OS. Examples of these targets include document files with extensions like txt, rtf, pdf, doc and docx, and action oriented files with extensions like hta (which would be rendered in Internet Explorer by default), and even just URL links. Prior to this contribution, such target files were not acceptable as entry points into MSIX (i.e. “shortcuts”).
The contribution extends this support via PsfLauncher. PsfLauncher will still use the non-shell process launching technique to start exe file targets, but any other file extension in the executable ParameterName of the applications secton of the config.json file will trigger use of the Shell for launching the app.
PsfTooling Support for these changes: PsfTooling 1.0 includes pre-built components of the Psf with changes included in my first submission only. PsfTooling 2.0 will include pre-built versions of the PSF with these updates as well. PsfTooling isn’t available as of this writing, but will be shortly as it is becoming a free MSIX based Windows Store App.
It took 6 months for my first contribution into PSF to be processed. There were a lot of startup issues involved as this Microsoft team had to build a process. I expected the next submissions to be considerably faster, but these were turned around in under two days! So the PSF is open for community contributions. I hope that others will contribute as well.
