6 ms·

Use Cygwin. This problem and related issues point toward reasons why: Cygwin is _designed_ to bridge, by hook or by crook, the gap between the Win32 and POSIX w

Use Cygwin. This problem and related issues point toward reasons why: Cygwin is _designed_ to bridge, by hook or by crook, the gap between the Win32 and POSIX worlds. It's not perfect, but it tries to work in a mixed environment --- even ACLs mostly work. Cygwin's Windows integration is so good that you can call CreateWindow from a Cygwin process and have it Just Work. The NT POSIX subsystem, on the other hand, is a very different beast. It's more of a container or VM-like object. That kind of operation is useful for some tasks, but when I want to use POSIX and Windows tools together on the same task, I don't want a container. I want tight integration, which Cygwin provides.

Callmenorm 10y ago
My experience with cygwin never "Just works". WSL needs to hit a much higher bar if they are going to seduce the people who use macOS because it's a better linux.
TazeTSchnitzel 10y ago
WSL is not the NT POSIX subsystem, which was a completely different thing that died a while ago.
- quotemstr 10y ago
  It's not SFU either, but it's a reincarnation of the same idea. It's a subsystem distinct from the Windows one. This year's branding is irrelevant.
  - xorblurb 10y ago
    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... :)
    - quotemstr 10y ago
      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.
      - xorblurb 10y ago
        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)
        10y ago

Callmenorm 10y ago

My experience with cygwin never "Just works". WSL needs to hit a much higher bar if they are going to seduce the people who use macOS because it's a better linux.

TazeTSchnitzel 10y ago

WSL is not the NT POSIX subsystem, which was a completely different thing that died a while ago.

quotemstr 10y ago
It's not SFU either, but it's a reincarnation of the same idea. It's a subsystem distinct from the Windows one. This year's branding is irrelevant.
- xorblurb 10y ago
  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... :)
  - quotemstr 10y ago
    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.
    - xorblurb 10y ago
      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)
      - 10y ago