Re: MSYS mode (continue)

Re: MSYS mode (continue)

[Corinna Vinschen]

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.


Corinna

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

Re: MSYS mode (continue)

[Christopher Faylor]

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.

Re: MSYS mode (continue)

[Corinna Vinschen]

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

Re: MSYS mode (continue)

[Alexey Pavlov]

Is this thread is interesting yet or we can leave all as is?

Regards,
Alexey.

Re: MSYS mode (continue)

[Corinna Vinschen]

On Jul 25 15:06, Alexey Pavlov wrote:
> Is this thread is interesting yet or we can leave all as is?

This is of course interesting.  That's why I sent my mail on the 11th.
A reply to the points raised and further discussion would help a lot.


Corinna

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

Re: 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

Re: MSYS mode (continue)

[Corinna Vinschen]

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

Re: MSYS mode (continue)

[Charles Wilson]

On 7/25/2013 11:02 AM, Corinna Vinschen wrote:
> 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.

Right, that's what the paragraph you snipped was about.

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

Ah, but you're assuming that the app itself is *recompiled* so that it 
links a different crt0.o.  I interpreted your statement:
	"The advantage being that the executable could run in
	 an MSYS and a Cygwin environment, whatever it happens
	 to be dropped into."
to mean "the exact same binary".  That misunderstanding is what led to 
most of the confusion below.

My point is, I don't think *that* would work, for all the reasons I 
detailed.

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

Of course it's bad. MSYS(current version), based on cygwin-1.3.x AND 
with an even more broken security model than 1.3.x had, sux when 
compared to modern day cygwin.

However...a LOT of people don't care about file security when operating 
in a network environment that is deemed "protected" from outside 
interference.  E.g. network shares on an internal lab network, etc.  At 
$dayjob, I've seen folks get really annoyed by the issues that crop up 
when trying to mix native tools and cygwin's security model [1].

[1] the magic
----------+ 1 me mygroup 1.4M Jul 25 11:51 some-file
permssion settings you get when some-file was created using win32 tools.

So, they prefer MSYS no-security model, because in a protected network, 
they just want to get their job done, and not spend time chmod'ing stuff 
(or, in severe cases you can get yourself into a jam where you don't 
even have permission to "fix" it, and you have to get some IT support 
guy with Local Administrator privilege to do it. "And how did you create 
this file? What where you doing?").

So...if your msys-on-cygwin implements $dumb-security, then...no ssh at 
all?  (Geez, I've seen people store their ~/.ssh on a network share, 
which is...counterindicated, at best. But it's still done.)

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

I thought the "whole idea" was to replicate the existing msys toolkit 
(which currently includes rsh, ssh, and an extremely limited subset of 
the cygwin universe), only with a better, more maintainable core msys 
dll (which is actually cygwin1.dll + the extra hook-impl-providing msys 
thingy).

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

Ah, so you're not talking about dropping in "the same executable" into 
the MSYS arena and expecting its behavior to magically change. 
C:\cygwin-msys\bin\make.exe is a different binary than 
C:\cygwin\bin\make.exe.

OK so far.

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

And that's the bit where I disagree.  Sure, some scripting tools might 
not need adjustment, so long as their interpreter was $MSYS-enabled 
(e.g. automake -> msys-perl, msys-bash) -- because the script will "see" 
dos-style paths, so its interpreter better be able to handle them.

But unless you restrict yourself to only passing around relative paths 
(or god forbid, that old "unity mount" idea), any .exe will need to live 
in one world or the other. Otherwise, how would paths be interpreted? 
Using which tools' mount table?

Naturally from the command line I can compensate:

msys$  /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath 
-d /msys/mount/table/path) )

but yee gods that'd be annoying in any automated setting.

--
Chuck

Re: MSYS mode (continue)

[Charles Wilson]

On 7/25/2013 2:20 PM, Charles Wilson wrote:
> On 7/25/2013 11:02 AM, Corinna Vinschen wrote:
>> 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.
>
> Ah, but you're assuming that the app itself is *recompiled* so that it
> links a different crt0.o.  I interpreted your statement:
>      "The advantage being that the executable could run in
>       an MSYS and a Cygwin environment, whatever it happens
>       to be dropped into."
> to mean "the exact same binary".  That misunderstanding is what led to
> most of the confusion below.
>
> My point is, I don't think *that* would work, for all the reasons I
> detailed.

Wait, ignore the rest of the previous message. I think I get where 
you're going now, but I'll need to think on it some more.

Going to be AFK for a day or so, tho...

--
Chuck

Re: MSYS mode (continue)

[Christopher Faylor]

On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote:
>> 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.
>
>And that's the bit where I disagree.  Sure, some scripting tools might 
>not need adjustment, so long as their interpreter was $MSYS-enabled 
>(e.g. automake -> msys-perl, msys-bash) -- because the script will "see" 
>dos-style paths, so its interpreter better be able to handle them.
>
>But unless you restrict yourself to only passing around relative paths 
>(or god forbid, that old "unity mount" idea), any .exe will need to live 
>in one world or the other. Otherwise, how would paths be interpreted? 
>Using which tools' mount table?
>
>Naturally from the command line I can compensate:
>
>msys$  /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath 
>-d /msys/mount/table/path) )
>
>but yee gods that'd be annoying in any automated setting.

I don't know if this helps but the vague plan is to now have two DLLs
where before you only had one.  You'd still be providing "MSYS" binaries
which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
small dll which relied on cygwin1.dll for all of the heavy lifting.

You'd still have a normal MSYS distribution and it would still, in theory,
support everything (with the possible exception of very lax security) that
the old MSYS did.  An MSYS release would consist of MSYS*.dll, cygwin1.dll,
bash, etc.

I don't think anyone was proposing seamless interoperation between MSYS
and cygwin.

The reason that this came about was because someone was proposing an MSYS2
so, rather than take another copy of the cygwin source code and hack on
it again, Corinna thought maybe we could do something to minimize the fork.

cgf

Re: MSYS mode (continue)

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26.07.2013 00:53, Christopher Faylor wrote:
> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote:
>>> 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.
>>
>> And that's the bit where I disagree.  Sure, some scripting tools might 
>> not need adjustment, so long as their interpreter was $MSYS-enabled 
>> (e.g. automake -> msys-perl, msys-bash) -- because the script will "see" 
>> dos-style paths, so its interpreter better be able to handle them.
>>
>> But unless you restrict yourself to only passing around relative paths 
>> (or god forbid, that old "unity mount" idea), any .exe will need to live 
>> in one world or the other. Otherwise, how would paths be interpreted? 
>> Using which tools' mount table?
>>
>> Naturally from the command line I can compensate:
>>
>> msys$  /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath 
>> -d /msys/mount/table/path) )
>>
>> but yee gods that'd be annoying in any automated setting.
> 
> I don't know if this helps but the vague plan is to now have two DLLs
> where before you only had one.  You'd still be providing "MSYS" binaries
> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
> small dll which relied on cygwin1.dll for all of the heavy lifting.
> 
> You'd still have a normal MSYS distribution and it would still, in theory,
> support everything (with the possible exception of very lax security) that
> the old MSYS did.  An MSYS release would consist of MSYS*.dll, cygwin1.dll,
> bash, etc.

Out of curiosity: why do you insist on having MSYS functionality in a
separate dll, when it could be just part of cygwin1.dll (disableable and
enableable in the same way other Cygwin features are disabled/enabled -
via CYGWIN envvar)? What advantage would that give, that justifies the
increase in implementation complexity (hooking up the dll, etc)? Was
that justified earlier in this thread and i just neglected to read that
far back?

Also, i'm planning on building experimental cygwin dll that doesn't use
NO_ACL on mounts by default (msys2 always uses NO_ACL on mounts by
default) and see if it works for me. If it does, that'll remove yet
another item from the list of msys vs cygwin differences, at least for me.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJR8ZOtAAoJEOs4Jb6SI2CwUSgIAJdl3w68YM9QQ+W4/HC4cWnj
7Nup127y2LI31ZaNKsr29XVfk9PaGCDYx/Ueoi5CCaOmZCaRmeAWGnaS6ftXjstf
KM1/ph/dIOx7nT2jHP3eWRp1IJh1DIHUOS0ZuTilgHWZzbpteKwdyq+WOuF1dT0J
c11ue23sYPSJ2QyXGYBuOfCjok+HCGCnfX305DKhWNwriw57xcixU8pU8TaGRDM8
zUlC2VJ3NO7e3Es2JDIq4uqVkh/JFdUZ+2W63W+xyTQyRJgLzA7egnq+8fpoX2HN
qM70cvmv2wD0AhS2tAHYPOPCGlfwoayd+dAJCVyy/cgs1qCnS/3N0yy6xTGkXGg=
=bHcW
-----END PGP SIGNATURE-----

Re: MSYS mode (continue)

[Larry Hall (Cygwin Developers)]

On 7/25/2013 5:07 PM, LRN wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 26.07.2013 00:53, Christopher Faylor wrote:
>> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote:
>>>> 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.
>>>
>>> And that's the bit where I disagree.  Sure, some scripting tools might
>>> not need adjustment, so long as their interpreter was $MSYS-enabled
>>> (e.g. automake -> msys-perl, msys-bash) -- because the script will "see"
>>> dos-style paths, so its interpreter better be able to handle them.
>>>
>>> But unless you restrict yourself to only passing around relative paths
>>> (or god forbid, that old "unity mount" idea), any .exe will need to live
>>> in one world or the other. Otherwise, how would paths be interpreted?
>>> Using which tools' mount table?
>>>
>>> Naturally from the command line I can compensate:
>>>
>>> msys$  /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath
>>> -d /msys/mount/table/path) )
>>>
>>> but yee gods that'd be annoying in any automated setting.
>>
>> I don't know if this helps but the vague plan is to now have two DLLs
>> where before you only had one.  You'd still be providing "MSYS" binaries
>> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
>> small dll which relied on cygwin1.dll for all of the heavy lifting.
>>
>> You'd still have a normal MSYS distribution and it would still, in theory,
>> support everything (with the possible exception of very lax security) that
>> the old MSYS did.  An MSYS release would consist of MSYS*.dll, cygwin1.dll,
>> bash, etc.
>
> Out of curiosity: why do you insist on having MSYS functionality in a
> separate dll, when it could be just part of cygwin1.dll (disableable and
> enableable in the same way other Cygwin features are disabled/enabled -
> via CYGWIN envvar)? What advantage would that give, that justifies the
> increase in implementation complexity (hooking up the dll, etc)? Was
> that justified earlier in this thread and i just neglected to read that
> far back?

Yes, it was mentioned.  The idea is to keep the MSYS-specific stuff separate
so Cygwin functionality isn't impacted by what MSYS wants.  This reduces
the complexity of the Cygwin code at least.


-- 
Larry

Re: MSYS mode (continue)

[Christopher Faylor]

On Thu, Jul 25, 2013 at 05:30:57PM -0400, Larry Hall (Cygwin Developers) wrote:
>On 7/25/2013 5:07 PM, LRN wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 26.07.2013 00:53, Christopher Faylor wrote:
>>> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote:
>>>>> 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.
>>>>
>>>> And that's the bit where I disagree.  Sure, some scripting tools might
>>>> not need adjustment, so long as their interpreter was $MSYS-enabled
>>>> (e.g. automake -> msys-perl, msys-bash) -- because the script will "see"
>>>> dos-style paths, so its interpreter better be able to handle them.
>>>>
>>>> But unless you restrict yourself to only passing around relative paths
>>>> (or god forbid, that old "unity mount" idea), any .exe will need to live
>>>> in one world or the other. Otherwise, how would paths be interpreted?
>>>> Using which tools' mount table?
>>>>
>>>> Naturally from the command line I can compensate:
>>>>
>>>> msys$  /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath
>>>> -d /msys/mount/table/path) )
>>>>
>>>> but yee gods that'd be annoying in any automated setting.
>>>
>>> I don't know if this helps but the vague plan is to now have two DLLs
>>> where before you only had one.  You'd still be providing "MSYS" binaries
>>> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
>>> small dll which relied on cygwin1.dll for all of the heavy lifting.
>>>
>>> You'd still have a normal MSYS distribution and it would still, in theory,
>>> support everything (with the possible exception of very lax security) that
>>> the old MSYS did.  An MSYS release would consist of MSYS*.dll, cygwin1.dll,
>>> bash, etc.
>>
>> Out of curiosity: why do you insist on having MSYS functionality in a
>> separate dll, when it could be just part of cygwin1.dll (disableable and
>> enableable in the same way other Cygwin features are disabled/enabled -
>> via CYGWIN envvar)? What advantage would that give, that justifies the
>> increase in implementation complexity (hooking up the dll, etc)? Was
>> that justified earlier in this thread and i just neglected to read that
>> far back?
>
>Yes, it was mentioned.  The idea is to keep the MSYS-specific stuff separate
>so Cygwin functionality isn't impacted by what MSYS wants.  This reduces
>the complexity of the Cygwin code at least.

Right.  Thanks Larry.

The bottom line is that we don't want there to be a bunch of "if
(is_msys)"'s in the code.  We don't want to have to worry about how msys
does things.  I don't want to have to inspect msys patches, except for
requests for a new hook.

A hook will be a fast no-op in the pure cygwin cases.  There would be
very little "implementation complexity".

cgf

Re: MSYS mode (continue)

[LRN]

[-- Attachment #1: Type: text/plain, Size: 3835 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26.07.2013 05:55, Christopher Faylor wrote:
> On Thu, Jul 25, 2013 at 05:30:57PM -0400, Larry Hall (Cygwin Developers) wrote:
>> On 7/25/2013 5:07 PM, LRN wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 26.07.2013 00:53, Christopher Faylor wrote:
>>>> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote:
>>>>>> 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.
>>>>>
>>>>> And that's the bit where I disagree.  Sure, some scripting tools might
>>>>> not need adjustment, so long as their interpreter was $MSYS-enabled
>>>>> (e.g. automake -> msys-perl, msys-bash) -- because the script will "see"
>>>>> dos-style paths, so its interpreter better be able to handle them.
>>>>>
>>>>> But unless you restrict yourself to only passing around relative paths
>>>>> (or god forbid, that old "unity mount" idea), any .exe will need to live
>>>>> in one world or the other. Otherwise, how would paths be interpreted?
>>>>> Using which tools' mount table?
>>>>>
>>>>> Naturally from the command line I can compensate:
>>>>>
>>>>> msys$  /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath
>>>>> -d /msys/mount/table/path) )
>>>>>
>>>>> but yee gods that'd be annoying in any automated setting.
>>>>
>>>> I don't know if this helps but the vague plan is to now have two DLLs
>>>> where before you only had one.  You'd still be providing "MSYS" binaries
>>>> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
>>>> small dll which relied on cygwin1.dll for all of the heavy lifting.
>>>>
>>>> You'd still have a normal MSYS distribution and it would still, in theory,
>>>> support everything (with the possible exception of very lax security) that
>>>> the old MSYS did.  An MSYS release would consist of MSYS*.dll, cygwin1.dll,
>>>> bash, etc.
>>>
>>> Out of curiosity: why do you insist on having MSYS functionality in a
>>> separate dll, when it could be just part of cygwin1.dll (disableable and
>>> enableable in the same way other Cygwin features are disabled/enabled -
>>> via CYGWIN envvar)? What advantage would that give, that justifies the
>>> increase in implementation complexity (hooking up the dll, etc)? Was
>>> that justified earlier in this thread and i just neglected to read that
>>> far back?
>>
>> Yes, it was mentioned.  The idea is to keep the MSYS-specific stuff separate
>> so Cygwin functionality isn't impacted by what MSYS wants.  This reduces
>> the complexity of the Cygwin code at least.
> 
> Right.  Thanks Larry.
> 
> The bottom line is that we don't want there to be a bunch of "if
> (is_msys)"'s in the code.  We don't want to have to worry about how msys
> does things.  I don't want to have to inspect msys patches, except for
> requests for a new hook.
> 
> A hook will be a fast no-op in the pure cygwin cases.  There would be
> very little "implementation complexity".

OK.

I've attached the patch that alexey gave me recently, if pointless
cygwin->msys renames are removed from msys2, this is what msys2 boils
down to. Please specify how the hooks will look, now that you know which
points of the code need to be hooked up.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJR8fTZAAoJEOs4Jb6SI2CwoU0H/1YQSxBz9NisJcCj6wUfo07u
yE7uqieB4sxv3dEJAigBHNVYMbEEqDehY/TVFqMoRIw9SXBSpBWFMla49w8aRHeA
7JUP3+5/cyQYJHXSLBMZBAxdYmSe61PrZVXaH/fMHVuuv31457/He/GaNrM+mos+
q6QqvB2S+lVDIBfZALPyYdS+VZ7jgDVKC2Eb5oFyrEV3EOBnkOFu/PjLUzm1ewMH
X5bn9HHiqHKHUxsss2LBbtZLO75ptLdFPBF+TY83H1TJDHDb3byFGSSGtXhB9+iB
q0j6fhXEqGT+0nCaXangHtt02zx9fvUMLb6bPJ36JTrhv3F/nxEPOjnUtq7Hzm0=
=DGCV
-----END PGP SIGNATURE-----

[-- Attachment #2: cygwin-msys.patch --]
[-- Type: text/plain, Size: 26590 bytes --]

diff -Naur curr_cyg/winsup/cygwin/environ.cc curr_msys/winsup/cygwin/environ.cc
--- curr_cyg/winsup/cygwin/environ.cc	2013-07-21 23:30:19.000000000 +0400
+++ curr_msys/winsup/cygwin/environ.cc	2013-07-22 06:34:55.000000000 +0400
@@ -999,7 +1021,7 @@
    prior to placing them in the string.  */
 char ** __reg3
 build_env (const char * const *envp, PWCHAR &envblock, int &envc,
-	   bool no_envblock)
+	   bool no_envblock, bool keep_posix)
 {
   int len, n;
   const char * const *srcp;
@@ -1024,6 +1046,9 @@
   for (srcp = envp, dstp = newenv, pass_dstp = pass_env; *srcp; srcp++)
     {
       bool calc_tl = !no_envblock;
+      /* Don't pass timezone environment to non-msys applications */
+      if (!keep_posix && ascii_strncasematch(*srcp, "TZ=", 3))
+        goto next1;
       /* Look for entries that require special attention */
       for (unsigned i = 0; i < SPENVS_SIZE; i++)
 	if (!saw_spenv[i] && (*dstp = spenvs[i].retrieve (no_envblock, *srcp)))
@@ -1104,6 +1129,13 @@
 	  conv = getwinenv (*srcp, rest, &temp);
 	  if (conv)
 	    p = conv->native;	/* Use win32 path */
+      else if (!keep_posix) {
+        char *win_arg = arg_heuristic(*srcp);
+		debug_printf("WIN32_PATH is %s", win_arg);
+		p = cstrdup1(win_arg);
+        if (win_arg != *srcp)
+          free (win_arg);
+      }
 	  else
 	    p = *srcp;		/* Don't worry about it */
 
diff -Naur curr_cyg/winsup/cygwin/environ.h curr_msys/winsup/cygwin/environ.h
--- curr_cyg/winsup/cygwin/environ.h	2013-07-21 23:30:19.000000000 +0400
+++ curr_msys/winsup/cygwin/environ.h	2013-07-22 06:34:55.000000000 +0400
@@ -45,6 +45,6 @@
 extern "C" char __stdcall **cur_environ ();
 #endif
 char ** __reg3 build_env (const char * const *envp, PWCHAR &envblock,
-			  int &envc, bool need_envblock);
+			  int &envc, bool need_envblock, bool keep_posix);
 
 #define ENV_CVT -1
diff -Naur curr_cyg/winsup/cygwin/external.cc curr_msys/winsup/cygwin/external.cc
--- curr_cyg/winsup/cygwin/external.cc	2013-07-21 23:30:19.000000000 +0400
+++ curr_msys/winsup/cygwin/external.cc	2013-07-22 06:34:55.000000000 +0400
@@ -137,7 +137,7 @@
 {
   int unused_envc;
   PWCHAR envblock = NULL;
-  char **envp = build_env (env ?: cur_environ (), envblock, unused_envc, false);
+  char **envp = build_env (env ?: cur_environ (), envblock, unused_envc, false, true);
   PWCHAR p = envblock;
 
   if (envp)
diff -Naur curr_cyg/winsup/cygwin/globals.cc curr_msys/winsup/cygwin/globals.cc
--- curr_cyg/winsup/cygwin/globals.cc	2013-07-21 23:30:19.000000000 +0400
+++ curr_msys/winsup/cygwin/globals.cc	2013-07-22 06:34:55.000000000 +0400
@@ -68,7 +68,7 @@
 /* Some CYGWIN environment variable variables. */
 bool allow_glob = true;
 bool ignore_case_with_glob = false;
-bool dos_file_warning = true;
+bool dos_file_warning = false;
 winsym_t allow_winsymlinks = WSYM_sysfile;
 bool reset_com = false;
 bool pipe_byte = false;
diff -Naur curr_cyg/winsup/cygwin/include/sys/cygwin.h curr_msys/winsup/cygwin/include/sys/cygwin.h
--- curr_cyg/winsup/cygwin/include/sys/cygwin.h	2013-07-21 23:30:19.000000000 +0400
+++ curr_msys/winsup/cygwin/include/sys/cygwin.h	2013-07-22 06:34:55.000000000 +0400
@@ -81,6 +81,8 @@
    to one of the above values, or to ENOMEM if malloc fails. */
 extern void *cygwin_create_path (cygwin_conv_path_t what, const void *from);
 
+extern char * arg_heuristic (char const * const);
+
 extern pid_t cygwin_winpid_to_pid (int);
 extern int cygwin_posix_path_list_p (const char *);
 extern void cygwin_split_path (const char *, char *, char *);
diff -Naur curr_cyg/winsup/cygwin/mount.cc curr_msys/winsup/cygwin/mount.cc
--- curr_cyg/winsup/cygwin/mount.cc	2013-07-21 23:30:19.000000000 +0400
+++ curr_msys/winsup/cygwin/mount.cc	2013-07-22 06:34:55.000000000 +0400
@@ -458,13 +456,13 @@
   sys_wcstombs (native_root, PATH_MAX, root);
   assert (*native_root != '\0');
   if (add_item (native_root, "/",
-		MOUNT_SYSTEM | MOUNT_BINARY | MOUNT_IMMUTABLE | MOUNT_AUTOMATIC)
+		MOUNT_SYSTEM | MOUNT_BINARY | MOUNT_IMMUTABLE | MOUNT_AUTOMATIC | MOUNT_NOACL)
       < 0)
     api_fatal ("add_item (\"%s\", \"/\", ...) failed, errno %d", native_root, errno);
   /* Create a default cygdrive entry.  Note that this is a user entry.
      This allows to override it with mount, unless the sysadmin created
      a cygdrive entry in /etc/fstab. */
-  cygdrive_flags = MOUNT_BINARY | MOUNT_NOPOSIX | MOUNT_CYGDRIVE;
+  cygdrive_flags = MOUNT_BINARY | MOUNT_NOPOSIX | MOUNT_CYGDRIVE | MOUNT_NOACL;
   strcpy (cygdrive, CYGWIN_INFO_CYGDRIVE_DEFAULT_PREFIX "/");
   cygdrive_len = strlen (cygdrive);
 }
@@ -1125,8 +1117,17 @@
   if (!*c)
     return true;
   cend = find_ws (c);
-  *cend = '\0';
   posix_path = conv_fstab_spaces (c);
+  if (!*cend)
+   {
+     unsigned mount_flags = MOUNT_SYSTEM | MOUNT_BINARY | MOUNT_NOPOSIX | MOUNT_NOACL;
+
+     int res = mount_table->add_item (native_path, posix_path, mount_flags);
+     if (res && get_errno () == EMFILE)
+       return false;
+     return true;
+   }
+  *cend = '\0';
   /* Third field: FS type. */
   c = skip_ws (cend + 1);
   if (!*c)
diff -Naur curr_cyg/winsup/cygwin/path.cc curr_msys/winsup/cygwin/path.cc
--- curr_cyg/winsup/cygwin/path.cc	2013-07-21 23:30:19.000000000 +0400
+++ curr_msys/winsup/cygwin/path.cc	2013-07-22 06:34:55.000000000 +0400
@@ -1487,6 +1486,86 @@
 
 /********************** Symbolic Link Support **************************/
 
+/*
+  Create a deep copy of src as dst, while avoiding descending in origpath.
+*/
+static int
+recursiveCopy (char * src, char * dst, const char * origpath)
+{
+  WIN32_FIND_DATA dHfile;
+  HANDLE dH;
+  BOOL findfiles;
+  int srcpos = strlen (src);
+  int dstpos = strlen (dst);
+  int res = -1;
+
+  debug_printf("recursiveCopy (%s, %s)", src, dst);
+
+  /* Create the destination directory */
+  if (!CreateDirectoryEx (src, dst, NULL))
+    {
+      debug_printf("CreateDirectoryEx(%s, %s, 0) failed", src, dst);
+      __seterrno ();
+      goto done;
+    }
+  /* Descend into the source directory */
+  if (srcpos + 2 >= MAX_PATH || dstpos + 1 >= MAX_PATH)
+    {
+      set_errno (ENAMETOOLONG);
+      goto done;
+    }
+  strcat (src, "\\*");
+  strcat (dst, "\\");
+  dH = FindFirstFile (src, &dHfile);
+  debug_printf("dHfile(1): %s", dHfile.cFileName);
+  findfiles = FindNextFile (dH, &dHfile);
+  debug_printf("dHfile(2): %s", dHfile.cFileName);
+  findfiles = FindNextFile (dH, &dHfile);
+  while (findfiles)
+    {
+      /* Append the directory item filename to both source and destination */
+      int filelen = strlen (dHfile.cFileName);
+      debug_printf("dHfile(3): %s", dHfile.cFileName);
+      if (srcpos + 1 + filelen >= MAX_PATH ||
+          dstpos + 1 + filelen >= MAX_PATH)
+        {
+          set_errno (ENAMETOOLONG);
+          goto done;
+        }
+      strcpy (&src[srcpos+1], dHfile.cFileName);
+      strcpy (&dst[dstpos+1], dHfile.cFileName);
+      debug_printf("%s -> %s", src, dst);
+      if (dHfile.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
+        {
+          /* Recurse into the child directory */
+          debug_printf("%s <-> %s", src, origpath);
+          if (strcmp (src, origpath)) // avoids endless recursion
+            if (recursiveCopy (src, dst, origpath))
+              goto done;
+        }
+      else
+        {
+          /* Just copy the file */
+          if (!CopyFile (src, dst, FALSE))
+            {
+              __seterrno ();
+              goto done;
+            }
+        }
+      findfiles = FindNextFile (dH, &dHfile);
+    }
+  if (GetLastError() != ERROR_NO_MORE_FILES)
+    {
+      __seterrno ();
+      goto done;
+    }
+  res = 0;
+
+done:
+
+  return res;
+}
+
 /* Create a symlink from FROMPATH to TOPATH. */
 
 extern "C" int
@@ -1891,6 +1970,73 @@
     }
   else
     {
+      path_conv src_path;
+      src_path.check (oldpath, PC_SYM_NOFOLLOW, stat_suffixes);
+      if (src_path.error)
+        {
+           set_errno (src_path.error);
+           goto done;
+        }
+      if (!src_path.isdevice () && !src_path.is_fs_special ())
+        {
+           /* MSYS copy file instead make symlink */
+
+           char * real_oldpath;
+           if (isabspath (oldpath))
+             strcpy (real_oldpath = tp.c_get (), oldpath);
+           else
+              /* Find the real source path, relative
+                 to the directory of the destination */
+             {
+                /* Determine the character position of the last path component */
+                int pos = strlen (newpath);
+                while (--pos >= 0)
+                  if (isdirsep (newpath[pos]))
+                    break;
+                /* Append the source path to the directory
+                   component of the destination */
+                if (pos+1+strlen(oldpath) >= MAX_PATH)
+                  {
+                     set_errno(ENAMETOOLONG);
+                     goto done;
+                  }
+                strcpy (real_oldpath = tp.c_get (), newpath);
+                strcpy (&real_oldpath[pos+1], oldpath);
+             }
+
+           /* As a MSYS limitation, the source path must exist. */
+		   path_conv win32_oldpath;
+           win32_oldpath.check (real_oldpath, PC_SYM_NOFOLLOW, stat_suffixes);
+           if (!win32_oldpath.exists ())
+             {
+                set_errno (ENOENT);
+                goto done;
+             }
+
+           char *w_newpath;
+           char *w_oldpath;
+           stpcpy (w_newpath = tp.c_get (), win32_newpath.get_win32());
+           stpcpy (w_oldpath = tp.c_get (), win32_oldpath.get_win32());
+           if (win32_oldpath.isdir())
+             {
+                char *origpath;
+                strcpy (origpath = tp.c_get (), w_oldpath);
+                res = recursiveCopy (w_oldpath, w_newpath, origpath);
+             }
+           else
+             {
+                if (!CopyFile (w_oldpath, w_newpath, FALSE))
+                  {
+                     __seterrno ();
+                  }
+                else
+                  {
+                     res = 0;
+                  }
+             }
+           goto done;
+        }
+
       /* Default technique creating a symlink. */
       buf = tp.t_get ();
       cp = stpcpy (buf, SYMLINK_COOKIE);
@@ -3182,6 +3328,488 @@
   return res;
 }
 
+static bool
+isabswinpath (const char * path)
+{
+  int plen = strlen (path);
+  bool p0alpha = isalpha (path[0]) != 0;
+  bool p1colon = (plen > 1 && path[1] == ':');
+  bool rval = 
+         (   ((plen == 2) && p0alpha && p1colon)
+          || (  (plen > 2) 
+	      && p0alpha 
+	      && p1colon 
+	      && (strchr (&path[2], ':') == (char *)NULL)
+	     )
+	  || (   plen > 3 
+	      && path[0] == '\\' 
+	      && path[1] == '\\' 
+	      && path[3] == '\\'
+	     )
+	 );
+    return rval;
+}
+
+static char *
+ScrubRetpath (char * const retpath)
+{ 
+  char * sspath = (char *)retpath;
+  //
+  // Check for null path because Win32 doesn't like them.
+  // I.E.:  Path lists of c:/foo;;c:/bar need changed to 
+  // c:/foo;c:/bar.
+  //
+  // This need be executed only if we actually converted the path.
+  //
+  while (*sspath)
+    {
+      if (*sspath == ';' && sspath[1] == ';')
+	  for (char *i = sspath; *i; i++)
+	      *i = *(i + 1);
+      else
+	sspath++;
+    }
+  if (*(sspath - 1) == ';')
+    *(sspath - 1) = '\0';
+
+  //
+  // If we modified the path then convert all / to \ if we have a path list
+  // else convert all \ to /.
+  // 
+  if ((strchr (retpath, ';')))
+  {
+    backslashify (retpath, retpath, 0);
+  } else
+  {
+    slashify (retpath, retpath, 0);
+  }
+  debug_printf("returning: %s", retpath);
+  return retpath;
+}
+
+//
+// The returned pointer should be freed with free unless,
+// as it turns out, it is equal to the input pointer.
+//
+extern "C" char *
+arg_heuristic (char const * const arg)
+{
+
+  int arglen = (arg ? strlen (arg): 0);
+  
+  if (arglen == 0)
+  {
+    char *retpath = (char *)malloc (sizeof (char));
+    memset (retpath, 0, sizeof (char));
+    return retpath;
+  }
+
+  debug_printf("Input value: (%s)", arg);
+
+  //
+  // copy of the path string that we can overwrite
+  //
+  char *spath = (char *)alloca (arglen + 1);
+  memcpy (spath, arg, arglen + 1);
+  
+  char * sspath;
+  
+  //
+  // retpath contains the converted path string to be returned
+  //
+  char *retpath = (char *)malloc(((MAX_PATH - arglen) > 0) ? 
+      MAX_PATH : arglen + MAX_PATH);
+  memset (retpath, 0, MAX_PATH);
+  int retpath_len = 0;
+  int retpath_buflen = MAX_PATH;
+    
+#define retpathcat(retstr) \
+  retpath_len += strlen(retstr); \
+  if (retpath_buflen <= retpath_len) \
+    { \
+      retpath_buflen = ((retpath_buflen * 2 <= retpath_len) ? \
+	  retpath_len + 1 : retpath_buflen * 2); \
+      retpath = (char *)realloc (retpath, retpath_buflen); \
+    } \
+  strcat (retpath, retstr);
+
+#define retpathcpy(retstr) \
+  retpath_len = strlen (retstr); \
+  *retpath = '\0'; \
+  if (retpath_buflen <= retpath_len ) \
+    { \
+      retpath_buflen = ((retpath_buflen * 2 <= retpath_len) ? \
+	  retpath_len + 1 : retpath_buflen * 2); \
+      retpath = (char *)realloc (retpath, retpath_buflen); \
+    } \
+  strcpy (retpath, retstr);
+
+  //
+  // Just return win32 paths and path lists.
+  //
+  if (isabswinpath (arg) 
+      || (strchr (arg, ';') > 0)
+      )
+    {
+      debug_printf("returning Win32 absolute path: %s", arg);
+      return ((char *)arg);
+    }
+  //
+  // Multiple forward slashes are treated special,
+  // Remove one and return for the form of //foo or ///bar
+  // but just return for the form of //server/share.
+  //
+  else if (arg[0] == '/' && arg[1] == '/')
+    {
+      int tidx = 2;
+      while (spath[tidx] && spath[tidx] == '/')
+	  tidx++;
+      if (strchr (&spath[tidx], '/'))
+	{
+	  retpathcpy (spath);
+	}
+      else
+	{
+	  retpathcpy (&spath[1]);
+	}
+      return ScrubRetpath (retpath);
+    }
+  //
+  // special case confusion elimination
+  // Translate a path that looks similar to /c: to c:/.
+  //
+  else if (arg[0] == '/' && isabswinpath (arg + 1))
+    {
+      retpathcpy (&arg[1]);
+      return ScrubRetpath (retpath);
+    }
+  //
+  // Check for variable set.
+  //
+  else if ((sspath = strchr(spath, '=')) && isalpha (spath[0]))
+    {
+      if (isabswinpath (sspath + 1)) {
+	debug_printf("returning: %s", arg);
+	return (char *)arg;
+      }
+      char *swin32_path = arg_heuristic(sspath + 1);
+      if (swin32_path == (sspath + 1)) {
+	debug_printf("returning: %s", arg);
+	return (char *)arg;
+      }
+      *sspath = '\0';
+      retpathcpy (spath);
+      retpathcat ("=");
+      retpathcat (swin32_path);
+      free (swin32_path);
+      return ScrubRetpath (retpath);
+    }
+  //
+  // Check for paths after commas, if string begins with a '-' character.
+  //
+  else if ((sspath = strchr(spath, ',')) && spath[0] == '-')
+    {
+      if (isabswinpath (sspath + 1)) {
+	debug_printf("returning: %s", arg);
+	return (char *)arg;
+      }
+      char *swin32_path = arg_heuristic(sspath + 1);
+      if (swin32_path == (sspath + 1)) {
+	debug_printf("returning: %s", arg);
+	return (char *)arg;
+      }
+      *sspath = '\0';
+      retpathcpy (spath);
+      retpathcat (",");
+      retpathcat (swin32_path);
+      free (swin32_path);
+      return ScrubRetpath (retpath);
+    }
+  //
+  // Check for POSIX path lists.
+  // But we have to allow processing of quoted strings and switches first
+  // which uses recursion so this code will be seen again.
+  //
+  else 
+    {
+      sspath = strchr (spath, ':');
+      //
+      // Prevent http://some.string/ from being modified.
+      // 
+      if ((sspath > 0 && strlen (sspath) > 2)
+	  && (sspath[1] == '/')
+	  && (sspath[2] == '/')
+	  )
+	{
+	  debug_printf("returning: %s", arg);
+	  return ((char *)arg);
+	}
+      else
+      if ((sspath > 0)
+	   && (strchr (spath, '/') > 0)
+	   // 
+	   // Prevent strings beginning with -, ", ', or @ from being processed,
+	   // remember that this is a recursive routine.
+	   // 
+	   && (strchr ("-\"\'@", spath[0]) == 0)
+	   // 
+	   // Prevent ``foo:echo /bar/baz'' from being considered a path list.
+	   // 
+	   && (strlen (sspath) > 1 && strchr (":./", sspath[1]) > 0)
+	   )
+    {
+      //
+      // Yes, convert to Win32 path list.
+      //
+      while (sspath)
+	{
+	  *sspath = '\0';
+	  char *swin32_path = arg_heuristic (spath);
+	  //
+	  // Just ignore sret; swin32_path has the value we need.
+	  //
+	  retpathcat (swin32_path);
+	  if (swin32_path != spath)
+	    free (swin32_path);
+	  spath = sspath + 1;
+	  sspath = strchr (spath, ':');
+	  retpathcat (";");
+	  //
+	  // Handle the last path in the list.
+	  //
+	  if (!sspath)
+	    {
+	      char *swin32_path = arg_heuristic (spath);
+	      retpathcat (swin32_path);
+	      if (swin32_path != spath)
+		free (swin32_path);
+	    }
+	}
+      return ScrubRetpath (retpath);
+    }
+  else
+    {
+      switch (spath[0])
+	{
+	case '/':
+	  //
+	  // Just a normal POSIX path.
+	  //
+	  {
+	    //
+	    // Convert only up to a ".." path component, and
+	    // keep all what follows as is.
+	    //
+	    sspath = strstr (spath, "/..");
+	    if (sspath)
+	      {
+		*sspath = '\0';
+		char *swin32_path = arg_heuristic (spath);
+		if (swin32_path == spath)
+		  {
+		    debug_printf("returning: %s", arg);
+		    return ((char *)arg);
+		  }
+		retpathcpy (swin32_path);
+		retpathcat ("/");
+		retpathcat (sspath+1);
+		free (swin32_path);
+		return ScrubRetpath (retpath);
+	      }
+		if (strcmp(spath, "/dev/null") == 0)
+	      {
+		retpathcpy("nul");
+		return ScrubRetpath (retpath);
+	      }
+	    path_conv p (spath, 0);
+	    if (p.error)
+	      {
+		set_errno(p.error);
+		debug_printf("returning: %s", arg);
+		return ((char *)arg);
+	      }
+	    retpathcpy (p.get_win32 ());
+	    return ScrubRetpath (retpath);
+	  }
+	case '-':
+	  //
+	  // here we check for POSIX paths as attributes to a POSIX switch.
+	  //
+	  sspath = strchr (spath, '=');
+	  if (sspath)
+	    {
+	      //
+	      // just use recursion if we find a set variable token.
+	      //
+	      *sspath = '\0';
+	      if (isabswinpath (sspath + 1)) {
+		debug_printf("returning: %s", arg);
+		return (char *)arg;
+	      }
+	      char *swin32_path = arg_heuristic(sspath + 1);
+	      if (swin32_path == sspath + 1)
+		{
+		  debug_printf("returning: %s", arg);
+		  return ((char *)arg);
+		}
+	      retpathcpy (spath);
+	      retpathcat ("=");
+	      retpathcat (swin32_path);
+	      free (swin32_path);
+	      return ScrubRetpath (retpath);
+	    }
+	  else
+	    {
+	      //
+	      // Check for single letter option with a
+	      // path argument attached, eg -I/include */
+	      //
+	      if (spath[1] && spath[2] == '/')
+		{
+		  debug_printf("spath = %s", spath);
+		  sspath = spath + 2;
+		  char *swin32_path = arg_heuristic (sspath);
+		  if (swin32_path == sspath)
+		    {
+		      debug_printf("returning: %s", arg);
+		      return ((char *)arg);
+		    }
+		  sspath = (char *)spath;
+		  sspath++;
+		  sspath++;
+		  *sspath = '\0';
+		  retpathcpy (spath);
+		  *sspath = '/';
+		  retpathcat (swin32_path);
+		  free (swin32_path);
+		  return ScrubRetpath (retpath);
+		}
+	      else
+		{
+		  debug_printf("returning: %s", arg);
+		  return ((char *)arg);
+		}
+	    }
+	  break;
+	case '@':
+	  //
+	  // here we check for POSIX paths as attributes to a response
+	  // file argument (@file). This is specifically to support
+	  // MinGW binutils and gcc.
+	  //
+	  sspath = spath + 1;
+	  if (isabswinpath (sspath))
+	    {
+	      debug_printf("returning: %s", arg);
+	      return (char *)arg;
+	    }
+	  if (spath[1] == '/')
+	    {
+	      debug_printf("spath = %s", spath);
+	      char *swin32_path = arg_heuristic (sspath);
+	      if (swin32_path == sspath)
+		{
+		  debug_printf("returning: %s", arg);
+		  return ((char *)arg);
+		}
+	      sspath = (char *)spath;
+	      sspath++;
+	      *sspath = '\0';
+	      retpathcpy (spath);
+	      *sspath = '/';
+	      retpathcat (swin32_path);
+	      free (swin32_path);
+	      return ScrubRetpath (retpath);
+	    }
+	  else
+	    {
+	      debug_printf("returning: %s", arg);
+	      return ((char *)arg);
+	    }
+	  break;
+	case '"':
+	  //
+	  // Handle a double quote case.
+	  //
+	  debug_printf ("spath: %s", spath);
+	  if (spath[1] == '/')
+	    {
+	      retpathcpy ("\"");
+	      char *tpath = strchr(&spath[1], '"');
+	      if (tpath)
+		*tpath = (char)NULL;
+	      char *swin32_path = arg_heuristic (&spath[1]);
+	      if (swin32_path == &spath[1])
+		{
+		  debug_printf("returning: %s", arg);
+		  return ((char *)arg);
+		}
+	      retpathcat (swin32_path);
+	      free (swin32_path);
+	      if (tpath)
+		retpathcat ("\"");
+	      return ScrubRetpath (retpath);
+	    }
+	  debug_printf("returning: %s", arg);
+	  return ((char *)arg);
+	case '\'':
+	  //
+	  // Handle a single quote case.
+	  //
+	  debug_printf ("spath: %s", spath);
+	  if (spath[1] == '/')
+	    {
+	      retpathcpy ("'");
+	      char *tpath = strchr(&spath[1], '\'');
+	      if (tpath)
+		*tpath = (char)NULL;
+	      char *swin32_path = arg_heuristic (&spath[1]);
+	      if (swin32_path == &spath[1])
+		{
+		  debug_printf("returning: %s", arg);
+		  return ((char *)arg);
+		}
+	      retpathcat (swin32_path);
+	      free (swin32_path);
+	      if (tpath)
+		retpathcat ("'");
+	      return ScrubRetpath (retpath);
+	    }
+	  debug_printf("returning: %s", arg);
+	  return ((char *)arg);
+	default:
+	  //
+	  // This takes care of variable_foo=/bar/baz
+	  //
+	  if ((sspath = strchr(spath, '=')) && (sspath[1] == '/'))
+	    {
+	      sspath[1] = '\0';
+	      retpathcpy (spath);
+	      sspath[1] = '/';
+	      char *swin32_path = arg_heuristic (&sspath[1]);
+	      if (swin32_path == &sspath[1])
+		{
+		  debug_printf("returning: %s", arg);
+		  return ((char *)arg);
+		}
+	      retpathcat (swin32_path);
+	      free (swin32_path);
+	      return ScrubRetpath (retpath);
+	    }
+	  //
+	  // Oh well, nothing special found, set win32_path same as path.
+	  //
+	  debug_printf("returning: %s", arg);
+	  return ((char *)arg);
+	}
+      }
+    }
+  // I should not get to this point.
+  assert (false);
+  debug_printf("returning: %s", arg);
+  return ScrubRetpath (retpath);
+}
+
 /******************** Exported Path Routines *********************/
 
 /* Cover functions to the path conversion routines.
@@ -4572,6 +5200,15 @@
   else
     tocopy = posix;
 
+  // Make sure that we have forward slashes always.
+  char *pstr;
+  pstr = strchr(tocopy, '\\');
+  while (pstr)
+    {
+      *pstr = '/';
+      pstr = strchr(pstr, '\\');
+    }
+
   debug_printf ("posix %s", posix);
   if (strlen (tocopy) >= ulen)
     {
diff -Naur curr_cyg/winsup/cygwin/spawn.cc curr_msys/winsup/cygwin/spawn.cc
--- curr_cyg/winsup/cygwin/spawn.cc	2013-07-21 23:30:19.000000000 +0400
+++ curr_msys/winsup/cygwin/spawn.cc	2013-07-22 06:34:55.000000000 +0400
@@ -407,12 +407,26 @@
 	  moreinfo->argc = newargv.argc;
 	  moreinfo->argv = newargv;
 	}
-      else if (!cmd.fromargv (newargv, real_path.get_win32 (),
+      else
+    {
+	    for (int i = 0; i < newargv.argc; i++)
+	      {
+            //convert argv to win32
+	        int newargvlen = strlen (newargv[i]);
+	        char *tmpbuf = (char *)malloc (newargvlen + 1);
+	        memcpy (tmpbuf, newargv[i], newargvlen + 1);
+	        tmpbuf = arg_heuristic(tmpbuf);
+	        debug_printf("newargv[%d] = %s", i, newargv[i]);
+	        newargv.replace (i, tmpbuf);
+	        free (tmpbuf);
+	      }
+        if (!cmd.fromargv (newargv, real_path.get_win32 (),
 				   real_path.iscygexec ()))
-	{
-	  res = -1;
-	  goto out;
-	}
+	      {
+	        res = -1;
+	        goto out;
+	      }
+    }
 
 
       if (mode != _P_OVERLAY || !real_path.iscygexec ()
@@ -537,11 +551,11 @@
 
   cygbench ("spawn-worker");
 
-  if (!real_path.iscygexec())
+  if (!real_path.iscygexec ())
     ::cygheap->fdtab.set_file_pointers_for_exec ();
 
   moreinfo->envp = build_env (envp, envblock, moreinfo->envc,
-			      real_path.iscygexec ());
+			      real_path.iscygexec (), real_path.iscygexec ());
   if (!moreinfo->envp || !envblock)
     {
       set_errno (E2BIG);
diff -Naur curr_cyg/winsup/cygwin/uname.cc curr_msys/winsup/cygwin/uname.cc
--- curr_cyg/winsup/cygwin/uname.cc	2013-07-21 23:30:19.000000000 +0400
+++ curr_msys/winsup/cygwin/uname.cc	2013-07-22 06:34:55.000000000 +0400
@@ -29,7 +29,9 @@
   char *snp = strstr  (cygwin_version.dll_build_date, "SNP");
 
   memset (name, 0, sizeof (*name));
-  __small_sprintf (name->sysname, "CYGWIN_%s", wincap.osname ());
+  char* msystem = getenv("MSYSTEM");
+  const char *msystem_cygwin = "CYGWIN";
+  __small_sprintf (name->sysname, "%s_%s", msystem ? msystem : msystem_cygwin, wincap.osname ());
 
   /* Add a hint to the sysname, that we're running under WOW64.  This might
      give an early clue if somebody encounters problems. */
diff -Naur curr_cyg/winsup/cygwin/winf.h curr_msys/winsup/cygwin/winf.h
--- curr_cyg/winsup/cygwin/winf.h	2013-07-21 23:30:19.000000000 +0400
+++ curr_msys/winsup/cygwin/winf.h	2013-07-22 06:34:55.000000000 +0400
@@ -53,6 +53,10 @@
 	calloced = 1;
       }
   }
+  void replace (int i, const char *arg)
+  {
+    argv[i] = cstrdup1 (arg);
+  }
   void dup_all ()
   {
     for (int i = calloced; i < argc; i++)
@@ -76,6 +80,8 @@
   void prepend (const char *, int);
   void __reg2 finish (bool);
   bool __reg3 fromargv(av&, const char *, bool);;
+  operator char *() {return buf;}
+  size_t idx() {return ix;}
   operator size_t () const { return ix + 1; }
   operator const char * () const { return buf; }
   operator wchar_t * ()

Re: MSYS mode (continue)

[Christopher Faylor]

On Fri, Jul 26, 2013 at 08:02:45AM +0400, LRN wrote:
>Please specify how the hooks will look, now that you know which points
>of the code need to be hooked up.

Apparently you haven't read any of the past discussion and are just
trying to jump into the middle without doing any homework.

We are still discussing implementation.  That is the whole point of
this thread.

I did provide a straw man proposal which showed what a hook could look
like, however.

cgf

Re: MSYS mode (continue)

[Corinna Vinschen]

On Jul 25 16:53, Christopher Faylor wrote:
> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote:
> >> 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.
> >
> >And that's the bit where I disagree.  Sure, some scripting tools might 
> >not need adjustment, so long as their interpreter was $MSYS-enabled 
> >(e.g. automake -> msys-perl, msys-bash) -- because the script will "see" 
> >dos-style paths, so its interpreter better be able to handle them.
> >
> >But unless you restrict yourself to only passing around relative paths 
> >(or god forbid, that old "unity mount" idea), any .exe will need to live 
> >in one world or the other. Otherwise, how would paths be interpreted? 
> >Using which tools' mount table?
> >
> >Naturally from the command line I can compensate:
> >
> >msys$  /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath 
> >-d /msys/mount/table/path) )
> >
> >but yee gods that'd be annoying in any automated setting.
> 
> I don't know if this helps but the vague plan is to now have two DLLs
> where before you only had one.  You'd still be providing "MSYS" binaries
> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
> small dll which relied on cygwin1.dll for all of the heavy lifting.
> 
> You'd still have a normal MSYS distribution and it would still, in theory,
> support everything (with the possible exception of very lax security) that
> the old MSYS did.  An MSYS release would consist of MSYS*.dll, cygwin1.dll,
> bash, etc.

Here's where I disagree.  I think the executables should *not* rely on
MSYS.dll being available.  Ideally the executables are linked against
the Cygwin DLL and MSYS.dll is called as a side-by-side implementation.
So, if MSYS.dll isn't available, they still function as normal Cygwin
executables.  That's why I proposed the solution(s) in
http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html

Assuming you implement it the first way, you get an executable linked
against a crt0.o which tries a LoadLibrary("MSYS.dll").  If it fails,
the executable does business as usual.  It will not fail, because
there's still the Cygwin DLL.

If LoadLib worked, crt0 calls GetProcAddress("__msys_hook") and then
__msys_hook().  __msys_hook collects the hook function pointers and
sends them to the CYgwin DLL via a call to cygwin_internal(CW_HOOK,
&hook_list).  Voila, the hooks are set up, we're in MSYS mode.


Another alternative would be if the Cygwin DLL itself had a switch to
load the MSYS dll (export CYGWIN=MSYS ;)).  This would allows MSYS mode
even with completely unchanged executables.


> I don't think anyone was proposing seamless interoperation between MSYS
> and cygwin.

Yes, I honestly think this would be possible and desirable.  MSYS is
just a tiny change for a specific task in comparison to the default
Cygwin mode.  MSYS would concentrate on this task and the required tools
for this task and the rest could be stock Cygwin distro.


Btw., this does *not* mean I agree with all changes MSYS is doing.  I
have a hard time to see the necessity changing the /etc/fstab layout,
for instance, since it doesn't add or change anything you can't have
with the standard fstab.


Corinna

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

Re: MSYS mode (continue)

[Christopher Faylor]

On Fri, Jul 26, 2013 at 10:15:10AM +0200, Corinna Vinschen wrote:
>On Jul 25 16:53, Christopher Faylor wrote:
>> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote:
>> >> 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.
>> >
>> >And that's the bit where I disagree.  Sure, some scripting tools might 
>> >not need adjustment, so long as their interpreter was $MSYS-enabled 
>> >(e.g. automake -> msys-perl, msys-bash) -- because the script will "see" 
>> >dos-style paths, so its interpreter better be able to handle them.
>> >
>> >But unless you restrict yourself to only passing around relative paths 
>> >(or god forbid, that old "unity mount" idea), any .exe will need to live 
>> >in one world or the other. Otherwise, how would paths be interpreted? 
>> >Using which tools' mount table?
>> >
>> >Naturally from the command line I can compensate:
>> >
>> >msys$  /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath 
>> >-d /msys/mount/table/path) )
>> >
>> >but yee gods that'd be annoying in any automated setting.
>> 
>> I don't know if this helps but the vague plan is to now have two DLLs
>> where before you only had one.  You'd still be providing "MSYS" binaries
>> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
>> small dll which relied on cygwin1.dll for all of the heavy lifting.
>> 
>> You'd still have a normal MSYS distribution and it would still, in theory,
>> support everything (with the possible exception of very lax security) that
>> the old MSYS did.  An MSYS release would consist of MSYS*.dll, cygwin1.dll,
>> bash, etc.
>
>Here's where I disagree.  I think the executables should *not* rely on
>MSYS.dll being available.  Ideally the executables are linked against
>the Cygwin DLL and MSYS.dll is called as a side-by-side implementation.
>So, if MSYS.dll isn't available, they still function as normal Cygwin
>executables.  That's why I proposed the solution(s) in
>http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html


>Assuming you implement it the first way, you get an executable linked
>against a crt0.o which tries a LoadLibrary("MSYS.dll").  If it fails,
>the executable does business as usual.  It will not fail, because
>there's still the Cygwin DLL.
>
>If LoadLib worked, crt0 calls GetProcAddress("__msys_hook") and then
>__msys_hook().  __msys_hook collects the hook function pointers and
>sends them to the CYgwin DLL via a call to cygwin_internal(CW_HOOK,
>&hook_list).  Voila, the hooks are set up, we're in MSYS mode.
>
>
>Another alternative would be if the Cygwin DLL itself had a switch to
>load the MSYS dll (export CYGWIN=MSYS ;)).  This would allows MSYS mode
>even with completely unchanged executables.
>
>
>> I don't think anyone was proposing seamless interoperation between MSYS
>> and cygwin.
>
>Yes, I honestly think this would be possible and desirable.  MSYS is
>just a tiny change for a specific task in comparison to the default
>Cygwin mode.  MSYS would concentrate on this task and the required tools
>for this task and the rest could be stock Cygwin distro.
>
>
>Btw., this does *not* mean I agree with all changes MSYS is doing.  I
>have a hard time to see the necessity changing the /etc/fstab layout,
>for instance, since it doesn't add or change anything you can't have
>with the standard fstab.

So, you did.  I missed the ramifications of that message.  I guess
that's why Chuck was confused.  I'm suggesting something different so
we're all confused.

This does not address the problem that there are local modifications in
some MSYS utilities.  This doesn't solve the problem of make
understanding c:\foo.  Doesn't MSYS bash allow constructs of the form
c:\foo without making that c:foo?  If so, the DLL isn't going to help
there.

I don't think that we should be seeing the word "msys" throughout the
DLL source code.  The hooks could all be just named "cygwin_hook"
generic and, maybe we should recognize something like a
"CYGWIN=PRELOAD=MSYS.dll".  I don't know how the MSYS folks would
feel about that however.  Having to tell their users that they need
to set an environment variable before they do anything seems like it
would be a maintenance headache.

As far as /etc/fstab is concerned, since they were the first to
implement the notion, I would assume that they don't want to have to
tell their userbase to change any more than we would want to have to
tell every Cygwin user that they have to edit a file to make the
next version of Cygwin work correctly.

cgf

Re: MSYS mode (continue)

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26.07.2013 19:14, Christopher Faylor wrote:
> On Fri, Jul 26, 2013 at 10:15:10AM +0200, Corinna Vinschen wrote:
>> On Jul 25 16:53, Christopher Faylor wrote:
>>> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote:
>>>>> 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.
>>>>
>>>> And that's the bit where I disagree.  Sure, some scripting tools might 
>>>> not need adjustment, so long as their interpreter was $MSYS-enabled 
>>>> (e.g. automake -> msys-perl, msys-bash) -- because the script will "see" 
>>>> dos-style paths, so its interpreter better be able to handle them.
>>>>
>>>> But unless you restrict yourself to only passing around relative paths 
>>>> (or god forbid, that old "unity mount" idea), any .exe will need to live 
>>>> in one world or the other. Otherwise, how would paths be interpreted? 
>>>> Using which tools' mount table?
>>>>
>>>> Naturally from the command line I can compensate:
>>>>
>>>> msys$  /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath 
>>>> -d /msys/mount/table/path) )
>>>>
>>>> but yee gods that'd be annoying in any automated setting.
>>>
>>> I don't know if this helps but the vague plan is to now have two DLLs
>>> where before you only had one.  You'd still be providing "MSYS" binaries
>>> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
>>> small dll which relied on cygwin1.dll for all of the heavy lifting.
>>>
>>> You'd still have a normal MSYS distribution and it would still, in theory,
>>> support everything (with the possible exception of very lax security) that
>>> the old MSYS did.  An MSYS release would consist of MSYS*.dll, cygwin1.dll,
>>> bash, etc.
>>
>> Here's where I disagree.  I think the executables should *not* rely on
>> MSYS.dll being available.  Ideally the executables are linked against
>> the Cygwin DLL and MSYS.dll is called as a side-by-side implementation.
>> So, if MSYS.dll isn't available, they still function as normal Cygwin
>> executables.  That's why I proposed the solution(s) in
>> http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html
> 
> 
>> Assuming you implement it the first way, you get an executable linked
>> against a crt0.o which tries a LoadLibrary("MSYS.dll").  If it fails,
>> the executable does business as usual.  It will not fail, because
>> there's still the Cygwin DLL.
>>
>> If LoadLib worked, crt0 calls GetProcAddress("__msys_hook") and then
>> __msys_hook().  __msys_hook collects the hook function pointers and
>> sends them to the CYgwin DLL via a call to cygwin_internal(CW_HOOK,
>> &hook_list).  Voila, the hooks are set up, we're in MSYS mode.
>>
>>
>> Another alternative would be if the Cygwin DLL itself had a switch to
>> load the MSYS dll (export CYGWIN=MSYS ;)).  This would allows MSYS mode
>> even with completely unchanged executables.
>>
>>
>>> I don't think anyone was proposing seamless interoperation between MSYS
>>> and cygwin.
>>
>> Yes, I honestly think this would be possible and desirable.  MSYS is
>> just a tiny change for a specific task in comparison to the default
>> Cygwin mode.  MSYS would concentrate on this task and the required tools
>> for this task and the rest could be stock Cygwin distro.
>>
>>
>> Btw., this does *not* mean I agree with all changes MSYS is doing.  I
>> have a hard time to see the necessity changing the /etc/fstab layout,
>> for instance, since it doesn't add or change anything you can't have
>> with the standard fstab.
> 
> So, you did.  I missed the ramifications of that message.  I guess
> that's why Chuck was confused.  I'm suggesting something different so
> we're all confused.
> 
> This does not address the problem that there are local modifications in
> some MSYS utilities.  This doesn't solve the problem of make
> understanding c:\foo.
Yep, you need make sure that make is not configured with ac_cv_dos_paths=no.

>  Doesn't MSYS bash allow constructs of the form
> c:\foo without making that c:foo?
It doesn't. You have to carefully avoid the use of '\' everywhere (much
easier than escaping it).

> I don't think that we should be seeing the word "msys" throughout the
> DLL source code.  The hooks could all be just named "cygwin_hook"
> generic and, maybe we should recognize something like a
> "CYGWIN=PRELOAD=MSYS.dll".  I don't know how the MSYS folks would
> feel about that however.  Having to tell their users that they need
> to set an environment variable before they do anything seems like it
> would be a maintenance headache.
MSYS actually does require an environment variable to be set.
MSYSTEM=MINGW32 or MSYSTEM=MSYS (at least MSYS1 did, if you wanted to
use it with MinGW, and MSYS2 does, in its current form). Most users must
have MSYSTEM=MINGW32, otherwise their build system type will be
misdetected (as MSYSTEM affects the name returned by uname() syscall).

In MSYS1 this was done by the msys.bat batch file that was used to
launch the shell.

> 
> As far as /etc/fstab is concerned, since they were the first to
> implement the notion, I would assume that they don't want to have to
> tell their userbase to change any more than we would want to have to
> tell every Cygwin user that they have to edit a file to make the
> next version of Cygwin work correctly.

I wouldn't worry about this too much. MSYS2, being nearly pure Cygwin,
may require more elaborate installation procedures than MSYS1 did. These
procedures could include an /etc/fstab conversion script, if users
upgrade from MSYS1.

MSYS1 compatibility might be interesting for some people (for mingw.org
- - definitely), but not for everyone.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJR8po9AAoJEOs4Jb6SI2CwC4sIAKW1+EdYl/OqCQDzfAnGICiw
uPhWlOCHnbKzUpK1URGB0DShU99YjI420hSlGwa8vSJss32DHFiLi9xpjBos5diV
nm5hc2B8MJ9tF0L0amPfJ+6dfUlwHwApKfiSWSxnZA4Sw+ZbPM3ImqHqAWibFP/3
poY0t0NisBFKsX7wZ8J23/5k4DcscEoXMUFowgatel6VTPxK47sQ1cOa6WmLMJCu
p0UUJvoGSsH6eskE1sXgucqkke60niRsWZCB8Qw2bh6Fkzk+J3A+YDjoGf+g58vx
vXXcB7G+1h7Wo5IDPbcv8PgQARRwB/0Z6dD1Dde1wF8hqreq0EQZMrA6n8bTmMw=
=d1B2
-----END PGP SIGNATURE-----

Re: MSYS mode (continue)

[Corinna Vinschen]

On Jul 26 11:14, Christopher Faylor wrote:
> On Fri, Jul 26, 2013 at 10:15:10AM +0200, Corinna Vinschen wrote:
> >On Jul 25 16:53, Christopher Faylor wrote:
> >> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote:
> >> >> 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.
> >> >
> >> >And that's the bit where I disagree.  Sure, some scripting tools might 
> >> >not need adjustment, so long as their interpreter was $MSYS-enabled 
> >> >(e.g. automake -> msys-perl, msys-bash) -- because the script will "see" 
> >> >dos-style paths, so its interpreter better be able to handle them.
> >> >
> >> >But unless you restrict yourself to only passing around relative paths 
> >> >(or god forbid, that old "unity mount" idea), any .exe will need to live 
> >> >in one world or the other. Otherwise, how would paths be interpreted? 
> >> >Using which tools' mount table?
> >> >
> >> >Naturally from the command line I can compensate:
> >> >
> >> >msys$  /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath 
> >> >-d /msys/mount/table/path) )
> >> >
> >> >but yee gods that'd be annoying in any automated setting.
> >> 
> >> I don't know if this helps but the vague plan is to now have two DLLs
> >> where before you only had one.  You'd still be providing "MSYS" binaries
> >> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
> >> small dll which relied on cygwin1.dll for all of the heavy lifting.
> >> 
> >> You'd still have a normal MSYS distribution and it would still, in theory,
> >> support everything (with the possible exception of very lax security) that
> >> the old MSYS did.  An MSYS release would consist of MSYS*.dll, cygwin1.dll,
> >> bash, etc.
> >
> >Here's where I disagree.  I think the executables should *not* rely on
> >MSYS.dll being available.  Ideally the executables are linked against
> >the Cygwin DLL and MSYS.dll is called as a side-by-side implementation.
> >So, if MSYS.dll isn't available, they still function as normal Cygwin
> >executables.  That's why I proposed the solution(s) in
> >http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html
> 
> 
> >Assuming you implement it the first way, you get an executable linked
> >against a crt0.o which tries a LoadLibrary("MSYS.dll").  If it fails,
> >the executable does business as usual.  It will not fail, because
> >there's still the Cygwin DLL.
> >
> >If LoadLib worked, crt0 calls GetProcAddress("__msys_hook") and then
> >__msys_hook().  __msys_hook collects the hook function pointers and
> >sends them to the CYgwin DLL via a call to cygwin_internal(CW_HOOK,
> >&hook_list).  Voila, the hooks are set up, we're in MSYS mode.
> >
> >
> >Another alternative would be if the Cygwin DLL itself had a switch to
> >load the MSYS dll (export CYGWIN=MSYS ;)).  This would allows MSYS mode
> >even with completely unchanged executables.
> >
> >
> >> I don't think anyone was proposing seamless interoperation between MSYS
> >> and cygwin.
> >
> >Yes, I honestly think this would be possible and desirable.  MSYS is
> >just a tiny change for a specific task in comparison to the default
> >Cygwin mode.  MSYS would concentrate on this task and the required tools
> >for this task and the rest could be stock Cygwin distro.
> >
> >
> >Btw., this does *not* mean I agree with all changes MSYS is doing.  I
> >have a hard time to see the necessity changing the /etc/fstab layout,
> >for instance, since it doesn't add or change anything you can't have
> >with the standard fstab.
> 
> So, you did.  I missed the ramifications of that message.  I guess
> that's why Chuck was confused.  I'm suggesting something different so
> we're all confused.
> 
> This does not address the problem that there are local modifications in
> some MSYS utilities.  This doesn't solve the problem of make
> understanding c:\foo.  Doesn't MSYS bash allow constructs of the form
> c:\foo without making that c:foo?  If so, the DLL isn't going to help
> there.

That's what I talked about in my next to last paragraph.  As far as I'm
concerned, MSYS would be a DLL tweaking the behaviour of Cygwin via the
hooks, *plus* a set of tools specificially tweaked where necessary for
what it's supposed to do.  Make is one example, bash another, gcc would
target mingw32 by default, stuff like that.  Still, that doesn't mean
that every tool has to be tweaked.  Most tools would work OOTB.

> I don't think that we should be seeing the word "msys" throughout the
> DLL source code.  The hooks could all be just named "cygwin_hook"
> generic

Actually, I'd prefer to have only a single foreign environment using
the Cygwin DLL, not a whole bunch.  This implies that I could live
with a single occurence of the work "MSYS" in the Cygwin code.

> and, maybe we should recognize something like a
> "CYGWIN=PRELOAD=MSYS.dll".  I don't know how the MSYS folks would
> feel about that however.  Having to tell their users that they need
> to set an environment variable before they do anything seems like it
> would be a maintenance headache.

I don't know if that's a problem for them, but this reminds me... maybe
we can use the LD_PRELOAD mechanism in hookapi.cc for that?

> As far as /etc/fstab is concerned, since they were the first to
> implement the notion, I would assume that they don't want to have to
> tell their userbase to change any more than we would want to have to
> tell every Cygwin user that they have to edit a file to make the
> next version of Cygwin work correctly.

Backward compatibility?  What a weird concept :)


Corinna

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

Re: MSYS mode (continue)

[Corinna Vinschen]

On Jul 26 19:48, LRN wrote:
> On 26.07.2013 19:14, Christopher Faylor wrote:
> > On Fri, Jul 26, 2013 at 10:15:10AM +0200, Corinna Vinschen wrote:
> > I don't think that we should be seeing the word "msys" throughout the
> > DLL source code.  The hooks could all be just named "cygwin_hook"
> > generic and, maybe we should recognize something like a
> > "CYGWIN=PRELOAD=MSYS.dll".  I don't know how the MSYS folks would
> > feel about that however.  Having to tell their users that they need
> > to set an environment variable before they do anything seems like it
> > would be a maintenance headache.
> MSYS actually does require an environment variable to be set.
> MSYSTEM=MINGW32 or MSYSTEM=MSYS (at least MSYS1 did, if you wanted to
> use it with MinGW, and MSYS2 does, in its current form). Most users must
> have MSYSTEM=MINGW32, otherwise their build system type will be
> misdetected (as MSYSTEM affects the name returned by uname() syscall).
> 
> In MSYS1 this was done by the msys.bat batch file that was used to
> launch the shell.

So that shouldn't be much of a problem.

> > As far as /etc/fstab is concerned, since they were the first to
> > implement the notion, I would assume that they don't want to have to
> > tell their userbase to change any more than we would want to have to
> > tell every Cygwin user that they have to edit a file to make the
> > next version of Cygwin work correctly.
> 
> I wouldn't worry about this too much. MSYS2, being nearly pure Cygwin,
> may require more elaborate installation procedures than MSYS1 did. These
> procedures could include an /etc/fstab conversion script, if users
> upgrade from MSYS1.
> 
> MSYS1 compatibility might be interesting for some people (for mingw.org
> - - definitely), but not for everyone.

Wouldn't a generic conversion script be in order then, which also
enforces the noacl setting if desired?


Corinna

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

Re: MSYS mode (continue)

[Christopher Faylor]

On Fri, Jul 26, 2013 at 06:12:05PM +0200, Corinna Vinschen wrote:
>I don't know if that's a problem for them, but this reminds me... maybe
>we can use the LD_PRELOAD mechanism in hookapi.cc for that?

I was thinking that we'd use something like that (re my use of PRELOAD
and your use of CW_HOOK) but, you're right.  Someone could potentially
implement MSYS.dll via LD_PRELOAD:

LD_PRELOAD=msys.dll

and then have msys.dll hook the functions that it is interested in using
via CW_HOOK.

cgf

Re: MSYS mode (continue)

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

On 7/26/2013 9:37 AM, Christopher Faylor wrote:
> On Fri, Jul 26, 2013 at 06:12:05PM +0200, Corinna Vinschen wrote:
>> I don't know if that's a problem for them, but this reminds me... maybe
>> we can use the LD_PRELOAD mechanism in hookapi.cc for that?
> 
> I was thinking that we'd use something like that (re my use of PRELOAD
> and your use of CW_HOOK) but, you're right.  Someone could potentially
> implement MSYS.dll via LD_PRELOAD:
> 
> LD_PRELOAD=msys.dll
> 
> and then have msys.dll hook the functions that it is interested in using
> via CW_HOOK.

By the way: can we make LD_PRELOAD hook all modules, not just the main program?
If my LD_PRELOADed module hooks write(2) in foo.exe, which uses bar.dll, then
write(2) from foo.exe will be intercepted, but write(2) from bar.dll won't be
--- only foo.exe's import table is munged.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: MSYS mode (continue)

[Corinna Vinschen]

On Jul 26 12:37, Christopher Faylor wrote:
> On Fri, Jul 26, 2013 at 06:12:05PM +0200, Corinna Vinschen wrote:
> >I don't know if that's a problem for them, but this reminds me... maybe
> >we can use the LD_PRELOAD mechanism in hookapi.cc for that?
> 
> I was thinking that we'd use something like that (re my use of PRELOAD
> and your use of CW_HOOK) but, you're right.  Someone could potentially
> implement MSYS.dll via LD_PRELOAD:
> 
> LD_PRELOAD=msys.dll
> 
> and then have msys.dll hook the functions that it is interested in using
> via CW_HOOK.

Two points come to mind.

- Does CW_HOOK still work?  I had to change a lot of code in
  hook_or_detect_cygwin to handle big executables and 32 vs. 64 bit, so
  I have no idea if it still does the righht thing in terms of CW_HOOK.

- Isn't CW_HOOK a bit heavy handed for MSYS?  MSYS only replaces partial
  functionality, not entire functions.  Something like a CW_HOOK2 which
  only results in Cygwin calling certain function pointers for minor
  tweaks could be the result...


Corinna

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

Re: MSYS mode (continue)

[Christopher Faylor]

On Fri, Jul 26, 2013 at 06:47:16PM +0200, Corinna Vinschen wrote:
>On Jul 26 12:37, Christopher Faylor wrote:
>> On Fri, Jul 26, 2013 at 06:12:05PM +0200, Corinna Vinschen wrote:
>> >I don't know if that's a problem for them, but this reminds me... maybe
>> >we can use the LD_PRELOAD mechanism in hookapi.cc for that?
>> 
>> I was thinking that we'd use something like that (re my use of PRELOAD
>> and your use of CW_HOOK) but, you're right.  Someone could potentially
>> implement MSYS.dll via LD_PRELOAD:
>> 
>> LD_PRELOAD=msys.dll
>> 
>> and then have msys.dll hook the functions that it is interested in using
>> via CW_HOOK.
>
>Two points come to mind.
>
>- Does CW_HOOK still work?  I had to change a lot of code in
>  hook_or_detect_cygwin to handle big executables and 32 vs. 64 bit, so
>  I have no idea if it still does the righht thing in terms of CW_HOOK.

Who knows?  That's something that should be fixed, regardless.

>- Isn't CW_HOOK a bit heavy handed for MSYS?  MSYS only replaces partial
>  functionality, not entire functions.  Something like a CW_HOOK2 which
>  only results in Cygwin calling certain function pointers for minor
>  tweaks could be the result...

MSYS is free to call the old function first if it needs to and then modify
the output.  That's basically what any hook would do anyway.

Daniel Colascione's point is a stumbling block though since the
LD_PRELOAD method doesn't currently allow hooking anything other than
the main executable.  That means that, say, ncurses wouldn't know about
an MSYS-hooked uname.  It is possible to work around that but it would
require the addition of new code to the LD_PRELOAD mechanism, requiring
that we keep a table of hooked functions.

cgf

Re: MSYS mode (continue)

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

On 7/26/2013 10:01 AM, Christopher Faylor wrote:
> Daniel Colascione's point is a stumbling block though since the
> LD_PRELOAD method doesn't currently allow hooking anything other than
> the main executable.  That means that, say, ncurses wouldn't know about
> an MSYS-hooked uname.  It is possible to work around that but it would
> require the addition of new code to the LD_PRELOAD mechanism, requiring
> that we keep a table of hooked functions.

You don't need to maintain your own table. When you hook, you just have to munge
all the import tables of all currently-loaded modules, then munge the export
table of the module you want to hook. Munging the export table will take care of
any modules that load in the future.





[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: MSYS mode (continue)

[Christopher Faylor]

On Fri, Jul 26, 2013 at 10:03:42AM -0700, Daniel Colascione wrote:
>On 7/26/2013 10:01 AM, Christopher Faylor wrote:
>>Daniel Colascione's point is a stumbling block though since the
>>LD_PRELOAD method doesn't currently allow hooking anything other than
>>the main executable.  That means that, say, ncurses wouldn't know about
>>an MSYS-hooked uname.  It is possible to work around that but it would
>>require the addition of new code to the LD_PRELOAD mechanism, requiring
>>that we keep a table of hooked functions.
>
>You don't need to maintain your own table.  When you hook, you just
>have to munge all the import tables of all currently-loaded modules,
>then munge the export table of the module you want to hook.  Munging
>the export table will take care of any modules that load in the future.

I think it would be faster to keep a list of functions since, otherwise,
on fork, it seems like you'd have to walk the whole Cygwin export list,
looking for functions to re-target.

cgf

Re: MSYS mode (continue)

[Yaakov (Cygwin/X)]

On 2013-07-26 11:47, Corinna Vinschen wrote:
> - Does CW_HOOK still work?  I had to change a lot of code in
>    hook_or_detect_cygwin to handle big executables and 32 vs. 64 bit, so
>    I have no idea if it still does the righht thing in terms of CW_HOOK.

datefudge (in Ports) seems to work correctly on x86_64, so I believe so.


Yaakov

Re: MSYS mode (continue)

[Charles Wilson]

On 7/26/2013 4:15 AM, Corinna Vinschen wrote:
> On Jul 25 16:53, Christopher Faylor wrote:
>> I don't know if this helps but the vague plan is to now have two DLLs
>> where before you only had one.  You'd still be providing "MSYS" binaries
>> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a
>> small dll which relied on cygwin1.dll for all of the heavy lifting.
>>
>> You'd still have a normal MSYS distribution and it would still, in theory,
>> support everything (with the possible exception of very lax security) that
>> the old MSYS did.  An MSYS release would consist of MSYS*.dll, cygwin1.dll,
>> bash, etc.
>
> Here's where I disagree.  I think the executables should *not* rely on
> MSYS.dll being available.  Ideally the executables are linked against
> the Cygwin DLL and MSYS.dll is called as a side-by-side implementation.
> So, if MSYS.dll isn't available, they still function as normal Cygwin
> executables.  That's why I proposed the solution(s) in
> http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html

So, in this proposal I'd have an "msys" directory structure, with 
cygwin1.dll, an /etc/fstab, and lots of plain-old-cygwin executables, 
bit-for-bit identical to the executables in my "real" cygwin 
installation/directory structure.

On executable launch, ALL such applications would check for the hook DLL 
(as directed by an env variable, perhaps, or some other mechanism -- 
maybe encoded in a known-present file, like.../etc/fstab? [1])  and if 
present, load it.

Even the (bit-for-bit-identical) apps in my "real" cygwin installation 
would do this -- but because (a) they don't have that env setting or 
fstab setting, and (b) even if they did, the special msys-hook dll isn't 
present in that tree -- so nothing actually happens in that situation.

Now, back in my MSYS-on-cygwin installation, there are SOME executables 
that are actually *different* that the corresponding ones in 
real-cygwin-land.  Stuff like make, bash, perl, etc -- all may have been 
compiled with different options because we (the mingw/msys people) want 
them to behave differently, in ways that can't automatically be handled 
by the hooked changes in cygwin1.dll's own behavior.

Have I got that all correct?



[1] I think this is better than an environment var, because then my 
"regular" cygwin tree and my "msys" cygwin tree would both just work, 
without needed extraneous global env vars that might interfere with the 
other's operation.

In fact, I might want *different* CYGWIN env var settings for the two 
trees, but unless I set them in the global env then StartMenu-launched 
apps lose out.

Could we maybe extend the CYGWIN env var idea to files, similar to the 
/etc/fstab[.d] structure, which are then *augmented* by $CYGWIN?

e.g.  in my msys-on-cygwin tree, I might have

/etc/cygwin_settings
    hook=/bin/msys-hook.dll
    export
    glob:ignorecase
    winsymlinks:nativestrict
/etc/cygwin_settings.d/user
    error_start:c:\msys\bin\gdb.exe

But in my "real" cygwin tree, I might have

/etc/cygwin_settings
    proc_retry:1
/etc/cygwin_settings.d/user
    pipe_byte

> Assuming you implement it the first way, you get an executable linked
> against a crt0.o which tries a LoadLibrary("MSYS.dll").  If it fails,
> the executable does business as usual.  It will not fail, because
> there's still the Cygwin DLL.
>
> If LoadLib worked, crt0 calls GetProcAddress("__msys_hook") and then
> __msys_hook().  __msys_hook collects the hook function pointers and
> sends them to the CYgwin DLL via a call to cygwin_internal(CW_HOOK,
> &hook_list).  Voila, the hooks are set up, we're in MSYS mode.
>
>
> Another alternative would be if the Cygwin DLL itself had a switch to
> load the MSYS dll (export CYGWIN=MSYS ;)).  This would allows MSYS mode
> even with completely unchanged executables.

Right -- but *some* executables would need to actually BE different, 
aside from the underlying posix library's behavioral changes, to get a 
"real" MSYS environment.

>> I don't think anyone was proposing seamless interoperation between MSYS
>> and cygwin.
>
> Yes, I honestly think this would be possible and desirable.  MSYS is
> just a tiny change for a specific task in comparison to the default
> Cygwin mode.  MSYS would concentrate on this task and the required tools
> for this task and the rest could be stock Cygwin distro.

I think that would, in fact, work -- but I think the list of tools that 
would need compile-time changes is larger than you would hope. But...IMO 
that's ok.  MSYS's goal was to be a *minimal* system...NOT an alternate 
cygwin.  If this proposal (a) makes the msys "fork" a non-fork, AND 
easier to maintain, and (b) incidentally means that SOMETIMES you might 
be able to "drop in" a stock cygwin .exe and it might just work -- no 
guarantees, you break it you bought it, we're just mean -- then it's a 
win overall.

The MSYS team would just provide patched and (re)compiled versions of 
most of their current set of tools...and if users wanted to "drop in" 
(e.g.) git.exe, well they are welcome to try it.  No support offered or 
guaranteed, and they might just get lucky.

> Btw., this does *not* mean I agree with all changes MSYS is doing.  I
> have a hard time to see the necessity changing the /etc/fstab layout,
> for instance, since it doesn't add or change anything you can't have
> with the standard fstab.

As cgf pointed out, if "we" (cygwin) are trying to come up with an easy 
upgrade path for existing users of MSYS, then we (mingw/msys) users 
would prefer not to have to change our existing fstab format on all of 
our installations.  Unless you (we, cygwin) automate that somehow...

--
Chuck

Re: MSYS mode (continue)

[NightStrike]

On Fri, Jul 26, 2013 at 11:06 PM, Charles Wilson wrote:
> On 7/26/2013 4:15 AM, Corinna Vinschen wrote:
>> Another alternative would be if the Cygwin DLL itself had a switch to
>> load the MSYS dll (export CYGWIN=MSYS ;)).  This would allows MSYS mode
>> even with completely unchanged executables.
>
>
> Right -- but *some* executables would need to actually BE different, aside
> from the underlying posix library's behavioral changes, to get a "real" MSYS
> environment.

Perhaps it would be useful to actually identify which packages have
extenuating needs.  Maybe it's just one or two.  Maybe it's all but
one or two.  I don't think that currently, the problem space is
properly enumerated, but is instead living in the abstract.

Re: MSYS mode (continue)

[Corinna Vinschen]

On Jul 26 23:06, Charles Wilson wrote:
> On 7/26/2013 4:15 AM, Corinna Vinschen wrote:
> >Here's where I disagree.  I think the executables should *not* rely on
> >MSYS.dll being available.  Ideally the executables are linked against
> >the Cygwin DLL and MSYS.dll is called as a side-by-side implementation.
> >So, if MSYS.dll isn't available, they still function as normal Cygwin
> >executables.  That's why I proposed the solution(s) in
> >http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html
> 
> So, in this proposal I'd have an "msys" directory structure, with
> cygwin1.dll, an /etc/fstab, and lots of plain-old-cygwin
> executables, bit-for-bit identical to the executables in my "real"
> cygwin installation/directory structure.
> 
> On executable launch, ALL such applications would check for the hook
> DLL (as directed by an env variable, perhaps, or some other
> mechanism -- maybe encoded in a known-present file,
> like.../etc/fstab? [1])  and if present, load it.

Depends.  If the Cygwin DLL itself cares for loading a side-by-side
MSYS.dll, then yes.  If the crt0.o takes over this job, then only
the applications rebuilt with this crt0.o will do that.

> Now, back in my MSYS-on-cygwin installation, there are SOME
> executables that are actually *different* that the corresponding
> ones in real-cygwin-land.  Stuff like make, bash, perl, etc -- all
> may have been compiled with different options because we (the
> mingw/msys people) want them to behave differently, in ways that
> can't automatically be handled by the hooked changes in
> cygwin1.dll's own behavior.
> 
> Have I got that all correct?

More or less, yes, except for the tiny detail above.

> [1] I think this is better than an environment var, because then my
> "regular" cygwin tree and my "msys" cygwin tree would both just
> work, without needed extraneous global env vars that might interfere
> with the other's operation.
> 
> In fact, I might want *different* CYGWIN env var settings for the
> two trees, but unless I set them in the global env then
> StartMenu-launched apps lose out.

They don't lose if you do it right.  Don't start the application,
start a script or batch file instead.

> Could we maybe extend the CYGWIN env var idea to files, similar to
> the /etc/fstab[.d] structure, which are then *augmented* by $CYGWIN?

Reluctantly so.  Opening files costs time.  Reading the env is extremly
cheap in comparison.

> >Another alternative would be if the Cygwin DLL itself had a switch to
> >load the MSYS dll (export CYGWIN=MSYS ;)).  This would allows MSYS mode
> >even with completely unchanged executables.
> 
> Right -- but *some* executables would need to actually BE different,
> aside from the underlying posix library's behavioral changes, to get
> a "real" MSYS environment.

Yes, that's what I said all the time.  MSYSies will want another make
and maybe another bash.

> The MSYS team would just provide patched and (re)compiled versions
> of most of their current set of tools...and if users wanted to "drop
> in" (e.g.) git.exe, well they are welcome to try it.  No support
> offered or guaranteed, and they might just get lucky.

Yes.  I'm sure this works most of the time and only a couple of tools
really need to be cripp^Waugmented.

> As cgf pointed out, if "we" (cygwin) are trying to come up with an
> easy upgrade path for existing users of MSYS, then we (mingw/msys)
> users would prefer not to have to change our existing fstab format
> on all of our installations.  Unless you (we, cygwin) automate that
> somehow...

I think the latter should be a "we, msys".  Providing an upgrade
script from MSYS to MSYS2 doesn't look like a Cygwin task to me.


Corinna

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

Re: MSYS mode (continue)

[Corinna Vinschen]

On Jul 27 20:17, NightStrike wrote:
> On Fri, Jul 26, 2013 at 11:06 PM, Charles Wilson wrote:
> > On 7/26/2013 4:15 AM, Corinna Vinschen wrote:
> >> Another alternative would be if the Cygwin DLL itself had a switch to
> >> load the MSYS dll (export CYGWIN=MSYS ;)).  This would allows MSYS mode
> >> even with completely unchanged executables.
> >
> >
> > Right -- but *some* executables would need to actually BE different, aside
> > from the underlying posix library's behavioral changes, to get a "real" MSYS
> > environment.
> 
> Perhaps it would be useful to actually identify which packages have
> extenuating needs.  Maybe it's just one or two.  Maybe it's all but
> one or two.  I don't think that currently, the problem space is
> properly enumerated, but is instead living in the abstract.

Very good point.  This would perhaps show us much better where we're
heading here.  From the current input I only see the following required
changes in relation to a stock Cygwin distro:

- make w/ DOS path handling
- gcc targeting Mingw rather than Cygwin.
- Cygwin compiler provided as cross tool $arch-pc-cygwin-gcc, etc.(*)


Corinna

(*) Per my suggestion there would be no MSYS targeting compiler anymore.
    It would target Cygwin and everything else just depends on how the
    MSYS dll gets loaded.

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

Re: MSYS mode (continue)

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29.07.2013 13:29, Corinna Vinschen wrote:
> On Jul 27 20:17, NightStrike wrote:
>> On Fri, Jul 26, 2013 at 11:06 PM, Charles Wilson wrote:
>>> On 7/26/2013 4:15 AM, Corinna Vinschen wrote:
>>>> Another alternative would be if the Cygwin DLL itself had a switch to
>>>> load the MSYS dll (export CYGWIN=MSYS ;)).  This would allows MSYS mode
>>>> even with completely unchanged executables.
>>>
>>>
>>> Right -- but *some* executables would need to actually BE different, aside
>>> from the underlying posix library's behavioral changes, to get a "real" MSYS
>>> environment.
>>
>> Perhaps it would be useful to actually identify which packages have
>> extenuating needs.  Maybe it's just one or two.  Maybe it's all but
>> one or two.  I don't think that currently, the problem space is
>> properly enumerated, but is instead living in the abstract.
> 
> Very good point.  This would perhaps show us much better where we're
> heading here.  From the current input I only see the following required
> changes in relation to a stock Cygwin distro:
> 
> - make w/ DOS path handling
Yes. Note that the code DOES exist in make, but is disabled when make is
built for Cygwin. One might question whether it was a good idea to
disable support for W32 paths in make that runs on W32 (with a
compatibility layer, but still...) in the first place.

> - gcc targeting Mingw rather than Cygwin.
You already have that, it's called "mingw cross-compiler for cygwin".
And that is not what msys users use.
I think you've meant something different here, i'm not sure what.

> - Cygwin compiler provided as cross tool $arch-pc-cygwin-gcc, etc.(*)
Yes. That includes binutils too (obviously)


Also:

base-files:
add /mingw/bin to PATH when running in MINGW mode
(adding /mingw/share/{man,info} to {MAN,INFO}PATH is also useful, but
not really mandatory)
(ok, these aren't binaries, so maybe they don't qualify)

bash:
Fix various instances of '\r' handling.

coreutils:
Bring back the '\r' support in md5sum. This is another change that might
just go into Cygwin in general. I'm not sure whether '\r' is a valid
character to use in filenames.
(optionally) embed install.exe.manifest into install.exe

There are also patches to rebase that i find useful, but they are up to
debate.

Yeah, that list turned out to be really short. There may be other
packages that need fixing ('\r' handling is the likely culprit), but i
haven't bumped into them yet, so i wouldn't know.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJR9ks4AAoJEOs4Jb6SI2CwGKwIAJjB2P3fS9xVjhBP5gyOSv8W
aevmjZ5nLXH0JyWqv9kNM87vyU16V7yEcXel1Md+Fcy6fdQ6xTzU9xjnDjLIPItk
B6IR/DKTAUMeZSo99gjKOcvi1YFH6AdlOlsvdBPemVl5TQ9FR11F5V0Ff9zSwyB9
tLH/bRIb3Wj5wiRBqg0mxIu1w+ur6crR0w9qavj3pGwfbfOQPJN4FD05iXtltwo5
MX1yWlnbySaYJsVGBzQX2w7ROQ7fEa2urvUxPASszuzQGrCVa1qQnfn3exv8+cX4
fwN3axRkM6P6UAPjO9UkuB9/AoNUDX9u+MIbWtrIGhnM6oewL7/aDypYogA66X4=
=7Rx3
-----END PGP SIGNATURE-----

Re: MSYS mode (continue)

[Earnie Boyd]

On Mon, Jul 29, 2013 at 7:00 AM, LRN wrote:
>> - make w/ DOS path handling
> Yes. Note that the code DOES exist in make, but is disabled when make is
> built for Cygwin. One might question whether it was a good idea to
> disable support for W32 paths in make that runs on W32 (with a
> compatibility layer, but still...) in the first place.
>

MSYS has never modified the make source and it uses the CYGWIN coding.
 The only thing is we do accept windows pathing in the form of
C:/SOME/DIR but not C:\SOME\DIR.

The only thing I know that is currently changed is bash to add a -W
option to pwd.  That should be carried forward to /bin/pwd but that
currently isn't the case.

All of the path handling magic happens in msys-1.0.dll.  The other
thing that happens are chosen sane defaults for the options provided
by CYGWIN so that users reporting errors wouldn't have the chance to
screw with a known set of configuration and the CYGWIN variable is
thus ignored.  And all file handles are set to _O_BINARY without the
ability to change it; I don't know if that matters for the current
version of Cygwin but mentioning it just in case.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Re: MSYS mode (continue)

[Corinna Vinschen]

On Jul 29 15:00, LRN wrote:
> On 29.07.2013 13:29, Corinna Vinschen wrote:
> > On Jul 27 20:17, NightStrike wrote:
> >> Perhaps it would be useful to actually identify which packages have
> >> extenuating needs.  Maybe it's just one or two.  Maybe it's all but
> >> one or two.  I don't think that currently, the problem space is
> >> properly enumerated, but is instead living in the abstract.
> > 
> > Very good point.  This would perhaps show us much better where we're
> > heading here.  From the current input I only see the following required
> > changes in relation to a stock Cygwin distro:
> > 
> > - make w/ DOS path handling
> Yes. Note that the code DOES exist in make, but is disabled when make is
> built for Cygwin. One might question whether it was a good idea to
> disable support for W32 paths in make that runs on W32 (with a
> compatibility layer, but still...) in the first place.

Cygwin paths can contain "x:" as part of a normal filename.

> > - gcc targeting Mingw rather than Cygwin.
> You already have that, it's called "mingw cross-compiler for cygwin".
> And that is not what msys users use.
> I think you've meant something different here, i'm not sure what.

That's exactly what I meant.  Of course we have a mingw cross compiler
in the Cygwin distro, but as far as the discussion on the mingw-w64 list
showed, MSYS users apparently prefer the "native" gcc compiler (the one
called "gcc") to produce mingw executables (aka "native Windows
exectables running without a compat layer") to avoid cross compiling
when creating native Windows executables.  If the native gcc in an MSYS
install targets MSYS, and if you had to use a cross compiler to create
native Windows executables (as in Cygwin), there would ne no reason for
MSYS at all since it would be equivalent to Cygwin.

> > - Cygwin compiler provided as cross tool $arch-pc-cygwin-gcc, etc.(*)
> Yes. That includes binutils too (obviously)
> 
> 
> Also:
> 
> base-files:
> add /mingw/bin to PATH when running in MINGW mode
> (adding /mingw/share/{man,info} to {MAN,INFO}PATH is also useful, but
> not really mandatory)
> (ok, these aren't binaries, so maybe they don't qualify)
> 
> bash:
> Fix various instances of '\r' handling.
> 
> coreutils:
> Bring back the '\r' support in md5sum. This is another change that might
> just go into Cygwin in general. I'm not sure whether '\r' is a valid
> character to use in filenames.

Yes.

> (optionally) embed install.exe.manifest into install.exe
> 
> There are also patches to rebase that i find useful, but they are up to
> debate.
> 
> Yeah, that list turned out to be really short. There may be other
> packages that need fixing ('\r' handling is the likely culprit), but i
> haven't bumped into them yet, so i wouldn't know.

Corinna

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

Re: MSYS mode (continue)

[Charles Wilson]

On 7/29/2013 7:19 AM, Earnie Boyd wrote:
> On Mon, Jul 29, 2013 at 7:00 AM, LRN wrote:
>>> - make w/ DOS path handling
>> Yes. Note that the code DOES exist in make, but is disabled when make is
>> built for Cygwin. One might question whether it was a good idea to
>> disable support for W32 paths in make that runs on W32 (with a
>> compatibility layer, but still...) in the first place.
>>
>
> MSYS has never modified the make source and it uses the CYGWIN coding.
>   The only thing is we do accept windows pathing in the form of
> C:/SOME/DIR but not C:\SOME\DIR.

No.

Here's the patches applied to msys's make-3.81

make/01-make-3.81-2-cygwin.patch       -- from cygwin's 3.81-2 package
make/02-make-3.81-dos-path.patch
make/03-make-3.81-case_preserve.patch
make/04-make-3.81-msys.patch

I've archives all the patches I used when I last built the msys apps -- 
it's over 1MB after xz compression.  I'll figure out somewhere to put it 
and post the link later today.

Here's the file listing -- 151 different patches to 56 different 
products. Some were unofficial, since I never actually published my 
msys-tcl port.

expat/expat-2.0.1-1-msys.patch
libiconv/00-wchar-libiconv-1.14.patch
libiconv/01-undo-cygwin17-reloc-libiconv-1.14.patch
libiconv/02-reloc-libiconv-1.14.patch
libiconv/03-cygwin-libiconv-1.14.patch
libiconv/libiconv-1.13.1-2-msys.patch
libiconv/libiconv-1.14-1.msys.patch
libiconv/libiconv-1.14-1.src.patch
autoconf/autoconf-2.67-1-msys.patch
autoconf/autoconf-2.68-1.msys.patch
autoconf/autoconf-2.68-1.src.patch
autogen/autogen-5.10.1-1-msys.patch
automake/automake-1.11.1-1-msys.patch
bash/01-bash-3.1-msys.patch
bison/bison-2.4.2-1-msys.patch
bzip2/01-cygming-bzip2-1.0.6.src.patch
bzip2/bzgrep-debian-1.0.5-6.patch
bzip2/bzip2-1.0.4-bzip2recover.patch
bzip2/bzip2-1.0.6-1.msys.patch
bzip2/bzip2-1.0.6-1.src.patch
bzip2/bzip2-1.0.6-3.mgw.patch
bzip2/bzip2-1.0.6-progress.patch
coreutils/01-coreutils-5.97-1-cygwin.patch
coreutils/02-coreutils-5.97-3-msys.patch
coreutils/03-coreutils-5.97-2-autoreconf.patch
coreutils/04-coreutils-5.97-3-more-autoreconf.patch
crypt/crypt-1.1_1-3-msys.patch
cvs/9991-cvs-1.12.13-10-cygwin-src.patch
cvs/9992-cvs-1.12.13-10-cygwin-ext.patch
cvs/9993-cvs-1.12.13-2-msys.patch
cvs/9994-cvs-1.12.13-po-template.patch
cygutils/cygutils-1.3.4-3-msys-unmerged.patch
cygutils/cygutils-1.3.4-4-msys.patch
dash/01-cygwin-dash-0.5.5.1-2.patch
dash/02-msys-dash-0.5.5.1.patch
diffutils/01-diffutils-2.8.7-3-gnulib.patch
diffutils/02-diffutils-2.8.7-3-msys.patch
libtool/0001-Fix-regression-in-command-line-length-computation.patch
libtool/0002-cygwin-mingw-Create-UAC-manifest-files.patch
libtool/0003-Pass-various-runtime-library-flags-to-GCC.patch
libtool/0004-Fix-linking-with-fstack-protector.patch
libtool/0005-msys-support.patch
libxml2/2.7.3-doc-install.patch
libxml2/libxml2-2.7.6-1-msys.patch
lndir/lndir-1.0.1-2-msys.patch
m4/01-m4-1.4.14-1-msys.patch
make/01-make-3.81-2-cygwin.patch
make/02-make-3.81-dos-path.patch
make/03-make-3.81-case_preserve.patch
make/04-make-3.81-msys.patch
man/01-man-1.6e-1-cygwin-src-fwdprt.patch
man/02-man-1.6f-2-msys.patch
minires/minires-1.01-1.patch
minires/minires-1.02_1-2-msys.patch
mktemp/mktemp-1.6-2-msys.patch
msysCORE/foo.patch
msysCORE-old/all-deltas.patch
msysCORE-old/build-machinery-1.0.15.patch
msysCORE-old/pseudo-reloc-fork-fix.patch
openssh/01-openssh-5.4p1-msys.patch
openssl/01-msys-initial.patch
openssl/openssl-0.9.6-x509.patch
openssl/openssl-0.9.7-beta5-version-add-engines.patch
openssl/openssl-0.9.8e-crt.patch
patch/9991-patch-2.5.8-9-cygwin-src-fwdprt.patch
patch/9992-patch-2.6.1-1-msys.patch
patch/msys-build-patch
perl-old/perl-5.6.1_2-1-msys.patch
popt/01-popt-0.15-2-msys.patch
rebase/rebase-4.0.1_1-1.msys.patch
rebase/rebase-4.0.1_1-1.src.patch
rsync/01-rsync-3.0.8-msys.patch
rxvt/991-rxvt-2.7.2-msys-dll-name.patch
rxvt/900-rxvt-2.7.2-yodl.patch
rxvt/901-rxvt-2.7.2-doc.patch
rxvt/902-rxvt-2.7.2-changelogs.patch
rxvt/903-rxvt-2.7.2-remove-files.patch
rxvt/904-rxvt-2.7.2-msys-orig.patch
rxvt/905-rxvt-2.7.2-license.patch
rxvt/990-rxvt-2.7.2-msys-3.patch
rxvt/992-rxvt-2.7.2-msys-fixup-resources.patch
sed/sed-4.2.1-2-msys.patch
tar/990-tar-1.22-1-cygwin-fwdport.patch
tar/991-tar-1.23-1-msys.patch
tar/992-silence-record-size-warning.patch
tcl/03-cygwin-un-win32ify.patch
tcl/04-cygwin-env-sync.patch
tcl/05-msys-libprefix-load.patch
tcl/06-cygwin-nocolons.patch
tcl/07-msys-termio-without-parext.patch
tcl/08-msys-workaround-stdhandles-ebadf.patch
tcl/09-cygwin-use-autoimport.patch
tcl/10-cygwin-msys-libprefix-build.patch
tcl/11-msys-tcl-m4.patch
tcl/8.5-cygwin.patch
tcl/8.5.10-tea-m4.patch
tcl/tcl-8.5.11-1.msys.patch
termcap/termcap-0.20050421_1-2-msys.patch
texinfo/9991-texinfo-4.13-3-cygwin-src.patch
texinfo/9992-texinfo-4.13a-1-msys-gnulib-updates.patch
texinfo/9993-texinfo-4.13a-2-msys-other.patch
texinfo/9994-texinfo-4.13a-3-msys-libintl.patch
unzip/01-unzip-6.0-10-cygwin.patch
unzip/02-unzip-6.0-1-msys.patch
unzip/bzip2-1.0.5-10.partial-src.patch
vim/vim-7.2-2-msys.patch
wget/01-wget-1.12-1-msys.patch
xz/01-cygwin-xz-5.0.2-1.patch
xz/02-msys-missing-stdint-inttypes.patch
xz/03-msys-getopt-workaround.patch
xz/04-msys-other.patch
xz/xz-5.0.3-1.msys.patch
xz/xz-rollup-fixes-7fcc6334.patch
zip/bzip2-1.0.5-10.partial-src.patch
zip/zip-3.0-1-msys.patch
zip/zip-3.0-11.src.patch
zip/zip-3.0-build.patch
file/9991-file-5.00-3-cygwin-src-partial.patch
file/9992-file-5.04-1-msys.patch
findutils/01-findutils-4.4.0-3-cygwin-src-fwdprt.patch
findutils/02-findutils-4.4.2-2-msys.patch
flex/flex-2.5.35-2-msys.patch
flex/flex-debian-2.5.35-7-partial.patch
gawk/999-gawk-3.1.7-2-msys.patch
gdbm/gdbm-1.8.3-3-msys.patch
gettext/gettext-0.18.1.1-1.msys.patch
gettext/gettext-0.18.1.1-1.src.patch
gettext/00-slowdown-cvs-archive-creation.patch
gettext/01-msys-fixes.patch
gettext/02-locale-gettext-0.18.1.1.patch
gettext/03-cygwin-gettext-0.18.1.1.patch
gettext/04-mingw-script-slash-fix.patch
gmp/gmp-5.0.1-1-msys.patch
grep/999-grep-2.5.4-2-msys.patch
groff/01-doc-gfdl-msys.patch
groff/02-msys-install.patch
guile/guile-1.8.7-2-msys.patch
gzip/9991-grep-1.3.12-2-cygwin-src.patch
gzip/9992-grep-1.3.12-2-msys.patch
inetutils/01-buildsystem-updates.patch
inetutils/02-gnulib_20100205-updates.patch
inetutils/03-autoreconf-updates.patch
inetutils/04-documentation-updates.patch
inetutils/05-missing-headers.patch
inetutils/06-cygwin-1.7-1pre-unofficial.patch
inetutils/07-msys-missing-headers.patch
inetutils/08-msys-fixups.patch
inetutils/09-msys-replace-rfunc-for-vista.patch
less/01-434417-LESS_IS_MORE.patch
less/02-less-429-1-cygwin-src.patch
libarchive/01-libarchive-msys-initial.patch



This also misses the changes to the build configurations (e.g. msys 
builds foo with --disable-bar, while cygwin uses --enable-bar, etc).

--
Chuck

Re: MSYS mode (continue)

[Corinna Vinschen]

On Jul 29 08:20, Charles Wilson wrote:
> On 7/29/2013 7:19 AM, Earnie Boyd wrote:
> >On Mon, Jul 29, 2013 at 7:00 AM, LRN wrote:
> >>>- make w/ DOS path handling
> >>Yes. Note that the code DOES exist in make, but is disabled when make is
> >>built for Cygwin. One might question whether it was a good idea to
> >>disable support for W32 paths in make that runs on W32 (with a
> >>compatibility layer, but still...) in the first place.
> >>
> >
> >MSYS has never modified the make source and it uses the CYGWIN coding.
> >  The only thing is we do accept windows pathing in the form of
> >C:/SOME/DIR but not C:\SOME\DIR.
> 
> No.
> 
> Here's the patches applied to msys's make-3.81
> 
> make/01-make-3.81-2-cygwin.patch       -- from cygwin's 3.81-2 package
> make/02-make-3.81-dos-path.patch
> make/03-make-3.81-case_preserve.patch
> make/04-make-3.81-msys.patch
> 
> I've archives all the patches I used when I last built the msys apps
> -- it's over 1MB after xz compression.  I'll figure out somewhere to
> put it and post the link later today.
> 
> Here's the file listing -- 151 different patches to 56 different
> products. Some were unofficial, since I never actually published my
> msys-tcl port.

The question is, are they really necessary?  I seriously doubt that you
have to patch inetutils beyond what's required for Cygwin, unless you
want the kitchen sink to work with DOS paths.


Corinna

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

Re: MSYS mode (continue)

[Charles Wilson]

[-- Attachment #1: Type: text/plain, Size: 3416 bytes --]

On 7/29/2013 8:49 AM, Corinna Vinschen wrote:
> The question is, are they really necessary?  I seriously doubt that you
> have to patch inetutils beyond what's required for Cygwin, unless you
> want the kitchen sink to work with DOS paths.

They *were* necessary for msys-1, given the following:

1) msys itself was very old, and had only cygwin-1.3.4 era capabilities
2) the msys targetting compiler is to this day ALSO very old: it's based 
on gcc-3.4.4 if you can believe it.

Now, it is certainly true that in the new "era" with msys-on-cygwin, 
point #1 above is no longer applicable. And, because there really won't 
be an msys target compiler, just the plain old cygwin one (with -DMSYS 
[1] and, depending on how the msys hook dll gets loaded, perhaps 
-lmsys), then msys apps no longer have to work around old-gcc breakage.

But there are still some patches that will be necessary, and I'm afraid 
only experience will tell us which ones.  My set of 151 patches to 56 
packages [2] is probably the "outer limit"; some packages might be 
workable with no special msys changes, others might only need a small 
subset of what was previously necessary.

Let's go back to our favorite example, msys-make:

make/01-make-3.81-2-cygwin.patch
--------------------------------
	from cygwin's 3.81-2 package, so this is not interesting
	when we're discussing *differences* between the cygwin and
	"msys" versions

make/02-make-3.81-dos-path.patch
--------------------------------
* configure.in (PATH_SEPARATOR_CHAR): Define to the value of
   $PATH_SEPARATOR.
* make.h (PATH_SEPARATOR_CHAR): Define only if still undefined.
   Normally, it is defined in config.h.
* config/dospaths.m4 <ac_cv_dos_paths>: Define to yes on Cygwin
   as well.
* job.c (construct_command_argv_internal) [HAVE_DOS_PATHS]:
   Define sh_chars_sh for Windows platforms that emulate Unix.

This *might* be in make-3.82.90, I'm not sure. But for msys we need to 
ensure that ac_cv_dos_paths is "yes", regardless of whether it is yes or 
no on cygwin.

make/03-make-3.81-case_preserve.patch
--------------------------------
case-insensitive but case-preserving rule matching. Pretty sure "real" 
cygwin doesn't want, and doesn't have, this one.  Over in mingw/msys 
land we went round and round with "csmake" (case sensitive), "cpmake" 
(this one), and "regular" make, and finally decided that cpmake had the 
fewest drawbacks when working with "native" gcc...

make/04-make-3.81-msys.patch
--------------------------------
build system changes. In configure.in, the original AC_SUBSTs didn't do 
the right thing and needed to use a more modern idiom. In Makefile.am, 
the test driver section relied on symlinks, which are obviously broken 
in "old" msys.


I think we're all pretty much on the same page, that "msys" needs a 
special version of make. Does bash need to be different? probably. 
Perl...maybe???  inetutils (clients only) -- I think some of these 
changes^Wcripplings are necessary, regardless of the "environment" 
improvements that modernizing msys and its associated gcc bring.  But 
it'll just have to be on a case-by-case basis.  I've uploaded my entire 
msys patch collection [2] in case anyone is really crazy^Winterested...


[1] This will still be needed because of the msys-*behavioral* patches 
that are still going to be necessary, in some cases...

[2] http://mingw.cwilson.fastmail.fm/msys-patches.tar.xz

--
Chuck


[-- Attachment #2: 02-make-3.81-dos-path.patch --]
[-- Type: text/plain, Size: 2809 bytes --]

2006-08-18  Eli Zaretskii  <address@hidden>

        * configure.in (PATH_SEPARATOR_CHAR): Define to the value of
        $PATH_SEPARATOR.

        * make.h (PATH_SEPARATOR_CHAR): Define only if still undefined.
        Normally, it is defined in config.h.

        * config/dospaths.m4 <ac_cv_dos_paths>: Define to yes on Cygwin as
        well.

        * job.c (construct_command_argv_internal) [HAVE_DOS_PATHS]: Define
        sh_chars_sh for Windows platforms that emulate Unix.


--- old/make-3.81/configure.in	2006-04-01 12:36:40.000000000 +0300
+++ new/make-3.81/configure.in	2006-08-18 21:12:32.828125000 +0300
@@ -384,6 +384,8 @@
     ;;
 esac
 
+AC_DEFINE_UNQUOTED(PATH_SEPARATOR_CHAR,'$PATH_SEPARATOR',[Define to the character that separates directories in PATH.])
+
 # Include the Maintainer's Makefile section, if it's here.
 
 MAINT_MAKEFILE=/dev/null

--- old/make-3.81/make.h	2006-02-16 03:54:43.000000000 +0200
+++ new/make-3.81/make.h	2006-08-18 21:12:32.859375000 +0300
@@ -347,12 +347,14 @@
 #define S_(msg1,msg2,num)   ngettext (msg1,msg2,num)
 
 /* Handle other OSs.  */
-#if defined(HAVE_DOS_PATHS)
-# define PATH_SEPARATOR_CHAR ';'
-#elif defined(VMS)
-# define PATH_SEPARATOR_CHAR ','
-#else
-# define PATH_SEPARATOR_CHAR ':'
+#ifndef PATH_SEPARATOR_CHAR
+# if defined(HAVE_DOS_PATHS)
+#  define PATH_SEPARATOR_CHAR ';'
+# elif defined(VMS)
+#  define PATH_SEPARATOR_CHAR ','
+# else
+#  define PATH_SEPARATOR_CHAR ':'
+# endif
 #endif
 
 /* This is needed for getcwd() and chdir().  */

--- old/make-3.81/config/dospaths.m4	2006-03-10 06:20:45.000000000 +0200
+++ new/make-3.81/config/dospaths.m4	2006-08-18 21:12:32.859375000 +0300
@@ -22,7 +22,7 @@
     AC_CACHE_CHECK([whether system uses MSDOS-style paths], [ac_cv_dos_paths],
       [
         AC_COMPILE_IFELSE([
-#if !defined _WIN32 && !defined __WIN32__ && !defined __MSDOS__ && !defined __EMX__ && !defined __MSYS__
+#if !defined _WIN32 && !defined __WIN32__ && !defined __MSDOS__ && !defined __EMX__ && !defined __MSYS__ && !defined __CYGWIN__
 neither MSDOS nor Windows nor OS2
 #endif
 ],

--- old/make-3.81/job.c	2006-03-20 07:03:04.000000000 +0200
+++ new/make-3.81/job.c	2006-08-19 09:25:07.687500000 +0300
@@ -2307,6 +2307,12 @@ construct_command_argv_internal (char *l
                              "login", "logout", "read", "readonly", "set",
                              "shift", "switch", "test", "times", "trap",
                              "umask", "wait", "while", 0 };
+# ifdef HAVE_DOS_PATHS
+  /* This is required if the MSYS/Cygwin ports (which do not define
+     WINDOWS32) are compiled with HAVE_DOS_PATHS defined, which uses
+     sh_chars_sh[] directly (see below).  */
+  static char *sh_chars_sh = sh_chars;
+# endif         /* HAVE_DOS_PATHS */
 #endif
   register int i;
   register char *p;

[-- Attachment #3: 03-make-3.81-case_preserve.patch --]
[-- Type: text/plain, Size: 9533 bytes --]

diff -rup make-3.81/implicit.c make-3.81-new/implicit.c
--- old/make-3.81/implicit.c	Wed May 28 23:57:40 2008
+++ new/make-3.81/implicit.c	Wed May 28 23:30:55 2008
@@ -27,7 +27,8 @@ Foundation, Inc., 51 Franklin St, Fifth 
 
 static int
 pattern_search PARAMS ((struct file *file, int archive,
-                        unsigned int depth, unsigned int recursions));
+                        unsigned int depth, unsigned int recursions,
+                        int strict_case));
 \f
 /* For a FILE which has no commands specified, try to figure out some
    from the implicit pattern rules.
@@ -36,16 +37,19 @@ pattern_search PARAMS ((struct file *fil
    or returns 0 if no implicit rule was found.  */
 
 int
-try_implicit_rule (struct file *file, unsigned int depth)
+try_implicit_rule (struct file *file, unsigned int depth, int strict_case)
 {
-  DBF (DB_IMPLICIT, _("Looking for an implicit rule for `%s'.\n"));
+  if (strict_case)
+    DBF (DB_IMPLICIT, _("Looking for an implicit rule for `%s'.\n"));
+  else
+    DBF (DB_IMPLICIT, _("Looking for a case-insensitive implicit rule for `%s'.\n"));
 
   /* The order of these searches was previously reversed.  My logic now is
      that since the non-archive search uses more information in the target
      (the archive search omits the archive name), it is more specific and
      should come first.  */
 
-  if (pattern_search (file, 0, depth, 0))
+  if (pattern_search (file, 0, depth, 0, strict_case))
     return 1;
 
 #ifndef	NO_ARCHIVES
@@ -55,7 +59,7 @@ try_implicit_rule (struct file *file, un
     {
       DBF (DB_IMPLICIT,
            _("Looking for archive-member implicit rule for `%s'.\n"));
-      if (pattern_search (file, 1, depth, 0))
+      if (pattern_search (file, 1, depth, 0, strict_case))
 	return 1;
     }
 #endif
@@ -198,7 +202,8 @@ get_next_word (char *buffer, unsigned in
 
 static int
 pattern_search (struct file *file, int archive,
-                unsigned int depth, unsigned int recursions)
+                unsigned int depth, unsigned int recursions,
+                int strict_case)
 {
   /* Filename we are searching for a rule for.  */
   char *filename = archive ? strchr (file->name, '(') : file->name;
@@ -698,13 +703,13 @@ pattern_search (struct file *file, int a
               /* @@ dep->changed check is disabled. */
               if (((f = lookup_file (name)) != 0 && f->is_target)
                   /*|| ((!dep->changed || check_lastslash) && */
-                  || file_exists_p (name))
+                  || (strict_case ? file_exists_p (name) : (access (name, F_OK) == 0)))
                 continue;
 
               /* This code, given FILENAME = "lib/foo.o", dependency name
                  "lib/foo.c", and VPATH=src, searches for "src/lib/foo.c".  */
               vname = name;
-              if (vpath_search (&vname, (FILE_TIMESTAMP *) 0))
+              if (vpath_search (&vname, (FILE_TIMESTAMP *) 0, strict_case))
                 {
                   DBS (DB_IMPLICIT,
                        (_("Found prerequisite `%s' as VPATH `%s'\n"),
@@ -735,7 +740,8 @@ pattern_search (struct file *file, int a
                   if (pattern_search (intermediate_file,
                                       0,
                                       depth + 1,
-                                      recursions + 1))
+                                      recursions + 1,
+                                      strict_case))
                     {
                       d->intermediate_file = intermediate_file;
                       d->intermediate_pattern = intermediate_file->name;
@@ -751,7 +757,8 @@ pattern_search (struct file *file, int a
                      so we won't go through the search again later.  */
                   if (intermediate_file->variables)
                     free_variable_set (intermediate_file->variables);
-                  file_impossible (name);
+                  if (strict_case==0)
+                    file_impossible (name);
                 }
 
               /* A dependency of this rule does not exist. Therefore,
diff -rup make-3.81/make.h make-3.81-new/make.h
--- old/make-3.81/make.h	Wed May 28 23:57:40 2008
+++ new/make-3.81/make.h	Wed May 28 23:30:55 2008
@@ -459,7 +459,7 @@ extern void install_default_implicit_rul
 
 extern void build_vpath_lists PARAMS ((void));
 extern void construct_vpath_list PARAMS ((char *pattern, char *dirpath));
-extern int vpath_search PARAMS ((char **file, FILE_TIMESTAMP *mtime_ptr));
+extern int vpath_search PARAMS ((char **file, FILE_TIMESTAMP *mtime_ptr, int strict_case));
 extern int gpath_search PARAMS ((char *file, unsigned int len));
 
 extern void construct_include_path PARAMS ((char **arg_dirs));
diff -rup make-3.81/remake.c make-3.81-new/remake.c
--- old/make-3.81/remake.c	Wed May 28 23:57:40 2008
+++ new/make-3.81/remake.c	Wed May 28 23:30:55 2008
@@ -39,7 +39,7 @@ Foundation, Inc., 51 Franklin St, Fifth 
 #include <io.h>
 #endif
 
-extern int try_implicit_rule PARAMS ((struct file *file, unsigned int depth));
+extern int try_implicit_rule PARAMS ((struct file *file, unsigned int depth, int strict_case));
 
 
 /* The test for circular dependencies is based on the 'updating' bit in
@@ -450,8 +450,10 @@ update_file_1 (struct file *file, unsign
 
   if (!file->phony && file->cmds == 0 && !file->tried_implicit)
     {
-      if (try_implicit_rule (file, depth))
+      if (try_implicit_rule (file, depth, 1))
 	DBF (DB_IMPLICIT, _("Found an implicit rule for `%s'.\n"));
+      else if (try_implicit_rule (file, depth, 0))
+	DBF (DB_IMPLICIT, _("Found an case-insensitive implicit rule for `%s'.\n"));
       else
 	DBF (DB_IMPLICIT, _("No implicit rule found for `%s'.\n"));
       file->tried_implicit = 1;
@@ -958,8 +960,10 @@ check_dep (struct file *file, unsigned i
 
       if (!file->phony && file->cmds == 0 && !file->tried_implicit)
 	{
-	  if (try_implicit_rule (file, depth))
+	  if (try_implicit_rule (file, depth, 1))
 	    DBF (DB_IMPLICIT, _("Found an implicit rule for `%s'.\n"));
+	  else if (try_implicit_rule (file, depth, 0))
+	    DBF (DB_IMPLICIT, _("Found an case-insensitive implicit rule for `%s'.\n"));
 	  else
 	    DBF (DB_IMPLICIT, _("No implicit rule found for `%s'.\n"));
 	  file->tried_implicit = 1;
@@ -1230,7 +1234,7 @@ f_mtime (struct file *file, int search)
 	{
 	  /* If name_mtime failed, search VPATH.  */
 	  char *name = file->name;
-	  if (vpath_search (&name, &mtime)
+	  if (vpath_search (&name, &mtime, 1) || vpath_search (&name, &mtime, 0)
 	      /* Last resort, is it a library (-lxxx)?  */
 	      || (name[0] == '-' && name[1] == 'l'
 		  && library_search (&name, &mtime)))
@@ -1533,7 +1537,7 @@ library_search (char **lib, FILE_TIMESTA
       /* Now try VPATH search on that.  */
 
       file = libbuf;
-      if (vpath_search (&file, mtime_ptr))
+      if (vpath_search (&file, mtime_ptr, 1) || vpath_search (&file, mtime_ptr, 1))
 	{
 	  *lib = file;
 	  return 1;
diff -rup make-3.81/vpath.c make-3.81-new/vpath.c
--- old/make-3.81/vpath.c	Wed May 28 23:57:40 2008
+++ new/make-3.81/vpath.c	Wed May 28 23:51:23 2008
@@ -48,7 +48,7 @@ static struct vpath *general_vpath;
 
 static struct vpath *gpaths;
 \f
-static int selective_vpath_search PARAMS ((struct vpath *path, char **file, FILE_TIMESTAMP *mtime_ptr));
+static int selective_vpath_search PARAMS ((struct vpath *path, char **file, FILE_TIMESTAMP *mtime_ptr, int strict_case));
 
 /* Reverse the chain of selective VPATH lists so they
    will be searched in the order given in the makefiles
@@ -334,7 +334,7 @@ gpath_search (char *file, unsigned int l
    Otherwise we return 0.  */
 
 int
-vpath_search (char **file, FILE_TIMESTAMP *mtime_ptr)
+vpath_search (char **file, FILE_TIMESTAMP *mtime_ptr, int strict_case)
 {
   register struct vpath *v;
 
@@ -351,11 +351,11 @@ vpath_search (char **file, FILE_TIMESTAM
 
   for (v = vpaths; v != 0; v = v->next)
     if (pattern_matches (v->pattern, v->percent, *file))
-      if (selective_vpath_search (v, file, mtime_ptr))
+      if (selective_vpath_search (v, file, mtime_ptr, strict_case))
 	return 1;
 
   if (general_vpath != 0
-      && selective_vpath_search (general_vpath, file, mtime_ptr))
+      && selective_vpath_search (general_vpath, file, mtime_ptr, strict_case))
     return 1;
 
   return 0;
@@ -370,7 +370,8 @@ vpath_search (char **file, FILE_TIMESTAM
 
 static int
 selective_vpath_search (struct vpath *path, char **file,
-                        FILE_TIMESTAMP *mtime_ptr)
+                        FILE_TIMESTAMP *mtime_ptr,
+                        int strict_case)
 {
   int not_target;
   char *name, *n;
@@ -500,10 +501,19 @@ selective_vpath_search (struct vpath *pa
 	     Now NAME is the name of the directory to look in.  */
 	  *n = '\0';
 
-	  /* We know the directory is in the hash table now because either
-	     construct_vpath_list or the code just above put it there.
-	     Does the file we seek exist in it?  */
-	  exists_in_cache = exists = dir_file_exists_p (name, filename);
+	  if (strict_case)
+	    {
+	      /* We know the directory is in the hash table now because either
+	         construct_vpath_list or the code just above put it there.
+	         Does the file we seek exist in it?  */
+	      exists_in_cache = exists = dir_file_exists_p (name, filename);
+	    }
+	  else
+	    {
+	      /* If using a case insensitive search, avoid the case sensitive
+	         lookup function above and force a real filesystem check. */
+	      exists_in_cache = exists = 1;
+	    }
 #endif
 	}
 

[-- Attachment #4: 04-make-3.81-msys.patch --]
[-- Type: text/plain, Size: 1981 bytes --]

diff -urN old/make-3.81/Makefile.am new/make-3.81/Makefile.am
--- old/make-3.81/Makefile.am	2006-04-01 02:36:40.000000000 -0400
+++ new/make-3.81/Makefile.am	2009-11-07 19:23:03.012300000 -0500
@@ -172,10 +172,17 @@
 	    case `cd $(srcdir); pwd` in `pwd`) : ;; \
 	      *) test -d tests || mkdir tests; \
 		 rm -f srctests; \
-		 if ln -s "$(srcdir)/tests" srctests; then \
+		 if /bin/false && ln -s "$(srcdir)/tests" srctests; then \
 		   for f in run_make_tests run_make_tests.pl test_driver.pl scripts; do \
 		     rm -f tests/$$f; ln -s ../srctests/$$f tests; \
-		   done; fi ;; \
+		   done; \
+	         else \
+	           mkdir srctests ;\
+	           lndir $(srcdir)/tests/ srctests ;\
+	           for f in run_make_tests run_make_tests.pl test_driver.pl scripts; do \
+	             rm -f tests/$$f; (cd tests && ln -s ../srctests/$$f .); \
+	           done; \
+	         fi ;; \
 	    esac; \
 	    echo "cd tests && $(PERL) ./run_make_tests.pl -make ../make$(EXEEXT) $(MAKETESTFLAGS)"; \
 	    cd tests && $(PERL) ./run_make_tests.pl -make ../make$(EXEEXT) $(MAKETESTFLAGS); \
diff -urN old/make-3.81/configure.in new/make-3.81/configure.in
--- old/make-3.81/configure.in	2009-11-07 19:22:43.044300000 -0500
+++ new/make-3.81/configure.in	2009-11-07 19:37:43.011500000 -0500
@@ -40,9 +40,8 @@
 
 # Specialized system macros
 AC_CANONICAL_HOST
-AC_AIX
+AC_USE_SYSTEM_EXTENSIONS
 AC_ISC_POSIX
-AC_MINIX
 
 # Needed for ansi2knr
 AM_C_PROTOTYPES
@@ -360,9 +359,14 @@
 #endif
  ], [AC_MSG_RESULT(yes)
 make_cv_sys_gnu_glob=yes], [AC_MSG_RESULT([no; using local copy])
-AC_SUBST(GLOBINC) GLOBINC='-I$(srcdir)/glob'
-AC_SUBST(GLOBLIB) GLOBLIB=glob/libglob.a
 make_cv_sys_gnu_glob=no])])
+if test "$make_cv_sys_gnu_glob" = no; then
+  GLOBINC='-I$(srcdir)/glob'
+  GLOBLIB=glob/libglob.a
+fi
+AC_SUBST(GLOBINC)
+AC_SUBST(GLOBLIB)
+
 # Tell automake about this, so it can build the right .c files.
 AM_CONDITIONAL(USE_LOCAL_GLOB, test "$make_cv_sys_gnu_glob" = no)
 

Re: MSYS mode (continue)

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29.07.2013 15:18, Corinna Vinschen wrote:
> On Jul 29 15:00, LRN wrote:
>> On 29.07.2013 13:29, Corinna Vinschen wrote:
>>> On Jul 27 20:17, NightStrike wrote:
>>>> Perhaps it would be useful to actually identify which packages have
>>>> extenuating needs.  Maybe it's just one or two.  Maybe it's all but
>>>> one or two.  I don't think that currently, the problem space is
>>>> properly enumerated, but is instead living in the abstract.
>>>
>>> Very good point.  This would perhaps show us much better where we're
>>> heading here.  From the current input I only see the following required
>>> changes in relation to a stock Cygwin distro:
>>>
>>> - gcc targeting Mingw rather than Cygwin.
>> You already have that, it's called "mingw cross-compiler for cygwin".
>> And that is not what msys users use.
>> I think you've meant something different here, i'm not sure what.
> 
> That's exactly what I meant.  Of course we have a mingw cross compiler
> in the Cygwin distro, but as far as the discussion on the mingw-w64 list
> showed, MSYS users apparently prefer the "native" gcc compiler (the one
> called "gcc")
"native" compiler is the one that does not do cross-compiling. That is,
it compiles with $build==$host, produces code for $build, and looks for
headers/libs in $prefix/{include,lib} (unlike cross-compilers, which
produce code for $host!=$build and look in $prefix/$host/{include,lib}).
Whether it's called "gcc.exe" or "i686-w64-mingw32.exe" is not important
(well, it is, but usually you just symlink gcc.exe to i686-w64-mingw32.exe).

> to produce mingw executables (aka "native Windows
> exectables running without a compat layer") to avoid cross compiling
> when creating native Windows executables.  If the native gcc in an MSYS
> install targets MSYS, and if you had to use a cross compiler to create
> native Windows executables (as in Cygwin), there would ne no reason for
> MSYS at all since it would be equivalent to Cygwin.

Yes. In this case i don't see how Cygwin fits in here. Unless you
suddenly decided to become a MinGW toolchain vendor.
/usr/bin/gcc is a cygwin gcc that targets cygwin
/mingw/bin/gcc is MinGW gcc that targets W32.

Anything that resides in /mingw is completely outside of cygwin domain,
which is why i was surprised to hear that you wanted to provide mingw gcc.

I would expect people to get cygwin/msys in one place, and get MinGW in
another. Even mingw-get, while being a source of both msys and mingw
packages, clearly distinguishes betweent he two.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJR9ovsAAoJEOs4Jb6SI2CwwdcH/0qynygMxZMHTh/P9WIkJ3oQ
yysC8gJ21ScexouI3uwSzFH6n9pFUZ7cboFsdY3b5WH62K85RHZnI0EUd8YLAmM+
NXPj7XiqSbWbEO7GBQhsvr3T5QEP4M/2xCOTQdqMJI2Ew4VAbKsEDrZQIvZoQoGD
59ZFzMZR1phE868EFg2QtdHVomyZwudUg+ZWkuK4vxhkfkMQ/ebNG21tvRSXFgYM
yh/jRXTd0ITVw7NgXc5w6U16u9xC3eJFtdIfpxF1cKvkPUikyo4rZFiLl+n8O1JM
X+XMrJmHOjTV/yqYB1g5Zx6Ebhb8xkh0S222fDrWCD7TtQixT5rKmt3XIdFwRSk=
=d8By
-----END PGP SIGNATURE-----

Re: MSYS mode (continue)

[Corinna Vinschen]

On Jul 29 19:36, LRN wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 29.07.2013 15:18, Corinna Vinschen wrote:
> > On Jul 29 15:00, LRN wrote:
> >> On 29.07.2013 13:29, Corinna Vinschen wrote:
> >>> On Jul 27 20:17, NightStrike wrote:
> >>>> Perhaps it would be useful to actually identify which packages have
> >>>> extenuating needs.  Maybe it's just one or two.  Maybe it's all but
> >>>> one or two.  I don't think that currently, the problem space is
> >>>> properly enumerated, but is instead living in the abstract.
> >>>
> >>> Very good point.  This would perhaps show us much better where we're
> >>> heading here.  From the current input I only see the following required
> >>> changes in relation to a stock Cygwin distro:
> >>>
> >>> - gcc targeting Mingw rather than Cygwin.
> >> You already have that, it's called "mingw cross-compiler for cygwin".
> >> And that is not what msys users use.
> >> I think you've meant something different here, i'm not sure what.
> > 
> > That's exactly what I meant.  Of course we have a mingw cross compiler
> > in the Cygwin distro, but as far as the discussion on the mingw-w64 list
> > showed, MSYS users apparently prefer the "native" gcc compiler (the one
> > called "gcc")
> "native" compiler is the one that does not do cross-compiling. That is,
> it compiles with $build==$host, produces code for $build, and looks for
> headers/libs in $prefix/{include,lib} (unlike cross-compilers, which
> produce code for $host!=$build and look in $prefix/$host/{include,lib}).
> Whether it's called "gcc.exe" or "i686-w64-mingw32.exe" is not important
> (well, it is, but usually you just symlink gcc.exe to i686-w64-mingw32.exe).

I'm perfectly aware what a cross compiler is, but in case of Cygwin or
MSYS you have a bit of a hard time to define what a native compiler is,
the one creating Cygwin binaries or the one creating Windows binaries
with the unspoken assumption that they don't require the Cygwin DLL.
That's why I tried to describe it in so may word and apparently failed.

> > to produce mingw executables (aka "native Windows
> > exectables running without a compat layer") to avoid cross compiling
> > when creating native Windows executables.  If the native gcc in an MSYS
> > install targets MSYS, and if you had to use a cross compiler to create
> > native Windows executables (as in Cygwin), there would ne no reason for
> > MSYS at all since it would be equivalent to Cygwin.
> 
> Yes. In this case i don't see how Cygwin fits in here. Unless you
> suddenly decided to become a MinGW toolchain vendor.
> /usr/bin/gcc is a cygwin gcc that targets cygwin
> /mingw/bin/gcc is MinGW gcc that targets W32.
> 
> Anything that resides in /mingw is completely outside of cygwin domain,
> which is why i was surprised to hear that you wanted to provide mingw gcc.
> 
> I would expect people to get cygwin/msys in one place, and get MinGW in
> another. Even mingw-get, while being a source of both msys and mingw
> packages, clearly distinguishes betweent he two.

That's what I understood differently.  From the discussion on mingw-w64
it seemed that a mingw dev using Cygwin/MSYS would prefer if the default
gcc creates non-CYgwin/MSYS, but rather Windows-only binaries.


Corinna

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

Re: MSYS mode (continue)

[Charles Wilson]

On 7/29/2013 11:47 AM, Corinna Vinschen wrote:
> That's what I understood differently.  From the discussion on mingw-w64
> it seemed that a mingw dev using Cygwin/MSYS would prefer if the default
> gcc creates non-CYgwin/MSYS, but rather Windows-only binaries.

I agree with Corinna here.  I think LRN is assuming that the 
installation structure will remain the same as MinGW/MSYS going forward, 
and I do not believe that is correct -- at least, that's not what 
Corinna is proposing IIUC.

Here's how MinGW/MSYS works right now:

*normally* the batch file you use to enter the "MinGW" environment, 
launches bash with
	1) MSYSTEM=MINGW32
	2) /mingw/bin at the "front" of $PATH (wherever your mount
	   table happens to say that is)

Your phyiscal directory structure *normally* looks something like this:

C:\MinGW      <<<<< mounted as /mingw
      bin      MinGW (that is, "native" win32) gcc.exe & friends
      include  "native" win32 headers
      lib      and libraries
      msys
         1.0   <<<<< mounted as /
             bin    gcc.exe -- only this time, it's an
                    msys-target compiler. But note that it is
                    actually configured as a "native" compiler
             include   msys headers and
             lib       libraries

Because of #1 and #2 above, uname reports MINGW32, and the first gcc 
found in your path is the "native" win32 MinGW one.

However, an *msys* developer would launch a script that invokes bash with
	1) MSYSTEM=MSYS
	2) /bin at the "front" of $PATH

In this case, uname reports MSYS, and the first gcc found in your path 
is the msys one.

=====-----=====

In the new scenario, we might have a separable installation -- maybe
    c:\msys\2.0\
but there isn't any gcc.exe installed there.  And then you might install 
MinGW gcc somewhere like
    c:\MinGW-4.8.1\
and just arrange that
    c:\msys\2.0\etc\fstab
has
    c:\MinGW-4.8.1\   /mingw

and again, you make sure that /mingw/bin is in your $PATH.

However, in the new scenario, you MIGHT have, in 
c:\msys\2.0\i686-pc-cygwin\, a cross compiler targetting "cygwin/msys" 
and running on...MinGW (even though "MinGW" environment is, for all 
intents and purposes, a slightly modified cygwin -- but uname reports 
MINGW32 just like it does for "native" MinGW/win32 operation).  To build 
msys apps in this environment, you have to use --host=i686-pc-cygwin 
(and remember, because uname is reporting "MINGW32", any build system 
will operate under the assumption that you are, in fact, cross compiling).

There are some advantages to the former system, not least of which is 
that when MSYSTEM=MSYS, you're compiling natively so you can easily run 
any test suites without having to play games with the build system.

I think LRN is assuming that the gcc installed in /bin would be the 
cygwin gcc (configured as a native compiler), and we'd continue to play 
$MSYSTEM/$PATH games.

One additional "advantage" to the former system is the autotools. Right 
now we can have a "clean" separation between aclocal/.m4 files that have 
data corresponding to MinGW-compiled native libs and tools, and 
aclocal/.m4 files that have data corresponding to the msys ones -- 
because we have two entirely distinct "sets" of autotools.

/mingw/* has the whole panoply of autoconf2.1/2.5/wrapper, 
automake1.4--1.12/wrapper, libtool, gettext, and libintl.  All are 
configured with --prefix=/mingw, so they look in /mingw/share/aclocal*/ 
for .m4 stuff.

OTOH, in /{bin,lib,share} we have one specific version of autoconf (2.59 
IIRC), one specific version of automake (1.11?), libtool specially 
hacked to support msys (because "regular" libtool does not), gettext, 
and libintl.  Because msys has never been, and was not intended to be, a 
public "triple" value, these versions' config.guess/config.sub were 
modified to recognize the MSYS uname, and report i686-pc-msys as a 
triple, and to actually handle that triple correctly.

The /mingw version of the autotools was not hacked in this way.

This way, when porting some package in /mingw land and running 
re-autoconf, users don't get "fooled" by picking up stuff in 
/share/aclocal/* -- they only "see" the .m4 files that correspond to 
OTHER fully-ported-to-mingw libs and tools.

--
Chuck

Re: MSYS mode (continue)

[Larry Hall (Cygwin Developers)]

On 7/29/2013 8:20 AM, Charles Wilson wrote:
> On 7/29/2013 7:19 AM, Earnie Boyd wrote:
>> On Mon, Jul 29, 2013 at 7:00 AM, LRN wrote:
>>>> - make w/ DOS path handling
>>> Yes. Note that the code DOES exist in make, but is disabled when make is
>>> built for Cygwin. One might question whether it was a good idea to
>>> disable support for W32 paths in make that runs on W32 (with a
>>> compatibility layer, but still...) in the first place.
>>>
>>
>> MSYS has never modified the make source and it uses the CYGWIN coding.
>>   The only thing is we do accept windows pathing in the form of
>> C:/SOME/DIR but not C:\SOME\DIR.
>
> No.
>
> Here's the patches applied to msys's make-3.81

<snip>

> I've archives all the patches I used when I last built the msys apps -- it's
> over 1MB after xz compression.  I'll figure out somewhere to put it and post
> the link later today.
>
> Here's the file listing -- 151 different patches to 56 different products.
> Some were unofficial, since I never actually published my msys-tcl port.

<snip>

Interesting.  Assuming a review of all these patches (and any future MSYS or
even Cygwin-specific patch) won't either be jettisoned as no longer needed
or viewed as common functionality desired in the unified MSYS/Cygwin
universe, I'm starting to think the question of whether EXEs are "drop-in"
chameleons for MSYS or CYGWIN is an implementation detail that the user
should not know about or exploit.  We don't want users to have to
understand which EXEs are exactly the same code for both MSYS and Cygwin
and which aren't.  Worse, we don't want to have to determine which EXE the
user has "dropped-in" when they report an issue.  By these statements, I'm
not saying that the "drop-in" capability shouldn't be used where possible. 
But if it is used, it should be something entirely opaque to the user.
Even beyond that, we should actively hide this technical "sugar" from the
end users to avoid the potential support nightmare.  This shouldn't be a
big deal though.  We'd just need to install all the tools for each
environment separately.

-- 
Larry

Re: MSYS mode (continue)

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29.07.2013 19:47, Corinna Vinschen wrote:
> On Jul 29 19:36, LRN wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 29.07.2013 15:18, Corinna Vinschen wrote:
>>> On Jul 29 15:00, LRN wrote:
>>>> On 29.07.2013 13:29, Corinna Vinschen wrote:
>>>>> On Jul 27 20:17, NightStrike wrote:
>>>>>> Perhaps it would be useful to actually identify which packages have
>>>>>> extenuating needs.  Maybe it's just one or two.  Maybe it's all but
>>>>>> one or two.  I don't think that currently, the problem space is
>>>>>> properly enumerated, but is instead living in the abstract.
>>>>>
>>>>> Very good point.  This would perhaps show us much better where we're
>>>>> heading here.  From the current input I only see the following required
>>>>> changes in relation to a stock Cygwin distro:
>>>>>
>>>>> - gcc targeting Mingw rather than Cygwin.
>>>> You already have that, it's called "mingw cross-compiler for cygwin".
>>>> And that is not what msys users use.
>>>> I think you've meant something different here, i'm not sure what.
>>>
>>> to produce mingw executables (aka "native Windows
>>> exectables running without a compat layer") to avoid cross compiling
>>> when creating native Windows executables.  If the native gcc in an MSYS
>>> install targets MSYS, and if you had to use a cross compiler to create
>>> native Windows executables (as in Cygwin), there would ne no reason for
>>> MSYS at all since it would be equivalent to Cygwin.
>>
>> Yes. In this case i don't see how Cygwin fits in here. Unless you
>> suddenly decided to become a MinGW toolchain vendor.
>> /usr/bin/gcc is a cygwin gcc that targets cygwin
>> /mingw/bin/gcc is MinGW gcc that targets W32.
>>
>> Anything that resides in /mingw is completely outside of cygwin domain,
>> which is why i was surprised to hear that you wanted to provide mingw gcc.
>>
>> I would expect people to get cygwin/msys in one place, and get MinGW in
>> another. Even mingw-get, while being a source of both msys and mingw
>> packages, clearly distinguishes betweent he two.
> 
> That's what I understood differently.  From the discussion on mingw-w64
> it seemed that a mingw dev using Cygwin/MSYS would prefer if the default
> gcc creates non-CYgwin/MSYS, but rather Windows-only binaries.

The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin.

The problem is that the convention that everyone has been following for
years now is that all mingw stuff lives in /mingw, and all msys (cygwin)
stuff lives in /usr. These two are never mixed.

If you start providing alternative gccs, that might confuse people. A
lot. Since for people who installed cygwin-gcc, gcc.exe will produce
cygwin binaries, while the ones with mingw-gcc will have a gcc.exe that
produces mingw binaries. Also, how will you have both cygwin-gcc and
mingw-gcc installed at the same time (some people do need that)?

Relying on prefixes (i686-pc-cygwin-gcc and i686-w64-mingw32-gcc) might
work, but not all packages are prefix-aware.
This also brings us back to the distinction between native and
non-native toolchains. To have both gccs in /usr, you'll have to make
them look for stuff in /usr/$target/{include,lib}. Can't have both mingw
and cygwin libs/headers in /usr/{lib,include}, obviously.
While that might work, i'd guess that it will also break in a some
cases, where people (and scripts) expect that $prefix/{lib,include} are
the right dirs to use.

If it looks in $prefix/$target/{lib,include} and has a name $target-gcc,
then from user's point of view it's a cross-compiler (even if has
build==host==target), and we've already decided that you already have a
cross-compiler and don't need another one.

/mingw also provided a way to swap mingw subsystem (just edit /etc/fstab
to make /mingw point to a different dir, then restart the shell). With
everything living in /usr that might be unnecessary, but now that i
think of this...how are you going to separate compiled binaries from
each other? Say, your /usr/bin/i686-w64-mingw-gcc builds libxml2-2.dll.
That lands in /usr/bin. And when you compile libxml with
/usr/bin/x86_64-w64-mingw-gcc, it builds libxml2-2.dll, and it lands
into the same directory. Where else could it go? /usr/i686-w64-mingw/bin
or /usr/x86_64-w64-mingw/bin? I've never seen mingw doing that kind of
stuff. And how are you going to maintain PATH for them?
If you propose to have only the toolchain in /usr, but build&install
everything with --prefix=/mingw...that, again, might work in some cases,
but not the others. Also, which packages are "the toolchain"? You will
also need to configure gcc that lives in /usr to look for headers/libs
in /mingw/{include,lib}.

So i'd suggest to stick with /usr and /mingw convention and let mingw
take care of itself. It's simpler that way.

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJR9wyWAAoJEOs4Jb6SI2CwkQ4H/iumE/JGhaPRrYrYygRTByht
9r+sTWocYtEeec1pM+Uza4lW9z03gMlcV5JZNM+UJ7d/mrJLFPFNBXR6B1PCZb7q
sPq/XGB0JdY/mhDQ7Zm6nzW1lTFucEoNQh/KHc6yiRJwkaKVgt1erkQVznOtTvCq
ZKk9HLqUx4zf6OVk7iJLNS9Y0pBesXmXljo3N4/iYKsRvGa3a1qWd7AmEmEKeYBU
AfBQezkmP1/L/alNB5oNCAA7yj2W+ilfz5sUHVyq6EeXjQlr+xKvuJ8M/gTp6lYa
6946x414ANr3pCXa/Du3coN2372zydssxnRcOqW5SgL8L6l1orsvnfYpuJ2QuOo=
=E7Iz
-----END PGP SIGNATURE-----

Re: MSYS mode (continue)

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29.07.2013 20:37, Charles Wilson wrote:
> On 7/29/2013 11:47 AM, Corinna Vinschen wrote:
>> That's what I understood differently.  From the discussion on mingw-w64
>> it seemed that a mingw dev using Cygwin/MSYS would prefer if the default
>> gcc creates non-CYgwin/MSYS, but rather Windows-only binaries.
> 
> I agree with Corinna here.  I think LRN is assuming that the 
> installation structure will remain the same as MinGW/MSYS going forward, 
> and I do not believe that is correct -- at least, that's not what 
> Corinna is proposing IIUC.
> 
> 
> In the new scenario, we might have a separable installation -- maybe
>     c:\msys\2.0\
> but there isn't any gcc.exe installed there.  And then you might install 
> MinGW gcc somewhere like
>     c:\MinGW-4.8.1\
> and just arrange that
>     c:\msys\2.0\etc\fstab
> has
>     c:\MinGW-4.8.1\   /mingw
> 
> and again, you make sure that /mingw/bin is in your $PATH.
> 
> However, in the new scenario, you MIGHT have, in 
> c:\msys\2.0\i686-pc-cygwin\, a cross compiler targetting "cygwin/msys" 
> and running on...MinGW (even though "MinGW" environment is, for all 
> intents and purposes, a slightly modified cygwin -- but uname reports 
> MINGW32 just like it does for "native" MinGW/win32 operation).  To build 
> msys apps in this environment, you have to use --host=i686-pc-cygwin 
> (and remember, because uname is reporting "MINGW32", any build system 
> will operate under the assumption that you are, in fact, cross compiling).

That might work. It also means that you'll need a new cygwin
cross-compiler (a mingw->cygwin cross-compiler, although in reality it
might be cygwin->cygwin native compiler that looks like a
cross-compiler). Unless existing one can be stuffed into
/usr/i686-pc-cygwin without any ill effects.

> 
> There are some advantages to the former system, not least of which is 
> that when MSYSTEM=MSYS, you're compiling natively so you can easily run 
> any test suites without having to play games with the build system.
> 
> I think LRN is assuming that the gcc installed in /bin would be the 
> cygwin gcc (configured as a native compiler), and we'd continue to play 
> $MSYSTEM/$PATH games.
Yes, LRN is assuming that /usr/bin/gcc is a cygwin-gcc, and
/mingw/bin/gcc is a mingw gcc.
$MSYSTEM/$PATH games worked well enough so far.

> 
> One additional "advantage" to the former system is the autotools. Right 
> now we can have a "clean" separation between aclocal/.m4 files that have 
> data corresponding to MinGW-compiled native libs and tools, and 
> aclocal/.m4 files that have data corresponding to the msys ones -- 
> because we have two entirely distinct "sets" of autotools.
> 
> /mingw/* has the whole panoply of autoconf2.1/2.5/wrapper, 
> automake1.4--1.12/wrapper, libtool, gettext, and libintl.  All are 
> configured with --prefix=/mingw, so they look in /mingw/share/aclocal*/ 
> for .m4 stuff.
Yes, that is a good point.

> 
> OTOH, in /{bin,lib,share} we have one specific version of autoconf (2.59 
> IIRC), one specific version of automake (1.11?), libtool specially 
> hacked to support msys (because "regular" libtool does not), gettext, 
> and libintl.  Because msys has never been, and was not intended to be, a 
> public "triple" value, these versions' config.guess/config.sub were 
> modified to recognize the MSYS uname, and report i686-pc-msys as a 
> triple, and to actually handle that triple correctly.
Yes, but with cygwin that is going to go away, as i686-pc-cygwin IS a
valid triplet. More reasons to not to let mingw apps see these autotools
and m4 files.

> 
> The /mingw version of the autotools was not hacked in this way.
Though it might be hacked in other, unspecified ways (for example, i
mess with stuff a lot to integrate W32 CPython; this is not needed for
msys-python).


You've laid out advantages and "advantages" of the former system.
What are the advantages of the latter system?

- -- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJR9xRSAAoJEOs4Jb6SI2CwZgUH/0O53vyz6+QfwWFYBWCtsXl9
yIwVEoEQY7GmwFFPRXLiZkh8EQx2/xKdZrpwFGVHPb/hFyYuBPjDkzDlWV6KrFBh
o3YKPlZjPw1gyD+p03ekFkxpgPgZpucaR0k54UyqnnXAtZwA8NhToMokxPJVKez3
e4gpM+dmmpWWsZLQl7I1ZwOTnG88B7aySt8nphGpfUCtfWGzaKU+6JN48HzQapHU
7Wj30Ashmt1eI9LJK5kz+RnBEzdrYlsJITDa+BdHBSFhgqZsMc/DothBmcxi4hl4
ZPFWi6ErAggdkIHrYku1/YUjDjZ19KXHkerY+0y9QwQAJUVZ0iSaau82C3EIZcY=
=p74t
-----END PGP SIGNATURE-----

Re: MSYS mode (continue)

[Corinna Vinschen]

On Jul 30 04:45, LRN wrote:
> On 29.07.2013 19:47, Corinna Vinschen wrote:
> > On Jul 29 19:36, LRN wrote:
> >> I would expect people to get cygwin/msys in one place, and get MinGW in
> >> another. Even mingw-get, while being a source of both msys and mingw
> >> packages, clearly distinguishes betweent he two.
> > 
> > That's what I understood differently.  From the discussion on mingw-w64
> > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default
> > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries.
> 
> The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin.
> 
> The problem is that the convention that everyone has been following for
> years now is that all mingw stuff lives in /mingw, and all msys (cygwin)
> stuff lives in /usr. These two are never mixed.
> [...]
> So i'd suggest to stick with /usr and /mingw convention and let mingw
> take care of itself. It's simpler that way.

Fine with me, of course.  I don't have that problem myself so whatever
works better for you is ok.  But then the number of changed packages
doesn't really matter.  From my POV MSYS sticks to being it's own distro
with another focus than the Cygwin distro.

So we're back to discussing in how far MSYS can be implemented using a
stock Cygwin DLL under the hood and the tweaks being in an external MSYS
DLL so users can mix the best of both worlds as they see fit for their
purpose.

Are you going to help implementing this?  If not, I'm missing input
from any of the developers working on MSYS2...


Corinna

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

Re: MSYS mode (continue)

[Alexey Pavlov]

2013/7/30 Corinna Vinschen
>
> On Jul 30 04:45, LRN wrote:
> > On 29.07.2013 19:47, Corinna Vinschen wrote:
> > > On Jul 29 19:36, LRN wrote:
> > >> I would expect people to get cygwin/msys in one place, and get MinGW in
> > >> another. Even mingw-get, while being a source of both msys and mingw
> > >> packages, clearly distinguishes betweent he two.
> > >
> > > That's what I understood differently.  From the discussion on mingw-w64
> > > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default
> > > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries.
> >
> > The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin.
> >
> > The problem is that the convention that everyone has been following for
> > years now is that all mingw stuff lives in /mingw, and all msys (cygwin)
> > stuff lives in /usr. These two are never mixed.
> > [...]
> > So i'd suggest to stick with /usr and /mingw convention and let mingw
> > take care of itself. It's simpler that way.
>
> Fine with me, of course.  I don't have that problem myself so whatever
> works better for you is ok.  But then the number of changed packages
> doesn't really matter.  From my POV MSYS sticks to being it's own distro
> with another focus than the Cygwin distro.
>
> So we're back to discussing in how far MSYS can be implemented using a
> stock Cygwin DLL under the hood and the tweaks being in an external MSYS
> DLL so users can mix the best of both worlds as they see fit for their
> purpose.
>

As I see all discussion not about implementing but about philosophy of
MSYS. At the start of discussion I wrote about my changes in Cygwin
sources to have MSYS. And also send small patches but nothing really
doing in this direction.
What steps do we need to start any work on implementing it?
Now I see next points where we can change Cygwin functionality:
 1. uname function
 2. reading /etc/fstab
 3. passing arguments and environment variables to non-Cygwin
processes ( environ.cc, spawn.cc )
 4. symlinks changes (copy instead symlink)

>
> Are you going to help implementing this?  If not, I'm missing input
> from any of the developers working on MSYS2...
>
>
I'm on vacation until September. But I can help if any work starting
in this direction.

Regards,
Alexey.

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

Re: MSYS mode (continue)

[Corinna Vinschen]

On Jul 30 13:32, Alexey Pavlov wrote:
> 2013/7/30 Corinna Vinschen
> >
> > On Jul 30 04:45, LRN wrote:
> > > On 29.07.2013 19:47, Corinna Vinschen wrote:
> > > > On Jul 29 19:36, LRN wrote:
> > > >> I would expect people to get cygwin/msys in one place, and get MinGW in
> > > >> another. Even mingw-get, while being a source of both msys and mingw
> > > >> packages, clearly distinguishes betweent he two.
> > > >
> > > > That's what I understood differently.  From the discussion on mingw-w64
> > > > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default
> > > > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries.
> > >
> > > The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin.
> > >
> > > The problem is that the convention that everyone has been following for
> > > years now is that all mingw stuff lives in /mingw, and all msys (cygwin)
> > > stuff lives in /usr. These two are never mixed.
> > > [...]
> > > So i'd suggest to stick with /usr and /mingw convention and let mingw
> > > take care of itself. It's simpler that way.
> >
> > Fine with me, of course.  I don't have that problem myself so whatever
> > works better for you is ok.  But then the number of changed packages
> > doesn't really matter.  From my POV MSYS sticks to being it's own distro
> > with another focus than the Cygwin distro.
> >
> > So we're back to discussing in how far MSYS can be implemented using a
> > stock Cygwin DLL under the hood and the tweaks being in an external MSYS
> > DLL so users can mix the best of both worlds as they see fit for their
> > purpose.
> >
> 
> As I see all discussion not about implementing but about philosophy of
> MSYS.

No.  We were talking about how to implement the changes.  Your patches
change Cygwin directly, but the idea is to keep the actual changes
separate, outside of Cygwin, as hooks.

> At the start of discussion I wrote about my changes in Cygwin
> sources to have MSYS. And also send small patches but nothing really
> doing in this direction.
> What steps do we need to start any work on implementing it?
> Now I see next points where we can change Cygwin functionality:
>  1. uname function
>  2. reading /etc/fstab
>  3. passing arguments and environment variables to non-Cygwin
> processes ( environ.cc, spawn.cc )
>  4. symlinks changes (copy instead symlink)

Yes, these are the behavioral changes you want to implement, but this is
the discussion as to *how* to implement them.  You never actually took
part in this discssion yet.


Corinna

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

Re: MSYS mode (continue)

[Alexey Pavlov]

2013/7/30 Corinna Vinschen:
> On Jul 30 13:32, Alexey Pavlov wrote:
>> 2013/7/30 Corinna Vinschen
>> >
>> > On Jul 30 04:45, LRN wrote:
>> > > On 29.07.2013 19:47, Corinna Vinschen wrote:
>> > > > On Jul 29 19:36, LRN wrote:
>> > > >> I would expect people to get cygwin/msys in one place, and get MinGW in
>> > > >> another. Even mingw-get, while being a source of both msys and mingw
>> > > >> packages, clearly distinguishes betweent he two.
>> > > >
>> > > > That's what I understood differently.  From the discussion on mingw-w64
>> > > > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default
>> > > > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries.
>> > >
>> > > The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin.
>> > >
>> > > The problem is that the convention that everyone has been following for
>> > > years now is that all mingw stuff lives in /mingw, and all msys (cygwin)
>> > > stuff lives in /usr. These two are never mixed.
>> > > [...]
>> > > So i'd suggest to stick with /usr and /mingw convention and let mingw
>> > > take care of itself. It's simpler that way.
>> >
>> > Fine with me, of course.  I don't have that problem myself so whatever
>> > works better for you is ok.  But then the number of changed packages
>> > doesn't really matter.  From my POV MSYS sticks to being it's own distro
>> > with another focus than the Cygwin distro.
>> >
>> > So we're back to discussing in how far MSYS can be implemented using a
>> > stock Cygwin DLL under the hood and the tweaks being in an external MSYS
>> > DLL so users can mix the best of both worlds as they see fit for their
>> > purpose.
>> >
>>
>> As I see all discussion not about implementing but about philosophy of
>> MSYS.
>
> No.  We were talking about how to implement the changes.  Your patches
> change Cygwin directly, but the idea is to keep the actual changes
> separate, outside of Cygwin, as hooks.
>
>> At the start of discussion I wrote about my changes in Cygwin
>> sources to have MSYS. And also send small patches but nothing really
>> doing in this direction.
>> What steps do we need to start any work on implementing it?
>> Now I see next points where we can change Cygwin functionality:
>>  1. uname function
>>  2. reading /etc/fstab
>>  3. passing arguments and environment variables to non-Cygwin
>> processes ( environ.cc, spawn.cc )
>>  4. symlinks changes (copy instead symlink)
>
> Yes, these are the behavioral changes you want to implement, but this is
> the discussion as to *how* to implement them.  You never actually took
> part in this discssion yet.
>

Now there are not many changes that I do in Cygwin sources and it
change only small functionality without breaking anything for cygwin
users (only symlinks is breaking thing).
If we need to implement changes in external DLL we doesn't want to
full rewrite modified functions in this DLL. External DLL need only do
changes inside the Cygwin functions not full replace this functions I
think.
Maybe you create separate branch in CVS source where we can try to
implement MSYS mode and also create hook in uname function, for
example, to try how it work?
From my POV we need to create separate distro for MSYS where in bash
profile we can activate MSYS mode for Cygwin.dll with some environment
variable that tell to load msys.dll. But if you want has working
applications between normal Cygwin and msys-in-cygwin then they need
to be linked only with cygwin.dll and doesn't need to know anything
about msys.dll.


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

Re: MSYS mode (continue)

[Corinna Vinschen]

On Jul 30 14:27, Alexey Pavlov wrote:
> 2013/7/30 Corinna Vinschen:
> > On Jul 30 13:32, Alexey Pavlov wrote:
> >> 2013/7/30 Corinna Vinschen
> >> >
> >> > On Jul 30 04:45, LRN wrote:
> >> > > On 29.07.2013 19:47, Corinna Vinschen wrote:
> >> > > > On Jul 29 19:36, LRN wrote:
> >> > > >> I would expect people to get cygwin/msys in one place, and get MinGW in
> >> > > >> another. Even mingw-get, while being a source of both msys and mingw
> >> > > >> packages, clearly distinguishes betweent he two.
> >> > > >
> >> > > > That's what I understood differently.  From the discussion on mingw-w64
> >> > > > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default
> >> > > > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries.
> >> > >
> >> > > The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin.
> >> > >
> >> > > The problem is that the convention that everyone has been following for
> >> > > years now is that all mingw stuff lives in /mingw, and all msys (cygwin)
> >> > > stuff lives in /usr. These two are never mixed.
> >> > > [...]
> >> > > So i'd suggest to stick with /usr and /mingw convention and let mingw
> >> > > take care of itself. It's simpler that way.
> >> >
> >> > Fine with me, of course.  I don't have that problem myself so whatever
> >> > works better for you is ok.  But then the number of changed packages
> >> > doesn't really matter.  From my POV MSYS sticks to being it's own distro
> >> > with another focus than the Cygwin distro.
> >> >
> >> > So we're back to discussing in how far MSYS can be implemented using a
> >> > stock Cygwin DLL under the hood and the tweaks being in an external MSYS
> >> > DLL so users can mix the best of both worlds as they see fit for their
> >> > purpose.
> >> >
> >>
> >> As I see all discussion not about implementing but about philosophy of
> >> MSYS.
> >
> > No.  We were talking about how to implement the changes.  Your patches
> > change Cygwin directly, but the idea is to keep the actual changes
> > separate, outside of Cygwin, as hooks.
> >
> >> At the start of discussion I wrote about my changes in Cygwin
> >> sources to have MSYS. And also send small patches but nothing really
> >> doing in this direction.
> >> What steps do we need to start any work on implementing it?
> >> Now I see next points where we can change Cygwin functionality:
> >>  1. uname function
> >>  2. reading /etc/fstab
> >>  3. passing arguments and environment variables to non-Cygwin
> >> processes ( environ.cc, spawn.cc )
> >>  4. symlinks changes (copy instead symlink)
> >
> > Yes, these are the behavioral changes you want to implement, but this is
> > the discussion as to *how* to implement them.  You never actually took
> > part in this discssion yet.
> >
> 
> Now there are not many changes that I do in Cygwin sources and it
> change only small functionality without breaking anything for cygwin
> users (only symlinks is breaking thing).
> If we need to implement changes in external DLL we doesn't want to
> full rewrite modified functions in this DLL. External DLL need only do
> changes inside the Cygwin functions not full replace this functions I
> think.

That was part of cgf's original proposal.  We have the CW_HOOK mechanism
to overload entire functions (per the discussion not fully implemented
yet) but there's no problem to implement a kind of mini-hook with a
set of function pointers called from the CYgwin DLL at certain, yet to
be defined points.

> Maybe you create separate branch in CVS source where we can try to
> implement MSYS mode and also create hook in uname function, for
> example, to try how it work?

That should be possible.

> >From my POV we need to create separate distro for MSYS where in bash
> profile we can activate MSYS mode for Cygwin.dll with some environment
> variable that tell to load msys.dll. But if you want has working
> applications between normal Cygwin and msys-in-cygwin then they need
> to be linked only with cygwin.dll and doesn't need to know anything
> about msys.dll.

Exactly.


Corinna

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

Re: MSYS mode (continue)

[Alexey Pavlov]

2013/7/30 Corinna Vinschen:
> On Jul 30 14:27, Alexey Pavlov wrote:
>> 2013/7/30 Corinna Vinschen:
>> > On Jul 30 13:32, Alexey Pavlov wrote:
>> >> 2013/7/30 Corinna Vinschen
>> >> >
>> >> > On Jul 30 04:45, LRN wrote:
>> >> > > On 29.07.2013 19:47, Corinna Vinschen wrote:
>> >> > > > On Jul 29 19:36, LRN wrote:
>> >> > > >> I would expect people to get cygwin/msys in one place, and get MinGW in
>> >> > > >> another. Even mingw-get, while being a source of both msys and mingw
>> >> > > >> packages, clearly distinguishes betweent he two.
>> >> > > >
>> >> > > > That's what I understood differently.  From the discussion on mingw-w64
>> >> > > > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default
>> >> > > > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries.
>> >> > >
>> >> > > The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin.
>> >> > >
>> >> > > The problem is that the convention that everyone has been following for
>> >> > > years now is that all mingw stuff lives in /mingw, and all msys (cygwin)
>> >> > > stuff lives in /usr. These two are never mixed.
>> >> > > [...]
>> >> > > So i'd suggest to stick with /usr and /mingw convention and let mingw
>> >> > > take care of itself. It's simpler that way.
>> >> >
>> >> > Fine with me, of course.  I don't have that problem myself so whatever
>> >> > works better for you is ok.  But then the number of changed packages
>> >> > doesn't really matter.  From my POV MSYS sticks to being it's own distro
>> >> > with another focus than the Cygwin distro.
>> >> >
>> >> > So we're back to discussing in how far MSYS can be implemented using a
>> >> > stock Cygwin DLL under the hood and the tweaks being in an external MSYS
>> >> > DLL so users can mix the best of both worlds as they see fit for their
>> >> > purpose.
>> >> >
>> >>
>> >> As I see all discussion not about implementing but about philosophy of
>> >> MSYS.
>> >
>> > No.  We were talking about how to implement the changes.  Your patches
>> > change Cygwin directly, but the idea is to keep the actual changes
>> > separate, outside of Cygwin, as hooks.
>> >
>> >> At the start of discussion I wrote about my changes in Cygwin
>> >> sources to have MSYS. And also send small patches but nothing really
>> >> doing in this direction.
>> >> What steps do we need to start any work on implementing it?
>> >> Now I see next points where we can change Cygwin functionality:
>> >>  1. uname function
>> >>  2. reading /etc/fstab
>> >>  3. passing arguments and environment variables to non-Cygwin
>> >> processes ( environ.cc, spawn.cc )
>> >>  4. symlinks changes (copy instead symlink)
>> >
>> > Yes, these are the behavioral changes you want to implement, but this is
>> > the discussion as to *how* to implement them.  You never actually took
>> > part in this discssion yet.
>> >
>>
>> Now there are not many changes that I do in Cygwin sources and it
>> change only small functionality without breaking anything for cygwin
>> users (only symlinks is breaking thing).
>> If we need to implement changes in external DLL we doesn't want to
>> full rewrite modified functions in this DLL. External DLL need only do
>> changes inside the Cygwin functions not full replace this functions I
>> think.
>
> That was part of cgf's original proposal.  We have the CW_HOOK mechanism
> to overload entire functions (per the discussion not fully implemented
> yet) but there's no problem to implement a kind of mini-hook with a
> set of function pointers called from the CYgwin DLL at certain, yet to
> be defined points.
>
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?
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:
if (!iscygexec() && msysmode)
{
  // hook to function from msys.dll
} else {

 // default cygwin code
}

In this case we can create mini-hooks in cygwin DLL that call
functions from msys.dll if necessary.

>> Maybe you create separate branch in CVS source where we can try to
>> implement MSYS mode and also create hook in uname function, for
>> example, to try how it work?
>
> That should be possible.
>
>> >From my POV we need to create separate distro for MSYS where in bash
>> profile we can activate MSYS mode for Cygwin.dll with some environment
>> variable that tell to load msys.dll. But if you want has working
>> applications between normal Cygwin and msys-in-cygwin then they need
>> to be linked only with cygwin.dll and doesn't need to know anything
>> about msys.dll.
>
> Exactly.
>
>
> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat

Re: MSYS mode (continue)

[Christopher Faylor]

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

*Choosing where to call this might be tricky.  I don't see any reason
why MSYS shouldn't avail itself of the new native symlinks if they
can be created.  Otherwise, symlink would have to be short-circuited
in some cases so maybe we need to check the return value of the callout
function:

  ...
  switch (callout (CW_SYMLINK, is_native_symlink, &oldpath, &newpath))
    {
    case CO_R_KEEP_GOING:
      break;
    case CO_R_SHORT_CIRCUIT:
      return 0;
    case CO_R_ERR:
      return -1;
    }
  ...

The callout function will look something like:

enum callout_return
callout (enum callout co, ...)
{
  if (!callout_func)
    return CO_R_KEEP_GOING;
  va_list ap;
  va_start (ap, co);
  return callout_func (co, ap);
}

(I have to think about the most efficient way to implement this)

What other CO_* values are needed?

cgf

Re: MSYS mode (continue)

[Christopher Faylor]

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

Re: MSYS mode (continue)

[Christopher Faylor]

On Tue, Jul 30, 2013 at 10:55:33AM -0400, Christopher Faylor wrote:
>CW_MALLOC	Amount of cygheap memory to allocate

I didn't make it clear that this would be a cygwin_internal() call.

cgf