This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: MSYS mode (continue)
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin-developers at cygwin dot com
- Date: Thu, 25 Jul 2013 09:11:07 -0400
- Subject: Re: MSYS mode (continue)
- References: <20130704091632 dot GM5118 at calimero dot vinschen dot de> <CABEPuQKb8ZFvA=5947_JNQ3xZUNi98FTkV=9Q04f8vMY-4q1pg at mail dot gmail dot com> <20130704101046 dot GN5118 at calimero dot vinschen dot de> <CABEPuQJ2S5jUbJDS+XUhrvdLtu6t53QAvsmQ_q5RbvELZxHJhw at mail dot gmail dot com> <20130704103708 dot GA12995 at calimero dot vinschen dot de> <CABEPuQ+iF265-SQzfLTmsBegG+BVjpLPowxRAH8ioWv1Us_iYg at mail dot gmail dot com> <20130704121617 dot GC12995 at calimero dot vinschen dot de> <20130704163612 dot GA4729 at ednor dot casa dot cgf dot cx> <20130705090704 dot GB4009 at calimero dot vinschen dot de> <20130705164230 dot GA7282 at ednor dot casa dot cgf dot cx> <20130711111744 dot GG15346 at calimero dot vinschen dot de>
On 7/11/2013 7:17 AM, Corinna Vinschen wrote:
The hooking itself is the lesser problem. What I'm rather wondering
about is how the MSYS helper DLL comes into action.
Ideally, MSYS executables would actually be Cygwin executables, linked
against the Cygwin DLL. The advantage being that the executable could
run in an MSYS and a Cygwin environment, whatever it happens to be
dropped into.
>
The MSYS DLL could be loaded from an MSYS specific crt0.o, which tries
to load the MSYS DLL dynamically. Either loading the MSYS DLL works or
it doesn't, but if it works, it could just call cygwin_internal in it's
dll_entry function to set up the hooking mechanism. If it fails, the
executable works as a plain Cygwin executable.
I dunno. Back in 2009, I (re)built and updated to then-current EVERY
single element of MinGW.org's msys distribution. There were a LOT of
patches required, which were not required on cygwin.
Some, to be sure, were because both cygwin and the app in question had
progressed since the msys fork circa cygwin 1.3.x -- for instance,
OpenSSH. As cygwin itself gained new capabilities, the OpenSSH code
adapted -- eliminating certain workarounds it had previously implemented
which were no longer necessary on newer cygwin. However, as MSYS was
frozen in time, those workarounds had to be manually patched back in.
In the cygwin-as-msys scenario, *those* sorts of things would not be
necessary, because cygwin-as-msys would be just as "current" as regular
cygwin; in fact, sharing the same cygwin1.dll.
However, many of the patches were to handle differences inherent in the
environment. For example, msys-make kept the "allow X:/foo/bar paths in
rules" patch, which cgf long ago removed from cygwin-make. The reason
for that change is obvious; msys is intended to make compiling with
native mingw[64,.org] compilers easier, and so you run into dos-style
paths a lot more often, even when you are nominally on the "unix" side
of the fence as with (msys-)make.
Or, as an example, I suspect msys users would prefer a "native
windowing" tcl/tk -> gdb/insight, not the X11-windowing version we now
ship. However, we (cygwin) long ago made the decision that we would not
muck with our X11 tcl/tk's directory structure to accomodate a
side-by-side GDI version simultaneously installed. So "we" can't
actually provide both (one X11 that is probably preferred by "real"
cygwin users, and one GDI that the cygwin-as-msys users would prefer),
without a lot of rework in our existing tcl/tk offerings.
A final example: msys (and, I presume, cygwin-as-msys) deliberate dumbs
down the permission model to the old mechanism used by cygwin on FAT:
everything is owned by $current-user, every file is always readable by
everybody. Every directory is rx by everybody. The DOS read-only flag
is used to control +w/-w for all users.
But some apps (and our config-foo scripts!) check those settings; for
instance, ssh.exe wants to ensure that ~/.ssh is not writable by anybody
except the owner. That stuff had to be patched out, to work on msys.
Well, we don't want $real-cygwin's ssh.exe to act in such an insecure
manner, but then cygwin-as-msys users lose out, unless then only use the
ssh.exe from their parallel installation of $real-cygwin.
Alternatively, MSYS crt0.o itself provides all the necessary functionality,
which might be a lot easier to implement. It could call cygwin_internal
and provide the necessary callbacks and it would be linked against the
Cygwin DLL "just so".
I think you would actually need an entirely separate distribution of
tools, each compiled specifically for the "new" platform -- so they
could directly link against the msys-modifier DLL (as well as
cygwin1.dll). The good news is, there's already a project out there to
handle distributing and maintaining a collection of msys ports -- "we"
don't have to do it.
--
Chuck