693

I want to make my C++ project cross platform, and I'm considering using Cygwin/MinGW. But what is the difference between them ?

Another question is whether I will be able to run the binary on a system without Cygwin/MinGW ?

MD XF
  • 7,062
  • 7
  • 34
  • 64
Łukasz Lew
  • 43,526
  • 39
  • 134
  • 202
  • You can set up so that MinGW is installed alongside your package. Although I cannot provide an accepted workflow for this (hence no answer.. maybe someone else can add), I am sure it is more than possible as git does this for the git bash. Look at the window name for git bash on any windows system. – Nathan Toulbert Dec 20 '20 at 09:00

17 Answers17

675

As a simplification, it's like this:

  • Compile something in Cygwin and you are compiling it for Cygwin.

  • Compile something in MinGW and you are compiling it for Windows.

About Cygwin

Cygwin is a compatibility layer that makes it easy to port simple Unix-based applications to Windows, by emulating many of the basic interfaces that Unix-based operating systems provide, such as pipes, Unix-style file and directory access, and so on as documented by the POSIX standards. If you have existing source code that uses these interfaces, you may be able to compile it for use with Cygwin after making very few or even no changes, greatly simplifying the process of porting simple IO based Unix code for use on Windows.

When you distribute your software, the recipient will need to run it along with the Cygwin run-time environment (provided by the file cygwin1.dll). You may distribute this with your software, but your software will have to comply with its open source license. Even just linking your software with it, but distributing the dll separately, can still impose license restrictions on your code.

About MinGW

MinGW aims to simply be a port of GNU's development tools for Windows. It does not attempt to emulate or provide comprehensive compatibility with Unix, other that to provide a version of the GNU Compiler Collection, GNU Binutils and GNU Debugger that can be used natively in Windows. It also includes header files allowing the use of Windows' native API in your code.

As a result your application needs to specifically be programmed for Windows, using the Windows API, which may mean significant alteration if it was created to rely on being run in a standard Unix environment and use Unix-specific features. By default, code compiled in MinGW's GCC will compile to a native Windows X86 target, including .exe and .dll files, though you could also cross-compile with the right settings, since you are basically using the GNU compiler tools suite.

MinGW is a free and open source alternative to using the Microsoft Visual C++ compiler and its associated linking/make tools on Windows. It may be possible in some cases to use MinGW to compile something that was intended for compiling with Microsoft Visual C++ without too many modifications.

Even though MingW includes some header files and interface code allowing your code to interact with the Windows API, as with the regular standard libraries this doesn't impose licensing restrictions on software you have created.

Other considerations

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.

For instance, the open source Qt framework is a popular and comprehensive cross-platform development framework, allowing the building of graphical applications that work across operating systems including windows. There are other such frameworks too. In addition to the large frameworks there are thousands of more specialized software libraries in existence which support multiple platforms allowing you to worry less about writing different code for different platforms.

When you are developing cross-platform software from the start, you would not normally have any reason to use Cygwin. When compiled on Windows, you would usually aim to make your code able to be compiled with either MingW or Microsoft Visual C/C++, or both. When compiling on Linux/*nix, you'd most often compile it with the GNU compilers and tools directly.

thomasrutter
  • 104,920
  • 24
  • 137
  • 160
  • 51
    The bash that comes with MinGW is not a native Windows program. It depends on the MSYS DLL, which is a fork of the Cygwin DLL. Same for many of the other Unix utilities that come with MinGW/MSYS. MinGW gcc indeed is a native program though. Make is available both in a native version and an MSYS one. – ak2 Mar 07 '12 at 10:23
  • 8
    any differences in terms of speed ? – EKanadily Feb 27 '14 at 19:33
  • 8
    The difference in speed will be ignorable in *most* situations. Any difference will come down to how much the additional level of abstraction provided by the cygwin compatibility layer slows things down. It may have a measurable effect on things like I/O. For instance, a long time back, *Git* only ran on Windows in cygwin, and because of that it was quite a bit slower. Then again, if you code using a framework, that's also an abstraction layer with the potential to slow some things down anyway. – thomasrutter Feb 28 '14 at 01:28
  • 34
    I should note that code compiled for cygwin is still *native code* - it doesn't need to run through an interpreter like say Java. It's just that when it needs to interact with certain OS features like disk/file it goes through another layer. – thomasrutter Feb 28 '14 at 01:31
  • 2
    Any differences in terms of output file size? I'd assume MingW output would be bigger since all the dependencies have to be included. Is it much of a difference? – Dax Fohl Apr 17 '14 at 01:43
  • 4
    Gnerally you wouldn't be able to compare, because you have to write your code differently depending on whether it's for cygwin or not. Though for any small, simple software like "hello world" the cygwin equivalent will be bigger only because of the cygwin runtime library. If you don't count the size of the cygwin runtime library the cygwin version will usually be *smaller* but that's a false figure I think as the library will practically always need to be supplied with the software. That said, if you are using any non-trivial libraries/frameworks then it will depend more on that. – thomasrutter Apr 17 '14 at 01:51
  • So i need an confirmation without any fancy GPLV++LGBT-?dsafbyr stuff. CygWin gives you a more powerful compiler in terms of functionality with added weight of added UNIX functionalities and you need to have some cygwin dlls present in your projects ? So it is more powerful than mingw, and you need to add some dlls to your project , right ? – Danilo Jul 22 '19 at 18:51
  • 1
    There is an additional difference. It appears that Mingw doesn't support openMPI? – user32882 Oct 24 '19 at 08:47
  • 2
    `Compile something in Cygwin and you are compiling it for Cygwin` - Ok, but what if I install mingw inside cygwin and then use `x86_64-w64-mingw32-gcc.exe`? But it seems for example cygwin does not have `mingw32-make.exe`. – user136036 Dec 25 '19 at 21:24
  • 1
    Cygwin has a special exception in its licening terms that allows you to distribute free software linked with it under other licences: https://cygwin.com/licensing.html And from https://www.cygwin.com/faq.html "Can I bundle Cygwin with my product for free? Starting with Cygwin version 2.5.2, which is LGPL licensed, yes." The LGPL allows developers and companies to use and integrate a software component released under the LGPL into their own (even proprietary) software without being required by the terms of a strong copyleft license to release the source code of their own components. – Massimo May 19 '20 at 02:07
326

Cygwin is an attempt to create a complete UNIX/POSIX environment on Windows. To do this it uses various DLLs. While these DLLs are covered by GPLv3+, their license contains an exception that does not force a derived work to be covered by the GPLv3+. MinGW is a C/C++ compiler suite which allows you to create Windows executables without dependency on such DLLs - you only need the normal MSVC runtimes, which are part of any normal Microsoft Windows installation.

You can also get a small UNIX/POSIX like environment, compiled with MinGW called MSYS. It doesn't have anywhere near all the features of Cygwin, but is ideal for programmers wanting to use MinGW.

Cole Johnson
  • 8,415
  • 15
  • 44
  • 66
  • 60
    But if I want to release free non-GPL software? Sorry, I'm not a GPL fan, is all. –  Jan 02 '10 at 15:05
  • 20
    @Dan You don't need to redistribute the runtime that MinGW uses - it's part of Windows. –  Jul 13 '10 at 22:50
  • 1
    MSYS is a fork of Cygwin, and hence has the same license: G – ak2 Dec 15 '10 at 09:16
  • 14
    @ak2: that is true, but misleading. cygwyn gcc + cygwin environment defaults to producing binaries linked to the (GPL) cygwin dll. mingw + msys defaults to producing binaries linked to the platform C lib. – Sean McMillan Jun 02 '11 at 20:49
  • 5
    @DanMoulding If you're not a Microsoft fan, you will have to ignore those feelings to develop for Windows in the first place. ;-) – Arda Xi Aug 17 '12 at 22:20
  • 15
    @anon "But if I want to release free non-GPL software?".. cygwin has a special exception in its licening terms that allows you to distribute free software linked with it under other (non-GPL) open-source licences. See "Open Source Licencing Exception" here: http://cygwin.com/licensing.html – steve cook Apr 19 '14 at 04:37
  • 4
    This overly terse answer glosses over the principal reason _not_ to use Cygwin-based `gcc` for compilation of proprietary software: **GPL infection.** As of mid-2015, MSYS2 is probably the ideal solution here. It offers a MinGW-64-based `gcc` _not_ constrained by the GPL license, as well as the Arch-based `pacman` package manager for installing additional open-source dependencies. – Cecil Curry Aug 23 '15 at 05:17
  • 1
    From https://www.cygwin.com/faq.html "Can I bundle Cygwin with my product for free? Starting with Cygwin version 2.5.2, which is LGPL licensed, yes." The LGPL allows developers and companies to use and integrate a software component released under the LGPL into their own (even proprietary) software without being required by the terms of a strong copyleft license to release the source code of their own components. – Massimo May 19 '20 at 02:08
143

To add to the other answers, Cygwin comes with the MinGW libraries and headers and you can compile without linking to the cygwin1.dll by using -mno-cygwin flag with gcc. I greatly prefer this to using plain MinGW and MSYS.

Ray Hulha
  • 8,891
  • 5
  • 41
  • 44
TrayMan
  • 6,567
  • 2
  • 21
  • 30
  • 31
    This does not work any more with cygwin 1.7.6. gcc: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler. – sigjuice Aug 30 '10 at 08:06
  • 2
    @sigjuice: true, but the old -mno-cygwin flag still works for GCC 3.x: `gcc-3 -mno-cygwin` – Amro Sep 04 '11 at 13:33
  • 1
    So does this mean I need to download the mingw libraries from mingw's official site in order to compile to a mingw target from a cygwin host? Or can these libraries be downloaded from Cygwin's package system? – CMCDragonkai Feb 20 '15 at 07:02
  • 5
    @CMCDragonkai You can acquire mingw compatible compilers from the Cygwin site by running the setup utility and finding and ticking them. So even though gcc no longer generates mingw-compatible code, you can within Cygwin run a "mingw-gcc" (that's not the full name) to make the same kind of executable that the mingw compiler would under msys. – cardiff space man Mar 03 '15 at 23:25
  • 10
    To amend cardiff's helpful reply, Cygwin's MinGW packages and commands have somewhat obscure names. To install MinGW-64 (*pretty much what you always want, these days*), install the `mingw64-x86_64-gcc-core` Cygwin package. MinGW-64 will then be available as the awkwardly named `x86_64-w64-mingw32-gcc` command. **Please God(s), somebody unify the names of these bloody things already.** – Cecil Curry Aug 23 '15 at 05:25
  • @CecilCurry Is this preferable to using MingW and MSYS? won't the Cygwin version be slower to get mingw/gcc updates? And why not just use the native mingw-64 compiler from windows in cygwin? – jiggunjer Dec 01 '15 at 04:19
  • @jiggunjer These days, it's difficult to be slower tracking than the original MSYS. Whereas Cygwin - and by extension MSYS2 - track pretty quickly. – underscore_d Apr 23 '16 at 14:20
  • @CecilCurry and anyone confused with naming, refer to this great explanation: https://stackoverflow.com/a/5731708/427898 – PF4Public Jul 08 '17 at 22:07
62

Wikipedia does a comparison here.

From Cygwin's website:

  • Cygwin is a Linux-like environment for Windows. It consists of two parts: A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality.
  • A collection of tools which provide Linux look and feel.

From Mingw's website:

MinGW ("Minimalistic GNU for Windows") is a collection of freely available and freely distributable Windows specific header files and import libraries combined with GNU toolsets that allow one to produce native Windows programs that do not rely on any 3rd-party C runtime DLLs

Skilldrick
  • 65,202
  • 32
  • 168
  • 226
dirkgently
  • 101,474
  • 16
  • 123
  • 183
  • The MinGW-w64 website is [now](http://mingw-w64.org/doku.php). As it says "Mingw-w64 is an advancement of the original mingw.org project, created to support the GCC compiler on Windows systems. It has forked it in 2007 in order to provide support for 64 bits and new APIs. It has since then gained widespread use and distribution. – DDay Mar 05 '21 at 16:45
48

Cygwin uses a DLL, cygwin.dll, (or maybe a set of DLLs) to provide a POSIX-like runtime on Windows.

MinGW compiles to a native Win32 application.

If you build something with Cygwin, any system you install it to will also need the Cygwin DLL(s). A MinGW application does not need any special runtime.

Michael Burr
  • 311,791
  • 49
  • 497
  • 724
43

Read these answered questions to understand the difference between Cygwin and MinGW.


Question #1: I want to create an application that I write source code once, compile it once and run it in any platforms (e.g. Windows, Linux and Mac OS X…).

Answer #1: Write your source code in JAVA. Compile the source code once and run it anywhere.


Question #2: I want to create an application that I write source code once but there is no problem that I compile the source code for any platforms separately (e.g. Windows, Linux and Mac OS X …).

Answer #2: Write your source code in C or C++. Use standard header files only. Use a suitable compiler for any platform (e.g. Visual Studio for Windows, GCC for Linux and XCode for Mac). Note that you should not use any advanced programming features to compile your source code in all platforms successfully. If you use none C or C++ standard classes or functions, your source code does not compile in other platforms.


Question #3: In answer of question #2, it is difficult using different compiler for each platform, is there any cross platform compiler?

Answer #3: Yes, Use GCC compiler. It is a cross platform compiler. To compile your source code in Windows use MinGW that provides GCC compiler for Windows and compiles your source code to native Windows program. Do not use any advanced programming features (like Windows API) to compile your source code in all platforms successfully. If you use Windows API functions, your source code does not compile in other platforms.


Question #4: C or C++ standard header files do not provide any advanced programming features like multi-threading. What can I do?

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.


Thus:

To use advantage of GCC cross platform compiler in Windows, use MinGW.

To use advantage of POSIX standard advanced programming features and tools in Windows, use Cygwin.

Amir Saniyan
  • 10,990
  • 18
  • 77
  • 124
  • 5
    About your little faq: 1) Your right, if you need something that runs anywhere and doesn't need to be compiled choose something like java (also don't forget python, perl, ruby and the rest of the script languages) 2) This is somewhat wrong for the case of C, since all compilers of C, support it very well. 3) You can still use win32 api, but you have to wrap it in a portability layer, so that is only a design problem. – Coyote21 Sep 26 '11 at 20:39
  • 1
    4) This is totally wrong, because of the reasons I give above, since POSIX is only other api, also if you defend so much POSIX, you should know that even Unices don't need to implement the same set of POSIX, so how do you deal with that? The real time POSIX api comes to mind. And that makes you conclusion completely bogus and wrong, because you don't need POSIX for anything in windows, you can just use the Win32 API. Or how do you think that Qt , GTK and WxWidgets have found a way to be cross-platform, I guess that they all have to use cygwin in windows. -1 vote for your answer. – Coyote21 Sep 26 '11 at 20:39
  • 6
    I don't understand your argument, @Coyote21. Are you saying that POSIX is unsuitable for cross-platform development? Are you saying that the only appropriate way to write code in C/C++ for multiple platforms is to write your own compatibility layer for each platform you wish to support? I don't see anything wrong with the suggestion to start with POSIX. You do need to see how far it can get you and whether an extensive compatibility layer solution will be required. Large compatibility layers are not the norm. To say otherwise is to argue that POSIX is a complete failure. – David Gladfelter Oct 22 '12 at 23:05
  • Multithreading is implemented through POSIX layer even in MinGW. – Alexander Shishenko Jan 22 '16 at 01:47
  • 4
    "you should not use any advanced programming features to compile your source code in all platforms successfully." You really need to clarify what you meant by "advanced programming features". Based on a later line, my guess is you actually mean _platform-specific_ features. If you meant modern language features, then no, because competent compilers exist for "all [major] platforms", and we should not deprive ourselves of features just to prop up those whose compilers or libraries still lag behind. With a decent compiler, standard C/++, and cross-platform libraries, we can be _plenty_ advanced. – underscore_d Apr 23 '16 at 14:25
  • 1
    Downvoted because very little of this is relevant to the original question. It might be better to start with the "Thus..." statement and provide the FAQ as context for those who need it. Promoting Java is unhelpful; the question author didnt ask what language to use. – matt2000 Dec 16 '20 at 19:16
  • Nowadays Golang is (arguably) the best option for question 2. – Dan Ortega Apr 13 '21 at 14:24
37

From the point of view of porting a C program, a good way to understand this is to take an example:

#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;
}

If we change stat to _stat, we can compile this program with Microsoft Visual C. We can also compile this program with MinGW, and with Cygwin.

Under Microsoft Visual C, the program will be linked to a MSVC redistributable run-time library: mxvcrtnn.dll, where nn is some version suffix. To ship this program we will have to include that DLL. That DLL provides _stat, system and printf. (We also have the option of statically linking the run-time.)

Under MinGW, the program will be linked to msvcrt.dll, which is an internal, undocumented, unversioned library that is part of Windows, and off-limits to application use. That library is essentially a fork of the redistributable run-time library from MS Visual C for use by Windows itself.

Under both of these, the program will have similar behaviors:

  • the stat function will return very limited information—no useful permissions or inode number, for instance.
  • the path c:file.txt is resolved according to the current working directory associated with drive c:.
  • system uses cmd.exe /c for running the external command.

We can also compile the program under Cygwin. Similarly to the redistributable run-time used by MS Visual C, the Cygwin program will be linked to Cygwin's run-time libraries: cygwin1.dll (Cygwin proper) and cyggcc_s-1.dll (GCC run-time support). Since Cygwin is now under the LGPL, we can package with our program, even if it isn't GPL-compatible free software, and ship the program.

Under Cygwin, the library functions will behave differently:

  • 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.

Both Cygwin and MinGW allow you to use Win32 functions. If you want to call MessageBox or CreateProcess, you can do that. You can also easily build a program which doesn't require a console window, using gcc -mwindows, under MinGW and Cygwin.

Cygwin is not strictly POSIX. In addition to providing access to the Windows API, it also provides its own implementations of some Microsoft C functions (stuff found in msvcrt.dll or the re-distributable msvcrtnn.dll run-times). An example of this are the spawn* family of functions like spawnvp. These are a good idea to use instead of fork and exec on Cygwin since they map better to the Windows process creation model which has no concept of fork.

Thus:

  • 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.

However:

  • As a native Windows development tool, Cygwin has some quirks, like path handling that is foreign to Windows, dependence on some hard-coded paths like /bin/sh and other issues. These differences are what render Cygwin programs "non-native". If a program takes a path as an argument, or input from a dialog box, Windows users expect that path to work the same way as it does in other Windows programs. If it doesn't work that way, that's a problem.

Plug: Shortly after the LGPL announcement, I started the Cygnal (Cygwin Native Application Library) project to provide a fork of the Cygwin DLL which aims to fix these issues. Programs can be developed under Cygwin, and then deployed with the Cygnal version of cygwin1.dll without recompiling. As this library improves, it will gradually eliminate the need for 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.

Kaz
  • 48,579
  • 8
  • 85
  • 132
  • 3
    Excellent answer. Showing what happens when same piece of code is compiled, linked and executed in each of the 3 environments is key and clarifies the differences. – drlolly Apr 21 '17 at 14:05
  • @Kaz How is that development going? Sound iteresting but it seem dead since at least a year back. Why don't you use GitHub so people can help and participate? – not2qubit Dec 21 '18 at 11:26
  • 3
    @not2qubit I feel I have better control over my projects when they are hosted on my own server that I control myself. I am using git; the repository can be pulled. I can accept pull requests by e-mail (as Linus Torvalds designed them). I can also give an account with commit privileges to someone who becomes a maintainer-level contributor. Cygnal works fine; I'm regularly bundling it in the Windows versions of new releases of the TXR language. I will rebase Cygnal it to a newer Cygwin baseline sometime in early 2019. – Kaz Dec 22 '18 at 06:36
  • 1
    @not2qubit Note that all 17 issues in the Cygnal agenda are as addressed. Nobody has suggested any new requirements, or complained about the way those 17 are handled. so there is no development required other than rebasing to newer Cygwin, which isn't hugely urgent. – Kaz Dec 22 '18 at 06:44
27

Wikipedia Says:

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.

Simon Sobisch
  • 4,650
  • 11
  • 33
PersianGulf
  • 2,388
  • 4
  • 36
  • 60
  • 2
    It's definitely **not** *"more complicated to install and maintain"*! Use **[`apt-cyg`](https://github.com/kou1okada/apt-cyg)** as it's perhaps even easier than using apt under WSL. – not2qubit Dec 21 '18 at 11:29
25

Other answers already hit the target. I just want to add an illustration for a quick catch.

enter image description here

smwikipedia
  • 52,824
  • 76
  • 267
  • 432
15

Don't overlook AT&T's U/Win software, which is designed to help you compile Unix applications on windows (last version - 2012-08-06; uses Eclipse Public License, Version 1.0).

Like Cygwin they have to run against a library; in their case POSIX.DLL. The AT&T guys are terrific engineers (same group that brought you ksh and dot) and their stuff is worth checking out.

Simon Sobisch
  • 4,650
  • 11
  • 33
Norman Ramsey
  • 188,173
  • 57
  • 343
  • 523
  • 4
    Wow, those are some bad web pages. I was finally able to find a download link at http://www2.research.att.com/sw/download/, but no online documentation or information about the project. – Fantius Feb 02 '12 at 01:24
  • 1
    While the information is useful, I feel this could be the answer to a question on alternatives for MingW or Cygwin rather than this question. – Vivek Nov 05 '16 at 13:47
11

Cygwin emulates entire POSIX environment, while MinGW is minimal tool set for compilation only (compiles native Win application.) So if you want to make your project cross-platform the choice between the two is obvious, MinGW.

Although you might consider using VS on Windows, GCC on Linux/Unices. Most open source projects do that (e.g. Firefox or Python).

vartec
  • 118,560
  • 34
  • 206
  • 238
  • "Most" seems like a meaningless weasel word here, especially with only 2 examples and no statistics. Many FOSS projects throw in a VS project file as a token gesture, I suspect is more accurate. But if past experience is anything to go by, GCC or Clang are usually safer as VS tends to lag behind considerably as the language standards evolve. – underscore_d Apr 02 '16 at 01:00
  • 1
    That's an answer from 2009. Nowadays things look even more bleak for GCC. As for "most", if you measure by impact, then just Firefox and Chrome alone have more users than anything else. – vartec Apr 02 '16 at 01:19
  • 3
    What has changed since when I've answered is that now `clang` is a viable cross-platform solution. – vartec Apr 02 '16 at 01:20
  • 1
    It would be awesome to get "what has changed since" for year 2021 edition. – Henry Tjhia Jan 31 '21 at 09:22
10

To use Cygwin in a commercial / proprietary / non-open-source application, you'll need to fork out tens of thousands of dollars for a "license buyout" from Red Hat; this invalidates the standard licensing terms at a considerable cost. Google "cygwin license cost" and see first few results.

For mingw, no such cost is incurred, and the licenses (PD, BSD, MIT) are extremely permissive. At most you may be expected to supply license details with your application, such as the winpthreads license required when using mingw64-tdm.

EDIT thanks to Izzy Helianthus: The commercial license is no longer available or necessary because the API library found in the winsup subdirectory of Cygwin is now being distributed under the LGPL, as opposed to the full GPL.

Engineer
  • 7,543
  • 7
  • 57
  • 96
  • 4
    An update from Redhat website (the link from "license buyout" - 'As of March 1, 2016 Red Hat no longer sells the commercial Buyout License for Cygwin. The commercial license is no longer necessary because Cygwin is now being distributed under the GNU Lesser GPL (LGPL).' > From Cygwin Website. The Cygwin™ API library found in the winsup subdirectory of the source code is covered by the GNU Lesser General Public License (LGPL) version 3 or later. For details of the requirements of LGPLv3, please read the GNU Lesser General Public License (LGPL). – Izzy Helianthus Feb 26 '17 at 11:24
9

Note that utility behaviour can genuinely vary between the two.

For example, Cygwin tar can fork - because fork() is supported in the DLL - where the mingw version cannot. This is a problem when trying to compile mysql from source.

  • This is why fully fledged MinGW-capable environments, e.g. MSYS2, offer a Cygwin or other fully POSIX-compatible layer for the low-level nuts and bolts of toolchains needed during building. Then the actual compilation and linking is left up to the fully native MinGW compiler. MSYS2 is really neat. – underscore_d Apr 02 '16 at 01:05
7

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.

In terms of the code generated by the two, the Cygwin toolchain relies on dynamic linking to a large runtime library, cygwin1.dll, while the MinGW toolchain compiles code to binaries that link dynamically to the Windows native C library msvcrt.dll as well as statically to parts of glibc. Cygwin executables are therefore more compact but require a separate redistributable DLL, while MinGW binaries can be shipped standalone but tend to be larger.

The fact that Cygwin-based programs require a separate DLL to run also leads to licensing restrictions. The Cygwin runtime library is licensed under GPLv3 with a linking exception for applications with OSI-compliant licenses, so developers wishing to build a closed-source application around Cygwin must acquire a commercial license from Red Hat. On the other hand, MinGW code can be used in both open-source and closed-source applications, as the headers and libraries are permissively licensed.

bwDraco
  • 2,201
  • 29
  • 37
3

Cygwin is is a Unix-like environment and command-line interface for Microsoft Windows.

Mingw is a native software port of the GNU Compiler Collection (GCC) to Microsoft Windows, along with a set of freely distributable import libraries and header files for the Windows API. MinGW allows developers to create native Microsoft Windows applications.

You can run binaries generated with mingw without the cygwin environment, provided that all necessary libraries (DLLs) are present.

gimel
  • 73,814
  • 10
  • 69
  • 104
2

Cygwin uses a compatibility layer, while MinGW is native. That is one of the main differences.

Mamun
  • 58,653
  • 9
  • 33
  • 46
1
   MinGW (or MinGW-w64)               Cygwin
   --------------------               ------

   Your program written        Your program written
    for Unix and Linux          for Unix and 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
Akib Azmain
  • 851
  • 3
  • 25
  • The top chart would be mostly relevant for programs designed for command-line/console based input and output and progressively less true as you add more complex device access or graphical user interfaces, where the cygwin compatibility layer helps you relatively less. – thomasrutter Apr 19 '21 at 06:46