For the MS folk reading this: native zsh on Windows, please?
WSL2 is great, but native POSIX is even better. Of course it’s a big undertaking, but it makes Windows a first-class dev platform for those who need POSIX in production.
WSL2 is great, but native POSIX is even better. Of course it’s a big undertaking, but it makes Windows a first-class dev platform for those who need POSIX in production.
And that would suck.
However, I'm not keen on using yet another Unix clone as well. At least Windows NT brought the world into 90s in the OS state-of-the-art where Unix clones are stuck in 80s and each of them patch around the deficiencies of POSIX. Native asynchronous APIs and truly object-oriented system call infrastructure is nowhere to be found in POSIX.
And it was never _fully_ implemented, as my post said. The NT kernel doesn't support certain POSIX semantics (fork).
> As an example, the Linux fork() syscall has no direct equivalent call documented for Windows. When a fork system call is made to the Windows Subsystem for Linux, lxcore.sys does some of the initial work to prepare for copying the process. It then calls internal Windows NT kernel APIs to create the process with the correct semantics, and completes copying additional data for the new process.
The MSFT driver prepped something-like-fork and then called the native NtCreateProcess, which does not implement anything like fork().
Just because YOU don't have access to the functionality used for fork, it doesn't mean that there are no internal API calls that can do a fork or do something very similar that it is indistinguishable. A ring-0 driver (like lxcore.sys) that can access a non-standard special process model (pico processes) and is allowed to register its own syscall entry/exit points can also access lower level functionality like accessing the page table of a pico process, modifying it and responding to non-Win32 syscalls.
When you run fork in a WSL1 program now, its effects are the same as doing a fork natively on a Linux kernel: the memory space view is cloned as CoW, a new stack is allocated and the execution is resumed in both processes. If it forks like a duck, it is a duck.
Yes standard Win32 cannot do forks. However, Win32 isn't the only identity NT can expose and NT provides functionality to do forks. Just not to the normal programmers.
Actually a further research reveals that it is very much possible to trigger forking behavior even from the user space. Here is the proof: https://github.com/mobdk/CloneProcess https://stackoverflow.com/questions/985281/what-is-the-close... . You just need to use ZwCreateProcess.