3 ms·

Forking a process on Windows is really slow, making most opensource toolchains sluggish on Windows. The UNIX philosophy is that everything is a file, so you ca

Forking a process on Windows is really slow, making most opensource toolchains sluggish on Windows. The UNIX philosophy is that everything is a file, so you can read and write from files and pass data around with convenient tools... that mindset is also missing in Windows. Command lines were not foreseen as a preferred way of interacting with the system in Windows until recently. PowerShell tried to fill some gaps, and many tools integrate with it... but it's not the same. It has a long way to go.

nimish 10y ago
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
- quotemstr 10y ago
  > 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.
nimish 10y ago
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
- quotemstr 10y ago
  > 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.
- justincormack 10y ago
  One day the capsicum port to Linux might happen, but in the meantime FreeBSD does have it, so has file descriptors for processes.
  - nimish 10y ago
    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"
ch_123 10y ago
Fork was implemented in the NT kernel for WSL - https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process-overview/ https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process...
- quotemstr 10y ago
  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.

nimish 10y ago

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

quotemstr 10y ago
> 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.

nimish 10y ago

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

quotemstr 10y ago
> 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.
justincormack 10y ago
One day the capsicum port to Linux might happen, but in the meantime FreeBSD does have it, so has file descriptors for processes.
- nimish 10y ago
  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"

ch_123 10y ago

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

quotemstr 10y ago
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.