Detailed view of a page, which is probably more useful for debugging than anything else.
Querying backend directly for 'Shells, terminals and MSYS'
| get_pagedata('Shells, terminals and MSYS') | |
| _cached_html | TransformedText Object
(
[_type] => PageType_wikitext Object
(
)
[_basepage] => Shells, terminals and MSYS
[_content] => Array
(
[0] => <div class="wikitext"><p class="tightenable top">What is an MSYS Application?</p>
<blockquote class="tightenable"><p class="tightenable top bottom">(This is a lightly edited description by Brian Dessent, extracted
from a mailing list discussion at 09/23/2007 and thereabouts.)</p>
</blockquote>
<p class="tightenable">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.</p>
<p class="tightenable">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.</p>
<p class="tightenable">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.)</p>
<p class="tightenable">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.</p>
<p class="tightenable">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 CONSOLE (and in fact it's recommended
due to pty emulation issues.)</p>
<p class="tightenable">More specifically, it's helpful to think in terms of a <b>shell</b> and a
<b>terminal</b>. 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.</p>
<p class="tightenable">Windows' cmd.exe is a shell. MSYS' bash.exe is a shell. rxvt is a
terminal. The native windows "CONSOLE" 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 CONSOLE. Or you could be using the cmd.exe shell under
the native CONSOLE. 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.</p>
<p class="tightenable bottom">Brian</p>
</div>
)
[_description] => 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.
)
|
| hits | 10653 |
| get_versiondata('Shells, terminals and MSYS',2) | |
| %content | What is an MSYS Application? (This is ... |
| author | SureshGovindachar |
| author_id | SureshGovindachar |
| is_minor_edit | false |
| markup | 2 |
| mtime | 1192897215 |
| pagetype | wikitext |
| get_backlinks('Shells, terminals and MSYS') | |
| 0 | MSYSArray |
| 1 | BuildMSYSApplicationArray |
| 2 | FAQArray |


