For those unaware, PSF stands for Package Support Framework, an open source utility that I contribute to for helping traditional Win32 and DotNet applications run inside the MSIX packaging container. This article contains information regarding new contributions.
First of all, the title of this article is a lie. The correct title for this article, if it weren’t so long, would be “What’s new in my fork of the PSF which will end up in Microsoft’s fork when they can manage to catch up with me”. One Pull Request into the mainline source has been stuck awaiting personnel availability at Microsoft and I have a larger one ready to go as soon as that one is resolved.
But I don’t want a slow Pull Request process to impact our ability to get work done. My changes are complete and we will shortly have a new version of PsfTooling using these changes, so here is the article explaining them. You do have this version available to you today in source form in a branch of my fork, which is accessed from this link:
https://github.com/TimMangan/MSIX-PackageSupportFramework/tree/FindFileAndLogging
There is a lot in there. I have been focusing exclusively on applications that I tested and analyzed as part of this year’s Report Card on MSIX and making changes to the PSF so that these applications will be deployable. This year’s report showed that using the PSF we could expect about 40% of typical enterprise apps to be deployable, up from 20% the year before when the PSF wasn’t ready for IT Pro use. The changes I am adding to the PSF here raises that acceptable rate by another 10%. So what is in there?
Fixes involving the PsfLauncher:
Any app needing the PSF uses PsfLauncher. By itself, if allows us to fix shortcut related issues, and bring in monitoring and scripting. It is also a pre-requisite to use the other fixups.
- Directory Iteration bug. There was a bug in the launcher affecting certain apps that resulted in the launcher crashing.
- Arguments. Support for target command arguments involving filepaths that are part of the package. We introduce a new pseudo-variable %MsixPackageRoot% that you can use in the config.json in the arguments field. The launcher will resolve this and start the command with the mounted path of the package (which could be different on different systems).
- Shell Launches. Last year I added support for shortcuts to files that were not exe files by using a Shell launch. Unfortunately these shell launches run outside of the container, which is OK in some cases but not in others. The Shell launches will now attempt a technique recommended by Microsoft to launch these inside the container. These changes are now in place, but ultimately the MSIX Runtime still launches it externally. The changes do no harm so they are going in hoping that we can get a future change to the runtime to accommodate. Microsoft has not committed to anything on this yet, but see the scripting issue below.
- Scripting Changes. There were issues with the script launching if you did not provide a reference to the file relative to the package, such as a script file on a network share. This is now resolved, and you may reference a script file either inside or outside the package. The reference to the script file inside the package may be a relative path to the file (from the root folder of the package) as before, or it may also use the %MsixPackageRoot% pseudo variable.
Also, file references to the script file that included spaces were also not resolvable in the original code. These are now detected and appropriately escaped using the PowerShell back-tic.
Be aware that, similar to the issue for Shell launches, the scripting implementation jumps out of the container even if you ask it not to. The launcher uses PowerShell to run your script (technically to run a PSF provided script called StartingScriptWrapper.ps1 which must be added to the package and that script calls your script). As PowerShell.exe is not part of the package, even through the code tries to launch it inside the container if you ask it to, it currently always runs external to the container. We will need Microsoft to resolve this (probably in the OS itself) , but we don’t have any commitments on it at this time.
Fixes involving FileRedirectionFixup:
The FileRedirectionFixup (or FRF for short), is our primary fixup used to resolve a host of traditional application issues for running in the MSIX container.
- PrivateProfile. Applications that make use of ini files using the Get and Set Private Profile APIs were broken when using the PSF because only a small subset of the APIs were targeted by the FRF. Coverage to the full set is now included.
- FindFirstFile and friends. Previously these intercepts supported a two layer strategy of finding files in the redirection area layered upon the path as requested by the app. Now it supports a third layer to cover files in the package VFS paths not found by the MSIX Runtime. Additionally, a few edge cases (network shares and the root of the C: drive) needed fixes.
- GetFileAttributes and friends. Edge case fixes were needed to resolve several issues involving VFS pathing inside the package seen in applications needing the FRF.
- CopyFile/MoveFile and Directories and Friends. Resolved more edge case issues involving VFS pathing inside the package.
- Crashes. There were instances when adding tracing led to crashes due to the tracing code. Generally these were cases where the application was making a call with incorrect parameters. All intercepts are now protected, and if an exception occurs the issue will be logged and the original requested API call attempted so that the app receives the same result as before.
Fixes for Tracing/Logging:
The TraceFixup is used for debugging MSIX issues. The fixup can log information to the verbose debug log (which you can view with a tool like Sysinternals DebugView) or to the PsfMonitor utility that is part of the PSF (for a more ProcMon like experience).
- Event GUID. A fix for PsfTracing to use the correct GUID for PsfMonitor was made. This was broken when Microsoft introduced the customer improvement tracing to the PSF.
- API Call ID. A general change to improve the tracing by including a API call instance identifier was added. I found this was needed when tracing multi-threaded applications where similar calls were overlapping with each other and using the debug output method of viewing the results.
- Crashes. There were instances when adding tracing led to crashes due to the tracing code. Generally these were cases where the application was making a call with incorrect parameters. All intercepts are now protected, and if an exception occurs the issue will be logged and the original requested API call attempted so that the app receives the same result as before.
What’s next?
A updated release of PsfTooling is in the works (version 3.5). In addition to including the PSF changes above, it will feature a stream-lined UI to help implement the PSF faster and more accurately, address more FTA issues, and make scripting easier. Stay tuned for more details.
