MSYS mode (continue)

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Fri Jul 5 16:42:00 GMT 2013


On Fri, Jul 05, 2013 at 11:07:04AM +0200, Corinna Vinschen wrote:
>On Jul  4 12:36, Christopher Faylor wrote:
>> On Thu, Jul 04, 2013 at 02:16:17PM +0200, Corinna Vinschen wrote:
>> >On Jul  4 13:45, Alexey Pavlov wrote:
>> >> 2013/7/4 Corinna Vinschen:
>> >> > On Jul  4 14:23, Alexey Pavlov wrote:
>> >> >> 2013/7/4 Corinna Vinschen:
>> >> >> > On Jul  4 12:37, Alexey Pavlov wrote:
>> >> >> >> 2013/7/4 Corinna Vinschen:
>> >> >> >> > On Jul  4 13:09, Alexey Pavlov wrote:
>> >> >> >> >>  struct utsname
>> >> >> >> >>  {
>> >> >> >> >> -  char sysname[20];
>> >> >> >> >> +  char sysname[21];
>> >> >> >> >
>> >> >> >> > We can't do that.  struct utsname is a publically facing structure.
>> >> >> >> > If you change the size, you're breaking compatibility with existing
>> >> >> >> > applications.
>> >> >> >> >
>> >> >> >> > You should better drop some character from the string you want to enter
>> >> >> >> > here.
>> >> >> >> >
>> >> >> >>
>> >> >> >> I can't drop any symbol from "MINGW32" word :)
>> >> >> >
>> >> >> > That's not 20 chars long.
>> >> >> >
>> >> >> Yes. But not only this need to be in 20 symbols. On cygwin 20 symbols is:
>> >> >>
>> >> >> CYGWIN_NT-6.1-WOW64\0
>> >> >>
>> >> >> But
>> >> >>
>> >> >> MINGW32_NT-6.1-WOW64\0
>> >> >>
>> >> >> is 21 symbol.
>> >> >
>> >> > Then drop the dash between "NT" and "6.1".  Or let's drop the WOW64
>> >> > since it's redundant anyway, given the content of "machine".
>> >> >
>> >> 
>> >> Let's drop it!
>> >
>> >I'm ok with that, but I think we should drop the "32" from MINGW in
>> >the first place.
>> >
>> >Does anybody rely on the "WOW64" in uname -s output?  I just checked
>> >the scripts in /bin in my installation and none of it seems to check
>> >for that info.
>> >
>> >And then again, it *is* redundant, given the uname -m output...
>> 
>> Can we back up a moment and discuss whether, regardless of string
>> length, this is the right approach?  This isn't what I'd envisioned
>> when I said "hooks".
>
>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.



More information about the Cygwin-developers mailing list