Submitted by 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.
You win some, you lose some. Support for Windows 7 and Windows Server 2008R2 was added, but you’re unlucky if you’re still running Windows 95, 98, or Me. Then again, if you’re still running any of those three, you deserve to be unlucky. Or you got bored with self-deprecation, and moved beyond it.
Of course, this release brings more than changes in platform support. For instance, the mount table is no longer stored in the registry, but has been moved to /etc/fstab and /etc/fstab.d/$USER instead. The support for pathnames has been extended beyond the old 260 characters border. Cygwin now supports up to 4096 characters, but it will try to support even more characters, up to the Windows maximum of 32767 Unicode characters.
You can now have multiple installations of Cygwin, but you’ll have to keep them isolated. IPv6 support has also been added to the mix, and internationalisation support has been improved, and the default character set has been set to UTF-8.
The list of improvements goes on for a while, so be sure to check if your pet bug has been fixed. You can download the new release from their website, but note that if you’re upgrading from a 1.5.x release, you’ll have to do some manual labour to accommodate for the mount table changes: every user has to run /bin/copy-user-registry-fstab once after the update.
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
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.
A lot of people would consider that a disadvantage.
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.
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++.
C is hardly a legacy language on Windows; the Windows API is still all C.
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++.
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
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
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.)
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.
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?
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
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.
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.
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.
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^A'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!
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.
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.
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.
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.