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 ?
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 ?
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
The purpose of Cygwin is to make porting Unix-based applications to Windows much easier, by emulating many of the small details that Unix-based operating systems provide, and are documented by the POSIX standards. Your application can use Unix feature such as pipes, Unix-style file and directory access, and so forth, and it can be compiled with Cygwin which will act as a compatibility layer around your application, so that many of those Unix-specific paradigms can continue to be used.
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. It may even be the case that even just linking your software with it, but distributing the dll separately, may still require you to honor the open source license.
About MinGW
MinGW aims to simply be a Windows port of the GNU compiler tools, such as GCC, Make, Bash, and so on. It does not attempt to emulate or provide comprehensive compatibility with Unix, but instead it provides the minimum necessary environment to use GCC (the GNU compiler) and a small number of other tools on Windows. It does not have a Unix emulation layer like Cygwin, but as a result your application needs to specifically be programmed to be able to run in Windows, which may mean significant alteration if it was created to rely on being run in a standard Unix environment and uses Unix-specific features such as those mentioned earlier. 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 essentially an alternative to the Microsoft Visual C++ compiler and its associated linking/make tools. It may be possible in some cases to use MinGW to compile something that was intended for compiling with Microsoft Visual C++, with the right libraries and in some cases with other modifications.
MinGW includes some basic standard libraries for interacting with the Windows operating system, but as with the normal standard libraries included in the GNU compiler collection these don't impose licensing restrictions on software you have created.
For non-trivial software applications, making them cross-platform can be a considerable challenge unless you use a comprehensive cross-platform framework. At the time I wrote this the Qt framework was one of the most popular for this purpose, allowing the building of graphical applications that work across operating systems including Windows, but there are other options too. 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.
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.
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.
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
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.
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:
Wikipedia Says:
MinGW
forked from version 1.3.3 ofCygwin
. Although bothCygwin
andMinGW
can be used to portUNIX
software toWindows
, they have different approaches:Cygwin
aims to provide a completePOSIX layer
that provides emulations of several system calls and libraries that exist onLinux
,UNIX
, and theBSD
variants. ThePOSIX layer
runs on top ofWindows
, sacrificing performance where necessary for compatibility. Accordingly, this approach requiresWindows
programs written withCygwin
to run on top of a copylefted compatibility library that must be distributed with the program, along with the program'ssource code
.MinGW
aims to provide native functionality and performance via directWindows API calls
. UnlikeCygwin
,MinGW
does not require a compatibility layerDLL
and thus programs do not need to be distributed withsource code
.Because
MinGW
is dependent uponWindows API calls
, it cannot provide a fullPOSIX API
; it is unable to compile someUNIX applications
that can be compiled withCygwin
. Specifically, this applies to applications that requirePOSIX
functionality likefork()
,mmap()
orioctl()
and those that expect to be run in aPOSIX environment
. Applications written using across-platform library
that has itself been ported toMinGW
, such asSDL
,wxWidgets
,Qt
, orGTK+
, will usually compile as easily inMinGW
as they would inCygwin
.The combination of
MinGW
andMSYS
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
withMinGW-GCC under POSIX systems
. This means that developers do not need a Windows installation withMSYS
to compile software that will run onWindows
withoutCygwin
.
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
.
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:
stat
function will return very limited information—no useful permissions or inode number, for instance.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:
stat
function has rich functionality, returning meaningful values in most of the fields.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.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:
/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
.
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.
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).
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.
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.
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.
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.
Cygwin
uses a compatibility layer, while MinGW
is native. That is one of the main differences.