3 ms·

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 wi

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)

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

quotemstr 10y ago

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.