Cygwin模拟整个POSIX环境，而MinGW是仅用于编译的最小工具集(编译本地Win应用程序)。所以，如果你想让你的项目跨平台，MinGW显然是两个选择之一。

尽管你可能会考虑在Windows上使用VS，在Linux/ unix上使用GCC。大多数开源项目都这样做(例如Firefox或Python)。

Cygwin使用一个DLL, Cygwin . DLL，(或者可能是一组DLL)在Windows上提供类似posix的运行时。

MinGW编译为本地Win32应用程序。

如果您使用Cygwin构建某个东西，那么您安装它的任何系统也将需要Cygwin DLL。MinGW应用程序不需要任何特殊的运行时。

维基百科在这里做了一个比较。

来自Cygwin网站:

Cygwin是一个用于Windows的类似linux的环境。它由两部分组成:DLL (cygwin1.dll)，作为Linux API模拟层，提供大量的Linux API功能。 提供Linux外观的工具集合。

摘自Mingw网站:

MinGW(“Minimalistic GNU for Windows”)是一个免费提供和可自由分发的Windows特定头文件和导入库的集合，结合了GNU工具集，允许人们生成不依赖任何第三方C运行时dll的本地Windows程序

Cygwin试图在Windows上创建一个完整的UNIX/POSIX环境。为此，它使用了各种dll。虽然这些dll由GPLv3+覆盖，但它们的许可包含一个异常，该异常不强制派生作品由GPLv3+覆盖。MinGW是一个C/ c++编译器套件，它允许你创建Windows可执行文件而不依赖于这些dll -你只需要正常的MSVC运行时，这是任何正常的微软Windows安装的一部分。

您还可以获得一个类似UNIX/POSIX的小型环境，使用MinGW编译，称为MSYS。它不具备Cygwin的所有功能，但对于想要使用MinGW的程序员来说是理想的。

Cygwin是Microsoft Windows的类unix环境和命令行界面。

Mingw是GNU Compiler Collection (GCC)到Microsoft Windows的原生软件移植，以及一组用于Windows API的可自由分发的导入库和头文件。MinGW允许开发人员创建本地Microsoft Windows应用程序。

您可以在没有cygwin环境的情况下运行用mingw生成的二进制文件，前提是提供了所有必要的库(dll)。

请注意，两者之间的效用行为确实不同。

例如，Cygwin tar可以fork -，因为DLL中支持fork()，而mingw版本则不支持。当试图从源代码编译mysql时，这是一个问题。

不要忽视AT&T的U/Win软件，该软件旨在帮助您在windows上编译Unix应用程序(最新版本- 2012-08-06;使用Eclipse公共许可证，版本1.0)。

像Cygwin一样，他们必须与图书馆赛跑;在它们的情况下是POSIX.DLL。AT&T的人都是很棒的工程师(同样的团队给你带来了ksh和dot)，他们的东西值得一看。

简单来说，它是这样的:

在Cygwin中编译一些东西，你就是在为Cygwin编译它。 在MinGW中编译一些东西，你就是在为Windows编译它。

Cygwin是什么?

Cygwin是一个兼容层，通过模拟基于unix的操作系统提供的许多基本接口，如管道、unix风格的文件和目录访问等，可以很容易地将简单的基于unix的应用程序移植到Windows上，这是POSIX标准所记录的。Cygwin还与GNU编译器集合的一个端口和一些其他工具捆绑在Cygwin环境中。

如果您有使用POSIX接口的现有源代码，那么只需做很少甚至不做任何更改，就可以将其编译为与Cygwin一起使用，这大大简化了将简单的基于IO的Unix代码移植到Windows上的过程。

Cygwin的缺点

使用Cygwin进行编译涉及到将程序与Cygwin运行时环境链接，该环境通常作为动态链接库cygwin1.dll随程序一起分发。这个库是开放源码的，并且要求使用它的软件共享兼容的开放源码许可证，即使您单独发布dll，因为头文件和接口都包含在内。因此，这对如何授权代码施加了一些限制。

MinGW是什么?

MinGW是一个针对本地Windows的GNU编译器工具的发行版，包括GNU编译器集合、GNU Binutils和GNU调试器。还包括头文件和库，允许开发本机Windows应用程序。因此，这将作为微软Visual c++套件的开源替代品。

可以使用MinGW编译一些原本打算用Microsoft Visual c++编译的东西，只做了相对较小的修改。

默认情况下，在MinGW的GCC中编译的代码将编译到本机Windows目标，包括.exe和.dll文件，尽管您也可以通过正确的设置进行交叉编译，因为您基本上使用的是GNU编译器工具套件。

尽管MingW包含一些头文件和接口代码，允许您的代码与Windows API交互，但与常规标准库一样，这不会对您创建的软件施加许可限制。

MinGW的缺点

使用MinGW为Windows编译的软件必须使用Windows自己的API进行文件和IO访问。如果您正在将Unix/Linux应用程序移植到Windows，这可能意味着代码的重大更改，因为POSIX类型API不能再使用。

其他的考虑

For any non-trivial software application, such as one that uses a graphical interface, multimedia or accesses devices on the system, you leave the boundary of what Cygwin can do for you and further work will be needed to make your code cross-platform. But, this task can be simplified by using cross-platform toolkits or frameworks that allow coding once and having your code compile successfully for any platform. If you use such a framework from the start, you can not only reduce your headaches when it comes time to port to another platform but you can use the same graphical widgets - windows, menus and controls - across all platforms if you're writing a GUI app, and have them appear native to the user.

例如，开源Qt框架是一个流行的、全面的跨平台开发框架，允许构建跨操作系统(包括windows)的图形化应用程序。还有其他类似的框架。除了大型框架之外，还有数以千计的更专业的软件库，它们支持多个平台，使您不必担心为不同的平台编写不同的代码。

当您从一开始就开发跨平台软件时，通常没有任何理由使用Cygwin。当在Windows上编译时，你的目标通常是让你的代码可以用MingW或Microsoft Visual C/ c++编译，或者两者都可以。在Linux/*nix上编译时，通常直接使用GNU编译器和工具进行编译。

为了补充其他答案，Cygwin附带了MinGW库和头文件，你可以在不链接到cygwin1.dll的情况下使用-mno-cygwin标志与gcc进行编译。比起使用普通的MinGW和MSYS，我更喜欢这个。

阅读这些已回答的问题，了解Cygwin和MinGW之间的区别。

问题#1:我想创建一个应用程序，我写源代码一次，编译一次，并在任何平台上运行(例如Windows, Linux和Mac OS X…)

答案#1:把源代码写进去 JAVA。编译源代码一次，然后 在任何地方运行它。

问题2:我想创建一个应用程序，我只写一次源代码，但我可以分别为任何平台编译源代码(例如Windows, Linux和Mac OS X…)

答案#2:用C语言编写源代码 或c++。使用标准头文件 只有。使用合适的编译器 平台(如Visual Studio for Windows, GCC for Linux, XCode for Mac)。注意，您不应该使用任何一种 高级编程特性 全部编译源代码 成功的平台。如果你使用 没有C或c++标准类或 函数，你的源代码没有 在其他平台编译。

问题#3:回答问题#2，在每个平台上使用不同的编译器是困难的，有跨平台的编译器吗?

答案#3:是的，使用GCC编译器。它 是一个跨平台编译器。来 在Windows中编译源代码 使用MinGW提供GCC编译器 并编译您的源代码 代码转换为本地Windows程序。不 使用任何高级编程特性 (如Windows API)来编译你的 所有平台的源代码 成功。如果你使用Windows API 函数，你的源代码没有 在其他平台编译。

问题4:C或c++标准头文件不提供任何高级编程特性，如多线程。我该怎么办?

Answer #4: You should use POSIX (Portable Operating System Interface [for UNIX]) standard. It provides many advanced programming features and tools. Many operating systems fully or partly POSIX compatible (like Mac OS X, Solaris, BSD/OS and ...). Some operating systems while not officially certified as POSIX compatible, conform in large part (like Linux, FreeBSD, OpenSolaris and ...). Cygwin provides a largely POSIX-compliant development and run-time environment for Microsoft Windows.

因此:

要在Windows下充分利用GCC跨平台编译器的优势，请使用MinGW。

要在Windows中使用POSIX标准高级编程特性和工具的优势，请使用Cygwin。

维基百科说:

MinGW forked from version 1.3.3 of Cygwin. Although both Cygwin and MinGW can be used to port UNIX software to Windows, they have different approaches: Cygwin aims to provide a complete POSIX layer that provides emulations of several system calls and libraries that exist on Linux, UNIX, and the BSD variants. The POSIX layer runs on top of Windows, sacrificing performance where necessary for compatibility. Accordingly, this approach requires Windows programs written with Cygwin to run on top of a copylefted compatibility library that must be distributed with the program, along with the program's source code. MinGW aims to provide native functionality and performance via direct Windows API calls. Unlike Cygwin, MinGW does not require a compatibility layer DLL and thus programs do not need to be distributed with source code. Because MinGW is dependent upon Windows API calls, it cannot provide a full POSIX API; it is unable to compile some UNIX applications that can be compiled with Cygwin. Specifically, this applies to applications that require POSIX functionality like fork(), mmap() or ioctl() and those that expect to be run in a POSIX environment. Applications written using a cross-platform library that has itself been ported to MinGW, such as SDL, wxWidgets, Qt, or GTK+, will usually compile as easily in MinGW as they would in Cygwin. The combination of MinGW and MSYS provides a small, self-contained environment that can be loaded onto removable media without leaving entries in the registry or files on the computer. Cygwin Portable provides a similar feature. By providing more functionality, Cygwin becomes more complicated to install and maintain. It is also possible to cross-compile Windows applications with MinGW-GCC under POSIX systems. This means that developers do not need a Windows installation with MSYS to compile software that will run on Windows without Cygwin.

Cygwin使用兼容层，而MinGW是本地的。这是主要的区别之一。

Cygwin is designed to provide a more-or-less complete POSIX environment for Windows, including an extensive set of tools designed to provide a full-fledged Linux-like platform. In comparison, MinGW and MSYS provide a lightweight, minimalist POSIX-like layer, with only the more essential tools like gcc and bash available. Because of MinGW's more minimalist approach, it does not provide the degree of POSIX API coverage Cygwin offers, and therefore cannot build certain programs which can otherwise be compiled on Cygwin.

就两者生成的代码而言，Cygwin工具链依赖于到大型运行时库cygwin1.dll的动态链接，而MinGW工具链将代码编译为二进制文件，动态链接到Windows原生C库msvcrt.dll，以及静态链接到glibc的某些部分。Cygwin可执行文件因此更紧凑，但需要一个单独的可重新分发的DLL，而MinGW二进制文件可以独立发布，但往往更大。

基于cygwin的程序需要单独的DLL才能运行，这一事实也导致了许可限制。Cygwin运行时库是在GPLv3下授权的，对于具有符合osi的许可证的应用程序有一个链接例外，因此希望围绕Cygwin构建闭源应用程序的开发人员必须从Red Hat获得商业许可证。另一方面，MinGW代码既可以用于开源应用程序，也可以用于闭源应用程序，因为其头文件和库都是经过许可的。

要在非免费/专有/闭源应用程序中使用Cygwin，您需要向Red Hat支付数万美元的“许可证买断”;这会使标准许可条款失效，并付出相当大的代价。谷歌“cygwin许可证成本”，并看到前几个结果。

对于mingw，不产生这种成本，并且许可证(PD、BSD、MIT)是非常允许的。您最多可能需要在应用程序中提供许可细节，例如使用mingw64-tdm时所需的winpthreads许可。

由Izzy Helianthus提供的编辑:商业许可证不再可用，也不再需要，因为Cygwin的winsup子目录中的API库现在是在LGPL下发布的，而不是完全的GPL。

从移植C程序的角度来看，理解这一点的一个好方法是举一个例子:

#include <sys/stat.h>
#include <stdlib.h>

int main(void)
{
   struct stat stbuf;
   stat("c:foo.txt", &stbuf);
   system("command");
   printf("Hello, World\n");
   return 0;
}

如果我们把stat改为_stat，我们可以用Microsoft Visual c编译这个程序。我们也可以用MinGW和Cygwin编译这个程序。

在Microsoft Visual C下，程序将被链接到MSVC可重分发的运行时库:mxvcrtnn.dll，其中nn是某个版本后缀。为了发布这个程序，我们必须包含那个DLL。DLL提供了_stat、system和printf。(我们还可以选择静态链接运行时。)

在MinGW下，程序将被链接到msvcrt.dll，这是一个内部的，无文档的，未版本的库，是Windows的一部分，并且禁止应用程序使用。该库本质上是MS Visual C的可重分发运行时库的一个分支，供Windows本身使用。

在这两种情况下，程序将具有类似的行为:

stat函数将返回非常有限的信息——例如，没有有用的权限或inode号。 路径“c:file.txt”根据当前与c:盘相关联的工作目录进行解析。 系统使用cmd.exe /c执行外部命令。

我们也可以在Cygwin下编译程序。类似于MS Visual C使用的可重分发运行时，Cygwin程序将被链接到Cygwin的运行时库:cygwin1.dll (Cygwin本身)和cyggcc_s-1.dll (GCC运行时支持)。由于Cygwin现在处于LGPL之下，我们可以将程序打包，即使它不是与gpl兼容的自由软件，也可以发布程序。

在Cygwin下，库函数会有不同的表现:

the stat function has rich functionality, returning meaningful values in most of the fields. the path c:file.txt is not understood at all as containing a drive letter reference, since c: isn't followed by a slash. The colon is considered part of the name and somehow mangled into it. There is no concept of a relative path against a volume or drive in Cygwin, no "currently logged drive" concept, and no per-drive current working directory. the system function tries to use the /bin/sh -c interpreter. Cygwin will resolve the / path according to the location of your executable, and expect a sh.exe program to be co-located with your executable.

Cygwin和MinGW都允许使用Win32函数。如果你想调用MessageBox或CreateProcess，你可以这样做。您还可以在MinGW和Cygwin下使用gcc -mwindows轻松构建一个不需要控制台窗口的程序。

Cygwin不是严格意义上的POSIX。除了提供对Windows API的访问，它还提供了自己的一些Microsoft C函数的实现(在msvcrtnn.dll或可重新分发的msvcrtnn.dll运行时中找到的东西)。一个例子是spawn*家族的函数，如spawnvp。在Cygwin上使用它们来代替fork和exec是一个好主意，因为它们更好地映射到没有fork概念的Windows进程创建模型。

因此:

Cygwin programs are no less "native" than MS Visual C programs on grounds of requiring the accompaniment of libraries. Programming language implementations on Windows are expected to provide their own run-time, even C language implementations. There is no "libc" on Windows for public use. The fact that MinGW requires no third-party DLL is actually a disadvantage; it is depending on an undocumented, Windows-internal fork of the Visual C run-time. MinGW does this because the GPL system library exception applies to msvcrt.dll, which means that GPL-ed programs can be compiled and redistributed with MinGW. Due to its much broader and deeper support for POSIX compared to msvcrt.dll, Cygwin is by far the superior environment for porting POSIX programs. Since it is now under the LGPL, it allows applications with all sorts of licenses, open or closed source, to be redistributed. Cygwin even contains VT100 emulation and termios, which work with the Microsoft console! A POSIX application that sets up raw mode with tcsetattr and uses VT100 codes to control the cursor will work right in the cmd.exe window. As far as the end-user is concerned, it's a native console app making Win32 calls to control the console.

然而:

作为一个本地Windows开发工具，Cygwin有一些怪癖，比如路径处理与Windows无关，依赖于一些硬编码的路径(如/bin/sh)以及其他问题。这些差异使得Cygwin程序“非原生”。如果一个程序以一个路径作为参数，或者从一个对话框中输入，Windows用户希望该路径以与其他Windows程序相同的方式工作。如果不是这样，那就有问题了。

插入:在LGPL发布后不久，我启动了Cygnal (Cygwin本机应用程序库)项目，以提供Cygwin DLL的一个分支，旨在修复这些问题。程序可以在Cygwin下开发，然后使用cygwin1.dll的Cygnal版本进行部署，无需重新编译。随着这个库的改进，它将逐渐消除对MinGW的需求。

When Cygnal solves the path handling problem, it will be possible to develop a single executable which works with Windows paths when shipped as a Windows application with Cygnal, and seamlessly works with Cygwin paths when installed in your /usr/bin under Cygwin. Under Cygwin, the executable will transparently work with a path like /cygdrive/c/Users/bob. In the native deployment where it is linking against the Cygnal version of cygwin1.dll, that path will make no sense, whereas it will understand c:foo.txt.

其他答案已经击中了目标。我只是想增加一个快速捕捉的例子。

   MinGW (or MinGW-w64)               Cygwin
   --------------------               ------

   Your program written        Your program written
  for Unix and GNU/Linux      for Unix and GNU/Linux

             |                           |
             |                           |
             V                           V

    Heavy modifications       Almost no modifications

             |                           |
             |                           |
             V                           V

        Compilation                 Compilation

Program compiled with Cygwin ---> Compatibility layer ---> Windows API

Program compiled with MinGW (or MingGW-w64) -------------> Windows API