On Thu, Jul 23, 2020 at 8:15 PM Clem Cole wrote: > 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. > Historically that was true, but no longer. Since 2000, more and more direct calls to the NT Executive have appeared in the cygwin1.dll source: there are about a thousand of them now, invoking about 90 different Executive APIs. Such features as flock(), mmap(), and reading from block devices cannot be done in Win32 and use the Executive directly. Unfortunately, it also makes Cygwin a bit more brittle to Microsoft changes, as the NT Executive API is permanently unstable. So far, Corinna and friends are keeping up nicely. 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]. > Thanks for the history! BTW, when you say "Win32S" you mean "Win32". Win32S was a long-obsolete package to let 32-bit Windows apps run on 16-bit Windows if they didn't try to do too much. (Which reminds me that in my list of subsystems running on the NT Executive, I forgot to mention WoW64, which provides a 32-bit WIn32 environment on the 64-bit Windows kernel, and is used to keep 32-bit Windows apps running.) > Anyway, my own experience is IF you have to use Windows 10, WSL pretty > much 'just works.' > I agree. However, I have spent much of my career on corporate Windows boxen, which are often locked down to prevent you from installing things, including WSL. Because Cygwin bypasses the regular Windows install system, it flies under the radar. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org You escaped them by the will-death and the Way of the Black Wheel. I could not. --Great-Souled Sam