[signal11]

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.

[0x1d7]

The NT kernel could never implement full POSIX semantics. It would have to be another UN*X clone to do so.

And that would suck.

[okanat]

NT kernel can and did implement POSIX. Multiple times even. That's how WSL1 works. NTFS can also support Unix-like permissions. There are ACLs for Owner and Group.

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.

[0x1d7]

POSIX was implemented as a subsystem.

And it was never _fully_ implemented, as my post said. The NT kernel doesn't support certain POSIX semantics (fork).

[okanat]

WSL1 DOES implement fork() for WSL1 lightweight processes in the lxcore.sys driver: https://learn.microsoft.com/en-gb/archive/blogs/wsl/windows-...

[0x1d7]

The NT kernel does not understand fork(). You can-sorta-fake-it, which is what WSL1 did. There's no equivalent to fork() in any version of Windows. From your link:

> 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().

[okanat]

In the next post they literally tell that NT kernel "supports" it https://learn.microsoft.com/en-gb/archive/blogs/wsl/pico-pro... . In the same post if you scroll down into the comments they also say that their fork implementation

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.

[piperswe]

Isn’t Win32 also implemented as a subsystem?

[0x1d7]

Yes, but the Executive has a hard dependence on Win32 for service control.

[yjftsjthsd-h]

Surely WSL1 proves that it mostly can