If you were just reading the section above, then continuing on, GnuWin32 and the now defunct GNU Utilities for Windows seem to do precisely that. True autotools, make and shell script functions have been ported as native win32 applications, but since they are only used as temporary tools to get to the finished product (a natively compiled win32 application) and the results don't depend on any of those temporary tools, why go through the effort of duplicating what Cygwin has already done so nicely?
#Mingw msys code#
However there is a huge chunk of open source code that is compiled using autotools and depending on shell scripting, which I think is where MSYS gets involved. In Cygwin you will find Python, GTK, nano, Ruby, Git, even some games I think, whereas in MinGW you will only find libraries most often used in common code. What that translates to is that MinGW and MSYS contain only the most essential tools required for developing native applications for Windows using the GNU open source suite of compilers, whereas Cygwin aims to provide Windows users every application available to Linux. MSYS is presumably part of MinGW, which stands for Minimalist GNU for Windows. The difference is really in a state of mind. It's true that if you compile an application using the MSYS version of gcc, then you will need to link it to the msys-1.0.dll, so in a sense it is the same as Cygwin. MSYS MSYS may seem like a variation on Cygwin, except it is really meant to be used as an environment for running shell scripts, similar to bash (the Bourne Again SHell). Now it might be fun to speculate about some internal strife or a passionate drive of a group of individuals with some bold ideal, but that's irrelevant to this fundamental difference between the Cygwin and MinGW. This means exactly what it sounds like, applications compiled using MinGW's compilers (gcc, g++, gfortran, etc.) will run on any Windows machine natively without any runtime other than the Windows API or mscvrt.
MinGW creates native applications for Windows using native libraries. The essential thing to realize here is this. I don't know if this is actually true, but that is what I've heard. The probable downside of using this layer between the Windows API and your application may be potentially slower speed and some limits in its features.įrom Cygwin was born MinGW. The Windows binary of GNU nano is an example of an application compiled using Cygwin that requires cygwin.dll to run. By native here I mean that it runs on one of the windows runtimes like the win32api or msvcrt. True, you could distribute the cygwin.dll with your application, so it would appear to be native, but it wouldn't be truly native. So essentially, when you use Cygwin you are more or less stuck in Cygwin. What this means in practice is that Cygwin applications use the cygwin.dll, a common runtime that must be linked to any applications that run on Cygwin, and consequently any applicaton compiled with Cygwin gcc. Their tagline is "Get that Linux feeling - on Windows!" This does a lot to explain exactly what Cygwin is, Linux emulated on Windows. So instead of getting angry with me, perhaps post a comment and disabuse me of my still as yet incomplete knowledge. In that case I apologize, and please remember that the purpose of this blog is purely selfish it is a note to myself to remind me of what took me so long to finally understand. I hope that I do not offend anyone, but I am sure that I inevitably will, as much of my opinion is based on hearsay. What was just said and what I am about to say is entirely opinion and not based on fact. Not really, but sordid sounds so much more interesting than complicated. So here's how I understand it, without any emotion, this is really just a navigational exercise.
0 kommentar(er)
