5 ms·

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.
    - geofft 10y ago
      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. https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 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.)
      - kazinator 10y ago
        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. Now I'm even more motivated to stop using MinGW.
- gpvos 10y ago
  > MSYS is a kind of "non-user-serviceable area" that you wouldn't deal with unless you were hacking on MinGW itself If so, why did they actually create MSYS(2)? Why not just compile MinGW executables using gcc under Cygwin?
  - kazinator 10y ago
    > 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.
    - CUViper 10y ago
      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.

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.
  - geofft 10y ago
    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. https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 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.)
    - kazinator 10y ago
      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. Now I'm even more motivated to stop using MinGW.
gpvos 10y ago
> MSYS is a kind of "non-user-serviceable area" that you wouldn't deal with unless you were hacking on MinGW itself If so, why did they actually create MSYS(2)? Why not just compile MinGW executables using gcc under Cygwin?
- kazinator 10y ago
  > 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.
  - CUViper 10y ago
    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.