public inbox for
 help / color / mirror / Atom feed
From: Warren Young <>
To: The Vulgar and Unprofessional Cygwin-Talk List <>
Subject: Re: native Linux userland in Windows 10
Date: Tue, 12 Apr 2016 15:46:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Apr 12, 2016, at 6:50 AM, Andrew Schulman <> wrote:
> By now I guess most of us have seen the reports of bash, and in fact a full
> Linux userland, running natively in Windows 10:

Yes; I started a thread here a couple of weeks ago on the same topic:

You might find my analysis of the feature useful.

> Apparently
> Microsoft has developed an API translation layer, simliar to the Cygwin DLL,

No, not like the Cygwin DLL at all.

From the very start, the Windows NT kernel has had a “subsystems” feature that lets it implement many different APIs on top of the core kernel.  This is the API that the old Services For Unix product (nee Interix) used, which is why I call this feature “SFU rides again.”

There are two major differences relative to Cygwin because of this:

1. NT subsystems can’t talk to each other.  Programs running under one subsystem are fully isolated from the others, kind of like running in separate VMs on the same host hardware.  This means simple things like “ps” don’t do what you expect.  Pretty much the only sharing possible is through the filesystem or network.

2. It’s not an emulation layer.  It’s all implemented inside the kernel, so you get 100% native application speed, full process isolation, etc.  Many of the problems with Cygwin simply go away: fork() problems, shared memory hacks via cygserver, etc.

> The first link cited above suggests that if this is all it claims to be, it
> would remove the need for Cygwin.

For some, yes, but it will hardly be an immediate Cygwin killer.

There are some huge areas where it will indeed be the better choice, such as running network servers.  (Apache, ssh, nginx, node…)

There are also a whole pile of disadvantages that will continue to drive people to Cygwin:

1. According to the info I’ve seen, it’s 64-bit only.

2. Only works on Windows 10.

3. Because of the NT kernel subsystem isolation, interop with native Windows processes is nearly nonexistent.  For example, I have a native Windows program I work on here that needs an MSI installer, and I build that by scripting the WiX command line tools in Bash, under Cygwin.  I can’t do that in this new “Ubuntu for Windows” thing because programs running under it can’t launch native Win32 processes, such as WiX’s candle.exe.  This is a bidirectional problem: you can’t launch a Bash shell script from PowerShell, either.

4. No X11.

5. No AD/SAM integration.

The first two are huge problems today, from a “Cygwin killing” standpoint, but as the user base moves into Windows 10, the problem will disappear.

The latter two may improve over time.

As far as I can tell, the only reason for the “no X” limitation is that they haven’t bothered to port X yet.  X being network based, you shouldn’t even need a “native” X server for it.  You could start Cygwin/X11 on the same box and run X software that way.

As for limitations like AD/SAM, that should disappear over time, too, as they go from 1.0 to 2.0.

That leaves only the inherent isolation from NT subsystems as a long-term limitation.

> I realize this may be strictly off-topic here,

There’s no such thing as off-topic on -talk. :)

> but it seems to me to be
> potentially so important to the future of Cygwin that it's worth discussing here
> insted of on cygwin-talk.

Wha??  You *are* on cygwin-talk.

  parent reply	other threads:[~2016-04-12 15:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <>
     [not found]   ` <>
2016-04-12 14:09     ` Marco Atzeri
2016-04-12 15:20       ` Corinna Vinschen
2016-04-12 15:46 ` Warren Young [this message]
2016-04-12 15:53   ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).