Using the PsfLauncher

In essence, you will need to replace the traditional shortcut .ink file 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 the PSF launcher executable.


This PSF launcher can have any name you want. For example, the PsfTooling kit injects a file named like PsfLauncher1.exe while Advanced Installer injects a file called AiStub.exe. Sometimes, we need to use alternate when a package contains more than one shortcut as MSIX restricts any individual package from having two shortcuts to the same target file.


The configuration file (config.json) is used to inform PSF launcher what the real target application is and how to start it. The launcher starts the real target EXE and performs DLL injection for a fixup to be applied. This config file specifies what fixups should be injected into which target processes and also provides the behavioral 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 of this work.


The startup sequence for this is depicted in the image below, where FileRedirectionFixup.dll is injected into the target executable process. For example, when an application is trying to write in its installation folder (an action forbidden by the MSIX standard), the runtime fixups redirect the call to a new location under AppData.


How Does Package Support Framework Work
How Does Package Support Framework Work

In addition to launching the target application, the PsfLauncher may be configured in the Json to support command line arguments, the working directory, scripts, and PsfMonitor.


How to determine the needed fixups

The most difficult part of using the PSF is knowing when and what you need it for. Determining the fixups that your application requires can be a very time-consuming process.


Some of the third-party vendors include capabilities in their tooling to provide analysis of the traditional package before you start packaging for MSIX. Currently, none of these tools appear to provide a complete analysis, but they can provide useful information.


This means that you will have to invest in your own efforts to track your app’s compatibility issues. And for the most part, that means creating packages and testing.


To help with that, you have a few options commonly used:


  • Use the PSF tracing dll, PsfTraceFixup, inside your package to show what are the Windows API calls that your application makes.
    • This special fixup traces points that you might need to modify in application activities by using the other fixups.
    • The fixup supports two output forms.
      • One is the output to the debug console port - and you need to use a tool like DebugView to capture and view the output.
      • The other form is to an event log - and you need to use PsfMonitor (also part of the PSF) to capture and view the output.
      • These logs are also automatically parsed by Advanced Installer, simplifying the debugging process.
    • Process Monitor shows the same file and registry captures as the API captures above, except that the capture is performed below the MSIX Runtime, which may have already made changes to the original request from the application.
    • Process Explorer is not a tracing utility, but it can be used to help understand command line arguments, process bitness, loaded modules, and kernel objects.
  • Other commercial tools, like API Spy Studio, also target monitoring at the Windows API level. These tools generally have a wider coverage of the Windows API than the PsfMonitor has, however this extra detail may be either a blessing or a curse (as it could overwhelm you with information about API calls that the PSF fixups are not designed to fix).
  • Process Monitor and ProcessExplorer (and similar).

Depending on your needs, the pre-existing fixups can be added to your package, or you may have to create/code your own fixup.


Here are the most common types of issues, and how they are addressed via PSF are given here:


Issue Type

Issue Description(s)

Fixup Type

Shortcuts

Issues with supporting command line arguments, and specifying a working directory. Also, a package cannot have two shortcuts to the same .exe file (solvable by having separate copies of the launcher calling the same target .exe).

PsfLauncher

Scripts

Applications sometimes require modification either as part of the installation, or prior to use by the end-user. Generally, these modifications are based on the environment (Machine, OS, User, or other).

PsfLauncher

Missing Files

Although files in certain VFS folders may be present in your package, some like LocalAppData, will not be seen without a fixup.

FileRedirectionFixup

Writing to Package Files

The application cannot write to or modify files in the package without a fixup that makes a copy for the application.

FileRedirectionFixup

Dll Not Found


The application may have difficulty finding dlls that are part of the package.

DynamicLibraryFixup

Writing to

The application cannot write to or

RegLegacyFi

Registry

modify the machine portion of the registry. It may also have difficulty under the HKCU if the app asks for more permissions than it really needs.

xups

Missing Environment Variables

The application cannot see new or changed values to environment variables created or modified in the package.

EnvVarFixup