Cygwin和MinGW有什么区别？
Answers:
为简化起见，它是这样的：
在Cygwin中编译某些内容，您正在为Cygwin进行编译。
在MinGW中编译某些内容，您正在为Windows进行编译。
关于西格温
Cygwin的目的是通过模拟POSIX标准记录的基于Unix的操作系统提供的许多小细节，使基于Unix的应用程序到Windows的移植更加容易。您的应用程序可以使用Unix功能，例如管道，Unix风格的文件和目录访问等，并且可以使用Cygwin进行编译，它将作为您应用程序周围的兼容层，因此许多特定于Unix的范例可以继续使用。
分发软件时，收件人将需要与Cygwin运行时环境（由file提供cygwin1.dll）一起运行。您可以将其与软件一起分发，但是您的软件必须符合其开放源代码许可。甚至可能只是将软件与其链接，但单独分发dll的情况可能仍然需要您遵守开放源代码许可证。
关于MinGW
MinGW的目标只是成为GNU编译器工具（例如GCC，Make，Bash等）的Windows端口。它不尝试模仿Unix或提供与Unix的全面兼容性，而是提供了在Windows上使用GCC（GNU编译器）和少量其他工具的最低必需环境。。它没有像Cygwin这样的Unix仿真层，但是结果是需要对您的应用程序进行特殊编程以使其能够在Windows上运行，这可能意味着如果将其创建为依靠在标准Unix环境中运行而进行重大更改，并且使用Unix特定的功能，例如前面提到的功能。默认情况下，在MinGW的GCC中编译的代码将编译为Windows X86本机目标，包括.exe和.dll文件，尽管您也可以使用正确的设置进行交叉编译，因为您基本上是在使用GNU编译器工具套件。
MinGW本质上是Microsoft Visual C ++编译器及其关联的链接/制作工具的替代方案。在某些情况下，可能会使用MinGW使用正确的库来编译旨在用于Microsoft Visual C ++编译的内容，在某些情况下可能会进行其他修改。
MinGW包括一些用于与Windows操作系统进行交互的基本标准库，但是与GNU编译器集合中包含的普通标准库一样，这些库不对您创建的软件施加许可限制。
对于非平凡的软件应用程序，除非使用全面的跨平台框架，否则使其成为跨平台的应用可能是一个巨大的挑战。在我撰写本文时，Qt框架是为此目的最受欢迎的框架之一，它允许构建可在包括Windows在内的各种操作系统上运行的图形应用程序，但是还有其他选择。如果您从一开始就使用这样的框架，则不仅可以减轻移植到另一个平台的麻烦，而且如果您正在编写一个框架，则可以在所有平台上使用相同的图形小部件-窗口，菜单和控件- GUI应用程序，并使它们对用户而言是本机的。
Cygwin试图在Windows上创建完整的UNIX / POSIX环境。为此，它使用各种DLL。虽然这些DLL包含在GPLv3 +中，但是它们的许可证包含一个例外，该例外不会强制派生作品被GPLv3 +覆盖。MinGW是C / C ++编译器套件，可让您创建Windows可执行文件而无需依赖此类DLL-您只需要普通的MSVC运行时，这是任何普通的Microsoft Windows安装的一部分。
您还可以获得一个类似于UNIX / POSIX的小型环境，该环境是使用MinGW编译的，名为MSYS。它不具有Cygwin的所有功能，但是对于希望使用MinGW的程序员来说是理想的选择。
为了增加其他答案，Cygwin附带了MinGW库和标头，并且可以通过在gcc中使用-mno-cygwin标志来进行编译而无需链接到cygwin1.dll。我非常喜欢使用普通的MinGW和MSYS。
gcc-3 -mno-cygwin
mingw64-x86_64-gcc-coreCygwin软件包。MinGW-64将以笨拙的命名x86_64-w64-mingw32-gcc命令提供。拜托上帝，有人已经统一了这些血腥事物的名称。
阅读这些回答的问题，以了解Cygwin和MinGW之间的区别。
问题1：我想创建一个应用程序，该应用程序只编写一次源代码，然后编译一次并在任何平台（例如Windows，Linux和Mac OS X…）上运行。
答案1：用JAVA编写源代码。一次编译源代码，然后在任何地方运行。
问题2：我想创建一个只编写一次源代码的应用程序，但是我可以分别编译任何平台（例如Windows，Linux和Mac OS X……）的源代码都没有问题。
答案2：使用C或C ++编写源代码。仅使用标准头文件。对任何平台使用合适的编译器（例如Windows的Visual Studio，Linux的GCC和Mac的XCode）。请注意，您不应使用任何高级编程功能在所有平台上成功编译源代码。如果您不使用任何C或C ++标准类或函数，则您的源代码不会在其他平台上编译。
问题3：在回答问题2时，很难为每个平台使用不同的编译器，是否有跨平台编译器？
答案3：是的，请使用GCC编译器。它是一个跨平台的编译器。要在Windows中编译源代码，请使用MinGW，它为Windows提供了GCC编译器，并将源代码编译为本地Windows程序。不要使用任何高级编程功能（例如Windows API）在所有平台上成功编译源代码。如果使用Windows API函数，则源代码无法在其他平台上编译。
问题4：C或C ++标准头文件不提供任何高级编程功能，例如多线程。我能做什么？
答案4：您应该使用POSIX（适用于UNIX的便携式操作系统接口）标准。它提供了许多高级编程功能和工具。许多完全或部分与POSIX兼容的操作系统（例如Mac OS X，Solaris，BSD / OS和...）。某些操作系统虽然未正式认证为与POSIX兼容，但在很大程度上符合标准（例如Linux，FreeBSD，OpenSolaris和...）。Cygwin为Microsoft Windows提供了一个与POSIX兼容的开发和运行时环境。
从而：
要在Windows中使用GCC跨平台编译器的优势，请使用MinGW。
要在Windows中使用POSIX标准高级编程功能和工具，请使用Cygwin。
从移植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函数将返回非常有限的信息，例如，没有有用的权限或索引节点号。 c:file.txt根据与drive关联的当前工作目录解析路径c:。system使用cmd.exe /c用于运行外部命令。
我们也可以在Cygwin下编译程序。与MS Visual C使用的可重新分发运行时类似，Cygwin程序将链接到Cygwin的运行时库：cygwin1.dll（Cygwin专有）和cyggcc_s-1.dll（GCC运行时支持）。由于Cygwin现在处于LGPL的管辖范围内，因此即使它不是GPL兼容的免费软件，我们也可以将其与程序打包在一起，并附带该程序。
在Cygwin下，库函数的行为将有所不同：
- 该
stat函数具有丰富的功能，可以在大多数字段中返回有意义的值。 - 该路径
c:file.txt根本不被理解为包含驱动器号引用，因为该路径后没有c:斜杠。冒号被认为是名称的一部分，并以某种方式被混入其中。Cygwin中没有针对卷或驱动器的相对路径的概念，没有“当前记录的驱动器”概念，也没有针对每个驱动器的当前工作目录。 - 该
system函数尝试使用/bin/sh -c解释器。Cygwin将/根据可执行文件的位置解析路径，并期望sh.exe程序与可执行文件位于同一位置。
Cygwin和MinGW都允许您使用Win32函数。如果您要致电MessageBox或CreateProcess，可以这样做。您还可以gcc -mwindows在MinGW和Cygwin下使用轻松构建不需要控制台窗口的程序。
Cygwin并不是严格的POSIX。除了提供对Windows API的访问权限外，它还提供了自己的某些Microsoft C函数（在msvcrt.dll或重新分配的msvcrtnn.dll运行时中找到的东西）的实现。例如的spawn*函数族就是一个例子spawnvp。这是使用，而不是一个好主意，fork而且exec，因为他们更好地映射到不具有的概念在Windows进程创建的模型在Cygwin fork。
从而：
Cygwin程序与MS Visual C程序一样，其“本机”也要基于要求库的伴随。Windows上的编程语言实现有望提供自己的运行时，甚至C语言实现。Windows上没有供公众使用的“ libc”。
MinGW不需要第三方DLL的事实实际上是一个缺点。它取决于Visual C运行时的未记录的Windows内部叉。MinGW这样做是因为GPL系统库例外适用于
msvcrt.dll，这意味着可以使用MinGW编译和重新分发GPL版本的程序。由于与POSIX相比
msvcrt.dll，它对POSIX的支持更加广泛和深入，因此Cygwin是迄今为止移植POSIX程序的优越环境。由于它现在属于LGPL之下，因此它可以重新分发具有各种许可证（包括开放源代码或封闭源代码）的应用程序。 Cygwin甚至包含VT100仿真和termios，可与Microsoft控制台一起使用！在POSIX应用程序中设置原始模式tcsetattr并使用VT100代码控制光标将在cmd.exe窗口中正常工作。就最终用户而言，这是一个本地控制台应用程序，它调用Win32来控制控制台。
然而：
- 作为Windows的本机开发工具，Cygwin有一些怪癖，例如Windows特有的路径处理，依赖于诸如此类的硬编码路径
/bin/sh以及其他问题。这些差异使Cygwin程序变得“非本地”。如果程序将路径作为参数或从对话框中输入，则Windows用户希望该路径的工作方式与其他Windows程序相同。如果那样行不通，那就是个问题。
插件： LGPL发布后不久，我启动了Cygnal（Cygwin本机应用程序库）项目，以提供旨在解决这些问题的Cygwin DLL的分支。程序可以在Cygwin下开发，然后与Cygnal版本的一起部署，cygwin1.dll而无需重新编译。随着该库的改进，它将逐渐消除对MinGW的需求。
当Cygnal解决路径处理问题时，将有可能开发一个可执行文件，当与Cygnal一起作为Windows应用程序提供时，该可执行文件可以与Windows路径一起使用，而当安装在/usr/binCygwin下时，则可以无缝与Cygwin路径一起使用。在Cygwin下，该可执行文件将透明地与路径一起使用/cygdrive/c/Users/bob。在与Cygnal版本链接的本机部署中cygwin1.dll，该路径没有意义，而它却可以理解c:foo.txt。
MinGW从的1.3.3版本分叉Cygwin。虽然两者Cygwin并MinGW可以用于端口UNIX的软件Windows，它们有不同的方法：Cygwin旨在提供一个完整的POSIX layer，它提供的几个系统调用，并且存在于库仿真Linux，UNIX和BSD变种。在POSIX layer之上运行Windows，牺牲性能在必要的兼容性。因此，此方法要求使用Windows编写的程序Cygwin在必须与程序一起分发的带版权的兼容库的顶部运行source code。MinGW旨在通过直接提供本地功能和性能Windows API calls。不像Cygwin，MinGW不需要兼容性层DLL，因此程序不需要与一起分发source code。因为
MinGW依赖Windows API calls，它不能提供完整POSIX API; 它无法编译UNIX applications可以使用编译的文件Cygwin。具体而言，这适用于需要的应用程序POSIX一样的功能fork()，mmap()或ioctl()和那些希望在运行POSIX environment。用编写的应用程序cross-platform library已本身被移植到MinGW，如SDL，wxWidgets，Qt，或GTK+，通常会因为容易编写MinGW，因为他们会在Cygwin。的组合
MinGW，并MSYS提供了一个可以装载到可移动媒体不留在计算机上的注册表项或文件小，独立的环境。Cygwin便携式提供类似的功能。通过提供更多功能，Cygwin安装和维护变得更加复杂。也可以
cross-compile Windows applications使用MinGW-GCC under POSIX systems。这就意味着，开发商并不需要一个Windows安装与MSYS到会运行编译软件Windows没有Cygwin。
不要忽视AT＆T的U / Win软件，该软件旨在帮助您在Windows上编译Unix应用程序（最新版本-2012-08-06；使用Eclipse Public License，版本1.0）。
像Cygwin一样，它们必须与库竞争。就他们而言POSIX.DLL。AT＆T的家伙是很棒的工程师（为您带来了ksh和dot的同一个小组），他们的东西值得一试。
Cygwin模拟整个POSIX环境，而MinGW是仅用于编译的最小工具集（编译本机Win应用程序。）因此，如果您想使项目跨平台，则在这两者之间的选择很明显，即MinGW。
尽管您可能考虑在Windows上使用VS，但在Linux / Unices上使用GCC。大多数开源项目都这样做（例如Firefox或Python）。
clang是可行的跨平台解决方案。
请注意，实用程序的行为在这两者之间确实可以改变。
例如，Cygwin tar可以进行分叉（因为DLL支持fork（）），而mingw版本则不能。尝试从源代码编译mysql时，这是一个问题。
要在商业/专有/非开源应用程序中使用Cygwin，您需要花费数万美元从Red Hat 进行“ 许可证购买 ”；这使标准许可条款无效，付出了巨大的代价。谷歌“ cygwin许可费用”，并看到前几个结果。
对于mingw，不会产生任何此类费用，并且许可证（PD，BSD，MIT）极为宽松。最多可能希望您在应用程序中提供许可证详细信息，例如使用mingw64-tdm时所需的winpthreads许可证。
感谢Izzy Helianthus的编辑：商业许可证不再可用或不再需要，因为Cygwin的winsup子目录中找到的API库现在在LGPL下分发，而不是在完整GPL下分发。
Cygwin旨在为Windows提供一个或多或少完整的POSIX环境，其中包括旨在提供完整的类似于Linux的平台的大量工具。相比较而言，MinGW和MSYS提供一个轻量级的，简约的类POSIX层，只有像更多的必不可少的工具gcc和bash可用。由于MinGW的极简主义方法，它无法提供Cygwin提供的POSIX API覆盖范围，因此无法构建某些可以在Cygwin上编译的程序。
就两者生成的代码而言，Cygwin工具链依赖于动态链接到大型运行时库cygwin1.dll，而MinGW工具链则将代码编译为二进制文件，这些二进制文件可动态链接到Windows本机C库msvcrt.dll以及静态链接到Windows的C 部分glibc。因此，Cygwin可执行文件更紧凑，但需要单独的可重新分发的DLL，而MinGW二进制文件可以独立提供，但往往更大。
基于Cygwin的程序需要单独的DLL才能运行的事实也导致许可限制。Cygwin运行时库是根据GPLv3许可的，具有OSI兼容许可证的应用程序具有链接例外，因此，希望围绕Cygwin构建开源应用程序的开发人员必须从Red Hat获得商业许可证。另一方面，MinHead代码可在开放源代码和封闭源代码应用程序中使用，因为标头和库已获得许可。