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 。