I'm guessing it was because of pressure from Mingw. A few years ago, Cygwin was the only option, and Mingw was a real pain to use. Now with Mingw becoming more and more mature, I'll bet people were using that instead of Cygwin.
Cygwin and MinGW [or rather, mingw-w64] are really different things with very different use cases. You should use Cygwin when you have POSIX code that you want to compile unmodified on Windows.
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.
So what do you do if you want to run Linux code on Windows, but you can't use the GPL? Cygwin (was/is) not an option in that case, so you just use MinGW. It's a pain, but it gets the job done.
Not exactly sure what your point is. Cygwin is now LGPL, and the mingw-w64 libraries are all under their own free licenses which are (almost) all compatible with linking to proprietary programs.
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
Not exactly sure what your point is. Cygwin is now LGPL
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.
MSYS is an ancient branch of a common code base with Cygwin, which only needs just enough POSIX content in order to compile the utilities which are included in the toolchain which MSYS supports: the toolchain known as MinGW. That toolchain itself doesn't link programs against MSYS; it links programs against Microsoft's redistributable C run-time library (MSVCRT.DLL). Essentially, MinGW is a cross-compiler.
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.
MSVCRT.DLL isn't redistributable, it's a system component. There are some changes recently that I haven't kept up with to make it easier to target a single C library, but the redistributables all had the compiler version in the name and were not compatible across versions.
"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++."
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.)
There's a difference between the unversioned MSVCRT.DLL and the versioned MSVCR100.DLL, MSVCR120.DLL, etc. libraries. MSVCRT.DLL is technically private API, for the Windows OS's own use, and its API changes on OS releases. The versioned MSVCRnnn.DLL are intended to be shipped with applications, and that's what's in the download links you provide.
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.)
Ouch! MinGW is really in a limbo, sticking its fork into the proverbial toaster. Microsoft can change behaviors in MSVCRT.DLL, which can break MinGW programs.
MSVCRT.DLL is what programs compiled with Visual Studio 6.0 link to. So I think it's safe to expect MS retaining compatibility for the forseeable future.
I have heard that it's possible to talk MinGW into linking against MSVCRnnn.DLL instead, with some effort. And then you have to figure out how to ship the redistributable, both physically and legally, but if you can do that, more power to you. Here's a plausible-sounding set of instructions:
Huh. That's a really interesting idea. I'd be worried about whether it translates to UNIX calls, but it looks like it mostly translates to Win32 calls (that WINE then emulates).
I don't know enough about MinGW to try it, but seems worth a shot!
> 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.
It used to be just "gcc -mno-cygwin" would suffice. Now the cross gcc is available separately, choose one of i686-pc-mingw32-gcc, i686-w64-mingw32-gcc, or x86_64-w64-mingw32-gcc.
MinGW is not getting more and more mature, because it keeps depending on the same library from Microsoft. That library is the big downer in MinGW. MinGW is now dead as a way of doing quick-and-dirty ports of POSIX programs to Windows. (Specifically, quick and dirty porting of non-GPL-ed programs to Windows, such as they are not tainted by the GPL).
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).
MinGW is particularly useful as part of a cross compilation chain for Windows targeting the native Windows APIs. That way you don't have to run Windows as part of a CI process.
I wrote:
> keeps depending on the same library from Microsoft.
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:
Cygwin handles the drive letter situation using a special directory under it's root called cygdrive. Each drive letter is exposed as a sub directory of it so in your example the path is:
/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.
I seem to recall that once upon a time, only the /cygdrive convention worked in Cygwin. But for years now, Cygwin has supported supported drive letter prefixes, as in c:/foo/bar.txt. Thus, effectively, /cygdrive/c can be regarded as a legacy hack. Sort of. If you do "cd c:" you end up with "/cygdrive/c" as your current working directory.
Backslashes work fine, too; try "ls c:\\temp".
