On 7/23/20 12:33 PM, Doug McIlroy wrote:
> I must admit, tough, that this approach will be pretty onerous if
> you do not want Cygwin for any other reason.
Do you have any idea how Windows Subsystem for Linux compares to Cygwin?
For this use case and / or in general?
The short answer is that Cygwin can never work as well as WSL because it's layered on top of Windows and has to map. So the API is inherently only as good as what Windows presents to the user. Which is often good enough... but it is incomplete and different workarounds are needed.
When I was as DEC I was involved with the whole story ... so let me pull much of the rest of the answer from my Quora answer to is 'Windows POSIX compliant'[1].
The long answer is this…. In the late 1990’s US Gov with the FIPS-151 standard, required all systems sold to the US Government be “POSIX” compliant [details of much of this is spelled out in John Quarterman's book UNIX, POSIX, and Open Systems]. At one time after the publishing of FIPS-151, the US Air Force tender
a bid that DEC and Microsoft wanted to chase with NT/Alpha. Microsoft/DEC (having only completed that *.1 interface with their POSIX subsystem), and did win the tender. Unisys sued saying that *.1 only subsystem, was not the spirit of the requirement. Microsoft’s defense was that they had built the API and that they were enabling 3rd parties to do the userspace work since their own user space was Windows and its Win32API. In the end, Microsoft/DEC was allowed to proceed
provided a 3rd party appeared to fill that hole by some date (I’ve forgotten the details). In effect, they were required to produce a fully functioning POSIX based NT system by said date. To meet the requirement, Microsoft cut a deal with a small firm (Softway Systems - our old friend from Univ of Toronto, Steve Walhi for other old-time-Unix folks) to develop the same which was released as Softway’s “Interix” product. Which in fact, did not suck
For real UNIX types like me, Steve and the team made Windows bear-able and frankly has fewer 'strangeness' that later/other UNIX for windows efforts because the Softway solution actually lives side-by-side with Windows as an NT client, so it calls the NT uKernel directly. i.e. it does not use the Window API under the covers (Cygin, UWIN, et al - sit on top of the Win32S so are ultimately limited to what features and conventions Windows provide under the covers).
The Softway folks actually had sources to NT from Microsoft and added some missing APIs (for instance NT’s file system has always support hard and softlinks, but Win32S does not have calls to create them). The fixes/changes were then taken back and released in Windows updates as needed. The original commands were primarily taken from FreeBSD and Gnu as needed, and all of the “open source” requirements were met - in that anything that Softway had taken with a GPL was made available (which was only userspace code, such as gcc and its libraries).
Because it is a microkernel, the POSIX subsystem and NT share the native file system. A problem is that UNIX (Posix) file permissions are not as refined as NT's, so there are things that the subsystem can not do, because it does not have a mechanism to do it. But it means, that as a user, you could compile run POSIX code as expected without any real mapping. So primary issue when “porting” code from a “real UNIX” such as Solaris, Tru64, or a Linux distro; tended to be that the NT file system supports a different security model than POSIX requires and POSIX APIs do not have ways of supporting some of those features.
Eventually, Microsoft bought Steve and the Softway folks and brought the Interix product in-house, released it as SFU - Services for Unix, and later renamed it SUA - Subsystem for UNIX-based Applications. However, in Windows 8, SUA was depreciated and then later removed it from Windows 8.1.
Starting with Windows 10, Microsoft (re)released it as WSL - Windows Subsystem for Linux, which resurrected the subsystem, but working with Canonical, make the API a Linux API and the commands based on Linux (Debian) versions instead of FreeBSD. The Linux kernel emulation was “clean room” and based on the earlier code, so none of that is tainted by the GPL. But anything in userspace that uses GPL is again available for download per the GPL licenses. You can recompile locally, although I believe that intentions were that userspace binaries from an Ubuntu 14.04 image are supposed to be able to run as-is under the subsystem. Changes in userspace code were really to make the command interact in a manner that is easier to utilize the base NTFS and live reasonably on the same uKernel side-by-side with a Win10 subsystem.
Also remember POSIX never defined X-windows, so that was always interesting. When Interix was released there were a number of X-Windows systems for NT. Those days, Hummingbird was the most popular. However, Softway (and later Microsoft) was always careful to ensure that it did not matter which X subsystem you ran. Today the Cygwin/X is what most people use if you need to use X under Windows (NT). Since WSL runs side-by-side, it all 'just works' (and I say, don't suck).
So coming back to it, WSL tends to have fewer 'rough edges' than Cygwin because it really is UNIX (Linux) under the covers, not trying to force Windows into doing its will by trying to map UNIX (Linux) into Win32S (or Win64). But, in all cases, UWIN, Cygwin or WSL, the file namespace is the same and shared (i.e. one disk file system), although windows are needed to support some (permission) style operations that POSIX never defined. My experience with the subsystem, if you plan to run it, then I would also recommend not using some of the NT file system (well Culter/VMS-ism to be more specific) additions, as UNIX (Linux) programs can get confused. [But a few of us ex-DEC Unix types have fought with Culter about those differences since the 1980s, so that's nothing new].
Anyway, my own experience is IF you have to use Windows 10, WSL pretty much 'just works.' We do a lot a Linux and Windows mixed work at Intel, and many (??most??) people turn it on and stopped using MKS/UWIN/Cygwin if they had to deal with Windows 10.
That said, my personal solution for a number of years is to try to not use Windows at all, and run Mac OS, which is a different set of issues but at least for a old-time UNIX guy, less troublesome.
Clem