25 Jul
2020
25 Jul
'20
8:45 p.m.
On Thu, Jul 23, 2020 at 8:15 PM Clem Cole <clemc(a)ccc.com> 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(a)ccil.org
You escaped them by the will-death and the Way of the Black Wheel.
I could not. --Great-Souled Sam