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  5 12:42, Christopher Faylor wrote:
> On Fri, Jul 05, 2013 at 11:07:04AM +0200, Corinna Vinschen wrote:
> >I don't think hooks make sense for such simple, nonintrusive stuff.
> >This may be different for bigger things like the weird "copy symlinks"
> >stuff, of course.
> >
> >Also, you didn't so far define how these hooks are supposed to work.
> >A detailed description of your idea would be useful for the discussion.
> 
> http://cygwin.com/ml/cygwin/2013-06/msg00515.html
> 
> I thought it was clear that this would be a general mechanism which
> could be used to modify Cygwin's behavior.
> 
> So, in this scenario, you would:
> 
> callout (CO_UNAME, &name);
> 
> We would provide a cygwin_internal method for setting up the callout
> hook.  If that wasn't set up then obviously callout would be a no-op.
> 
> I don't think that it makes sense for there to be two mechanisms to
> accomplish the goal of allowing another DLL to modify Cygwin's behavior.
> 
> Obviously a MSYS helper DLL would have to do the setup early, maybe
> in its DLL initialization.

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.

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


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]