7 ms·

No, this change was being contemplated over a year ago and the final internal decision was made before the announcement of that Linux compatibility subsystem. I

No, this change was being contemplated over a year ago and the final internal decision was made before the announcement of that Linux compatibility subsystem. It has more to do with the commercial viability of Cygwin as a product.

namtrac 10y ago
I sincerely hope Red Hat continues to develop Cygwin further. It's amazing to be able to run my favourite shell on Windows.
ktRolster 10y ago
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.
- xorblurb 10y ago
  Cygwin and Mingw are not really comparable. And if you are thinking about MSys, it's a fork of Cygwin, so...
  - kazinator 10y ago
    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.
    - maxerickson 10y ago
      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.
      - kazinator 10y ago
        See here: https://support.microsoft.com/en-ca/kb/2977003 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 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.)
        maxerickson 10y ago
        No, none of those ship MSVCRT.DLL (at least, none of the earlier ones, as I said, I stopped paying attention). Here's MSDN talking about it being a system component: https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).a... At least since .NET 2003. It's handled differently in 2015.
        kazinator 10y ago
        Wow, thanks for clearing up a major misunderstanding.
- kazinator 10y ago
  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).
  - smhenderson 10y ago
    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.
    - kazinator 10y ago
      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".
- rwmj 10y ago
  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.
  - ktRolster 10y ago
    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.
    - rwmj 10y ago
      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 https://fedoraproject.org/wiki/MinGW
      - ktRolster 10y ago
        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.
        rwmj 10y ago
        What is "openGPL"? There is no such license. Cygwin is now under the GNU LGPL.
        ktRolster 10y ago
        It's what I type when I'm not thinking very clearly. Do you have an actual point, or are you just going to continue harassing me over irrelevant things?

namtrac 10y ago

I sincerely hope Red Hat continues to develop Cygwin further. It's amazing to be able to run my favourite shell on Windows.

ktRolster 10y ago

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.

xorblurb 10y ago
Cygwin and Mingw are not really comparable. And if you are thinking about MSys, it's a fork of Cygwin, so...
- kazinator 10y ago
  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.
  - maxerickson 10y ago
    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.
    - kazinator 10y ago
      See here: https://support.microsoft.com/en-ca/kb/2977003 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 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.)
      - maxerickson 10y ago
        No, none of those ship MSVCRT.DLL (at least, none of the earlier ones, as I said, I stopped paying attention). Here's MSDN talking about it being a system component: https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).a... At least since .NET 2003. It's handled differently in 2015.
        kazinator 10y ago
        Wow, thanks for clearing up a major misunderstanding.
kazinator 10y ago
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).
- smhenderson 10y ago
  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.
  - kazinator 10y ago
    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".
rwmj 10y ago
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.
- ktRolster 10y ago
  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.
  - rwmj 10y ago
    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 https://fedoraproject.org/wiki/MinGW
    - ktRolster 10y ago
      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.
      - rwmj 10y ago
        What is "openGPL"? There is no such license. Cygwin is now under the GNU LGPL.
        ktRolster 10y ago
        It's what I type when I'm not thinking very clearly. Do you have an actual point, or are you just going to continue harassing me over irrelevant things?