Linked by Thom Holwerda on Wed 23rd Dec 2009 23:49 UTC, submitted by diegocg
Linux After two long years since the last release, Cygwin 1.7 (a Linux-like environment that runs on Windows systems) has been released. Among many other improvement, this release adds support for Windows 7 and Server 2008R2.
Thread beginning with comment 400863
To read all comments associated with this story, please click here.
mingw/cygwin ... 2010 and beyond?
by kad77 on Thu 24th Dec 2009 01:11 UTC
kad77
Member since:
2007-03-20

What are the chances of MinGW and Cygwin ever merging?

While I mostly (95% for years) use MinGW for cross-porting to windows, because I like the "true" native binary without external dependencies; MSYS/MinGW seems to be a herculean effort mostly on the backs of very few people. Getting DirectX and other headers/libs is very DIY/scattered...

But *everything* works, eventually. I commonly can get cygwin ports, or just unported linux apps to compile with a few hours work (CLI, of course). But porting SDL apps is trivial.

At this point, "unofficial" gcc mingw compilers are coming out many months ahead of regular official releases, and Cygwin releases are years behind mingw (look at the gcc 4.x series).

I know MSYS/MinGW has somewhat of a different philosophy (I welcome different takes on this) than the Cygwin project, but it seems that so few talented people are able to do this level of largely non-compensated work, that it would make the most sense to pool their efforts.

In my mind it seems to be an OpenBSD vs FreeBSD type situation (to use a rough O/S analogy)...

Can anyone else share there insights/experiences with Cygwin vs MinGW, and where we can expect GCC on windows to go in the future?

I would love to have more insight into the development differences, and whether I should finally switch away from non-official MinGW builds + CodeBlocks to the larger and slower moving (?, imo) Cygwin project??

Thanks for this post!

Edited 2009-12-24 01:14 UTC

Reply Score: 3

kaiwai Member since:
2005-07-06

What are the chances of MinGW and Cygwin ever merging?


I think the more important question; do MinGW and Cygwin have a place when one considers on one hand there is the UNIX Subsystem for Windows/Services for UNIX then on the other hand there is virtualisation which is getting to the stage where it can be a drop in solution for having integrated subsystem in the operating system itself.

Reply Parent Score: 1

Bill Shooter of Bul Member since:
2006-07-14

Oh, absolutely they have a place!

It has the following advantages over UNIX Subsystem for Windows

* much easier and faster to install
* much closer to Linux
* more software available

Vs virtualization

* much easier and faster to install
* faster to enter the environment
* less resource usage( memory/ cpu/disk)
* integrates better into host

But what do I know, I've only been using it for eleven years.

Reply Parent Score: 3

ba1l Member since:
2007-09-08

I think the more important question; do MinGW and Cygwin have a place when one considers on one hand there is the UNIX Subsystem for Windows/Services for UNIX then on the other hand there is virtualisation which is getting to the stage where it can be a drop in solution for having integrated subsystem in the operating system itself.


SFU is not an appropriate solution.

First, it is not included and installed by default on any shipping version of Windows, and never has been. Current Windows Server versions (may) include it, but it's not installed by default.

Second, it doesn't work on all versions of Windows. It's completely unavailable on the "Home" versions of Windows XP, Vista, and 7. The only people who could install SFU are businesses, individuals who actually bought a copy of XP Pro or Vista / 7 Ultimate, and pirates. Everyone else it out of luck.

Third, the versions are tied to specific versions of Windows, and each version is markedly different. Notably, the only available version for Windows XP uses ancient versions of the compiler (either MSVC or GCC), and lacks lots of features that are present in Cygwin.

It's really intended for businesses that have Unix applications they want to run on Windows. That's all it really does, and because it's positioned as a business feature, it's only available in the business versions of Windows (and the I-have-more-money-than-sense versions).

Regardless, it's not a replacement for MinGW anyway. MinGW produces native Win32 binaries, which work without any runtime, on any version of Windows. Neither Cygwin or SFU do that.

As for virtualization... that might work, but it's still a much more heavyweight solution.

Reply Parent Score: 3

computeruser Member since:
2009-07-21

MinGW provides an alternate compiler to Microsoft's own for compiling Win32 applications. This makes it possible to compile programs that rely on non-standard GCC extensions, for example, but MinGW doesn't provide any APIs other than Win32. Also, Microsoft seems to focus on C++ more than C, so those wanting to use C99 have to use a compiler other than Microsoft's - and GCC/MinGW happens to support C99.

Subsystem for UNIX-based applications also includes GCC.

Reply Parent Score: 2

computeruser Member since:
2009-07-21

The distinction is rather simple... MinGW provides GCC to compile native Win32 applications. Cygwin provides a Unixlike environment on top of Windows, including an implementation of a Unixlike API, and also uses GCC as its compiler.

Reply Parent Score: 1

kad77 Member since:
2007-03-20

The distinction is rather simple... MinGW provides GCC to compile native Win32 applications. Cygwin provides a Unixlike environment on top of Windows, including an implementation of a Unixlike API, and also uses GCC as its compiler.


Yes, this is the basic understanding I've been operating under... but in regards to the differences, I see MinGW as more of a ReactOS/OpenBSD reverse engineering, co-mingling effort, whereas Cygwin perhaps takes an understanding (to what extent, I don't know) of Win APIs and tries to write a layer over an interface...

I guess philosophically I've always found MinGW to be superior, but they seem to have stalled out on Win32, and don't seem to have a coherent or discernible (help!) plan for .NET / Win64 / wow / etc...

Where do the two projects have advantages moving forward? MinGW always has the latest GCC, unofficial or not, where Cygwin has greater compatibility at the expense of "being older than CentOS"/dirt

Do we just rely on Win32 being around due to legacy forever, and stick with MinGW? I haven't been able to do x64 apps forever, and hardly could care for the most part as memory is adequate.. for now..

Will MinGW just creep along until Ernie moves on?

For windows being a huge platform, GCC seems hardly relevant at times. I thought with all the alt OSes, and linux trudging along in popularity and needing to gain wider app support, there would be keener interest in GCC on windows than I've seen over the years.

I see no compelling reason to hitch my wagon to the plodding pace of Cygwin, when MinGW covers my porting needs/interests year after year adequately... Should they converge? Should MinGW focus on MS's UNIX subsystem???

EDIT: thx, ba1l .. posted this at same time as you answered many of the Qs in it!.. ;-)

Edited 2009-12-24 04:36 UTC

Reply Parent Score: 1

nimble Member since:
2005-07-06

What are the chances of MinGW and Cygwin ever merging?


Cygwin ships with a MinGW compiler. With gcc-3, you need to provide the option -mno-cygwin to create native executables.

For gcc-4, there'll be a separate MinGW cross compiler package, which unfortunately isn't quite ready yet.


MSYS/MinGW seems to be a herculean effort mostly on the backs of very few people.


Much the same for Cygwin. One Redhat employee and a small number of dedicated volunteers.

Please also note that MSYS is in fact a fork of Cygwin 1.3.


But *everything* works, eventually.


For some definition of "eventually". Afaik, there is no native version of bash. The MSYS bash depends on the MSYS (nee Cygwin) DLL.


I commonly can get cygwin ports, or just unported linux apps to compile with a few hours work (CLI, of course).


Yeah, but of course it greatly depends on how Unixy a program is. For example, if it uses the likes of fork, select, or ptys in non-trivial ways, you've got a substantial redesign on your hands. Also, it's not just a one-off effort as the upstream program continues to evolve.

Horses for courses.


At this point, "unofficial" gcc mingw compilers are coming out many months ahead of regular official releases, and Cygwin releases are years behind mingw (look at the gcc 4.x series).


Cygwin 1.7 ships with gcc-4.3.4 as default. gcc-4.5 is in the works, as is the MinGW cross-compiler.

Reply Parent Score: 2

cgf0 Member since:
2009-12-24

There is pretty much zero chance that the two projects will merge. Their fundamental goals differ.

Cygwin wants to provide a UNIX-like environment.

MinGW just wants to provide a method to build programs for Windows.

The only overlap is that both projects work on Windows.

Reply Parent Score: 2