The new approach is relevant. NT POSIX or SFU was a completely different target from mainly used Unixes of their time. Now GNU/Linux has supplanted everything (Mac Os does not really rely on nor is administered by its Unix layer), Ubuntu is a major and well maintained distro, and even the WSL Beta in the AU has a quite impressive compat -- and the last insider versions are even better. So will WSL become irrelevant? Maybe: either at the same time Ubuntu does, or if MS decides to stop this subsystem project. I hope they don't... :)
It's just a different system call interface though. The big integration problem remains. Microsoft could definitely solve it differently: specifically, there should be a winuser.so loadable in WSL that would do the same job as user32.dll and kernel32.dll do in win32. It could, in principle, talk to win32k.sys.
Personally, though, I'd like Microsoft to make two changes to the _existing_ win32 subsystem:
1) expose as public API the interface between the kernel console subsystem and conhost.exe: this interface will not only allow Cygwin to supply a real pty layer, but also let programs like console2 work much better
2) teach win32 userspace components to tolerate NtCreateProcess-based fork, and make CSRSS understand what's going on. Then regular win32 processes (like Cygwin programs) can fork and take advantage of the copy-on-write semantics that NT already supports
If I ever rejoin Microsoft, I'm going to push to get this functionality implemented. If core Windows ever goes open source, I'll implement it myself.
Forking and copy on write is important for historical reasons but very few tools can take advantage of this model, and it causes its load of problems (ex: if widely used on the system, need for overcommit). Something like CreateProcess / posix_spawn / vfork+exec is actually a better model 99% of the time fork would be used for fork+exec. I don't see what would be achieved in the pure Win32 ecosystem by providing more support for forking+CoW, and Cygwin already work well enough without that kind of official Win32 support of fork+CoW.
I understand what you desire is to get something like a better Cygwin instead of following the WSL approach, however that won't leverage the Ubuntu ecosystem, so that would still have the same problems as what I described for NT Posix and SFU: Cygwin is a target completely separated from mainstream ones -- the tools WSL is trying to provide (and succeeds in doing so -- available today) would not be as well maintained and/or even working correctly (if available at all).
Now I agree that an interface is needed to provide alternate console implementation, and the current situation in that regard, and hacks used to make ConEmu or console2 kind of work, are terrible (and unfortunately it is now even worse with WSL, and an absolute mess with the new WSL interop in Insider builds)
Lots and lots of software does use fork, though, so in lieu of rewriting the world, fork has some utility.
> Cygwin already work well enough
:laughter_to_sobbing:
Cygwin's fork works, but it has two major problems: 1) it's slow, and 2) it relies on awful hacks to load DLLs at the same virtual offsets in parent and child, and if these hacks fail (which they do if it's the wrong day of the week, or if the moon has the right phase), your fork fails. With proper fork support, this operation becomes fast and reliable.
I agree that vfork is better. Implementation complexities made Cygwin define vfork as fork though. :-(
> I understand what you desire is to get something like a better Cygwin instead of following the WSL approach, however that won't leverage the Ubuntu ecosystem,
That's true, but Cygwin has enough critical mass that its own ecosystem is usable. FOSS developers of third-party packages usually care to some minimal degree about Cygwin support, for example, and will take patches to help it work better. SFU never achieved that critical mass.
> Now I agree that an interface is needed to provide alternate console implementation
I never understood the difficulty of making this feature happen. It's clearly needed, as evidenced by all the awful hacks out there, and it's not even that hard: I've seen the conhost code. You could make the protocol a public API with minimal changes.
Yes, the resulting interface ends up being a bit more complicated than openpty(3), but that's okay.
