I wonder if the new Linux compatibility subsystem for Windows provided any motivation for this change? That work seems likely to make Cygwin obsolete eventually, since it allows running unmodified applications rather than porting them.
See, for instance, this discussion about how copy-on-write fork is available as a system call (and had been around for a while, to support SUA), but doesn't work right with the Win32 subsystem, and that means Cygwin can't use it:
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-U...
I don't know how many actual applications take advantage of this, though. But if they do, then Cygwin is definitely not obsolete for them.
As you mention, WSL also isn't stuck with the restrictions that come from Win32 compatibility. One of the big impacts of this is that fork() can be faster (although I'm not sure if it actually is right now) than the mess that is Cygwin's emulated fork(). There are some more subtle distinctions, too, though: for example, WSL maintains Linux's conventions around locking open files and has full case-sensitivity. Cygwin doesn't even try to simulate Linux's behavior for either of those; it maintains Win32's behavior.
Genuine question, why is that useful? Intuitively, it seems like if you ever used that capability, you'd end up with a horrible chimera program that can't run on linux or windows, which doesn't seem good.
A couple of plausible scenarios:
1. You have a legacy UNIX app that is now only being used on Windows, but rewriting it entirely is a giant project. You can compile it against Cygwin, and then new development can run on Windows.
2. You have a cross-platform app that needs a few OS-specific things in certain places. Maybe it's some sort of system status checking/auditing tool, maybe it interacts with hardware drivers, etc. You can use #ifdef WIN32 and call Windows-specific APIs, just like you can use #ifdefs to check for Apple-specific or Linux-specific APIs, and you don't have to port your entire app away from the UNIX model.
You should use mingw-w64 when you can modify your sources (eg. with lots of #ifdef WIN32) to call Win32 APIs, OR if you are using a framework like glib2 which handles those differences for you.
In Fedora we have both Cygwin and the Fedora cross-compiler project which packages mingw-w64 compiler and many many precompiled libraries. https://fedoraproject.org/wiki/MinGW
My point was to hypothesize why Cygwin became openGPL. I stated some of the advantages of mingw, and why those might motivate Cygwin to change their licensing.
Do you have an actual point, or are you just going to continue harassing me over irrelevant things?
If you're doing that, what's the difference between MinGW and compiling for native Windows?
MSYS is a kind of "non-user-serviceable area" that you wouldn't deal with unless you were hacking on MinGW itself. Say you wanted to add some missing utility to MinGW, and there was some issue between MSYS and that utility requiring MSYS hacking.
If you think that you have a POSIX program that could benefit from being linked against MSYS, you're almost certainly better off just using Cygwin to port it. And now you can redistribute the Cygwin DLL with that program without tainting the program with the GPL.
https://support.microsoft.com/en-ca/kb/2977003
"Visual C++ Redistributable Packages install runtime components of Visual C++ Libraries on a computer that does not have Visual C++ installed. The libraries are required to run applications that are developed by using the corresponding version of Visual C++."
And an overview here:
https://msdn.microsoft.com/en-us/library/ms235299.aspx
Visual C++ libraries are not a core component of Windows; they are run-time support for Visual C++ programs. Microsoft calls them "redistributable".
If you write a program which depends on this, it behooves you to ship the exact version you're testing with and install it in the same directory as your executables. (See the "corresponding version" remark above from Microsoft themselves!)
(Which is why it is a myth that MinGW makes "native" Windows executables that don't need anything; in fact they rely on some program having been installed before them which rudely put some version of the MSVCRT.DLL into the System folder.)
https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=...
The trouble is (AIUI) that the GPL has an exception for system libraries, and MSVCRT.DLL is shipped with the system and MSVCRnnn.DLL are not. Microsoft legally allows you to redistribute MSVCRnnn.DLL, but does not provide source. Therefore, distributors of GPL apps linked against MSVCRnnn.DLL have no way to satisfy their legal obligations. So MinGW makes life easier for GPL apps, which are a significant part of the target audience, by linking against MSVCRT.DLL instead. This is worse from a software engineering point of view because you're using private / unstable API, but it is not illegal, and it lets you avoid the GPL issue.
The program that put MSVCRT.DLL in a system folder wasn't being rude; it was the Windows setup program itself, which was perfectly allowed to put it there. MinGW is being rude by looking for it. (However, if an app linked against one of the versioned libraries did not ship with the versioned library, then yes, it would be expecting some rude app to have copied the versioned library into the system folder.)
Now I'm even more motivated to stop using MinGW.
http://source.winehq.org/git/wine.git/tree/HEAD:/dlls/msvcrt
I don't know enough about MinGW to try it, but seems worth a shot!
Here's MSDN talking about it being a system component:
https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).a...
At least since .NET 2003. It's handled differently in 2015.
If so, why did they actually create MSYS(2)? Why not just compile MinGW executables using gcc under Cygwin?
I have no idea. A cross toolchain for making Windows programs compiled with GCC, and linked with MSVCRT.DLL could be made available as a Cygwin package. All of the utilities for controlling the build can just be the Cygwin ones; all that is needed is the cross-gcc.
Going forward, MinGW is only useful for writing Windows-only programs using GCC, GNU Make and Bash. Well, sort of. Anyone in their right mind will just download a copy of Visual Studio if they want to write Windows programs in C or C++.
MinGW still has a tiny advantage: its path handling is more Windows-like. Cygwin programs do not understand the concept of each drive letter having its own current directory, so that drive-letter-qualified relative paths are possible. A drive relative path like "C:foo/bar/txt" does not work properly in Cygwin. What it is supposed to do is resolve against the current directory that is associated with the C: drive. I think what happens is that it gets treated as "C:/foo/bar.txt". If you compile a command line utility with Cygwin, and that utility works with path arguments, it will surprise Windows users in some circumstances. Perhaps Cygwin can fix this issue someday (if it hasn't already; I haven't been tracking this).
It's actually worse. What I didn't understand it that it depends on an internal library which Microsoft says applications aren't supposed to use! See informative comment by geofft:
https://news.ycombinator.com/item?id=11964589
Oops!
/cygdrive/c/foo/bar.txt
Not saying it's any prettier but that's how they do it. Not sure how they do this but thankfully it doesn't nest recursively. Say you install cygwin on your C: drive. If you do "cd /cygdrive/c/cygwin" and then ls you'll see cygdrive as a directory entry but if you cd into it and ls again there are no drive letters. The only place the drive letter directories are exposed is directly under /cygdrive.
You can cheat using VNC to localhost, of course ;)
I have it installed, and still rely on Cygwin for projects that live on my Windows directory.
Microsoft has said that they have no plans to push it to / support it on their Server OSs. If you're planning on SERVING something with Windows + Linuxy stuff on top of it, Ubuntu on Windows is not an option.