Linked by Thom Holwerda on Tue 9th Aug 2005 17:47 UTC
Thread beginning with comment 16062
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
More News »
Sponsored Links



Member since:
2005-07-06
MinGW and Cygwin serve different purposes. MinGW brings you a UNIX command shell and tools for development of normal Windows EXEs. The EXEs produced by MinGW are designed to be stand-alone so that a consumer of the EXE need not have MinGW installed. Basically, this gives you access to the free gcc-family of compilers and tools allowing you to build standard Windows apps without a Microsoft (or other commercial) compiler. It uses all the usual Windows header files and such and is not designed to build standard POSIX code without some modifications as you'd have to port it just like you would if you were using Visual Studio (for example) instead of MinGW.
Cygwin, on the other hand, tries to not just bring a UNIX shell and tools to the Windows world, but also brings along a complete UNIX compatibility layer. The idea is that most any POSIX code can be compiled for Windows within the Cygwin environment unchanged. This is because Cygwin includes a lot of functionality in some DLLs that the EXEs depend upon; meaning that the EXEs you get out of Cygwin usually will require that the user has one or more Cygwin DLLs installed on their system (plus, some programs won't run properly unless certain Cygwin registry settings are present which means that you can't necessarily just distribute your app with the proper DLLs to end-users without dealing with that). It makes porting very east (often just a ./configure; make) but at the loss of a truly native stand-alone end result.