This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: native Linux userland in Windows 10

On Apr 15, 2016, at 4:04 AM, Andrey Repin <> wrote:
>> And yet, despite the free
>> availability of top-quality VM technology, Cygwin continues to thrive.
> Because interoperability.

So the ability to run native Linux ELF binaries without recompilation on Windows is not âinteroperabilityâ?

>> UfW wonât fill 100% of the use cases of Cygwin from day 1, but for a lot of
>> cases, the two will be interchangeable,
> Name me a few.

I can name a bunch, including some where UfW comes out ahead:

1. The Cygwin solution has some fatal flaw, either due to a missing POSIX facility in cygwin1.dll or an attempt to bypass the DLL, going straight to the Windows API under Cygwin, which results in mismatched semantics.

One such example is the recent complaint thread about Gitâs path handling, which wouldnât even come up under UfW, because it isnât Windows at all.  Git under UfW has exactly the same semantics as under Linux, where presumably the semantics are perfect, since Linux is gitâs natural environment.

Another example is CRLF and UTF-8 handling.  Any program running under Cygwin that bypasses its POSIX interfaces (e.g. calling ReadFile() instead of read(2)) will likely do strange things with LF-terminated UTF-8 text files, whereas a UfW binary will always assume LF and UTF-8 (or $LANG, anyway) text encoding.  Thus, all the hacks in Cygwin and Cygwin-ported executables for CRLF workarounds (e.g. Cygwinâs âtextâ mount option hack, the crnl-glob feature in Fossil to make it ignore CRs when determining if a file is âbinaryâ, etc.) donât need to exist under UfW.

Still another example is the unfortunate mismatches in Windows vs POSIX file locking semantics, as you recently noted in your recent thread complaining about another âuselessâ feature, Cygwinâs flock() implementation.  Again, the insides of the UfW box are completely POSIX, not Windows at all, so presumably locking semantics are Linux-native (i.e. advisory by default, rather than mandatory), too, so there is no mismatch between Windows and POSIX semantics.  Here, the wall between NT subsystems helps: you canât have a Windows app and a UfW app fighting for lock control of a single file, since Windows apps canât even see inside the UfW filesystem.

(You could have such a fight through the /mnt/[driveletter] door, but thatâs like arguing that the availability of NFS or SMB locking prevents Linux locking semantics from working correctly.  Conflicts can only occur in the shared filesystem.)

2. Many people using Cygwin merely want a given non-portable Unixy tool (e.g. git) to work on Windows.  The choice between installing Cygwin git vs installing UfW from the Windows app store and then saying âapt install gitâ is a âsix of one, half a dozen of the otherâ alternative, as long as youâre only interested in managing a Windows git tree from the command line. 

If you need non-CLI things to work, such as like git gdiff integration with, say, Beyond Compare, then of course youâd have to use Cygwin git or similar, such as the MinGW-based âGit for Windowsâ offering instead of UfW git.

3. Youâre using Cygwin merely to give Windows an interactive POSIX userland, so you have things like grep and sed for operation on Windows filesystem objects.  The same ability to say something like âsed -i -e s/foo/bar $(grep -Rsl foo)â in Cygwin works just as well under UfW.  It works better under UfW, in fact, since the recursive filesystem search will probably be a lot faster under UfW, since all file access isnât going through an in-userspace POSIX translation layer.

This is what I meant when I described UfW as an apology to Windows users for the complete misinterpretation of request vs intent when the PC poweruser crowd demanded a better shell and Microsoft gave us PowerShell instead of what we actually wanted, which is something more like Bash.

4. Youâre using Cygwin on Windows to test software that normally builds and runs on Linux on a PC where installing Linux or a VM manager isnât an option.  (e.g. A typical corporate locked-down desktop PC.)  Given a choice between Cygwin and UfW, both will work; UfW will probably work better, since your actual deployment environment needs ELF executables, so you can even build distribution tarballs under UfW, whereas under Cygwin, youâd have to do cross-compilation, which adds a bunch of complexity.  (Custom compilers, separate include and lib trees, etc.)

In fact, in such an environment, UfW might have a distinct advantage, being available through the Windows Store.  A typical corporate PC lock-down policy might not restrict installation from the Windows Store (such apps being pre-vetted, signed, and therefore âsafeâ) but might prevent installation of Cygwin, since Cygwin is third-party and doesnât normally install on a per-user basis.

5. Anything where the Ubuntu package repo has software not present in the Cygwin or Cygwin Ports repo.  For example, the Cygwin package repo only has iperf2, which is protocol-incompatible with iperf3.  If you need to do a bandwidth test against a remote system running iperf3, installing UfW so you can âapt install iperf3â is probably easier than porting iperf3 to Cygwin and maintaining a private copy.   

(Indeed, iperf3 doesnât build OOTB on Cygwin due to an API conflict with newlib, a problem that doesnât impact glibc based systems like UfW.)

Plus, iperf3 measures I/O overheads, so the lower impedance mismatch between the UfW ABI and the cygwin1.dll translation layer means the benchmark results will probably be more accurate under UfW.  (i.e. A truer measure of the systemâs network I/O bandwidth.)

6. A lot of Unix software runs like a pig under Cygwin due to the user-space gyrations Cygwin must go through to implement POSIX semantics under Windows.

The classic example of this is fork(), which makes a lot of software (e.g. Apache, shell scripts, etc.) much faster on Linux or in native Windows ports than under Cygwin.

Another example is anything dealing with many I/O sockets or other file descriptors, which often use poll() or epoll() on Linux for speed, relative to select(2).  Cygwin doesnât implement epoll() at all, its poll() implementation is done in terms of select() (therefore giving no speed advantage at all) and its select() implementation doesnât even delegate to the in-kernel Windows Winsock function select(), but instead reimplements its effect purely in user space in terms of Windows events, which are limited to 64 per user thread, purely to get POSIX semantics (e.g. select() on FD, FD passing, etc.) under Windows, things the Winsock select() implementation doesnât provide.  All of this makes Cygwin select() much slower than Winsock select(), which in turn is much slower than more modern interfaces native to Linux and its competitors, such as epoll(), kqueue, aio_*(), and IO Completion Ports.

Still another common area of Cygwin weakness is in threading.  Cygwinâs handling of threads is a lot better these days than it used to be, but itâs still not at the level of thread handling under Linux, due to the translation layer Cygwin needs to supply to convert POSIX threading semantics to Windows semantics.  We saw this on the mailing list not long ago when someone posted a question about using C++âs native threading libraries under g++ on Cygwin, where Cygwin did something very odd that it didnât do on Linux.  No one answered the question, apparently because so few Cygwin users really understand how Cygwin threads are supposed to work, whereas such software Just Works on Linux, where the NPTL library and its in-kernel backings (e.g. clone(2)) are highly-debugged and optimized.

Thus, the availability of UfW will be a much greater disincentive to create native Windows ports of software than Cygwin ever was.  We have things like native Apache for Windows because it simply runs so much better that way than under Cygwin, because it swaps out all the POSIX mechanisms for native ones, removing the impedance layer mismatch.  That was necessary 20 years ago when the alternative was Cygwin and all its attendant limitations.  The same will be true for anything else based on libapr, like Subversion, another piece of software thatâs difficult to port to Cygwin, as I understand it.  Whereas âapt install subversionâ is trivial.

7. Running âtoo-portableâ software.

A lot of things ported to Cygwin have in-tree support for building natively on Windows as well.  (e.g. Perl.)  Often such software has â#ifdef WINDOWSâ conditional code in it, so that it behaves differently when run under Cygwin than when run under Linux, because its portable code compiles instead of the POSIX alternative.  Thus, a UfW version of the same program may simply behave more correctly than a naive rebuild of the same source under Cygwin.  A true Cygwin port â where all the #if WINDOWS code is carefully rewritten so the ifdef path isnât taken under Cygwin â may simply not be available, whereas a proper Linux binary build may be available under UfW.

8. All of us who greatly prefer installing software via a command line package manager (e.g. apt, pkg, brew, yumâ) rather than a GUI (e.g. setup.exe) will probably be happier under UfW than on Cygwin.  âapt install fooâ is a whole lot easier than Cmd-E, navigate to the Cygwin download folder, and click-click-click for 2-3 minutes to navigate the GUI just to install one piece of software.

9. A lot of software for Linux simply isnât portable enough to build under Cygwin, and there is no native Windows port.  Such software may do low-level unportable things, include assembly language hacks, etc. that donât work on Windows, so your only alternative heretofore to run such software on a Windows box was to run a Linux VM.  (e.g. Node.js, the Oracle JVM (as opposed to Cygwinâs current JVM alternative, gcc-gcj), Valgrind, etc.)

Bottom line, for many use cases, UfW might well completely displace Cygwin.

Obviously Cygwin will continue to be useful in many cases, too, as I enumerated in my original post on the -talk list in the Disadvantages section of the post.

> People always find uses for everything. Doesn't make it any
> more useful.

Again, I think you might be running into an âEnglish as a second languageâ problem here.

(I wouldnât normally complain about your use of English except for your signature, apologizing for your facility with the English language.  I am therefore taking your signature at its face value: an admission that your facility with the language is not at the level you wish it to be.)

Letâs define terms:

    useless /yÅosleÉs/ adj. not fulfilling or not expected to achieve the intended purpose or desired outcome.

Therefore, a thing is only âuselessâ if if fails to achieve intended purposes.  You can say that UfW is useless *for your own purposes*, but to claim that a clearly useful thing is flat out âuselessâ is simply incorrect.  There is almost nothing in the world that is purely âuseless.â

Iâm fine if you want to say UfW is of no use to yourself.  Iâm objecting to the concept that because you canât use it, that no one else can use it either because it is âuseless.â

That is, my objection is to the absolute nature of your statement.  If you make such a statement relative to yourself and I wonât have any argument against the pronouncement.

> And they will see no issues when moving from this crap to real *NIX system.

Thereâs much less impedance mismatch between UfW and Linux than between Cygwin and Linux.  Therefore, UfW wins on this front as well.

Is UfW problem-free?  Certainly not.  But does it have reduced problems relative to Cygwin?  In many cases, yes.

> Always working as root? What could possible go wrong?

Thatâs a temporary issue, a limitation of UfWâs current beta nature.  Microsoft have publicly stated that they will be reworking it to allow it to run under your normal userâs permissions and to implement sudo before they release it to the public.

Iâm sure the âeverything runs as rootâ nature of it is for the same reason that during the bootstrapping process for any OS, you normally do everything as root.  User permission management is one of the last things you port over when bootstrapping a new OS, once all the tooling is ported over. 
Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]