Home
Welcome to the TimMangan/MSIX-PackageSupportFramework wiki! This wiki provides documentation on this fork's version of the Package Support Framework (PSF for short). The intent of this Wiki is to provide more usable documentation for people that are using the PSF.
The PSF is a collection of software used when (re)packaging software originally developed as Win32 or Dot Net Framework based applications into MSIX in situations where that software requires remediation to be able to work correctly from inside the MSIX container without modification to the source code of the original application.
This fork of the PSF comes from the original Microsoft open-source project of the same name, which (unfortunately) is not being well maintained any more. This fork is the active fork used in a variety of my own tools, such as 'PsfTooling' and 'TMEditX', but is also ingested in one way or another by some of the other third-party tools used for (re)packaging.
While the PSF is available in a variety of forms:
- Source code form for developers needing something special.
- Prebuilt binary release versions, available from the right side of the Code page of this repository, which are more commonly used.
- IT Professionals looking to repackage existing software should also look for third party tooling that will ease the process of injecting and configuring the PSF into your package for you, although this wiki may prove invaluable to understand and tweak what you get out of those tools.
The PSF consists of a Launcher application, and a number of Fixup dlls that each offer different kinds of remediation support.
To use the PSF in an MSIX package, the PsfLauncher must be made as the entry point into the container for the end user. This exe will end up being the target of shortcuts, file type associations, and other entry-points to the application.
PsfLauncher supports the following remediations:
- Adds support for parameters that might be used in an original shortcut (lnk) that are not directly available in MSIX:
- Command line arguments to the target application.
- Specifying the Working Directory for the target process (which is changed to the System32 folder under MSIX by default)
- Allows for start/end of application scripts, which may be used for client-side configuration of the application. MSIX does not support any kind of client-side scripting to be performed at installation time.
- Allows for the specification of a monitor program to be run prior to the application. This is used in debugging in conjunction with the PsfTrace fixup.
The PsfLauncher can also inject any of the following Fixups dlls into the target application. This injection occurs prior to the application being allowed to run and offers a variety of intercepts into well-known Windows API calls to affect the behavior of the app when running in the container.
More information on PsfLauncher in the wiki PsfLauncher page.
PsfTraceFixup provides for logging of the well-known API calls that the application makes. The specific calls that are intercepted for this logging line up with the calls intercepted by other fixup types. This fixup is used without other fixups to help detect what fixups are required. When used in EventLog mode, the fixup output may be viewed in a convenient monitor also started by PsfLauncher (PsfMonitor).
More information on PsfTraceFixup in the wiki PsfTraceFixup page. More information on PsfMonitor in the wiki PsfMonitor page.
This fixup supports the redirection of file requests by the application to ensure correct functionality. This fixup is used for one of the following situations:
- The package contains VFS files that would normally have been placed under either the user's AppData\Local or AppData\Roaming folders. Without FileRedirectionFixup support the application would not see these files layered into the virtual file system like other VFS paths.
- The package contains files that the end-user can modify. These are often configuration files that have default files that are part of the package. Package files are generally immutable without the FRF.
The fixup had considerable configuration to adjust what may be intercepted or not.
More information on FileRedirectionFixup in the wiki FileRedirectionFixup page.
This fixup supports older applications that request registry permissions or actions that are not compatible with the MSIX container. Currently the fixup only addresses issues with HKCU requests.
The fixup is configured using rules. There are currently two types of rules supported:
- ModifyKeyAccess - adjusts the permissions being requested when the application open a registry key. Some older applications request full access to the key, which would grant them permissions that the MSIX runtime won't allow but would have been OK in a native application running outside of the MSIX container. In so many cases, we see that the app did not need those extra permissions, so this rule adjusts the permissions requested to the MSIX registry to the subset supported.
- FakeDelete - Deletion of a key/item that is part of the package is not allowed by the MSIX runtime. This rule simply returns a success result to the application without asking for the delete. Some apps use the registry as a scratchpad area and make these calls as part of cleanup when shutting down. Adding this rule may prevent an application crash at shutdown.
More information on RegLegacyFixup in the wiki RegLegacyFixup page.
This fixup ensures that the application will find a dll if it is located anywhere in the package. There are several causes of dlls not being found when migrating to MSIX, and this ensures they are fixed.
More information on DynamicLibraryFixupin the wiki DynamicLibraryFixup page.
This fixup makes Environment Variables that are part of the package available under MSIX. The application may also update one of these variables at runtime (or this may be prevented by configuration of the fixup)
More information on EnvVarFixup in the wiki EnvVarFixup page.
This is a fixup defined for applications built on the Electron framework.
More information on ElectronFixupin the wiki ElectronFixup page.
Typically, this fixup is only used by a developer wanting to attach a source code debugger to the target application.
More information on WaitForDebuggerFixup in the wiki WaitForDebuggerFixup page.
The PsfLauncher exe file and PSF dll files are available in both 32 and 64-bit versions. The version used must match the 'bitness' of the target application. As files, they are provided with names including X86 and X64 as the base of the filename, such as 'FileRedirectionFixupX86.dll'. There is also a PsfRunX**.exe in both bitnesses which is helpful when a process of one flavor launches an exe of the other (32 to 64 or visa-versa). The exception components in both flavors PsfMonitor.exe which is provided as an 'AnyCPU' program.
MSIX packages may not have two applications as entry-points using the same name. Thus it is normal to rename the PsfLauncherX**.exe program in your package. A common form of the name will be PsfLauncher1.exe, PsfLauncher2.exe, etc.
To be Provided. This is about some of those scripting files.
Actions taken by the PsfLauncher are controlled through a JSON based configuration file named "config.json". This file may be placed anywhere in the package, however either the root folder of the package or the folder where the primary application is are preferred. Only one copy of the file is allowed, no matter how many launchers are in the package.
More information on Config.Json in the wiki Config.json page as well as wiki pages on the individual components that use the file.