* From Microsoft: Windows 10 Console and Cygwin @ 2015-04-29 19:01 Rich Eizenhoefer 2015-04-29 19:50 ` Tim Prince 2015-04-29 20:06 ` Corinna Vinschen 0 siblings, 2 replies; 26+ messages in thread From: Rich Eizenhoefer @ 2015-04-29 19:01 UTC (permalink / raw) To: cygwin Hi, I'm the Program Manager at Microsoft for the updated Windows 10 console. I searched the Cygwin FAQ and mailing list archives for issues related to Windows 10 and found an item about multiple windows which should already be fixed. We have received a couple reports about crashes when running on Windows 10 with the new console enabled. For example: "cygwin is dying when i run a bunch of the git tools. For example: >grep -rin log .\ 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x68570000, RegionSize 0x3A0000, State 0x10000 C:\Program Files (x86)\Git\bin\grep.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0" Please let me know if there are other problems you are experiencing with the W10 console that are a regression from previous versions. We are a small team, but we want to help where possible to ensure that Cygwin continues to run well in Windows 10. Thanks, Rich -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-04-29 19:01 From Microsoft: Windows 10 Console and Cygwin Rich Eizenhoefer @ 2015-04-29 19:50 ` Tim Prince 2015-04-29 20:06 ` Corinna Vinschen 1 sibling, 0 replies; 26+ messages in thread From: Tim Prince @ 2015-04-29 19:50 UTC (permalink / raw) To: cygwin On 4/29/2015 3:01 PM, Rich Eizenhoefer wrote: > Hi, > > I'm the Program Manager at Microsoft for the updated Windows 10 console. I searched the Cygwin FAQ and mailing list archives for issues related to Windows 10 and found an item about multiple windows which should already be fixed. We have received a couple reports about crashes when running on Windows 10 with the new console enabled. For example: > > "cygwin is dying when i run a bunch of the git tools. For example: >grep -rin log .\ 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x68570000, RegionSize 0x3A0000, State 0x10000 C:\Program Files (x86)\Git\bin\grep.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0" > > Please let me know if there are other problems you are experiencing with the W10 console that are a regression from previous versions. We are a small team, but we want to help where possible to ensure that Cygwin continues to run well in Windows 10. > > Thanks, > > Rich > > -- > Windows 10 has given me satisfactory results with cygwin64 (although I'm more likely to run git under 8.1). This is a welcome change from the days when Microsoft personnel stated that bugs reported primarily by cygwin users would not be fixed even when they could be reproduced outside cygwin. -- Tim Prince -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-04-29 19:01 From Microsoft: Windows 10 Console and Cygwin Rich Eizenhoefer 2015-04-29 19:50 ` Tim Prince @ 2015-04-29 20:06 ` Corinna Vinschen 2015-04-29 21:31 ` Rich Eizenhoefer 2015-04-29 23:43 ` Michael DePaulo 1 sibling, 2 replies; 26+ messages in thread From: Corinna Vinschen @ 2015-04-29 20:06 UTC (permalink / raw) To: cygwin, Rich Eizenhoefer [-- Attachment #1: Type: text/plain, Size: 2879 bytes --] Hi Rich, nice to read from you. On Apr 29 19:01, Rich Eizenhoefer wrote: > Hi, > > I'm the Program Manager at Microsoft for the updated Windows 10 > console. I searched the Cygwin FAQ and mailing list archives for > issues related to Windows 10 and found an item about multiple windows > which should already be fixed. We have received a couple reports about > crashes when running on Windows 10 with the new console enabled. For > example: > > "cygwin is dying when i run a bunch of the git tools. For example: >grep -rin log .\ 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x68570000, RegionSize 0x3A0000, State 0x10000 C:\Program Files (x86)\Git\bin\grep.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0" This error message is a bit weird. For one thing, it would be nice if you could give us a pointer to the message. I'm not aware of such a bug report. Also, this is about a non-Cygwin version of git as the path to the git tools suggests. On the other hand, if it's not a Cygwin version, the error message itself only makes marginal sense. So maybe it's a Cygwin DLL as part of some third party package which is often outdated in relation to the official Cygwin distro version. As for the error message itself, it refers to the fact that, after a Cygwin fork() call, the forked child can't reserve the space required for the so-called "cygwin heap", a region used for internal usage especially important for fork/exec related stuff. This usually points to Cygwin DLLs which are not rebased, or a non-Cygwin DLL loaded into a spot required for a Cygwin DLL after a fork. This is especially a problem on 32 bit due to the restricted virtual memory. However, if I'm not completely off-track, the bug report does not really have anything to do with a bad interaction between the W10 console and Cygwin. While my own W10 virtual machine under Qemu/KVM fails to update to versions after build 9926, I didn't encounter any unusual behaviour of the W10 console in comparison with, say, the W8.1 console yet. I'm usually running Cygwin tools in mintty, but I did test the W10 console, too, of course. > Please let me know if there are other problems you are experiencing > with the W10 console that are a regression from previous versions. We > are a small team, but we want to help where possible to ensure that > Cygwin continues to run well in Windows 10. Thanks for the offer. We have a regression introduced with Windows 7 and never fixed in W8 or 8.1, albeit I reported it as part of the Windows 7 beta tests. Are you interested to give this a whirl as well? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: From Microsoft: Windows 10 Console and Cygwin 2015-04-29 20:06 ` Corinna Vinschen @ 2015-04-29 21:31 ` Rich Eizenhoefer 2015-04-30 8:22 ` Corinna Vinschen 2015-04-29 23:43 ` Michael DePaulo 1 sibling, 1 reply; 26+ messages in thread From: Rich Eizenhoefer @ 2015-04-29 21:31 UTC (permalink / raw) To: cygwin Thanks Corinna. The info I sent on the bug below is all that I have. It's quite likely related to the stability of the version of Win 10 it was run against. My larger purpose is to reach out to you all and see what we can do to help Cygwin run with our new console, we don't want to break anybody if at all possible. Please send me the info on the Windows 7 issue and I'll review and get back to you about whether we are able to help. If we "can" (figure it out, understand and repro the issue, not several weeks worth of work) we'll get to it. Rich -----Original Message----- From: Corinna Vinschen [mailto:corinna-cygwin@cygwin.com] Sent: Wednesday, April 29, 2015 1:06 PM To: cygwin@cygwin.com; Rich Eizenhoefer Subject: Re: From Microsoft: Windows 10 Console and Cygwin Hi Rich, nice to read from you. On Apr 29 19:01, Rich Eizenhoefer wrote: > Hi, > > I'm the Program Manager at Microsoft for the updated Windows 10 > console. I searched the Cygwin FAQ and mailing list archives for > issues related to Windows 10 and found an item about multiple windows > which should already be fixed. We have received a couple reports about > crashes when running on Windows 10 with the new console enabled. For > example: > > "cygwin is dying when i run a bunch of the git tools. For example: >grep -rin log .\ 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x68570000, RegionSize 0x3A0000, State 0x10000 C:\Program Files (x86)\Git\bin\grep.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0" This error message is a bit weird. For one thing, it would be nice if you could give us a pointer to the message. I'm not aware of such a bug report. Also, this is about a non-Cygwin version of git as the path to the git tools suggests. On the other hand, if it's not a Cygwin version, the error message itself only makes marginal sense. So maybe it's a Cygwin DLL as part of some third party package which is often outdated in relation to the official Cygwin distro version. As for the error message itself, it refers to the fact that, after a Cygwin fork() call, the forked child can't reserve the space required for the so-called "cygwin heap", a region used for internal usage especially important for fork/exec related stuff. This usually points to Cygwin DLLs which are not rebased, or a non-Cygwin DLL loaded into a spot required for a Cygwin DLL after a fork. This is especially a problem on 32 bit due to the restricted virtual memory. However, if I'm not completely off-track, the bug report does not really have anything to do with a bad interaction between the W10 console and Cygwin. While my own W10 virtual machine under Qemu/KVM fails to update to versions after build 9926, I didn't encounter any unusual behaviour of the W10 console in comparison with, say, the W8.1 console yet. I'm usually running Cygwin tools in mintty, but I did test the W10 console, too, of course. > Please let me know if there are other problems you are experiencing > with the W10 console that are a regression from previous versions. We > are a small team, but we want to help where possible to ensure that > Cygwin continues to run well in Windows 10. Thanks for the offer. We have a regression introduced with Windows 7 and never fixed in W8 or 8.1, albeit I reported it as part of the Windows 7 beta tests. Are you interested to give this a whirl as well? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-04-29 21:31 ` Rich Eizenhoefer @ 2015-04-30 8:22 ` Corinna Vinschen 2015-05-01 19:29 ` Rich Eizenhoefer 0 siblings, 1 reply; 26+ messages in thread From: Corinna Vinschen @ 2015-04-30 8:22 UTC (permalink / raw) To: cygwin, Rich Eizenhoefer [-- Attachment #1: Type: text/plain, Size: 2730 bytes --] On Apr 29 21:31, Rich Eizenhoefer wrote: > Thanks Corinna. > > The info I sent on the bug below is all that I have. It's quite likely > related to the stability of the version of Win 10 it was run against. Nothing to worry about. Msys is so old, it's almost not true anymore. > My larger purpose is to reach out to you all and see what we can do to > help Cygwin run with our new console, we don't want to break anybody > if at all possible. Please send me the info on the Windows 7 issue and > I'll review and get back to you about whether we are able to help. If > we "can" (figure it out, understand and repro the issue, not several > weeks worth of work) we'll get to it. That may be tricky, but the workaround we use is really annoying. The problem is centered around creating an invisible console. Please have a look at https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler_console.cc;h=44ee1c404baf1263867596c274103f4a216160bb;hb=refs/heads/cygwin-2.0#l2595 The comment starting at line 2603 explains what we're trying to accomplish. The method called for pre-Windows 7 systems, and the only part of the functionality up to 2009 is fhandler_console::create_invisible_console, starting at line 2470. This simple technique, basically just CreateWindowStation SetProcessWindowStation(new window station) AllocConsole SetProcessWindowStation(original window station) doesn't work anymore since Windows 7. What happens is that AllocConsole will NOT create the console in the newly created and invisible window station, but instead it will create the console fully visible on the original window station. As I mentioned in my previous mail, I reported this problem in the Windows 7 beta test phase, but unfortunately it was rejected. Windows 8 and 8.1, as well as Windows 10 still suffer the same problem. The workaround for all systems since Windows 7 is implemented in fhandler_console::create_invisible_console_workaround starting at line 2508. See the preceeding and inline comments. What it does is basically to start a dummy process with the SW_HIDE flag and then to attach the current process to the console of this dummy process. As you can imagine, this is awkward and slow. It would be very nice if the original method could be made to work again in Windows 10. Out of curiosity, and if you're willing to share, it would be nice to know why this regression (from an external developer point of view) was introduced in Windows 7. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: From Microsoft: Windows 10 Console and Cygwin 2015-04-30 8:22 ` Corinna Vinschen @ 2015-05-01 19:29 ` Rich Eizenhoefer 2015-05-02 13:47 ` Corinna Vinschen 0 siblings, 1 reply; 26+ messages in thread From: Rich Eizenhoefer @ 2015-05-01 19:29 UTC (permalink / raw) To: cygwin Hi Corinna, I spent most of the day yesterday and part of this AM talking with console devs and going through the windows codebase to understand the changes between Vista and W7 (and now). The regression in functionality wasn't inadvertent, but related to security. The result is that the console is no longer able to get the windowstation id and object information (oi.dwFlags) to test whether the console window should be visible, all things it used to do. You are right that during console init, our process has already been assigned to the default Windows station. I took your code and spent several hours experimenting as well, looking for another way to do this (simply) with no luck. I have added an item in our backlog to see how we can provide a secure way to allow allocating an invisible console. We have some ideas, just have to work with other teams in windows core to provide the functionality. You'd think this would be pretty easy, but the console driver is a little nutty and by the time we get to the visible or not decision point, no meaningful context is currently available to check against. Rich -----Original Message----- From: Corinna Vinschen [mailto:corinna-cygwin@cygwin.com] Sent: Thursday, April 30, 2015 1:23 AM To: cygwin@cygwin.com; Rich Eizenhoefer Subject: Re: From Microsoft: Windows 10 Console and Cygwin On Apr 29 21:31, Rich Eizenhoefer wrote: > Thanks Corinna. > > The info I sent on the bug below is all that I have. It's quite likely > related to the stability of the version of Win 10 it was run against. Nothing to worry about. Msys is so old, it's almost not true anymore. > My larger purpose is to reach out to you all and see what we can do to > help Cygwin run with our new console, we don't want to break anybody > if at all possible. Please send me the info on the Windows 7 issue and > I'll review and get back to you about whether we are able to help. If > we "can" (figure it out, understand and repro the issue, not several > weeks worth of work) we'll get to it. That may be tricky, but the workaround we use is really annoying. The problem is centered around creating an invisible console. Please have a look at https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler_console.cc;h=44ee1c404baf1263867596c274103f4a216160bb;hb=refs/heads/cygwin-2.0#l2595 The comment starting at line 2603 explains what we're trying to accomplish. The method called for pre-Windows 7 systems, and the only part of the functionality up to 2009 is fhandler_console::create_invisible_console, starting at line 2470. This simple technique, basically just CreateWindowStation SetProcessWindowStation(new window station) AllocConsole SetProcessWindowStation(original window station) doesn't work anymore since Windows 7. What happens is that AllocConsole will NOT create the console in the newly created and invisible window station, but instead it will create the console fully visible on the original window station. As I mentioned in my previous mail, I reported this problem in the Windows 7 beta test phase, but unfortunately it was rejected. Windows 8 and 8.1, as well as Windows 10 still suffer the same problem. The workaround for all systems since Windows 7 is implemented in fhandler_console::create_invisible_console_workaround starting at line 2508. See the preceeding and inline comments. What it does is basically to start a dummy process with the SW_HIDE flag and then to attach the current process to the console of this dummy process. As you can imagine, this is awkward and slow. It would be very nice if the original method could be made to work again in Windows 10. Out of curiosity, and if you're willing to share, it would be nice to know why this regression (from an external developer point of view) was introduced in Windows 7. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-05-01 19:29 ` Rich Eizenhoefer @ 2015-05-02 13:47 ` Corinna Vinschen 2015-05-04 22:35 ` Rich Eizenhoefer 0 siblings, 1 reply; 26+ messages in thread From: Corinna Vinschen @ 2015-05-02 13:47 UTC (permalink / raw) To: Rich Eizenhoefer; +Cc: cygwin [-- Attachment #1: Type: text/plain, Size: 3428 bytes --] Hi Rich, thanks for your help. On May 1 18:51, Rich Eizenhoefer wrote: > Hi Corinna, > > I spent most of the day yesterday and part of this AM talking with > console devs and going through the windows codebase to understand the > changes between Vista and W7 (and now). The regression in > functionality wasn't inadvertent, but related to security. Oh, ok. W7 introduced the conhost.exe process as well. Was that part of the security consideration or was the windowstation change a result of changing to a process-based model? > The result > is that the console is no longer able to get the windowstation id and > object information (oi.dwFlags) to test whether the console window > should be visible, all things it used to do. You are right that during > console init, our process has already been assigned to the default > Windows station. I took your code and spent several hours > experimenting as well, looking for another way to do this (simply) > with no luck. Bummer. > I have added an item in our backlog to see how we can > provide a secure way to allow allocating an invisible console. We have > some ideas, just have to work with other teams in windows core to > provide the functionality. You'd think this would be pretty easy, but > the console driver is a little nutty and by the time we get to the > visible or not decision point, no meaningful context is currently > available to check against. No worries. I never thought that's easy stuff. I'm looking forward to trying out the ideas you're coming up with. Two points: - I'm on vacation for a while now so my replies will be a bit sluggish and testing anything will have to wait, too. I hope that's ok. - Tonight it occured to me to ask you another question: For a long time Cygwin is emulating pseudo ttys using named pipes. This works fine for Cygwin applications, but it has some downside when using non-Cygwin executables. MSVCRT's isatty() function returns 0 for named pipes, because it's (obviously) not aware of Cygwin's pseudo tty functionality. As a result, many non-Cygwin console applications misbehave in Cygwin terminals or remote ssh sessions as soon as it comes to user input or paging. Two possible solutions for this problem come to mind: - Either MSVCRT's isatty function recognizes named pipes used as Cygwin PTYs. That's not tricky because the name of the pipe is a simple indicator. But I could understand a certain reluctance, because that would require the MSVCRT guys to support this solution. - Or the console API could be extended (or even just documented as far as it exists) so that the Cygwin PTY implementation could use console handles under the hood, rather than named pipes. For that to work, the PTY master side would have to have been able to create console handles and connect to the master side of them, basically the side which right now conhost.exe is attached to. Do you see a chance to open this API up to allow other processes than conhost to create the master side of a console, aka a PTY in POSIX speak? Or is there already an existing solution I just don't see? Thanks a lot, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: From Microsoft: Windows 10 Console and Cygwin 2015-05-02 13:47 ` Corinna Vinschen @ 2015-05-04 22:35 ` Rich Eizenhoefer 2015-05-05 8:22 ` Michael DePaulo 2015-05-31 20:07 ` Ismail Donmez 0 siblings, 2 replies; 26+ messages in thread From: Rich Eizenhoefer @ 2015-05-04 22:35 UTC (permalink / raw) To: cygwin Hi Corinna, On May 1 18:51, Rich Eizenhoefer wrote: > Hi Corinna, > > I spent most of the day yesterday and part of this AM talking with > console devs and going through the windows codebase to understand the > changes between Vista and W7 (and now). The regression in > functionality wasn't inadvertent, but related to security. Oh, ok. W7 introduced the conhost.exe process as well. Was that part of the security consideration or was the windowstation change a result of changing to a process-based model? The tribal knowledge of what drove the change is seeming lost in time. There are no comments in the code base discussing it, nor can we find any legacy specs. There is a reference to the security change being made, but not to the why. <snip> Two points: - I'm on vacation for a while now so my replies will be a bit sluggish and testing anything will have to wait, too. I hope that's ok. - Tonight it occured to me to ask you another question: For a long time Cygwin is emulating pseudo ttys using named pipes. This works fine for Cygwin applications, but it has some downside when using non-Cygwin executables. MSVCRT's isatty() function returns 0 for named pipes, because it's (obviously) not aware of Cygwin's pseudo tty functionality. As a result, many non-Cygwin console applications misbehave in Cygwin terminals or remote ssh sessions as soon as it comes to user input or paging. Two possible solutions for this problem come to mind: - Either MSVCRT's isatty function recognizes named pipes used as Cygwin PTYs. That's not tricky because the name of the pipe is a simple indicator. But I could understand a certain reluctance, because that would require the MSVCRT guys to support this solution. - Or the console API could be extended (or even just documented as far as it exists) so that the Cygwin PTY implementation could use console handles under the hood, rather than named pipes. For that to work, the PTY master side would have to have been able to create console handles and connect to the master side of them, basically the side which right now conhost.exe is attached to. Do you see a chance to open this API up to allow other processes than conhost to create the master side of a console, aka a PTY in POSIX speak? Or is there already an existing solution I just don't see? I've created a backlog item for this request so we can track the ask. It's possible, but would probably need to pick your brain in-depth more about the ask in the future. In the meantime, is it okay if I attach a copy of this email thread to the internal tracking item in our database? If not, I'll just keep the summary that I've already added. --Rich ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-05-04 22:35 ` Rich Eizenhoefer @ 2015-05-05 8:22 ` Michael DePaulo 2015-05-31 20:07 ` Ismail Donmez 1 sibling, 0 replies; 26+ messages in thread From: Michael DePaulo @ 2015-05-05 8:22 UTC (permalink / raw) To: The Cygwin Mailing List On Mon, May 4, 2015 at 3:51 PM, Rich Eizenhoefer <riche@microsoft.com> wrote: <snip> > > I've created a backlog item for this request so we can track the ask. It's possible, but would probably need to pick your brain in-depth more about the ask in the future. In the meantime, is it okay if I attach a copy of this email thread to the internal tracking item in our database? If not, I'll just keep the summary that I've already added. > > --Rich I am not an official spokesperson for Cygwin, but I am sure that you are allowed to copy this email thread. The cygwin mailing lists are public and they are publicly archived: https://cygwin.com/ml/cygwin/2015-05/ https://cygwin.com/ml/cygwin/2015-05/msg00063.html -Mike -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: From Microsoft: Windows 10 Console and Cygwin 2015-05-04 22:35 ` Rich Eizenhoefer 2015-05-05 8:22 ` Michael DePaulo @ 2015-05-31 20:07 ` Ismail Donmez 2015-06-01 8:24 ` Corinna Vinschen 1 sibling, 1 reply; 26+ messages in thread From: Ismail Donmez @ 2015-05-31 20:07 UTC (permalink / raw) To: cygwin Rich Eizenhoefer wrote > I've created a backlog item for this request so we can track the ask. It's > possible, but would probably need to pick your brain in-depth more about > the ask in the future. In the meantime, is it okay if I attach a copy of > this email thread to the internal tracking item in our database? If not, > I'll just keep the summary that I've already added. I wonder if there is any news on this? Since Windows 10 RTM is approaching it would be nice to have some update about this. -- View this message in context: http://cygwin.1069669.n5.nabble.com/From-Microsoft-Windows-10-Console-and-Cygwin-tp117937p118602.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-05-31 20:07 ` Ismail Donmez @ 2015-06-01 8:24 ` Corinna Vinschen 2015-06-01 20:27 ` Rich Eizenhoefer 0 siblings, 1 reply; 26+ messages in thread From: Corinna Vinschen @ 2015-06-01 8:24 UTC (permalink / raw) To: cygwin; +Cc: Rich Eizenhoefer [-- Attachment #1: Type: text/plain, Size: 806 bytes --] On May 31 11:51, Ismail Donmez wrote: > Rich Eizenhoefer wrote > > I've created a backlog item for this request so we can track the ask. It's > > possible, but would probably need to pick your brain in-depth more about > > the ask in the future. In the meantime, is it okay if I attach a copy of > > this email thread to the internal tracking item in our database? If not, > > I'll just keep the summary that I've already added. > > I wonder if there is any news on this? Since Windows 10 RTM is approaching > it would be nice to have some update about this. I'd sent my OK to attach the thread to Rich in PM during my vacation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: From Microsoft: Windows 10 Console and Cygwin 2015-06-01 8:24 ` Corinna Vinschen @ 2015-06-01 20:27 ` Rich Eizenhoefer 2015-06-02 7:56 ` Corinna Vinschen 2015-06-02 8:10 ` İsmail Dönmez 0 siblings, 2 replies; 26+ messages in thread From: Rich Eizenhoefer @ 2015-06-01 20:27 UTC (permalink / raw) To: cygwin This feature requires multiple moving parts from other teams at Microsoft and we have not started on it yet. We have begun planning for the first post-Windows 10 release, and within our team we have talked about how to create hidden consoles and make the console driver/API better all around. I don't have a timeframe yet when we might get to this but it has been part of our presentation to management about the backlog items we prioritized. Overall there are almost 280 items on the backlog and this is in the "elite 25" that are being considered. Thanks, Rich -----Original Message----- From: Corinna Vinschen [mailto:corinna-cygwin@cygwin.com] Sent: Monday, June 1, 2015 1:25 AM To: cygwin@cygwin.com Cc: Rich Eizenhoefer Subject: Re: From Microsoft: Windows 10 Console and Cygwin On May 31 11:51, Ismail Donmez wrote: > Rich Eizenhoefer wrote > > I've created a backlog item for this request so we can track the > > ask. It's possible, but would probably need to pick your brain > > in-depth more about the ask in the future. In the meantime, is it > > okay if I attach a copy of this email thread to the internal > > tracking item in our database? If not, I'll just keep the summary that I've already added. > > I wonder if there is any news on this? Since Windows 10 RTM is > approaching it would be nice to have some update about this. I'd sent my OK to attach the thread to Rich in PM during my vacation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-06-01 20:27 ` Rich Eizenhoefer @ 2015-06-02 7:56 ` Corinna Vinschen 2015-06-02 8:10 ` İsmail Dönmez 1 sibling, 0 replies; 26+ messages in thread From: Corinna Vinschen @ 2015-06-02 7:56 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1013 bytes --] Hi Rich, On Jun 1 20:27, Rich Eizenhoefer wrote: > This feature requires multiple moving parts from other teams at > Microsoft and we have not started on it yet. We have begun planning > for the first post-Windows 10 release, and within our team we have > talked about how to create hidden consoles and make the console > driver/API better all around. I don't have a timeframe yet when we > might get to this but it has been part of our presentation to > management about the backlog items we prioritized. Overall there are > almost 280 items on the backlog and this is in the "elite 25" that > are being considered. Thanks for letting us know. Surely a lot of stuff you have to look into. I'm looking forward to the updates. Feel free to contact us any time if you need testers (or critics ;)) for certain features. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-06-01 20:27 ` Rich Eizenhoefer 2015-06-02 7:56 ` Corinna Vinschen @ 2015-06-02 8:10 ` İsmail Dönmez 2015-06-02 16:37 ` Rich Eizenhoefer 1 sibling, 1 reply; 26+ messages in thread From: İsmail Dönmez @ 2015-06-02 8:10 UTC (permalink / raw) To: cygwin; +Cc: riche On Mon, Jun 1, 2015 at 11:27 PM, Rich Eizenhoefer <riche@microsoft.com> wrote: > This feature requires multiple moving parts from other teams at Microsoft and we have not started on it yet. We have begun planning for the first post-Windows 10 release, and within our team we have talked about how to create hidden consoles and make the console driver/API better all around. I don't have a timeframe yet when we might get to this but it has been part of our presentation to management about the backlog items we prioritized. Overall there are almost 280 items on the backlog and this is in the "elite 25" that are being considered. Many thanks for the update, one thing I wonder if you consider changing isatty function to support Cygwin PTYs, that would fix a lot of headaches we have with native windows programs running under Cygwin. ismail -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: From Microsoft: Windows 10 Console and Cygwin 2015-06-02 8:10 ` İsmail Dönmez @ 2015-06-02 16:37 ` Rich Eizenhoefer 2015-06-02 16:50 ` Corinna Vinschen 2015-06-02 19:20 ` Eric Blake 0 siblings, 2 replies; 26+ messages in thread From: Rich Eizenhoefer @ 2015-06-02 16:37 UTC (permalink / raw) To: İsmail Dönmez, cygwin Can you provide more detail on changing isatty function to support Cygwin PTY's? I need to be able to support the request in our backlog. Thanks again, Rich -----Original Message----- From: İsmail Dönmez [mailto:ismail@donmez.ws] Sent: Tuesday, June 2, 2015 1:10 AM To: cygwin@cygwin.com Cc: Rich Eizenhoefer Subject: Re: From Microsoft: Windows 10 Console and Cygwin On Mon, Jun 1, 2015 at 11:27 PM, Rich Eizenhoefer <riche@microsoft.com> wrote: > This feature requires multiple moving parts from other teams at Microsoft and we have not started on it yet. We have begun planning for the first post-Windows 10 release, and within our team we have talked about how to create hidden consoles and make the console driver/API better all around. I don't have a timeframe yet when we might get to this but it has been part of our presentation to management about the backlog items we prioritized. Overall there are almost 280 items on the backlog and this is in the "elite 25" that are being considered. Many thanks for the update, one thing I wonder if you consider changing isatty function to support Cygwin PTYs, that would fix a lot of headaches we have with native windows programs running under Cygwin. ismail ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-06-02 16:37 ` Rich Eizenhoefer @ 2015-06-02 16:50 ` Corinna Vinschen 2015-06-02 17:50 ` Rich Eizenhoefer 2015-06-02 19:20 ` Eric Blake 1 sibling, 1 reply; 26+ messages in thread From: Corinna Vinschen @ 2015-06-02 16:50 UTC (permalink / raw) To: cygwin; +Cc: Rich Eizenhoefer [-- Attachment #1.1: Type: text/plain, Size: 799 bytes --] Hi Rich, On Jun 2 16:37, Rich Eizenhoefer wrote: > Can you provide more detail on changing isatty function to support > Cygwin PTY's? I need to be able to support the request in our backlog. As I outlined in https://cygwin.com/ml/cygwin/2015-05/msg00029.html, I'm wondering if the MSVCRT guys would really like to support this, but if they are willing to consider that, I have a POC implementation of a MSVCRT isatty replacement implementation I once created for a customer. I attached it to this mail. It's entirely self-written, free for any usage, no strings attached. Feel free to use it as you see fit. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #1.2: isatty-for-native-apps.c --] [-- Type: text/plain, Size: 3122 bytes --] #include <stdio.h> #include <io.h> #include <errno.h> #include <wchar.h> #include <windows.h> #include <winternl.h> #ifndef __MINGW64_VERSION_MAJOR /* MS winternl.h defines FILE_INFORMATION_CLASS, but with only a different single member. */ enum FILE_INFORMATION_CLASSX { FileNameInformation = 9 }; typedef struct _FILE_NAME_INFORMATION { ULONG FileNameLength; WCHAR FileName[1]; } FILE_NAME_INFORMATION, *PFILE_NAME_INFORMATION; NTSTATUS (NTAPI *pNtQueryInformationFile) (HANDLE, PIO_STATUS_BLOCK, PVOID, ULONG, FILE_INFORMATION_CLASSX); #else NTSTATUS (NTAPI *pNtQueryInformationFile) (HANDLE, PIO_STATUS_BLOCK, PVOID, ULONG, FILE_INFORMATION_CLASS); #endif int isatty (int fd) { HANDLE fh; NTSTATUS status; IO_STATUS_BLOCK io; long buf[66]; /* NAME_MAX + 1 + sizeof ULONG */ PFILE_NAME_INFORMATION pfni = (PFILE_NAME_INFORMATION) buf; PWCHAR cp; /* First check using _isatty. Note that this returns the wrong result for NUL, for instance! Workaround is not to use _isatty at all, but rather GetFileType plus object name checking. */ if (_isatty (fd)) return 1; /* Now fetch the underlying HANDLE. */ fh = (HANDLE) _get_osfhandle (fd); if (!fh || fh == INVALID_HANDLE_VALUE) { errno = EBADF; return 0; } /* Must be a pipe. */ if (GetFileType (fh) != FILE_TYPE_PIPE) goto no_tty; /* Calling the native NT function NtQueryInformationFile is required to support pre-Vista systems. If that's of no concern, Vista introduced the GetFileInformationByHandleEx call with the FileNameInfo info class, which can be used instead. */ if (!pNtQueryInformationFile) { pNtQueryInformationFile = (NTSTATUS (NTAPI *)(HANDLE, PIO_STATUS_BLOCK, PVOID, ULONG, FILE_INFORMATION_CLASS)) GetProcAddress (GetModuleHandle ("ntdll.dll"), "NtQueryInformationFile"); if (!pNtQueryInformationFile) goto no_tty; } if (!NT_SUCCESS (pNtQueryInformationFile (fh, &io, pfni, sizeof buf, FileNameInformation))) goto no_tty; /* The filename is not guaranteed to be NUL-terminated. */ pfni->FileName[pfni->FileNameLength / sizeof (WCHAR)] = L'\0'; /* Now check the name pattern. The filename of a Cygwin pseudo tty pipe looks like this: \cygwin-%16llx-pty%d-{to,from}-master %16llx is the hash of the Cygwin installation, (to support multiple parallel installations), %d is the pseudo tty number, "to" or "from" differs the pipe direction. "from" is a stdin, "to" a stdout-like pipe. */ cp = pfni->FileName; if (!wcsncmp (cp, L"\\cygwin-", 8) && !wcsncmp (cp + 24, L"-pty", 4)) { cp = wcschr (cp + 28, '-'); if (!cp) goto no_tty; if (!wcscmp (cp, L"-from-master") || !wcscmp (cp, L"-to-master")) return 1; } no_tty: errno = EINVAL; return 0; } int main () { if (isatty(0)) printf("tty\n"); else printf("not a tty\n"); return 0; } [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: From Microsoft: Windows 10 Console and Cygwin 2015-06-02 16:50 ` Corinna Vinschen @ 2015-06-02 17:50 ` Rich Eizenhoefer 0 siblings, 0 replies; 26+ messages in thread From: Rich Eizenhoefer @ 2015-06-02 17:50 UTC (permalink / raw) To: cygwin Thank you, Corinna and Ismail. I had added an item for this to the console backlog and attached your email (with my annotations) and is_a_tty code to it. --Rich -----Original Message----- From: Corinna Vinschen [mailto:corinna-cygwin@cygwin.com] Sent: Tuesday, June 2, 2015 9:50 AM To: cygwin@cygwin.com Cc: Rich Eizenhoefer Subject: Re: From Microsoft: Windows 10 Console and Cygwin Hi Rich, On Jun 2 16:37, Rich Eizenhoefer wrote: > Can you provide more detail on changing isatty function to support > Cygwin PTY's? I need to be able to support the request in our backlog. As I outlined in https://cygwin.com/ml/cygwin/2015-05/msg00029.html, I'm wondering if the MSVCRT guys would really like to support this, but if they are willing to consider that, I have a POC implementation of a MSVCRT isatty replacement implementation I once created for a customer. I attached it to this mail. It's entirely self-written, free for any usage, no strings attached. Feel free to use it as you see fit. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-06-02 16:37 ` Rich Eizenhoefer 2015-06-02 16:50 ` Corinna Vinschen @ 2015-06-02 19:20 ` Eric Blake 2015-06-02 20:36 ` Vince Rice 2015-06-02 20:49 ` Warren Young 1 sibling, 2 replies; 26+ messages in thread From: Eric Blake @ 2015-06-02 19:20 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 478 bytes --] On 06/02/2015 10:37 AM, Rich Eizenhoefer wrote: > Can you provide more detail on changing isatty function to support Cygwin PTY's? I need to be able to support the request in our backlog. As long as we are wishing, it would be awesome if Windows natively supported ptys as actual objects, instead of making cygwin have to emulate them on top of other objects. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 604 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-06-02 19:20 ` Eric Blake @ 2015-06-02 20:36 ` Vince Rice 2015-06-02 20:49 ` Warren Young 1 sibling, 0 replies; 26+ messages in thread From: Vince Rice @ 2015-06-02 20:36 UTC (permalink / raw) To: cygwin > On Jun 2, 2015, at 2:20 PM, Eric Blake <eblake@redhat.com> wrote: > > On 06/02/2015 10:37 AM, Rich Eizenhoefer wrote: >> Can you provide more detail on changing isatty function to support Cygwin PTY's? I need to be able to support the request in our backlog. > > As long as we are wishing, it would be awesome if Windows natively > supported ptys as actual objects, instead of making cygwin have to > emulate them on top of other objects. > An ignorant question from an uninformed bystander — wouldn’t the “awesome” be the other of Corinna’s suggestions in her original email, i.e. that Windows open up the console API so that Cygwin can create a real TTY instead of having to emulate them in PTYs? I would think that would be the biggest win, with the least amount of cygwin-specific flavor to it. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-06-02 19:20 ` Eric Blake 2015-06-02 20:36 ` Vince Rice @ 2015-06-02 20:49 ` Warren Young 2015-06-08 11:49 ` Corinna Vinschen 1 sibling, 1 reply; 26+ messages in thread From: Warren Young @ 2015-06-02 20:49 UTC (permalink / raw) To: The Cygwin Mailing List On Jun 2, 2015, at 1:20 PM, Eric Blake <eblake@redhat.com> wrote: > > On 06/02/2015 10:37 AM, Rich Eizenhoefer wrote: >> Can you provide more detail on changing isatty function to support Cygwin PTY's? I need to be able to support the request in our backlog. > > As long as we are wishing, it would be awesome if Windows natively > supported ptys as actual objects, instead of making cygwin have to > emulate them on top of other objects. In my ignorance of how ptys map to Windows console objects, I held off from asking for this when Mr. Eizenhoefer solicited ideas, but this is what I thought of at that time, too. In other words, this notion of “virtual terminals” is already implemented multiple times, following a standard that specifies the expected semantics — POSIX — so why not just do that? Why, in the end, can Windows *not* have ptys? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-06-02 20:49 ` Warren Young @ 2015-06-08 11:49 ` Corinna Vinschen 2015-06-08 17:23 ` Rich Eizenhoefer 0 siblings, 1 reply; 26+ messages in thread From: Corinna Vinschen @ 2015-06-08 11:49 UTC (permalink / raw) To: cygwin; +Cc: Rich Eizenhoefer [-- Attachment #1: Type: text/plain, Size: 1513 bytes --] On Jun 2 14:49, Warren Young wrote: > On Jun 2, 2015, at 1:20 PM, Eric Blake <eblake@redhat.com> wrote: > > > > On 06/02/2015 10:37 AM, Rich Eizenhoefer wrote: > >> Can you provide more detail on changing isatty function to support Cygwin PTY's? I need to be able to support the request in our backlog. > > > > As long as we are wishing, it would be awesome if Windows natively > > supported ptys as actual objects, instead of making cygwin have to > > emulate them on top of other objects. > > In my ignorance of how ptys map to Windows console objects, I held off from asking for this when Mr. Eizenhoefer solicited ideas, but this is what I thought of at that time, too. > > In other words, this notion of “virtual terminals” is already implemented multiple times, following a standard that specifies the expected semantics — POSIX — so why not just do that? > > Why, in the end, can Windows *not* have ptys? That's a good question. Basically Windows console handles are kind of one half of the equation. They don't follow the expected semantics but they are what native Windows tools know and expect. Opening up the other half of the equation, the server side, without forcing to start conhost, might be enough to allow emulating POSIX ptys. But I agree, real ptys with POSIX semantics would be cool. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: From Microsoft: Windows 10 Console and Cygwin 2015-06-08 11:49 ` Corinna Vinschen @ 2015-06-08 17:23 ` Rich Eizenhoefer 0 siblings, 0 replies; 26+ messages in thread From: Rich Eizenhoefer @ 2015-06-08 17:23 UTC (permalink / raw) To: cygwin We're hearing more and more need for something like this, not just a hidden console window but a proper bifurcation between a console server and client so to speak. I'll add the POSIX pty idea to our backlog for when we start reviewing the overall requests in this area. --Rich -----Original Message----- From: Corinna Vinschen [mailto:corinna-cygwin@cygwin.com] Sent: Monday, June 8, 2015 4:49 AM To: cygwin@cygwin.com Cc: Rich Eizenhoefer Subject: Re: From Microsoft: Windows 10 Console and Cygwin On Jun 2 14:49, Warren Young wrote: > On Jun 2, 2015, at 1:20 PM, Eric Blake <eblake@redhat.com> wrote: > > > > On 06/02/2015 10:37 AM, Rich Eizenhoefer wrote: > >> Can you provide more detail on changing isatty function to support Cygwin PTY's? I need to be able to support the request in our backlog. > > > > As long as we are wishing, it would be awesome if Windows natively > > supported ptys as actual objects, instead of making cygwin have to > > emulate them on top of other objects. > > In my ignorance of how ptys map to Windows console objects, I held off from asking for this when Mr. Eizenhoefer solicited ideas, but this is what I thought of at that time, too. > > In other words, this notion of “virtual terminals” is already implemented multiple times, following a standard that specifies the expected semantics — POSIX — so why not just do that? > > Why, in the end, can Windows *not* have ptys? That's a good question. Basically Windows console handles are kind of one half of the equation. They don't follow the expected semantics but they are what native Windows tools know and expect. Opening up the other half of the equation, the server side, without forcing to start conhost, might be enough to allow emulating POSIX ptys. But I agree, real ptys with POSIX semantics would be cool. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-04-29 20:06 ` Corinna Vinschen 2015-04-29 21:31 ` Rich Eizenhoefer @ 2015-04-29 23:43 ` Michael DePaulo 2015-04-30 7:56 ` Corinna Vinschen 2015-04-30 11:27 ` LRN 1 sibling, 2 replies; 26+ messages in thread From: Michael DePaulo @ 2015-04-29 23:43 UTC (permalink / raw) To: Rich Eizenhoefer, The Cygwin Mailing List Hi, see bottom post. On Wed, Apr 29, 2015 at 4:06 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote: > Hi Rich, > > nice to read from you. > > On Apr 29 19:01, Rich Eizenhoefer wrote: >> Hi, >> >> I'm the Program Manager at Microsoft for the updated Windows 10 >> console. I searched the Cygwin FAQ and mailing list archives for >> issues related to Windows 10 and found an item about multiple windows >> which should already be fixed. We have received a couple reports about >> crashes when running on Windows 10 with the new console enabled. For >> example: >> >> "cygwin is dying when i run a bunch of the git tools. For example: >grep -rin log .\ 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x68570000, RegionSize 0x3A0000, State 0x10000 C:\Program Files (x86)\Git\bin\grep.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0" > > This error message is a bit weird. For one thing, it would be nice if > you could give us a pointer to the message. I'm not aware of such a bug > report. > > Also, this is about a non-Cygwin version of git as the path to the git > tools suggests. On the other hand, if it's not a Cygwin version, the > error message itself only makes marginal sense. So maybe it's a Cygwin > DLL as part of some third party package which is often outdated in > relation to the official Cygwin distro version. > > As for the error message itself, it refers to the fact that, after a > Cygwin fork() call, the forked child can't reserve the space required > for the so-called "cygwin heap", a region used for internal usage > especially important for fork/exec related stuff. This usually points > to Cygwin DLLs which are not rebased, or a non-Cygwin DLL loaded into a > spot required for a Cygwin DLL after a fork. This is especially a > problem on 32 bit due to the restricted virtual memory. > > However, if I'm not completely off-track, the bug report does not really > have anything to do with a bad interaction between the W10 console and > Cygwin. While my own W10 virtual machine under Qemu/KVM fails to update > to versions after build 9926, I didn't encounter any unusual behaviour > of the W10 console in comparison with, say, the W8.1 console yet. I'm > usually running Cygwin tools in mintty, but I did test the W10 console, > too, of course. [...] Allow me to clarify. "C:\Program Files (x86)\Git\" is "Git for Windows", AKA "msysgit": https://msysgit.github.io/ As explained on README.md, it uses a MSys: https://github.com/msysgit/msysgit And as explained on that README.md, MSys is a fork of an old version of Cygwin. MSys's home page is here, it is part of the MinGW project: http://mingw.org/wiki/msys -Mike -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-04-29 23:43 ` Michael DePaulo @ 2015-04-30 7:56 ` Corinna Vinschen 2015-04-30 11:27 ` LRN 1 sibling, 0 replies; 26+ messages in thread From: Corinna Vinschen @ 2015-04-30 7:56 UTC (permalink / raw) To: cygwin; +Cc: Rich Eizenhoefer [-- Attachment #1: Type: text/plain, Size: 2334 bytes --] Hi Michael, On Apr 29 19:43, Michael DePaulo wrote: > Hi, see bottom post. > > On Wed, Apr 29, 2015 at 4:06 PM, Corinna Vinschen > <corinna-cygwin@cygwin.com> wrote: > > Hi Rich, > > > > nice to read from you. > > > > On Apr 29 19:01, Rich Eizenhoefer wrote: > >> Hi, > >> > >> I'm the Program Manager at Microsoft for the updated Windows 10 > >> console. I searched the Cygwin FAQ and mailing list archives for > >> issues related to Windows 10 and found an item about multiple windows > >> which should already be fixed. We have received a couple reports about > >> crashes when running on Windows 10 with the new console enabled. For > >> example: > >> > >> "cygwin is dying when i run a bunch of the git tools. For example: >grep -rin log .\ 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x68570000, RegionSize 0x3A0000, State 0x10000 C:\Program Files (x86)\Git\bin\grep.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0" > > > > This error message is a bit weird. For one thing, it would be nice if > > you could give us a pointer to the message. I'm not aware of such a bug > > report. > > > > Also, this is about a non-Cygwin version of git as the path to the git > > tools suggests. On the other hand, if it's not a Cygwin version, the > > error message itself only makes marginal sense. So maybe it's a Cygwin > > DLL as part of some third party package which is often outdated in > > relation to the official Cygwin distro version. > > [...] > [...] > > Allow me to clarify. > > "C:\Program Files (x86)\Git\" is "Git for Windows", AKA "msysgit": > https://msysgit.github.io/ > > As explained on README.md, it uses a MSys: > https://github.com/msysgit/msysgit > > And as explained on that README.md, MSys is a fork of an old version of Cygwin. > > MSys's home page is here, it is part of the MinGW project: > http://mingw.org/wiki/msys Good to know. The original Msys is so very old (based on Cygwin 1.3) that we really don't have to care. Cygwin comes with git anyway and the newer fork MSYS2 comes with git, too. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-04-29 23:43 ` Michael DePaulo 2015-04-30 7:56 ` Corinna Vinschen @ 2015-04-30 11:27 ` LRN 2015-04-30 12:44 ` Tony Kelman 1 sibling, 1 reply; 26+ messages in thread From: LRN @ 2015-04-30 11:27 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 2308 bytes --] On 30.04.2015 2:43, Michael DePaulo wrote: > On Wed, Apr 29, 2015 at 4:06 PM, Corinna Vinschen wrote: >> On Apr 29 19:01, Rich Eizenhoefer wrote: >>> I'm the Program Manager at Microsoft for the updated Windows 10 >>> console. I searched the Cygwin FAQ and mailing list archives for >>> issues related to Windows 10 and found an item about multiple windows >>> which should already be fixed. We have received a couple reports about >>> crashes when running on Windows 10 with the new console enabled. For >>> example: >>> >>> "cygwin is dying when i run a bunch of the git tools. For example: >grep -rin log .\ 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x68570000, RegionSize 0x3A0000, State 0x10000 C:\Program Files (x86)\Git\bin\grep.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0" >> >> This error message is a bit weird. For one thing, it would be nice if >> you could give us a pointer to the message. I'm not aware of such a bug >> report. >> >> Also, this is about a non-Cygwin version of git as the path to the git >> tools suggests. On the other hand, if it's not a Cygwin version, the >> error message itself only makes marginal sense. So maybe it's a Cygwin >> DLL as part of some third party package which is often outdated in >> relation to the official Cygwin distro version. >> > > Allow me to clarify. > > "C:\Program Files (x86)\Git\" is "Git for Windows", AKA "msysgit": > https://msysgit.github.io/ > > As explained on README.md, it uses a MSys: > https://github.com/msysgit/msysgit > > And as explained on that README.md, MSys is a fork of an old version of Cygwin. > Public service reminder: "msysgit" is not a MSYS-git. The git program that they ship is, in fact, a full-fledged port of git to W32 (i.e. mingw-git), which is achieved by applying lots of patches (~300KB last time i checked) on top of git. It is, however, bundled with MSYS1, as parts of git are written in shell language and thus need a POSIX shell. Also, last time i checked the MSYS1 version they shipped itself had a few patches applied on top of it[1]. [1] https://github.com/msysgit/msysgit/tree/msys/src/rt/patches -- O< ascii ribbon - stop html email! - www.asciiribbon.org [-- Attachment #1.2: 0x922360B0.asc --] [-- Type: application/pgp-keys, Size: 1732 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: From Microsoft: Windows 10 Console and Cygwin 2015-04-30 11:27 ` LRN @ 2015-04-30 12:44 ` Tony Kelman 0 siblings, 0 replies; 26+ messages in thread From: Tony Kelman @ 2015-04-30 12:44 UTC (permalink / raw) To: cygwin > Public service reminder: "msysgit" is not a MSYS-git. The git program that > they > ship is, in fact, a full-fledged port of git to W32 (i.e. mingw-git), > which is > achieved by applying lots of patches (~300KB last time i checked) on top > of > git. It is, however, bundled with MSYS1, as parts of git are written in > shell > language and thus need a POSIX shell. Also, last time i checked the MSYS1 > version they shipped itself had a few patches applied on top of it[1]. > > [1] https://github.com/msysgit/msysgit/tree/msys/src/rt/patches And for those who might not follow these things too closely, the upcoming 2.x releases of git-for-windows will be based off of MSYS2 (see https://github.com/git-for-windows), so a much more modern Cygwin dll under the hood of the bash/coreutils pieces. But yes, large parts of that git distribution, aside from the shell, are compiled by MinGW compilers (MinGW-w64 in the under-development git 2.x releases) rather than Cygwin compilers. -Tony -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2015-06-08 17:23 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-29 19:01 From Microsoft: Windows 10 Console and Cygwin Rich Eizenhoefer 2015-04-29 19:50 ` Tim Prince 2015-04-29 20:06 ` Corinna Vinschen 2015-04-29 21:31 ` Rich Eizenhoefer 2015-04-30 8:22 ` Corinna Vinschen 2015-05-01 19:29 ` Rich Eizenhoefer 2015-05-02 13:47 ` Corinna Vinschen 2015-05-04 22:35 ` Rich Eizenhoefer 2015-05-05 8:22 ` Michael DePaulo 2015-05-31 20:07 ` Ismail Donmez 2015-06-01 8:24 ` Corinna Vinschen 2015-06-01 20:27 ` Rich Eizenhoefer 2015-06-02 7:56 ` Corinna Vinschen 2015-06-02 8:10 ` İsmail Dönmez 2015-06-02 16:37 ` Rich Eizenhoefer 2015-06-02 16:50 ` Corinna Vinschen 2015-06-02 17:50 ` Rich Eizenhoefer 2015-06-02 19:20 ` Eric Blake 2015-06-02 20:36 ` Vince Rice 2015-06-02 20:49 ` Warren Young 2015-06-08 11:49 ` Corinna Vinschen 2015-06-08 17:23 ` Rich Eizenhoefer 2015-04-29 23:43 ` Michael DePaulo 2015-04-30 7:56 ` Corinna Vinschen 2015-04-30 11:27 ` LRN 2015-04-30 12:44 ` Tony Kelman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).