MSYS mode (continue)

[Charles Wilson]

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