Re: MSYS mode (continue)

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

On 7/26/2013 4:15 AM, Corinna Vinschen wrote:
> On Jul 25 16:53, Christopher Faylor wrote:
> > 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

So, in this proposal I'd have an "msys" directory structure, with 
cygwin1.dll, an /etc/fstab, and lots of plain-old-cygwin executables, 
bit-for-bit identical to the executables in my "real" cygwin 
installation/directory structure.

On executable launch, ALL such applications would check for the hook DLL 
(as directed by an env variable, perhaps, or some other mechanism -- 
maybe encoded in a known-present file, like.../etc/fstab? [1])  and if 
present, load it.

Even the (bit-for-bit-identical) apps in my "real" cygwin installation 
would do this -- but because (a) they don't have that env setting or 
fstab setting, and (b) even if they did, the special msys-hook dll isn't 
present in that tree -- so nothing actually happens in that situation.

Now, back in my MSYS-on-cygwin installation, there are SOME executables 
that are actually *different* that the corresponding ones in 
real-cygwin-land.  Stuff like make, bash, perl, etc -- all may have been 
compiled with different options because we (the mingw/msys people) want 
them to behave differently, in ways that can't automatically be handled 
by the hooked changes in cygwin1.dll's own behavior.

Have I got that all correct?



[1] I think this is better than an environment var, because then my 
"regular" cygwin tree and my "msys" cygwin tree would both just work, 
without needed extraneous global env vars that might interfere with the 
other's operation.

In fact, I might want *different* CYGWIN env var settings for the two 
trees, but unless I set them in the global env then StartMenu-launched 
apps lose out.

Could we maybe extend the CYGWIN env var idea to files, similar to the 
/etc/fstab[.d] structure, which are then *augmented* by $CYGWIN?

e.g.  in my msys-on-cygwin tree, I might have

/etc/cygwin_settings
   hook=/bin/msys-hook.dll
   export
   glob:ignorecase
   winsymlinks:nativestrict
/etc/cygwin_settings.d/user
   error_start:c:\msys\bin\gdb.exe

But in my "real" cygwin tree, I might have

/etc/cygwin_settings
   proc_retry:1
/etc/cygwin_settings.d/user
   pipe_byte

> 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.

Right -- but *some* executables would need to actually BE different, 
aside from the underlying posix library's behavioral changes, to get a 
"real" MSYS environment.

> > 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.

I think that would, in fact, work -- but I think the list of tools that 
would need compile-time changes is larger than you would hope. But...IMO 
that's ok.  MSYS's goal was to be a *minimal* system...NOT an alternate 
cygwin.  If this proposal (a) makes the msys "fork" a non-fork, AND 
easier to maintain, and (b) incidentally means that SOMETIMES you might 
be able to "drop in" a stock cygwin .exe and it might just work -- no 
guarantees, you break it you bought it, we're just mean -- then it's a 
win overall.

The MSYS team would just provide patched and (re)compiled versions of 
most of their current set of tools...and if users wanted to "drop in" 
(e.g.) git.exe, well they are welcome to try it.  No support offered or 
guaranteed, and they might just get lucky.

> 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.

As cgf pointed out, if "we" (cygwin) are trying to come up with an easy 
upgrade path for existing users of MSYS, then we (mingw/msys) users 
would prefer not to have to change our existing fstab format on all of 
our installations.  Unless you (we, cygwin) automate that somehow...

--
Chuck