Why does Mingw exist? - gcc

MSYS and UNIX-like build systems apart; why does Mingw exist? What I mean is, why isn't win32/64 just another target available in "vanilla GCC"? Are there technical reasons for this or are they "political"? It would seem to me that there isn't really anything special about the Windows platform that would make a GCC port to it "incompatible" with the original GCC.

Mingw isn't just the compilers - it's also the libraries and headers (and whatever other support files you might need).
GCC is just a compiler. Mingw is a full environment.

MingW is intended to allow easy porting of Posix apps to windows. It's simply a "thinner" layer than CygWin, so not everything might work where windows too different. CygWin allows provides enough insulation that even the scripting tools to build and generate code run.
Edit:
Microsoft is very fond of making there own standards, and want to put there own brand on things for which open standards already exist. i.e. OpenGL -> DirectX, Java -> .net, OpenCL is the next standard they want to spurn. This makes them a bit of a pain for non sponsored project to support them as a target. They have always turned away from anything that allows easy cross platform development, because they only want you to develop your app for there OS. It's a marketing strategy, control the brand, control the platform, and make it painful for people to support other OSes. MingW is required because GCC can generate x86 code, but even the most basic runtime support is different than Posix based OSes.

well, while you can use cross compiler to produce win32/64 binary codes from GCC, someone has to port all the C runtime libraries across though. Both Mingw and Cygwin are created for this purpose.

From MinGW's main site
Offered in easily installed binary package format, for native deployment on MS-Windows, or user-built from source, for cross-hosted use on Unix or GNU/Linux, the suite exploits Microsoft's standard system DLLs to provide the C-Runtime and Windows API.

Related

What is the appropriate Unix-POSIX based tool chain to use in Windows

Let's say I have retrieved some C/C++ original and unmodified distribution libraries that were specifically designed for the Unix-POSIX based environments where the original developers who designed their code wrote them specifically for their environments - systems and these libraries originally are not portable to modern Windows systems.
What I would like to be able to do is to at the least build the needed static or dynamic libraries to be able to link them against my own Visual Studio projects.
I know that with Mingw(clang) you only need the MSVC run-time libraries as it doesn't have any need of the POSIX dll dependencies as it uses the Win32 libraries directly. However, it doesn't have all of the Unix environment features that Cygwin(gcc/g++) does and for any C/C++ code that relies on native POSIX functionality such as fork(), mmap(), etc. would have to be re-implemented into the Win32 equivalents for proper compilation, linking, and running of the application.
With Cygwin I'm more exposed to nearly all of the Unix-POSIX features with a little higher learning curve and to integrate these libraries that are built by Cygwin's compiler(s), they would rely on cygwin1.dll to be able to run on a Windows machine.
A Primary Example:
The current libraries that I'm trying to build to work with Visual Studio are GNU's: GMP, MPIR, MPFR, MPFRC++.
So far I have successfully been able to build MPIR in Visual Studio 2017 with the aid of Python and Windows version of Yasm. However, when trying to build MPFR it requires the dependency of GMP. So now I have to build GMP.
I could use Mingw to build GMP which may be in some ways a little easier, but by using Gygwin and building GMP through the Unix/Linux/POSIX environment I would be exposing myself to the functionality of Unix/POSIX systems.
Note - I'm primarily familiar with Windows environments and until recently have never worked with or on any Unix based OS. So there is a bit of a learning curve for me. I'm doing all the research and reading that I can on my own which is not a problem. It provides good experience with every bit of trial and error.
What I would like to know is when working on a Windows machine; what would be the preferable method between the two case scenarios to build POSIX designed libraries to be able to link properly into MSVC Window's based applications? Another words, I would like to efficiently convert POSIX specific libraries to be able to work on my current platform or machine. Notice that I did not say that I wanted to "rewrite" the libraries to make them portable to any arbitrary environment. In this specific case I only need them to run on my Windows environment. Or any other appropriate method. I will be using some C and some C++ libraries to be linked into my MSVC c++17 project(s). (I may also have some of the terminology wrong in some of my above statements or assumptions as I'm not familiar with Unix-POSIX environments).

How does the same source code generate binaries for different platforms?

Many multi-platform applications seem to have common source code. How do builds generate platform specific binaries?
Is it possible to build say, a windows binary on linux or mac?
It's possible if you have an appropriate cross-compiler and libraries. For example, many programs which are available on both Linux and Windows use the MinGW toolchain on Windows, which includes a library that emulates POSIX functions using Win32 functions.
The platform a binary is compiled to run on depends on the compiler and generally, one can have the compiler compile for a target system. To that end, yes it is generally possible to compile for a system other than the one you are running on. Though you are usually better off compiling for a target system on that system.

Which programming languages that can generate self contained windows .exes?

I want to make an easy to deploy Windows application and was was wondering which programming systems can create totally self contained Windows .exe files?
As a plus, if the same can be done with MacOSX and Linux from the same source this would be a bonus. I took a look at Realbasic but they have since abandoned the single .exe concept.
update: i am looking for something that can run from Windows XP up to Windows 7, no matter what version of .NET is installed. Is this even possible?
Delphi compiles to one executable, and generates native windows executables. So no dependencies to any kind of framework. If you use Free Pascal (fpc) and the Lazarus IDE, you could even develop for Linux and Apple from the same source.
If your using external dll's this would become a bit more tricky, but you could pack them up in your resource file and still maintain the one exe property.
Update 2020: since #Vassilis & #Marco van der Voort commented on this, I would like to update my old andswer and add that go is a very good way to make self-contained executables. Even crossplatform compilation is realy simple.
You can certainly do this with C/C++. Technically the runtime libraries are required, but they should already be installed on any windows, mac or linux system.
With .NET you can compile to an EXE, but of course the .NET framework is required. For newer versions of windows it should be installed by default, but on older versions (XP or older?) it may or may not be there. And of course you couldn't expect mono to be there by default on linux or mac either.
For Windows the following languages are viable:
C (MS, gcc)
C++ (MS, g++, Digital Mars)
D (Digital Mars)
Delphi (Embarcadero??? how do you spell that? just trips off the tongue doesn't it?)
Fortran (Intel, Salford Software)
Visual Basic 6 (MS)
Lua (you'll need a special tool to do it, but it is doable)
C#, VB.Net, F#, J#, etc (assuming that you don't mind using .Net technology)
You can use Tcl/tk. The technology you should research is a "starpack", which combines a runtime executable (a starkit) with a platform-specific runtime (a "tclkit") to create a single-file executable. It's remarkable in the fact that it's not just compiled code, but an entire self-contained virtual filesystem that can include images, sound, data, etc.
This same technology works for many platforms from the same code base. The only thing that is different is the platform-specific runtime. You can even "cross compile" in that you can copy the runtime for multiple platforms onto your dev box and then build starpacks for each platform without having to actually be on each platform.
Tcl can do this, especially through producing starpacks. They can be produced for all platforms from the same code. Note that this also includes all the necessary runtime libraries (except for things like the C library, but you don't want to make that static under normal circumstances).
JavaFX 2.2 supports that. It allows creation of self-contained applications targeting Windows, Mac OS, and Linux.
Please follow this link for more information: http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm.
I would recommend taking a look at AutoIt. It is an easy-to-use scripting language that will compile into an exe, so there are no runtimes needed. This would be for windows only though.
http://www.autoitscript.com/autoit3/index.shtml
From the website:
AutoIt v3 is a freeware BASIC-like
scripting language designed for
automating the Windows GUI and general
scripting. ... AutoIt is also very small,
self-contained and will run on all
versions of Windows out-of-the-box
with no annoying "runtimes" required!
c/c++
purebasic
delphi
vb6
i hope this help :)
Here's a good source for a number of basic-like programming languages that build small stand-alone EXEs. Some are cross-platform for Windows and Linux:
www.basic.mindteq.com
You can use Liberty Basic which is easy and cheap, you can easily make stand alone programs for windows but not possible to transfer to MacOS or Linux.
You can do this for Windows with .NET languages using ILMerge
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly. It works on executables and DLLs alike and comes with several options for controlling the processing and format of the output. See the accompanying documentation for details.
However:
Currently, ILMerge works only on Windows-based platforms. It does not yet support Rotor or Mono.
QBasic can :-)
I wrote a few command line tools using it!

Is there any material about makefile in Windows?

Is there any difference between makefile in Windows and Linux?
If I know how to use it in Linux, is it necessary to learn
something new when in Windows system?
The fine folks over at GnuWin32 have Gnu make built for Windows as a native binary. It works well, but does have a few minor quirks due to a well-intentioned hack that tries to equate a target named foo with the file foo.exe. The GnuWin32 package does include a nice PDF of the manual, IIRC.
I use it on XP alongside GCC from the MinGW project, as well as with several different embedded systems cross compiler toolchains. MinGW also provides a native build of Gnu Make.
We do use Cygwin for a couple of projects, in particular one where the system-on-a-chip vendor provided a complete, working toolchain and build environment hosted in Cygwin. Moving it to a native Windows shaped build would be prohibitively expensive, and would make it harder to accept updates from the vendor.
If you want to use mostly native Windows tools, but need to start by running configure on an existing source kit, then take a look at MSYS. This started as a fork of Cygwin by the MinGW developers, and it intends to provide a minimal set of unix-like tools with a bash shell so that configure can be used on Windows. It isn't as complete as Cygwin, but it is a lot lighter weight.
You will find that the manual for Gnu Make is mostly true. However, you have to keep in mind that the content of a Makefile is not written in a single language. The stuff that defines variables and lays out the dependancy tree is one language. Each line of an action is a miniature shell script that is in the language of the default shell (which might be CMD.EXE rather than /bin/sh on Windows), and each command has options and arguments.
If you are comfortable with your *nix build environment, then Cygwin might be the path of least pain. But MSYS is often sufficient, and there is something to be said for adopting the native tools of the target platform so that you have a sense of how your users see Windows, in which case MinGW and GnuWin32 are handy resources to know about.
In addition to what iftrue note that Microsoft has a Makefile based build tool called nmake with some changes in syntax/semantics from the traditional *nix based make tool. This page lists some of the differences.
Well, if you download "cygwin", you can run the "make" tool directly on windows, but you may want to look into a true cross-platform build tool such as "cmake". It's like make, but it's a bit more spiffy and is inherently cross-platform.

What is the difference between Cygwin and 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.
What is 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. Cygwin is also bundled with a port of the GNU Compiler Collection and some other tools to the Cygwin environment.
If you have existing source code that uses POSIX 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.
Disadvantages of Cygwin
Compiling with Cygwin involves linking your program with the Cygwin run-time environment, which will typically be distributed with your program as the dynamically linked library cygwin1.dll. This library is open source and requires software using it to share a compatible open source license, even if you distribute the dll separately, because the header files and interface are included. This therefore imposes some restrictions on how you can license your code.
What is MinGW?
MinGW is a distribution of the GNU compiler tools for native Windows, including the GNU Compiler Collection, GNU Binutils and GNU Debugger. Also included are header files and libraries allowing development of native Windows applications. This therefore will act as an open source alternative to the Microsoft Visual C++ suite.
It may be possible to use MinGW to compile something that was originally intended for compiling with Microsoft Visual C++ with relatively minor modifications.
By default, code compiled in MinGW's GCC will compile to a native Windows 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.
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.
Disadvantages of MinGW
Software compiled for Windows using MinGW has to use Windows' own API for file and IO access. If you are porting a Unix/Linux application to Windows this may mean significant alteration to the code because the POSIX type API can no longer be used.
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.
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:
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.
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.
Other answers already hit the target. I just want to add an illustration for a quick catch.
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.
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.
To use Cygwin in a non-free / proprietary / closed-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.
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).
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.
MinGW (or MinGW-w64) Cygwin
-------------------- ------
Your program written Your program written
for Unix and GNU/Linux for Unix and GNU/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
Cygwin uses a compatibility layer, while MinGW is native. That is one of the main differences.
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.

Resources