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: Fri, 26 Jul 2013 23:06:50 -0400
- Subject: Re: MSYS mode (continue)
- References: <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> <51F123EB dot 9000900 at cwilson dot fastmail dot fm> <20130725150209 dot GA15619 at calimero dot vinschen dot de> <51F16C82 dot 7030509 at cwilson dot fastmail dot fm> <20130725205320 dot GA2725 at ednor dot casa dot cgf dot cx> <20130726081510 dot GN5086 at calimero dot vinschen dot de>
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