Re: MSYS mode (continue)

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jul 25 16:53, Christopher Faylor wrote:
> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote:
> >> But underlying there's still a normal Cygwin DLL and
> >> most tools could just be copied verbatim since they don't need this
> >> extra functionality.
> >
> >And that's the bit where I disagree.  Sure, some scripting tools might 
> >not need adjustment, so long as their interpreter was $MSYS-enabled 
> >(e.g. automake -> msys-perl, msys-bash) -- because the script will "see" 
> >dos-style paths, so its interpreter better be able to handle them.
> >
> >But unless you restrict yourself to only passing around relative paths 
> >(or god forbid, that old "unity mount" idea), any .exe will need to live 
> >in one world or the other. Otherwise, how would paths be interpreted? 
> >Using which tools' mount table?
> >
> >Naturally from the command line I can compensate:
> >
> >msys$  /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath 
> >-d /msys/mount/table/path) )
> >
> >but yee gods that'd be annoying in any automated setting.
> 
> I don't know if this helps but the vague plan is to now have two DLLs
> where before you only had one.  You'd still be providing "MSYS" binaries
> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
> small dll which relied on cygwin1.dll for all of the heavy lifting.
> 
> You'd still have a normal MSYS distribution and it would still, in theory,
> support everything (with the possible exception of very lax security) that
> the old MSYS did.  An MSYS release would consist of MSYS*.dll, cygwin1.dll,
> bash, etc.

Here's where I disagree.  I think the executables should *not* rely on
MSYS.dll being available.  Ideally the executables are linked against
the Cygwin DLL and MSYS.dll is called as a side-by-side implementation.
So, if MSYS.dll isn't available, they still function as normal Cygwin
executables.  That's why I proposed the solution(s) in
http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html

Assuming you implement it the first way, you get an executable linked
against a crt0.o which tries a LoadLibrary("MSYS.dll").  If it fails,
the executable does business as usual.  It will not fail, because
there's still the Cygwin DLL.

If LoadLib worked, crt0 calls GetProcAddress("__msys_hook") and then
__msys_hook().  __msys_hook collects the hook function pointers and
sends them to the CYgwin DLL via a call to cygwin_internal(CW_HOOK,
&hook_list).  Voila, the hooks are set up, we're in MSYS mode.


Another alternative would be if the Cygwin DLL itself had a switch to
load the MSYS dll (export CYGWIN=MSYS ;)).  This would allows MSYS mode
even with completely unchanged executables.


> I don't think anyone was proposing seamless interoperation between MSYS
> and cygwin.

Yes, I honestly think this would be possible and desirable.  MSYS is
just a tiny change for a specific task in comparison to the default
Cygwin mode.  MSYS would concentrate on this task and the required tools
for this task and the rest could be stock Cygwin distro.


Btw., this does *not* mean I agree with all changes MSYS is doing.  I
have a hard time to see the necessity changing the /etc/fstab layout,
for instance, since it doesn't add or change anything you can't have
with the standard fstab.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat