Windows Support

[rydrman]

I've had a number of conversations about windows support lately, and so I wanted to write down some of the details and next step items that have been discussed.

On windows, spfs will manage the C:\spfs path via a virtual file system implemented with WinFSP. Spk will need to consider multiple OSes in its next spec file version, specifically where you would need to be able to define build scripts for different scripting environments on different platforms.

Roadmap

• WinFSP Rust Bindings
  WinFSP is a virtual filesystem (like FUSE) for windows, written in C++. We will need to produce at least some minimal Rust bindings that allow us to set up and implement a filesystem in Rust. There's lots of documentation on this process, and I have some snippets from the initial PoC that I can provide.
• Windows build pipeline for CI Windows SPFS Build #829
  We will want to be able to make the necessary changes incrementally. Being able to build the codebase on windows, even if we just return errors in the windows code would allow us to contribute changes for windows into mainline moving forward.
• OS-Agnostic File-System Errors Initial Windows Runtime Support #880
  A lot of the spfs codebase relies on libc error codes to identify and handle file system errors. With the move to windows, we will need to define new error types that can represent the same conditions on both platforms and be handled agnostically.
• VFS-Friendly Startup and Commit Fuse Backend (First Pass) #657
  Spfs currently assumes that we need to create renders, and establish working space for overlayfs but with WinFSP we will be able to server directly from the object database. We will also need to change how we store writes and manage the commit process in the VFS world.
• VFS Implementation (Read-Only) Initial Windows Runtime Support #880
  Using WinFSP, we'll need to create a filesystem implementation that mimics the spfs overlayfs implementation. WinFSP is mounted as a single filesystem so the implementation will need to track process trees and associate them to active runtime environments. Whenever a filesystem request is made, we will need to identify the active environment (or lack of) and return results based on that. (@rydrman can speak more to this and the initial PoC)
• PowerShell environment support Initial Windows Runtime Support #880
  Spfs will need to support PowerShell as an environment setup and startup shell on windows
• Multiple Scripting Languages in Package Specs
  We are already designing the next iteration of the spk spec file format Updated Package Spec - v1alpha1 #296, but part of this will need to include the ability to write build scripts in PowerShell for windows, and just generally have multiple scripts for different builds of a package.
• Environment operations support for PowerShell
  The environment operations in spk generate startup scripts for different shell environments, which will need to be updated to also generate PowerShell ones.
• Runtime Management
  Without mount namespaces, windows will use a single VFS for the entire system. This service will also need to replace the monitor process in order to track which process are in which runtimes, and then clean up the runtime when they have all exited.
• Writeable VFS
  The current implementation of the WinFSP filesystem is read-only and we will need to support edits in order to use the commit workflow in spfs that spk relies on.