Username or EmailPassword
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
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
* 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.
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.
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.
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´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.