OSNews

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.

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.

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.

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.

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

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.




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.




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




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.




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

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.