Also, on Unix everything is a fd until it isn't, like timers, signals, semaphores , pids...(and sockets have their own peculiar API). Pids not being fds leads to a really annoying issue of basically not being able to easily implement a robust way of handling child exits

NT is more Unix than Unix in a lot of ways, where everything is an object (more or less)

Plan 9 though really ran with the whole file thing

> NT is more Unix than Unix in a lot of ways, where everything is an object

Yep. NT's design in this respect is great. Each NT object also has a name in a global system namespace; each object has its own access control list; and most objects are dispatcher objects that you can use with functions like WaitForMultipleObjects. In Windows, it's trivial to wait for, say, a socket* and a process at the same time.

I've always wanted to add NT-style process handles to Linux. A few other people have tried, but Linus has rejected their patches on the grounds that if you can open a handle to a process (preserving its PID), a program can fill up the process table.

I've never bought this argument. You can fill up the process table in other ways today without a ulimit, and we can make the process ulimit apply to process handles too.

...

* Screw you, in-process winsock providers. My programs treat sockets as regular HANDLEs, and if you install some shim that breaks this model, shame on you.

One day the capsicum port to Linux might happen, but in the meantime FreeBSD does have it, so has file descriptors for processes.

And signals, timers and events (inc semaphores) have non-standard fd versions too, but they've been bolted on and you need all kinds of new syscalls to make them work right.

Plan 9 did it right if you want to go "everything is a file"

Fork doesnt make a lot of sense on win32 processes (how do you handle a forked message loop?) so the functionality isn't exposed, though nt native processes can do it. The best you can do is a spawn equivalent with manual copying of structures so you lose the CoW fork semantics that allow for speed on Unix.

For Linux subsystem processes fork works pretty well, but they are different animals

> Fork doesnt make a lot of sense on win32 processes (how do you handle a forked message loop?

Message loops are per-thread and per-HWND (which are thread-affine) anyway. One way of making fork "make sense" in win32 processes is to say "Okay, you can fork, but your new process begins execution in a new thread, and none of the old threads survive."

New thread means new message loop. You could even do things like automatically tear down single-threaded COM apartments in the child process.

Fork was implemented in the NT kernel for WSL - https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process...

Fork worked already, as the article notes. What I really want is fork to work for the win32 subsystem! I want Cygwin, not WSL! I want tight integration between the POSIX and Win32 worlds, not the pseudo-container that WSL gives you.