Cygwin和MinGW有什么区别？

我想让个人C ++项目跨平台，我正在考虑使用Cygwin / MinGW。 但它们之间有什么区别？

另外一个问题是我是否可以在没有Cygwin / MinGW的系统上运行二进制文件？

---

#1楼

维基百科说 ：

MinGW从Cygwin 1.3.3版本开始。 尽管Cygwin和MinGW均可用于将UNIX软件移植到Windows ，但它们有不一样的方法： Cygwin旨在提供完整的POSIX layer ，提供Linux ， UNIX和BSD变体上存在的多个系统调用和库的模拟。 POSIX layer在Windows之上运行，在必要时牺牲性能以实现兼容性。 所以，这种方法要求使用Cygwin编写的Windows程序在copylefted兼容库之上运行，该库必须与程序一块儿分发，以及程序的source code 。 MinGW旨在经过直接的Windows API calls提供本机功能和性能。 与Cygwin不一样， MinGW不须要兼容层DLL ，所以程序不须要与source code一块儿分发。

因为MinGW依赖于Windows API calls ，所以没法提供完整的POSIX API ; 它没法编译可使用Cygwin编译的一些UNIX applications 。 具体来讲，这适用于须要POSIX功能的应用程序，如fork() ， mmap()或ioctl()以及指望在POSIX environment运行的应用程序。 使用本身移植到MinGW的cross-platform library编写的应用程序，例如SDL ， wxWidgets ， Qt或GTK+ ，一般能够像在Cygwin同样在MinGW轻松编译。

MinGW和MSYS的组合提供了一个小型的自包含环境，能够将其加载到可移动媒体上，而无需在注册表或计算机上的文件中留下条目。 Cygwin Portable提供了相似的功能。 经过提供更多功能， Cygwin安装和维护变得更加复杂。

也能够MinGW-GCC under POSIX systems使用MinGW-GCC under POSIX systems cross-compile Windows applications 。 这意味着开发人员不须要使用MSYS安装Windows来编译将在没有Cygwin状况下在Windows运行的软件。

---

#2楼

Cygwin使用兼容层，而MinGW是原生的。 这是主要的差别之一。

---

#3楼

Cygwin旨在为Windows提供或多或少的完整POSIX环境，包括一系列旨在提供完整的类Linux平台的工具。 相比之下，MinGW和MSYS提供了一个轻量级，简约的POSIX类图层，只有像gcc和bash这样的基本工具可用。 因为MinGW更简约的方法，它没有提供Cygwin提供的POSIX API覆盖程度，所以没法构建某些程序，不然能够在Cygwin上编译。

就二者生成的代码而言，Cygwin工具链依赖于动态连接到大型运行时库cygwin1.dll ，而MinGW工具链将代码编译为动态连接到Windows本机C库msvcrt.dll以及二进制文件的二进制文件。静态的部分glibc 。 所以，Cygwin可执行文件更紧凑，但须要单独的可再发行DLL，而MinGW二进制文件能够单独发布，但每每更大。

基于Cygwin的程序须要运行单独的DLL这一事实也会致使许可限制。 Cygwin运行时库在GPLv3下得到许可，对于具备OSI兼允许可证的应用程序具备连接例外，所以但愿围绕Cygwin构建闭源应用程序的开发人员必须从Red Hat得到商业许可。 另外一方面，MinGW代码能够在开源和闭源应用程序中使用，由于标头和库是许可的。

---

#4楼

要在商业/专有/非开源应用程序中使用Cygwin，您须要为Red Hat的“ 许可证收购 ”支付数万美圆; 这会以至关大的成本使标准许可条款无效。 谷歌“cygwin许可证费用”，并看到前几个结果。

对于mingw，不会产生这样的费用，许可证（PD，BSD，MIT）很是宽松。 最多可能须要为您的应用程序提供许可证详细信息，例如使用mingw64-tdm时所需的winpthreads许可证。

编辑感谢Izzy Helianthus：商业许可证再也不可用或没必要要，由于在Cygwin的winsup子目录中找到的API库如今正在 LGPL下发布，而不是完整的GPL。

---

#5楼

从移植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:关联的当前工做目录解析。
• 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将根据您的可执行文件的位置解析/ path，并指望sh.exe程序与您的可执行文件位于sh.exe位置。

Cygwin和MinGW都容许您使用Win32功能。 若是要调用MessageBox或CreateProcess ，则能够执行此操做。 您还可使用gcc -mwindows在MinGW和Cygwin下轻松构建一个不须要控制台窗口的程序。

Cygwin不是严格的POSIX。 除了提供对Windows API的访问以外，它还提供了本身的一些Microsoft C函数的实现（在msvcrt.dll找到的东西或可从新分发的msvcrtnn.dll运行时）。 一个例子是spawn*函数系列，如spawnvp 。 这些是在Cygwin上使用而不是fork和exec的好主意，由于它们更好地映射到没有fork概念的Windows进程建立模型。

从而：

• 因为须要图书馆的伴奏，Cygwin程序不比MS Visual C程序“原生”。 Windows上的编程语言实现有望提供本身的运行时，甚至C语言实现。 Windows上没有“libc”供公众使用。

• MinGW不须要第三方DLL的事实其实是一个缺点; 它取决于Visual C运行时的未记录的Windows内部分支。 MinGW这样作是由于GPL系统库异常适用于msvcrt.dll ，这意味着可使用MinGW编译和从新分发GPL编辑的程序。

• 与msvcrt.dll相比，因为对POSIX的支持范围更广，更深刻，所以Cygwin是移植POSIX程序的优越环境。 因为它如今属于LGPL，它容许从新分发具备各类许可证（开放源代码或封闭源代码）的应用程序。 Cygwin甚至包含VT100仿真和termios ，它们可与Microsoft控制台配合使用！ 使用tcsetattr设置原始模式并使用VT100代码控制光标的POSIX应用程序将在cmd.exe窗口中正常工做。 就最终用户而言，它是一个本机控制台应用程序，能够经过Win32调用来控制控制台。

然而：

• 做为一个原生的Windows开发工具，Cygwin有一些怪癖，好比Windows的外来路径处理，依赖于某些硬编码路径，如/bin/sh和其余问题。 这些差别使得Cygwin程序“非本地”。 若是程序将路径做为参数或从对话框输入，则Windows用户但愿该路径的工做方式与在其余Windows程序中的工做方式相同。 若是它不起做用，那就是一个问题。

插件：在LGPL发布后不久，我启动了Cygnal （Cygwin Native Application Library）项目，提供了一个Cygwin DLL的分支，旨在解决这些问题。 程序能够在Cygwin下开发，而后使用Cygnal版本的cygwin1.dll进行部署而无需从新编译。 随着这个库的改进，它将逐渐消除对MinGW的需求。

当Cygnal解决路径处理问题时，能够开发一个单独的可执行文件，看成为带有Cygnal的Windows应用程序提供时，它能够与Windows路径一块儿使用，而且当安装在Cygwin下的/usr/bin时，能够无缝地与Cygwin路径一块儿使用。 在Cygwin下，可执行文件将透明地使用/cygdrive/c/Users/bob类的路径。 在与cygwin1.dll的Cygnal版本连接的本机部署中，该路径没有意义，而它将理解c:foo.txt 。