From Microsoft: Windows 10 Console and Cygwin

From Microsoft: Windows 10 Console and Cygwin

[Rich Eizenhoefer]

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

Re: From Microsoft: Windows 10 Console and Cygwin

[Tim Prince]

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

Re: From Microsoft: Windows 10 Console and Cygwin

[Corinna Vinschen]

[-- 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 --]

RE: From Microsoft: Windows 10 Console and Cygwin

[Rich Eizenhoefer]

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

Re: From Microsoft: Windows 10 Console and Cygwin

[Michael DePaulo]

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

Re: From Microsoft: Windows 10 Console and Cygwin

[Corinna Vinschen]

[-- 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 --]

Re: From Microsoft: Windows 10 Console and Cygwin

[Corinna Vinschen]

[-- 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 --]

Re: From Microsoft: Windows 10 Console and Cygwin

[LRN]

[-- 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 --]

Re: From Microsoft: Windows 10 Console and Cygwin

[Tony Kelman]

> 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

RE: From Microsoft: Windows 10 Console and Cygwin

[Rich Eizenhoefer]

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

Re: From Microsoft: Windows 10 Console and Cygwin

[Corinna Vinschen]

[-- 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 --]

RE: From Microsoft: Windows 10 Console and Cygwin

[Rich Eizenhoefer]

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

Re: From Microsoft: Windows 10 Console and Cygwin

[Michael DePaulo]

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

RE: From Microsoft: Windows 10 Console and Cygwin

[Ismail Donmez]

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

Re: From Microsoft: Windows 10 Console and Cygwin

[Corinna Vinschen]

[-- 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 --]

RE: From Microsoft: Windows 10 Console and Cygwin

[Rich Eizenhoefer]

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

Re: From Microsoft: Windows 10 Console and Cygwin

[Corinna Vinschen]

[-- 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 --]

Re: From Microsoft: Windows 10 Console and Cygwin

[İsmail Dönmez]

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

RE: From Microsoft: Windows 10 Console and Cygwin

[Rich Eizenhoefer]

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

Re: From Microsoft: Windows 10 Console and Cygwin

[Corinna Vinschen]

[-- 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 --]

RE: From Microsoft: Windows 10 Console and Cygwin

[Rich Eizenhoefer]

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

Re: From Microsoft: Windows 10 Console and Cygwin

[Eric Blake]

[-- 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 --]

Re: From Microsoft: Windows 10 Console and Cygwin

[Vince Rice]

> 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

Re: From Microsoft: Windows 10 Console and Cygwin

[Warren Young]

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

Re: From Microsoft: Windows 10 Console and Cygwin

[Corinna Vinschen]

[-- 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 --]

RE: From Microsoft: Windows 10 Console and Cygwin

[Rich Eizenhoefer]

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