This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MSYS mode (continue)


On Jul 25 09:11, Charles Wilson wrote:
> 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.
> [...]

In how far does this affect us today?  The idea to have a Cygwin DLL
underneath and just add the MSYS functionality by linking one way or
the other allows to get rid of lots of old workarounds.  There's no
reason to stick with the old ways.

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

This isn't relevant.  The idea is to have a different crt0.o which
allows to get the MSYS specific functionaily by building an application.
against it.  This does not reduce the necessity to patch applications
which require special functionality like a DOS-path-resistant make.

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

Which is bad.  I removed some older code from ssh specificially per the
request from the upstream devs since they thought it's too unsecure.
It's kind of frustrating having others adding this stuff back in just
to stay happily unsecure.  Windows 95 is long gone.

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

And the disadvantage is...?  The whole idea is to be able to stick to
full-fledged Cygwin functionalitiy, except for the cases where it
revolves around building native applications and DOS path handling.
There's no good reason to duplicate everything in an incompatible
way.

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

That was the point, Chuck.  The idea was to have an MSYS distro with
tools linked against the special crt0.o to get the aforementioned extra
functionality.  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.  You could have your cake *and* eat it.


Corinna

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]