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.
Order by: Score:
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 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 Score: 3

phoenix Member since:
2005-07-11

* much closer to Linux


A lot of people would consider that a disadvantage. ;)

Reply Score: 2

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 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 Score: 2

moondevil Member since:
2005-07-08

That is only because on Windows, C is seen as legacy language, and Microsoft has decided to focus its development effort on C++ instead.

Granted, this is typical Microsoft only caring about its own stuff, but in many IT shops, C is only used when it is not possible to use C++.

Reply Score: 1

computeruser Member since:
2009-07-21

C is hardly a legacy language on Windows; the Windows API is still all C.

Reply Score: 1

moondevil Member since:
2005-07-08

Since Vista, most of the new APIs are actually COM based.

Which although you can use from C, there is only proper compiler support when compiling from C++.

Reply Score: 1

gilboa Member since:
2005-07-06

True, but MS is trying to push users into using C# instead of C/C++.
In the long run, I would imagine that MS will try to kill the C Win32I (and NT) APIs and drop support for "legacy" C/C++ applications.

- Gilboa

Reply 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 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 Score: 1

computeruser Member since:
2009-07-21

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...

I don't think it's fair to say one is superior to the other; the projects have different goals and shouldn't be compared in this way. MinGW is primarily a port of GCC and related tools to Windows, and .NET support has no place here (as GCC doesn't support .NET either.) The Mono project provides open source .NET, and Mono runs on Windows.

MinGW only provides the ability to compile Windows API programs. Good programs should compile on any Win32 compiler that supports the same language (of course, this might exclude MS's own compiler in the case where MS's compiler is insufficient - for example, C99 support.)

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.

GCC shouldn't be anything more than one of many compilers people can choose on Windows. If a program requires GCC to compile, perhaps the program is doing something nonstandard.

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???

The decision shouldn't be difficult to make. Are you writing UNIX software? Are you writing Windows software? Are you writing software that only targets standard C/C++/some other library that supports both Windows and UNIX?

Reply Score: 1

nimble Member since:
2005-07-06

Should MinGW focus on MS's UNIX subsystem???

No, because MinGW stands for Minimalist GNU for Windows, and SUA is not a core part of Windows. Also, SUA already has a gcc port anyway.

Edited 2009-12-24 09:30 UTC

Reply Score: 2

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 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 Score: 2

Cygwin ports
by fithisux on Thu 24th Dec 2009 07:14 UTC
fithisux
Member since:
2006-01-22

are difficult and error prone to download. Someone on Cygwin must take some care on it. The cygwin installer takes pathetically a lot of time parsing ports tree and downloads crash.

Reply Score: 1

RE: Cygwin ports
by samad on Thu 24th Dec 2009 18:58 UTC in reply to "Cygwin ports"
samad Member since:
2006-03-31

The default mirror is usually painfully slow, but when I switched to a better mirror for my location, it is extremely fast (~1.7MB/s). Have you tried looking at different mirrors? mirrors.kernel.org is pretty good if you're in the US. If you're in France, usually any mirror with an *.fr domain is good.

Reply Score: 2

Supporting several installations
by Claxus on Thu 24th Dec 2009 09:54 UTC
Claxus
Member since:
2007-07-19

Supporting several installations on the same computer is a great feature that has been on the wish-list for long.
Companies that deliver their product with a build system, that should work on Solaris, Windows and Linux has been able to use Cygwin for this. But when releasing the next version, there has been strange conflicts between the new and the old Cygwin installation.

I havenĀ“t been able to test it yet, but perhaps the new release is also faster. There has been a significant difference in speed compiling with a makefile on Linux and on Windows/Cygwin.

Thanks for the new release anyway!

Reply Score: 1

Cygwin is immensely useful
by samad on Thu 24th Dec 2009 19:04 UTC
samad
Member since:
2006-03-31

For any of you who are stuck on using Windows and wish to use Unix for development, Cygwin with puttycyg for terminal emulation is a godsend. I love using vim + screen for Java development. It does, though, have some problems, such as:
* GNU screen is buggy
* having to convert paths from Cygwin to Windows when using Windows programs; this is what makes running Java with Cygwin cumbersome

I would argue that puttycyg is much better than OS X's Terminal.app since it's much faster and supports proper full screen support that works great with dual monitors.

Reply Score: 2

RE: Cygwin is immensely useful
by nimble on Thu 24th Dec 2009 19:13 UTC in reply to "Cygwin is immensely useful"
nimble Member since:
2005-07-06

Have a look at mintty as well, which is a Cygwin-only terminal based on PuTTY's terminal emulation. Available through setup.exe (under 'Shells') or from http://mintty.googlecode.com. Among other features, it's got improved xterm compatibility; perhaps that'll help with screen.

Reply Score: 2

RE[2]: Cygwin is immensely useful
by suryad on Fri 25th Dec 2009 03:07 UTC in reply to "RE: Cygwin is immensely useful"
suryad Member since:
2005-07-09

Thanks for that link. Dead useful. Didnt realize cygwin had such a cool feature like that. Copy and paste! Awesome! I still dont understand why Windows does not do something like that out of the box...and also why there are no tabbed command prompts like Secure CRT does.

Reply Score: 2

Cygwin, perl, cpan and path names with spaces
by reez on Sat 26th Dec 2009 15:08 UTC
reez
Member since:
2006-06-28

What is the state with cygwin, perl, cpan and path names with spaces?

When I tried CPAN on cygwin the last time I ran into problems, because there are problems handling file names with spaces (C:\Documents and Settings\$User).

Maybe it is more a perl/cpan problem, but on the other hand it seems to be the only environment where there are these stupid spaces.

I know there are some ways to work around this, but the problem still exists and it isn't really nice, if one has to use some kind of hack to be able to use a tool which comes with an official release.

Anyway it's always nice if you have *nix/Linux stuff available on Windows.

Reply Score: 1