How did you get fork(2) (or clone(2)) working well enough to support Linux binaries?
By implementing a new "PicoProcess" infrastructure within the Windows kernel that allows us to create secure, lightweight PicoProcesses lightning quick!
So, if you're in a mood to share details, I would like to know how you implemented fork(2) and clone(2) under the NT process model (which, due to CreateProcess(), mandates that no process will ever have access to any state of its parent as an implicit operation), how the memory management works, whether it properly implements shared/copy-on-write pages, the whole works.
Yes, our fork() implements true copy-on-write semantics. You think we'd half-bake this thing? ;)
I'd beg you to open-source the kernel driver that implements the Subsystem for Linux
No plans to do so at this time, but we have hear the frequent request.
I'm sorry that I can't choke down the bitterness, here. Microsoft has ill-served the communities that have wanted to migrate from other platforms for a long time, and it continues to do so. It has dropped technologies and left its developers in the lurch many times over its history, and it continues to do so by abandoning the support of those technologies without open-sourcing them. I wish that I could have the benefits of Windows (like real ACLs on processes instead of relying on POSIX abandoned-draft permissions, or service logins that are sane instead of relying on systemd or its predecessor of init scripts, or a more solid driver architecture) as incremental improvements to what Linux has created thus far
... but I'm too afraid of Microsoft's old "embrace, extend, abandon" approach to ever be fully comfortable with it.
In case you've not noticed, Microsoft today operates almost entirely differently to Microsoft of old, and is run by entirely different people.