Windows Support Status

Problems with Supporting Windows

Take the fork syscall, for example. The shell needs to be able to perform forking in order to create background processes that are an exact copy of the parent process but executing a different codepath, and to assign new process group IDs to these background child processes. Windows does not support forking as a concept at all, so we'd need to replicate the forking concept from scratch for Windows. It's one of the biggest reasons why most system shells are *nix-exclusive.

There's also the manner in which *nix architectures perform job control, of which Windows also does not support at all. With *nix architectures, you configure spawned processes to set their process group ID to be the same as their process ID, and manage processes with various *nix signals, and use functions like tcsetpgrp to set foreground processes.

Or the difference between how *nix systems operate on file descriptors, which are integers, but Windows operates on handles, which are void pointers. Jobs are controlled by passing along PIDs and mapping FDs on *nix systems, but Windows is very different.

What Needs To Be Done

Basically, to gain Windows support, all of the code that manages foreground and background processes, process creation and execution, and piping / redirection would need to be rewritten from scratch with Windows-specific APIs. But for that to happen, we first need someone who uses and develops for Windows to be willing to do that.

Checklist

• Piping
• Redirection
• Signal Handling
• Replicate Forking Functionality
• Handle-based Job Management
• Process Groups
• Background & Foreground Process Management
• Integrate AppVeyor for Testing Windows Builds