The Package Support Framework (PSF) was started by Microsoft as an Open Source Project to help Win32 and .Net Framework based software operate in the new MSIX Container runtime, however the latest changes are now made in my own fork at https://github.com/TimMangan/MSIX-PackageSupportFramework/tree/develop .
The “v.2022.01.19” release completes the updates began last fall to clear up a slew of issues. It modernizes the PSF, so that it no longer uses deprecated versions of the Windows SDK, covers additional edge cases for both app launching and file accesses, as well as addressing new issues that cropped up in the December release (such as RegLegacyFixup). With these changes, the PSF is now again better capable of improving application compatibility. You will see this effect in the new Report Card on MSIX when released next month.
The individual changes are too numerous to list, but here are the highlights of what changed since the November release:
App Launching. Additional types of exe files are now supported by the PSF. This is by no means a complete fix for all types of exes, but is better than it was. More importantly, if the PSF fails in injecting itself into a process, it should no longer kill that process but just let it run without the PSF.
Child and Special Processes. The way that some applications start processes, especially child processes and the use of client file types (such as to open a text file or pdf) to spawn a process, powershell, and cmd scripting had issues with these processes jumping outside of the container. The PSF should now contain most of these. The exceptions are conhost and powershell, although the new powershell scripting solution will launch a powershell outside the container to inject the real powershell script back in.
File Accesses. I found a number of applications that required reverse virtualization searching when querying for files (Find*File calls). The rewrite of these functions is now complete and includes a potential 5-layer model to cover all known cases. The generic file redirection also now includes support for this kind of reverse lookup when opening files.
Products using PSF/Breaking Changes: For those vendors that use the PSF components to build packages, there are some “breaking changes” that you will need to be aware of. For example, the RegLegacyFixup now has some dependency dlls from Microsoft redistribution that may need to be added to packages using this Fixup. Additionally, the December release added new PS1 files that might be needed in some packages. And packages with both 32 and 64 bit exe files (or any package with AnyCPU exe files) will once again need PsfRun32.exe and PsfRun64.exe along with both bitnesses of the dll files of any fixups you include in the package.
What’s Next?: It is anticipated that February will be the next release for the PSF, as there were additional changes that have been identified in the testing and are being worked. Some of these go to the heart of how Detours is implemented. These changes will open the door for the PSF to be able to address more application issues. You can track the progress on these changes in the 2022FebUpdate branch.
The v2022.01.19 changes will be reflected in releases of TMEditX (2.0.0.0 ) and PsfTooling (5.0.0) in the near future. Other vendors including the PSF in their products may implement these changes at their own pace.
