On 23 Sep 2002 at 10:29, Soren A wrote:
> "Paul G." <pgarceau@...> wrote in
> > Ok, so if I see MSYS_..., it is MSYS runtime we are talking
> > about. If it is MINGW32_..., it is Mingw runtime we are talking
> > about.
> Yes, exactly.
> And very few things need to run with that MSYS runtime; only a few
> special tools that Earnie et al are finding cannot be made to port
> cleanly to standard (that's msvcrt-based) MinGW. AFAIK it was never the
> intention of MSYS to become what Cygwin is, a full-time intermediary
> layer to sit over the basic API of the Windows 32-bit OS's and allow
> many *nix applications to "think" they are running on some kind of real
> *nix. As I understand it, MSYS is more like the temporary construction
> scaffolding that you'll see erected at big building sites. Or like
> temporary structural support bracing. It gives access for certain tools
> or holds things up while the building is being put up but then is
> UWIN is another thing that is what Cygwin is (and MSYS is not). Given that
> there are these very capable things out there already (and although I have
> not had a chance to play with UWIN yet, I think it can be assumed that it
> is VERY capably accomplished because it is written by David Korn of the
> Korn shell: a very skilled programmer). A very basic precept of Open-Source
> hacking is "do not re-invent the wheel". If these several projects (UWIN,
> Cygwin) are already occupying that particular niche, why (IMHO) try to
> develop MSYS into YAWPO (Yet Another Windows-32 Posix-Overlayer)? I got the
> sense from your words previously that you were envisioning things that way.
I was confused about what msys is today (Snapshot 1.0.8) vs. what it was initially
intended to be. Initially, I had been under the impression that the primary purpose of MSYS
was to facilitate building mingw32 runtime linked apps/pkgs which could use the existing
Unix tools (during build time) without forcing the extreme, and infamous, unix/posix overhead
of any environment such as Cygwin and, subsequently, Uwin. It was that overhead that got
me started in the direction of Mingw32.
Essentially, I started with Cygwin (r17 or so) and moved through "egcs" to Mingw32
once I started seeing a major increase in the amount of time it took to port something for
Cygwin. The largest part of that porting time was spent waiting for Cygwin to complete the
compiles and the linking. Mingw32 offered an alternative, which very quickly showed itself to
be more efficient and effective in terms of my porting needs.
Intially, then, my sense of Msys was that it was to be a Minimal "Cygwin". By
Minimal, I mean "Cygwin, with all its neat tools" minus the overhead. That also, at least for
me, defines what Mingw32 can and, with the advent, the conception of Msys, _is_ evolving
in to ("becoming"). Growing pains are to be expected.
> >> The developers of MinGW can call/describe/label it whatever they
> >> want to, and the only thing that really matters from a practical
> >> perspective is that all the parties concerned agree on (and
> >> sufficiently possess) a common (shared) understa(nding)...
> > Ok. It is that which is what I am trying to establish here, a
> > common (shared) understanding...
> > Thank you, Soren for your time on this.
> You are very welcome ;-).