Re: MSYS mode (continue)

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Tue, Jul 30, 2013 at 10:55:33AM -0400, Christopher Faylor wrote:
>On Tue, Jul 30, 2013 at 02:59:40PM +0400, Alexey Pavlov wrote:
>>We need to determine places where you need to create hooks in
>>Cygwin.dll and also prototypes for external functions (input and
>>output arguments). Msys mode only change functions for non-Cygwin
>>applications and in this case where it can be handled? In cygwin.dll
>>or in msys.dll?
>
>This is the outstanding question for the last month or so.
>
>>For example, when we pass arguments to new process we determine in
>>Cygwin is new process depends on cygwin.dll or not and make decision
>>about changing arguments. If new process is non-cygwin then we try to
>>change arguments else we leave them as is. If we need do implement
>>decision logic in msys.dll then we need to rewrite many code. But if
>>we implement it in Cygwin dll then it was simple like this:
>
>No.  In the spawn function, you have something like:
>
>  if (!callout (CO_SPAWN, mode, &argv, &argc))
>    ...
>
>And a DLL which has been preloaded and registered with cygwin1.dll will
>modify the arguments as needed.
>
>Either that or, the other proposal is that MSYS could just use LD_PRELOAD
>but, as attractive as the notion of not modifying Cygwin at all might be,
>it would mean that the MSYS dll would have to do a lot more work for
>the above scenario because it would have to emulate a lot of what Cygwin
>does to emulate exec/spawn.
>
>So, in the interests of moving this discussion along, here is a more
>fleshed out proposal:
>
>Any helper DLL would be registered using a CYGWIN environment variable
>preload keyword:
>
>set CYGWIN=preload:msys.dll
>
>An error will be issued if Cygwin can't find the preload dll.
>
>The DLL will register callouts via:
>
>cygwin_internal (CW_CALLOUT, function_which_handles_callouts);
>
>Callout		Arguments
>CO_SPAWN	mode (value), argv (reference), argc (reference)
>CO_UNAME	utsname (reference)
>CO_ENV		envp (reference)
>CO_SYMLINK	is_native_symlink (value), oldpath (reference), newpath (reference)*
>CW_MALLOC	Amount of cygheap memory to allocate

I just implemented some of this and I'm wondering if we might need
some way of controlling the flow on entry to a function and on exit.
So maybe the above could be implemented as:

CO_UNAME_ENTRY
CO_UNAME_EXIT

but that might be overkill.  It wouldn't necessarily make sense for
CO_SPAWN either.

cgf