Re: [PATCH v2 7/7] t/helper/simple-ipc: convert test-simple-ipc to use start_bg_command

[Adam Dinwoodie <adam@dinwoodie.org>]

On Fri, 12 Nov 2021 at 16:01, Junio C Hamano <gitster@pobox.com> wrote:
>
> Adam Dinwoodie <adam@dinwoodie.org> writes:
> > But yes, the (lack of) speed of running the Git test suite on Cygwin
> > is one of the reasons I run the tests on high-spec Azure VMs rather
> > than my own systems. Unfortunately the Cygwin compatibility layer plus
> > the overheads of NTFS mean things are unlikely to get significantly
> > quicker any time soon, and between WSL and Git for Windows, I expect
> > interest in improving Cygwin's performance is going to continue to
> > wane.
>
> Out of curiosity, are the use cases and user base of Cygwin waning,
> or are there still viable cases where Cygwin is a more preferred
> solution over WSL (the question is not limited to use of Git)?

No formal research here, just impressions as someone who has used
Cygwin for a long time and who hangs out on the Cygwin mailing list:
for a lot of use cases, WSL is at least as good, if not better, than
Cygwin. There are a few areas where Cygwin is still a better solution,
though:

- WSL requires essentially installing an entire operating system. Disk
space is relatively cheap, so that's not nearly the obstacle it used
to be, but it is an obstacle. This is more relevant for people who
want to distribute packaged installers to Windows users: most
non-technical users won't want to get WSL working, but if you've
written code for *nix and don't want to port it manually to Windows,
it's relatively straightforward to compile it using Cygwin and bundle
the cygwin1.dll file with the installer. That'll mostly get your code
working with a user experience that doesn't differ too much from a
fully native Windows application. (This is essentially what Git for
Windows is doing, albeit with an increasingly distant Cygwin fork.)

- There are some functions that Cygwin offers that WSL doesn't. The
key one for me is the ability to access Windows network file shares,
which WSL doesn't support (or at least didn't last time I checked). I
expect some of these gaps will disappear as WSL gets more features,
but I expect some of them are fairly fundamental restrictions: Cygwin
applications can have code specifically to handle the fact that
there's a Windows OS there, so they can -- with care -- interact with
the Windows OS directly to (say) use Windows file access APIs or the
Windows clipboard. WSL applications generally don't have that ability;
if I install something from apt on my Debian WSL installation, it'll
pull exactly the same binary as if I'd installed it on a normal Debian
system. I guess in theory people could write code to detect that
they're running in WSL and handle that specially, in the same way that
it's normally possible to detect and handle when you're running in a
VM versus running on bare metal. I expect that'll be much less common,
though, just as Git has code for handling Cygwin specially but doesn't
have code for handling Linux-within-WSL specially, even though both
could be used to access a Git repository stored in the same Windows
NTFS directory.

I expect some folk who historically have used Cygwin will shift over
to WSL, some will stick with Cygwin, and a small number (as I do) will
use both in parallel for slightly different jobs.

tl;dr IMO both is true: WSL is better than Cygwin for some use cases
so the user base is waning, but Cygwin is still a very viable
preference over WSL for other use cases.