[xorblurb]

Cygwin is layered above Win32. Win32 has no provision to nicely handle forks. So even if there was an NT API fork syscall (I'm don't think there is on Windows 10, WSL does not use the NT API, there is not any more Posix/SFU/{Whatever Unix NT classic subsys of the day} as far as I know), this would not go anywhere.

[pcwalton]

> So even if there was an NT API fork syscall

You can do it with NtCreateProcess: https://groups.google.com/d/msg/microsoft.public.win32.progr...

(The Win32 userland won't understand what you did, but you can still do it.)

[xorblurb]

Well, you can do it on some versions of Windows. On Windows 10, and even future version of Windows 10, not so sure...

[lmm]

Windows 10 is still windows NT. The NT native API is widely used these days. It would be a huge departure for MS to stop supporting it in future versions of windows.

[xorblurb]

Most parts of the NT API have never been officially documented, officially supported, stable (in the "won't change" meaning), and the tiny parts that have actually been documented come with caveats that they are susceptible to change. Supporting fork through the NT API forever makes no sense if there are no users anymore. They could continue to do it for no specific reason, just because fork is internally needed by WSL for example, and so because it is easy to export the capability through the NT API, but I really don't see why they would necessarily do that.

[lmm]

MS has historically maintained compatibility with even undocumented APIs. Of course that could change.

[rossy]

Cygwin programs technically run under the Win32 subsystem, but they're not that cleanly layered. The runtime calls into a lot of Nt* functions, including undocumented ones. midipix (which another commenter mentioned) is another Unix-like environment for Windows that also runs under the Win32 subsystem, and apparently it has successfully implemented a real copy-on-write fork() on top of undocumented NT syscalls, so it's definitely possible.