From: Brian D. <br...@de...> - 2007-09-23 01:53:55
|
Suresh Govindachar wrote: > A recent post has the line: > > > I never planned to make an MSYS build of man; > > I always planned to distribute it as a native app. > > What is a "MSYS application"? I have never really used > MSYS -- I used to think that any window's cmd application > would run in rxvt and that any application buit from the > rxvt command line would run in the Window's cmd shell. Okay, you seem to be confusing several unrelated concepts. Firstly: a MSYS application is one that uses (links with) the the MSYS runtime (msys-1.0.dll), just like a Cygwin application is one that links to the Cygwin runtime (cygwin1.dll), and a MinGW application is one that links to the native system runtime (msvcrt.dll). Here the "runtime" means the library that implements the basic C library and related support functions. The C library (libc) is a rather low-level thing and so it is not like a regular library in the sense the runtime you pick determines a number of characteristics of the application. In particular, apps using the MinGW runtime get exactly what Windows provides and nothing more. This means that there is no support for most POSIX functions such as fork or select on fds (and so on.) Thus applications built to use the MinGW runtime must be ported to Win32, meaning their source must be modified so that they don't use these POSIX APIs that aren't on native Windows. This porting is a large undertaking and for some applications it is much easier to take a different tack -- to use a runtime that provides implementations of these POSIX APIs so that the source can be compiled unmodified. This is the main goal of Cygwin, to allow any Linux/POSIX app to be build without any source changes (or with trivial build tweaks.) However, there is the fact that building a Cygwin app means it's dependant on the Cygwin runtime DLL and is not a stand-alone binary. (And a whole slew of other issues that aren't really germane to this discussion.) MSYS is also a runtime that provides POSIX emulation. In fact it's just an old copy of Cygwin (from the 1.3 days) that has been forked and modified in certain ways. Specifically, the mount table is moved out of the registry and into a file (/etc/fstab) and code has been added to convert POSIX-filename arguments like /usr/local/foo to Win32-filenames like c:/path/to/foo when invoking native Win32 apps. The whole goal of this is to allow building POSIX build tools like bash, m4, sed, autoconf, perl, etc. which would be hard or impossible to port to Win32 natively. The combination of these tools can be used to run POSIX configure scripts to drive the build process of POSIX software that uses autoconf/libtool/automake/etc. However, the key here is that this MSYS environment is just a driver for native Win32 tools such as the MinGW gcc which produces MinGW binaries. It is very rare and uncommon to actually use MSYS to build MSYS apps, and in fact to do this you have to install a special environment and use a specially modified copy of gcc -- currently a very old 2.95 version. Now, you mentioned cmd and rxvt. Those are totally unrelated to the above discussion; it's just that the MSYS default is rxvt, but you can just as well use a native command prompt (and in fact it's recommended due to pty emulation issues.) More specifically, it's helpful to think in terms of a *shell* and a *terminal*. A shell is what interprets commands, a terminal is what displays things. These are two different things -- you can use a shell without a terminal at all, such as when you run a script with output redirected. And you can use a terminal without a shell, such as the case when you directly invoke a program binary and it outputs to stdout. Windows' cmd.exe is a shell. MSYS' bash.exe is a shell. rxvt is a terminal. The native windows "command prompt" is a terminal. In other words, you can mix and match these in any combination: you could be using the bash shell under rxvt, you could be using the bash shell under a native command prompt. Or you could be using the cmd.exe shell under the native command prompt. You could in theory use the cmd.exe shell under rxvt but this probably doesn't work because of the pty emulation issue, but that's an implementation detail and doesn't change the fundamental separation between shell and terminal. Brian |