On 8/3/05, Greg Chicares <chicares@...> wrote:
> On 2005-8-2 23:22 UTC, Jonathan Turkanis wrote:
> > Cygwin and MinGW represent very different approaches to porting the GNU=
> > Windows.
> Let's talk first about MinGW versus MSYS.
> MinGW proper, as I understand it, is only a port of gcc and binutils,
> along with a set of public-domain msw headers and gcc import libraries to
> support msw system calls. As such, it isn't really very useful for portin=
> non-trivial gnu tools to msw. Its purpose is to let you use gcc to create
> msw-native binaries.
> MSYS adds to MinGW other capabilities that, before its advent, only cygwi=
> (or uwin) provided. Its main purpose, as I understand it, is to make
> ./configure && make
> work well enough to build many *nix packages (not just gnu packages)
> without further ado. To that end, it provides many of the command-line
> utilities, like rm and sed, that are customarily used in makefiles.
I like to use the following simple descriptions for someone new to GNU
MSYS is a tool to assist developers familiar to, or needing to use,
Unix tools. Any development done using MSYS could be done without it.
Cygwin is a platform on top of Windows, bringing it into conformance
with POSIX, and encouraging POSIX compliant code. This means that
end-users and developers are both running a new platform with
additional benefits and problems, and an additional layer of versions.
> Cygwin goes a step further by providing a posix runtime. You can build
> a shell with Cygwin. In MSYS, you can't do that 'normally', e.g., because
> a *nix shell uses fork() and exec(), which aren't built into msw. Of
> course, MSYS provides a shell, and I believe it's built in MSYS, but by
> a 'non-normal' procedure that depends on its own posix runtime. That's
> where the distinctions start to blur; perhaps we can say that Cygwin
> pretends it's *nix and 'encourages' you to write posix code, while MSYS's
> posix support exists mainly so that MSYS can bootstrap itself. Or maybe
> I've got this wrong, but if so, someone will correct me quickly here.
> Another blurry distinction: I've heard it said that Cygwin-built apps
> run slower because of the posix emulation, and that they are subject to
> the GPL because the posix emulator is GPL'd; I'm not sure whether those
> things were ever true, but I think they're not necessarily true now,
> because Cygwin, with the right switches, can avoid those issues and do
> exactly what a combination of MinGW and MSYS does.
Applications that depend on the Cygwin environment are free to use any
Windows API's so there is no technical limitation that would make them
slower. The only distinction that can be made wrt performance is that
where no Win32 equivalent exists, a port using MinGW must provide its
own native implementation, that may be faster than the generic layer
The licensing issue is a very important point when recommending
options to new users or students, because this means the commercial
viability of their knowledge of "Cygwin" is limited to companies that
are able to make money from GPL software.
non-GPL'd programs should be able to use Cygwin without falling under
the GPL by purchasing the "proprietary-use license for the Cygwin
library" , however the listed Redhat site to purchase this from is
no longer available. It may be that the commercial cygwin has been
incorporated into Redhat GNUpro .
> And it may be worth noting that these projects aren't nearly as distinct
> from each other as I believe both are from uwin. I think the msw headers
> for MinGW actually reside in cygwin's cvs, and MSYS's posix emulator is
> a fork of Cygwin's.
And to further muddy the water, it is possible to build using the
MinGW compiler, within the Cygwin environment .
> > Cygwin is an ambitious project to produce a Linux-like environment
> > hosted by Windows; a remarkable assortment of GNU utilities are availab=
> > part of the Cygwin distribution.
> Plenty of non-GNU utilities, too. MSYS has bash; Cygwin has bash, zsh,
> ash, and I forget what others, just as one example.
> > While one of the main goals of Cygwin is to
> > facilitate porting GNU applications to Windows, even if you are not UNI=
> > developer you may soon come to regard the Cygwin tools as indispensable=
> There I actually wouldn't agree. I've built much free GNU/Linux software
> using MSYS instead of Cygwin. That worked fine for libxml2-2.6.19 and
> gnu sed-4.0.7, for instance. Then again, maybe this depends on the
> definition of 'porting'. Much GNU/Linux software can be built on msw
> without changes (perhaps because it was already written with support for
> multiple platforms including msw) and doesn't require a posix runtime
> environment; MSYS suffices for this. For some other software, Cygwin's
> emulation would make things much simpler.
> > MinGW, which stands for "Minimalist GNU for Windows," is an attempt to =
> > minimal environment for porting GNU applications to Windows. While the =
> > Cygwin installation occupies several Gigabytes, the MinGW distribution =
> > relatively small.
> Yes, probably a few tens of megabytes if you download everything.
Notably Cygwin/X, the X windowing environment on top of Cygwin.
> > Among other things, MinGW includes a runtime environment, a
> > port of GCC, a port of the GNU archiver and linker - part of the GNU bi=
> > package - and a port of the GNU debugger, GDB. It also includes MSYS, a
> > command-line environment capable of executing GNU makefiles and configu=
> > scripts.
> I think of MSYS as a separate package, not part of MinGW. You can
> use MinGW without MSYS--I did for years, before MSYS existed; but
> I doubt anyone uses MSYS without MinGW.
> I'm not sure what you mean by "MinGW includes a runtime environment":
> do you mean bash, or perhaps the posix emulator underlying it? I'd
> consider those parts of MSYS instead.
> > MSYS provides the minimal environment necessary to run UNIX-style makef=
> > configure scripts on Windows. Among the useful tools it provides are aw=
> > cp, grep, ls, mkdir, mv, rm and sed. MSYS was designed to work with GCC=
, and it
> > does so beautifully; it has trouble with other Windows toolsets, howeve=
> > especially if they take command-line options beginning with a slash (/)=
> Certain msw conventions, like slash as an option prefix, or paths
> with embedded spaces, conflict with *nix conventions. Those conflicts
> are a problem with Cygwin as well as MSYS, but the last sentence above
> almost seems to imply that they're a worse problem for MSYS, which I
> don't think would be correct.
> Backslash-delimited paths are typical in the msw world, although as
> far as I know most msw programs except CMD.EXE and COMMAND.COM happily
> accept posix paths as command-line arguments. I have the impression
> that MSYS strives harder than Cygwin to accept paths like 'C:\foo\bar'.
Earnie and others have indicate that MS-DOS also handles POSIX paths
properly as well. I have only tried with CMD.EXE, and have found that
argument quoting is required to avoid the command shell from treating
the directory separator as an argument separator as well. e.g.
CMD> dir "C:/"