windows - Cygwin和MinGW有什麼區別？（MinGW從Cygwin 1.3.3版本中分離出來）

windows - Cygwin和MinGW有什麼區別？

我想讓個人C ++項目跨平臺，我正在考慮使用Cygwin / MinGW。 可是他們之間有什麼區別呢？

另外一個問題是，若是沒有Cygwin / MinGW，我可否在系統上運行二進制文件？

 Answers

---

Cygwin是嘗試在Windows上建立一個完整的UNIX / POSIX環境。 要作到這一點，它使用各類DLL。 雖然這些DLL被GPLv3 +覆蓋，可是它們的許可證包含一個異常 ，不會強制派生的工做被GPLv3 +覆蓋。 MinGW是一個C / C ++編譯器套件，它容許您建立Windows可執行文件而不依賴於這樣的DLL - 您只須要普通的MSVC運行時，這是Microsoft Windows正常安裝的一部分。

你也能夠獲得一個小的UNIX / POSIX環境，用MinGW編譯成MSYS 。 它沒有Cygwin的全部功能，但對於想要使用MinGW的程序員來講是很是理想的。

做爲一個簡化，就是這樣的：

• 在Cygwin中編譯一些東西，而後編譯Cygwin 。

• 編譯MinGW中的東西，你正在爲Windows編譯它。

關於Cygwin

Cygwin的目的是經過模擬許多基於Unix的操做系統提供的小細節，並經過POSIX標準來記錄，使得基於nix的應用程序更容易移植到Windows上。 若是您的應用程序假定它可使用Unix功能，例如管道，Unix風格的文件和目錄訪問等等，那麼您能夠在Cygwin中編譯它，而Cygwin自己將做爲您的應用程序的兼容層 ，這些特定於Unix的範例能夠繼續使用，對應用程序進行不多或不須要修改。

若是你想爲Cygwin編譯一些東西並分發這個應用程序，那麼你還必須將Cygwin運行時環境（由cygwin1.dll提供）與它一塊兒cygwin1.dll ， 這對你可能使用哪一種類型的軟件許可有影響 。

關於MinGW

MinGW是GNU編譯器工具的Windows端口，例如GCC，Make，Bash等等。 它不會試圖模擬或提供與Unix的全面兼容性，而是提供在Windows上使用GCC（GNU編譯器）和少許其餘工具的最低必要環境。 它沒有像Cygwin同樣的Unix仿真層，可是結果是你的應用程序須要特別的編程才能在Windows上運行，這可能意味着若是它被建立爲依賴於在標準Unix環境中運行，使用Unix特有的功能，好比前面提到的功能。 默認狀況下，在MinGW的GCC中編譯的代碼將編譯爲本機Windows X86目標，包括.exe和.dll文件，可是也可使用正確的設置進行交叉編譯。 MinGW是Microsoft Visual C ++編譯器及其關聯的連接/製做工具的開源替代品。

存在至關複雜的跨平臺框架，這使得將應用輕鬆移植到各類操做系統的任務成爲可能 - 例如Qt框架是跨平臺應用的流行框架。 若是您從一開始就使用這樣的框架，那麼您不只能夠減小在移植到其餘平臺時遇到的麻煩，並且能夠在全部平臺上使用相同的圖形窗口小部件（窗口，菜單和控件） GUI應用程序。

要添加到其餘答案，Cygwin附帶MinGW庫和標題，您能夠經過使用-mno-cygwin標誌與gcc編譯而不連接到cygwin1.dll。 我很是喜歡使用簡單的MinGW和MSYS。

維基百科在這裏作一個比較。

從Cygwin的網站 ：

• Cygwin是一個相似於Linux的Linux環境。 它由兩部分組成：一個DLL（cygwin1.dll），充當Linux API仿真層，提供大量的Linux API功能。
• 提供Linux外觀的一系列工具。

從Mingw的網站 ：

MinGW（簡稱「GNU for Windows」）是一個可免費得到並可自由分發的Windows特定頭文件和導入庫的集合，與GNU工具集相結合，能夠生成不依賴任何第三方C運行時DLL的本地Windows程序

Cygwin使用DLL，cygwin.dll（或者一組DLL）在Windows上提供相似於POSIX的運行時。

MinGW編譯爲本機Win32應用程序。

若是你用Cygwin構建一些東西，你安裝它的任何系統也將須要Cygwin DLL。 MinGW應用程序不須要任何特殊的運行時。

閱讀這些回答的問題，瞭解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中編譯源代碼，請使用爲Windows提供GCC編譯器的MinGW ，並將源代碼編譯爲本機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。

維基百科說 ：

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+編寫的應用程序一般在MinGW編譯將像在Cygwin那樣容易。

MinGW和MSYS的組合提供了一個小型自包含的環境，能夠將其加載到可移動媒體上，而無需在註冊表或計算機上的文件中留下條目。 Cygwin Portable提供了相似的功能。 經過提供更多的功能， Cygwin安裝和維護變得更加複雜。

也能夠MinGW-GCC under POSIX systems用MinGW-GCC under POSIX systems cross-compile Windows applications 。 這意味着開發人員不須要使用MSYS進行Windows安裝來編譯在沒有Cygwin狀況下在Windows運行的軟件。

從移植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:相關聯的當前工做目錄來解析路徑c:file.txt 。
• system使用cmd.exe /c來運行外部命令。

咱們也能夠編譯Cygwin下的程序。 相似於MS Visual C使用的可再發行的運行時，Cygwin程序將被連接到Cygwin的運行時庫： cygwin1.dll （Cygwin proper）和cyggcc_s-1.dll（GCC運行時支持）。 因爲Cygwin如今在LGPL之下，即便它不是GPL兼容的免費軟件，咱們也能夠用咱們的程序打包，並運行程序。

在Cygwin下，庫函數的行爲將有所不一樣：

• stat函數具備豐富的功能，在大多數字段中返回有意義的值。
• 路徑c:file.txt徹底不理解爲包含驅動器號引用，由於c:後面沒有斜槓。 冒號被認爲是名字的一部分，並以某種方式破壞了它。 在Cygwin中沒有針對卷或驅動器的相對路徑的概念，沒有「當前記錄的驅動器」概念，也沒有每一個驅動器當前的工做目錄。
• system函數嘗試使用/bin/sh -c解釋器。 Cygwin將根據您的可執行文件的位置來解析/路徑，並但願sh.exe程序與您的可執行文件位於sh.exe位置。

Cygwin和MinGW都容許你使用Win32函數。 若是你想調用MessageBox或CreateProcess ，你能夠這樣作。 你也能夠在MinGW和Cygwin下使用gcc -mwindows輕鬆地建立一個不須要控制檯窗口的程序。

Cygwin不是嚴格的POSIX。 除了提供對Windows API的訪問以外，它還提供了一些Microsoft C函數（在msvcrt.dll找到的東西或可從新分發的msvcrtnn.dll運行時）的本身的實現。 一個例子就是spawn*系列的spawn*系列。 這些在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本地應用程序庫）項目，以提供一個旨在解決這些問題的Cygwin DLL的分支。 程序能夠在Cygwin下開發，而後使用Cygnal版本的cygwin1.dll進行部署，而無需從新編譯。 隨着這個庫的改進，它將逐漸消除對MinGW的需求。

當Cygnal解決路徑處理問題時，能夠開發一個單獨的可執行文件做爲Windows應用程序與Cygnal一塊兒使用時，與Cygwin的/usr/bin下安裝Cygwin路徑無縫工做與Windows路徑。 在Cygwin下，可執行文件將透明地處理/cygdrive/c/Users/bob類的路徑。 在Cygnal版本的cygwin1.dll連接的本地部署中，該路徑將沒有任何意義，而它將理解c:foo.txt 。

不要忽視AT＆T的U / Win軟件，該軟件能夠幫助您在Windows上編譯Unix應用程序（最新版本 - 2012-08-06;使用Eclipse公共許可證，版本1.0）。

像Cygwin同樣，他們必須跑到一個圖書館。 在他們的狀況下POSIX.DLL 。 AT＆T的工做人員是很是棒的工程師（一樣的團隊給你帶來了ksh和dot ），他們的東西值得一試。

Cygwin模擬整個POSIX環境，而MinGW只是編譯的最小工具集（編譯本地Win應用程序）。因此若是你想讓你的項目跨平臺，二者之間的選擇是明顯的，MinGW。

雖然你可能會考慮在Windows上使用VS，在Linux / Unices上使用GCC。 大多數開源項目都是這樣作的（例如Firefox或Python）。

請注意，效用行爲能夠真正在二者之間變化。

例如，Cygwin tar能夠fork - 由於fork（）在DLL中被支持，而mingw版本則不能。 嘗試從源代碼編譯mysql時，這是一個問題。

要在商業/專有/非開源應用程序中使用Cygwin，您須要從Red Hat得到「 許可證買斷 」的數萬美圓; 這使標準許可條款以至關大的成本無效。 谷歌「cygwin許可證費用」，看到前幾個結果。

對於mingw，這樣的成本是不會發生的，許可證（PD，BSD，MIT）是很是寬容的。 您至多可能須要爲您的應用程序提供許可證詳細信息，例如使用mingw64-tdm時所需的winpthreads許可證。

編輯感謝Izzy向日葵：商業許可證再也不是可用的或必要的，由於在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以及靜態地glibc部分。 Cygwin可執行文件所以更爲緊湊，但須要單獨的可再發行DLL，而MinGW二進制文件能夠獨立運行，但每每會更大。

基於Cygwin的程序須要單獨運行的DLL也會致使許可限制。 Cygwin運行時庫在GPLv3下得到許可，對於具備OSI兼允許可的應用程序，連接例外，所以但願圍繞Cygwin構建閉源應用程序的開發者必須從Red Hat得到商業許可。 另外一方面，MinGW代碼能夠用於開放源碼和封閉源碼的應用程序，由於頭文件和庫文件是被許可的。

Cygwin是一個相似於Unix的環境和Microsoft Windows的命令行界面。

Mingw是GNU編譯器集合（GCC）到Microsoft Windows的原生軟件端口，還有一套可自由分發的用於Windows API的導入庫和頭文件。 MinGW容許開發人員建立本機Microsoft Windows應用程序。

只要全部必要的庫（DLL）都存在，您就能夠在不使用cygwin環境的狀況下運行使用mingw生成的二進制文件。

Cygwin使用兼容性層，而MinGW是本地的。 這是不一樣的。

 

https://code.i-harness.com/zh-CN/q/bc6ac