{lp,cb}Reserved2 under Windows 7 and file descriptors

{lp,cb}Reserved2 under Windows 7 and file descriptors

[Daniel Colascione]

Windows 7 WOW64 seems to DTRT with respect to copying the process data;
needs_count_in_si_lpres2 can be false except on Vista. I'm testing a cygwin
with that modification now and it works fine (persistent Windows 7 sporadic
issues notwithstanding; those seem to be solved by rebaseall).

lpReserved2 working properly leads to another idea: set *lpReserved2 to a
non-zero value even when needs_count_in_si_lpres2 is a false; specifically,
set it to three and pass the stdin, stdout, and stderr handles and flags via
child_info. (child_info would have to begin with the appropriate values.) At
the worst, it does no harm; but if the child is using the MS C runtime,
it'll pick up the stdin file descriptors and flags from this data area. If
the flags are set properly, you should be able to get the C runtime to
report _isatty() is true for cygwin ptys. (Though of course GetFileType will
still reveal the thing to be a socket.)


--
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: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Christopher Faylor]

On Wed, Jul 14, 2010 at 11:37:26AM -0700, Daniel Colascione wrote:
>Windows 7 WOW64 seems to DTRT with respect to copying the process data;
>needs_count_in_si_lpres2 can be false except on Vista. I'm testing a cygwin
>with that modification now and it works fine (persistent Windows 7 sporadic
>issues notwithstanding; those seem to be solved by rebaseall).
>
>lpReserved2 working properly leads to another idea: set *lpReserved2 to a
>non-zero value even when needs_count_in_si_lpres2 is a false; specifically,
>set it to three and pass the stdin, stdout, and stderr handles and flags via
>child_info. (child_info would have to begin with the appropriate values.) At
>the worst, it does no harm; but if the child is using the MS C runtime,
>it'll pick up the stdin file descriptors and flags from this data area. If
>the flags are set properly, you should be able to get the C runtime to
>report _isatty() is true for cygwin ptys. (Though of course GetFileType will
>still reveal the thing to be a socket.)

You seem to be jumping into the middle of a discussion here.  How about
providing some context?

--
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: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Daniel Colascione]

> On Wed, Jul 14, 2010 at 11:37:26AM -0700, Daniel Colascione wrote:
> >Windows 7 WOW64 seems to DTRT with respect to copying the process data;
> >needs_count_in_si_lpres2 can be false except on Vista. I'm testing a
> >cygwin with that modification now and it works fine (persistent Windows
> >7 sporadic issues notwithstanding; those seem to be solved by rebaseall).
> >
> >lpReserved2 working properly leads to another idea: set *lpReserved2 to
> >a non-zero value even when needs_count_in_si_lpres2 is a false;
> >specifically, set it to three and pass the stdin, stdout, and stderr
> >handles and flags via child_info. (child_info would have to begin with
> >the appropriate values.) At the worst, it does no harm; but if the
> >child is using the MS C runtime, it'll pick up the stdin file
> >descriptors and flags from this data area. If the flags are set
> >properly, you should be able to get the C runtime to report _isatty()
> >is true for cygwin ptys. (Though of course GetFileType will still
> >reveal the thing to be a socket.)
> 
> You seem to be jumping into the middle of a discussion here.  How about
> providing some context?

This is from sigproc.cc:

  /* It appears that when running under WOW64 on Vista 64, the first DWORD
     value in the datastructure lpReserved2 is pointing to (msv_count in
     Cygwin), has to reflect the size of that datastructure as used in the
     Microsoft C runtime (a count value, counting the number of elements in
     two subsequent arrays, BYTE[count and HANDLE[count]), even though the C
     runtime isn't used.  Otherwise, if msv_count is 0 or too small, the
     datastructure gets overwritten.

     This seems to be a bug in Vista's WOW64, which apparently copies the
     lpReserved2 datastructure not using the cbReserved2 size information,
     but using the information given in the first DWORD within lpReserved2
     instead.  32 bit Windows and former WOW64 don't care if msv_count is 0
     or a sensible non-0 count value.  However, it's not clear if a non-0
     count doesn't result in trying to evaluate the content, so we do this
     really only for Vista 64 for now.

     Note: It turns out that a non-zero value *does* harm operation on
     XP 64 and 2K3 64 (Crash in CreateProcess call).

     The value is sizeof (child_info_*) / 5 which results in a count which
     covers the full datastructure, plus not more than 4 extra bytes.  This
     is ok as long as the child_info structure is cosily stored within a
bigger
     datastructure. */

While this workaround is indeed necessary for Vista, it's *not* necessary
for Windows 7, which again handles copying the data structure pointed to by
lpReserved2 properly. Therefore, needs_count_in_si_lpres2 can be false on
that platform. Setting that variable to something non-zero is dangerous
because it tells the CRT that that many file descriptor entries are in the
data block, opening up the possibility that child_info will be
misinterpreted as some inherited file descriptors for the CRT.

Furthermore, there is a very long-standing issue with Cygwin pty devices:
while Cygwin programs report true from isatty() when called on a Cygwin PTY,
MSVCRT applications do *not*. From their point of view, Cygwin ptys are not
ttys, which has led to all sorts of trouble over the years. Because Windows
lacks a pseudoconsole facility, it's not possible to solve the problem in
general (though some people, like the author of conin, have taken some steps
in that direction). 

However, due to the way the CRT works, we can fool it into thinking a
passed-in file descriptor is actually a tty. All you need to do is use 3 for
the value of *lpReserved2, then follow it with three flag bytes, then three
HANDLE values --- corresponding respectively to flags[fd0], flags[fd1],
flags[fd2] and fh[0], fh[fd1] and fh[fd2].  This information would be
followed by the normal child_info structure. If stdin, stdout, or stderr is
a Cygwin PTY, Cygwin can manually set the FDEV bit (described in the old
MSDOS headers) in corresponding flag byte, which will make _isatty() return
true in the child.

(Not that I've actually tried it --- it's just an idea.)


 



--
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: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Corinna Vinschen]

On Jul 14 15:38, Daniel Colascione wrote:
> This is from sigproc.cc:
> 
>   /* It appears that when running under WOW64 on Vista 64, the first DWORD
>      value in the datastructure lpReserved2 is pointing to (msv_count in
>      Cygwin), has to reflect the size of that datastructure as used in the
>      Microsoft C runtime (a count value, counting the number of elements in
>      two subsequent arrays, BYTE[count and HANDLE[count]), even though the C
>      runtime isn't used.  Otherwise, if msv_count is 0 or too small, the
>      datastructure gets overwritten.
> [...]
> While this workaround is indeed necessary for Vista, it's *not* necessary
> for Windows 7, which again handles copying the data structure pointed to by
> lpReserved2 properly. Therefore, needs_count_in_si_lpres2 can be false on
> that platform. 

Thanks for the hint.  You *did* test that, did you?  I made a quick test
on Windows 7 x64.  Starting a shell, running scripts and starting other
processes looks good.  I checked in the change to wincap.cc.

> [...]
> Furthermore, there is a very long-standing issue with Cygwin pty devices:
> while Cygwin programs report true from isatty() when called on a Cygwin PTY,
> MSVCRT applications do *not*.

Right.

> [...]
> However, due to the way the CRT works, we can fool it into thinking a
> passed-in file descriptor is actually a tty. All you need to do is use 3 for
> the value of *lpReserved2, then follow it with three flag bytes, then three
> HANDLE values --- corresponding respectively to flags[fd0], flags[fd1],
> flags[fd2] and fh[0], fh[fd1] and fh[fd2].  This information would be
> followed by the normal child_info structure. If stdin, stdout, or stderr is
> a Cygwin PTY, Cygwin can manually set the FDEV bit (described in the old
> MSDOS headers) in corresponding flag byte, which will make _isatty() return
> true in the child.
> 
> (Not that I've actually tried it --- it's just an idea.)

That sounds like an interesting idea.  I'll play around with it as soon
as I have a bit of spare time again.  Unless, of course, nobody else
will try it or already did...


Corinna

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

--
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: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Daniel Colascione]

On 7/15/10 1:19 AM, Corinna Vinschen wrote:
> Thanks for the hint.  You *did* test that, did you?

Yep. I've been using this setup for a few days now and everything works.

[...]
> That sounds like an interesting idea.  I'll play around with it as soon
> as I have a bit of spare time again.  Unless, of course, nobody else
> will try it or already did...

Likewise, I'll see if I can hack that up if I ever get some free time.
Thanks again for Cygwin.

--
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: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Andy Koppe]

On 15 July 2010 09:19, Corinna Vinschen wrote:
>> Furthermore, there is a very long-standing issue with Cygwin pty devices:
>> while Cygwin programs report true from isatty() when called on a Cygwin PTY,
>> MSVCRT applications do *not*.
>
> Right.
>
>> [...]
>> However, due to the way the CRT works, we can fool it into thinking a
>> passed-in file descriptor is actually a tty. All you need to do is use 3 for
>> the value of *lpReserved2, then follow it with three flag bytes, then three
>> HANDLE values --- corresponding respectively to flags[fd0], flags[fd1],
>> flags[fd2] and fh[0], fh[fd1] and fh[fd2].  This information would be
>> followed by the normal child_info structure. If stdin, stdout, or stderr is
>> a Cygwin PTY, Cygwin can manually set the FDEV bit (described in the old
>> MSDOS headers) in corresponding flag byte, which will make _isatty() return
>> true in the child.
>>
>> (Not that I've actually tried it --- it's just an idea.)
>
> That sounds like an interesting idea.  I'll play around with it as soon
> as I have a bit of spare time again.  Unless, of course, nobody else
> will try it or already did...

It would be brilliant if this did work, taking at least some of the
sting out of the whole pty vs interactive console app issue.

Andy

--
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: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Christopher Faylor]

On Thu, Jul 15, 2010 at 12:25:09PM +0100, Andy Koppe wrote:
>On 15 July 2010 09:19, Corinna Vinschen wrote:
>>> Furthermore, there is a very long-standing issue with Cygwin pty devices:
>>> while Cygwin programs report true from isatty() when called on a Cygwin PTY,
>>> MSVCRT applications do *not*.
>>
>> Right.
>>
>>> [...]
>>> However, due to the way the CRT works, we can fool it into thinking a
>>> passed-in file descriptor is actually a tty. All you need to do is use 3 for
>>> the value of *lpReserved2, then follow it with three flag bytes, then three
>>> HANDLE values --- corresponding respectively to flags[fd0], flags[fd1],
>>> flags[fd2] and fh[0], fh[fd1] and fh[fd2]. ??This information would be
>>> followed by the normal child_info structure. If stdin, stdout, or stderr is
>>> a Cygwin PTY, Cygwin can manually set the FDEV bit (described in the old
>>> MSDOS headers) in corresponding flag byte, which will make _isatty() return
>>> true in the child.
>>>
>>> (Not that I've actually tried it --- it's just an idea.)
>>
>> That sounds like an interesting idea. ??I'll play around with it as soon
>> as I have a bit of spare time again. ??Unless, of course, nobody else
>> will try it or already did...
>
>It would be brilliant if this did work, taking at least some of the
>sting out of the whole pty vs interactive console app issue.

I actually have thought about doing this in the past but it always
seemed to me that lying to a program about the "ttyness" of a file
handle was going to cause more subtle problems than what we have
currently.

It also obviously isn't a panacea since not everything is going to use
msvcrt file handles.

If we really can create a standard file handle structure and not have to
tweak it for the next five years and if we only fill it out for
non-cygwin programs (which we do know when we're about to exec
something) maybe it will be worth it.  I think I'm going to need some
real convincing though.

Hmm.  I wonder if anything else does this.  Does MKS do something similar?

cgf

--
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: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Andy Koppe]

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

On 14 July 2010 23:38, Daniel Colascione wrote:
> there is a very long-standing issue with Cygwin pty devices:
> while Cygwin programs report true from isatty() when called on a Cygwin PTY,
> MSVCRT applications do *not*. From their point of view, Cygwin ptys are not
> ttys, which has led to all sorts of trouble over the years. Because Windows
> lacks a pseudoconsole facility, it's not possible to solve the problem in
> general (though some people, like the author of conin, have taken some steps
> in that direction).
>
> However, due to the way the CRT works, we can fool it into thinking a
> passed-in file descriptor is actually a tty. All you need to do is use 3 for
> the value of *lpReserved2, then follow it with three flag bytes, then three
> HANDLE values --- corresponding respectively to flags[fd0], flags[fd1],
> flags[fd2] and fh[0], fh[fd1] and fh[fd2].  This information would be
> followed by the normal child_info structure. If stdin, stdout, or stderr is
> a Cygwin PTY, Cygwin can manually set the FDEV bit (described in the old
> MSDOS headers) in corresponding flag byte, which will make _isatty() return
> true in the child.
>
> (Not that I've actually tried it --- it's just an idea.)

This does appear to work! Proof-of-concept code attached, along with a
couple of tests. Running in mintty:

$ gcc-3 -mno-cygwin fdev.c -o fdev
$ gcc-3 -mno-cygwin isatty.c -o isatty
$ gcc-3 -mno-cygwin input.c -o input

First test: just calling isatty().

$ ./isatty
isatty(0)=0
isatty(1)=0
isatty(2)=0

$ ./fdev ./isatty
isatty(0)=64
isatty(1)=64
isatty(2)=64

Second test: prompting with printf, reading with scanf. This comes
from mintty issue 218. Problem here is that stdout is fully-buffered
if it's a pipe, with the consequence that the prompt doesn't appear
until after input.

$ ./input
12
Please input a number
The number is 12

Fine through fdev though:

$ ./fdev ./input
Please input a number
12
The number is 12

Unfortunately it only seems to work for fdev's direct child process
though. For example, when running cmd.exe through fdev and invoking
isatty.exe from there, it's all zeroes from isatty() again.

I suspect the common case is to run Windows programs directly from
bash though, so this might still be worth having in spawn()/exec().
Alternatively, it could be provided as a wrapper that has to be
invoked explicitly.

Andy

[-- Attachment #2: fdev.c --]
[-- Type: application/octet-stream, Size: 815 bytes --]

#include <windows.h>

#define FOPEN 0x01
#define FDEV  0x40

int
main(int argc, char *argv[])
{
  int cbReserved2 = 4 + 3 * 5;
  char *lpReserved2 = malloc(cbReserved2);
  
  *(int *)lpReserved2 = 3;
  
  char *file_flags = lpReserved2 + 4;
  file_flags[0] = FOPEN | FDEV;
  file_flags[1] = FOPEN | FDEV;
  file_flags[2] = FOPEN | FDEV;

  HANDLE *file_handles = (HANDLE *)(lpReserved2 + 4 + 3);
  file_handles[0] = GetStdHandle(STD_INPUT_HANDLE);
  file_handles[1] = GetStdHandle(STD_OUTPUT_HANDLE);
  file_handles[2] = GetStdHandle(STD_ERROR_HANDLE);
  
  STARTUPINFO sui = {
    .cb = sizeof sui,
    .cbReserved2 = cbReserved2,
    .lpReserved2 = lpReserved2
  };
  PROCESS_INFORMATION pi;
  CreateProcess(0, argv[1], 0, 0, TRUE, 0, 0, 0, &sui, &pi);
  WaitForSingleObject(pi.hProcess, INFINITE);
  return 0;
}

[-- Attachment #3: isatty.c --]
[-- Type: application/octet-stream, Size: 156 bytes --]

#include <stdio.h>

int main(void)
{
  printf("isatty(0)=%i\n", isatty(0));
  printf("isatty(1)=%i\n", isatty(1));
  printf("isatty(2)=%i\n", isatty(2));
}

[-- Attachment #4: input.c --]
[-- Type: application/octet-stream, Size: 178 bytes --]

#include <stdio.h>

int main(int argc, char* argv[]){
    int n;
    printf("Please input a number\n");
    scanf("%d", &n);
    printf("The number is %d\n", n);
    return 0;
}

[-- Attachment #5: Type: text/plain, Size: 218 bytes --]

--
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: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Daniel Colascione]

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

On 9/12/10 2:29 PM, Andy Koppe wrote:
> This does appear to work! Proof-of-concept code attached, along with a
> couple of tests. Running in mintty:

Awesome. Thanks for doing this work. I believe the Cygwin developers had
concerns about this change inadvertently breaking some applications.
Have you noticed any unusual behavior?

> Unfortunately it only seems to work for fdev's direct child process
> though. For example, when running cmd.exe through fdev and invoking
> isatty.exe from there, it's all zeroes from isatty() again.

Unfortunately, cmd.exe does not appear to use the C runtime IO library,
and it doesn't pass on inherited file descriptors --- except for the
standard handles via CreateProcess. It's a shame, too, because cmd
understands the syntax for manipulating the first ten file descriptors
in much the same way that a unix shell does.

I think it would work for other families of process though, and it's
still an improvement.


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

Re: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Andy Koppe]

On 12 September 2010 22:39, Daniel Colascione wrote:
> On 9/12/10 2:29 PM, Andy Koppe wrote:
>> This does appear to work! Proof-of-concept code attached, along with a
>> couple of tests. Running in mintty:
>
> Awesome. Thanks for doing this work. I believe the Cygwin developers had
> concerns about this change inadvertently breaking some applications.
> Have you noticed any unusual behavior?

Nope, but of course I've only tried a few things.


>> Unfortunately it only seems to work for fdev's direct child process
>> though. For example, when running cmd.exe through fdev and invoking
>> isatty.exe from there, it's all zeroes from isatty() again.
>
> Unfortunately, cmd.exe does not appear to use the C runtime IO library,
> and it doesn't pass on inherited file descriptors --- except for the
> standard handles via CreateProcess. It's a shame, too, because cmd
> understands the syntax for manipulating the first ten file descriptors
> in much the same way that a unix shell does.
>
> I think it would work for other families of process though, and it's
> still an improvement.

Yep. And it turns out it does actually work for child processes too if
they're created through spawn() rather than CreateProcess:

$ cat spawn.c
#include <process.h>
int main(int argc, const char *argv[]) {
  return spawnv(P_WAIT, argv[1], argv + 1);
};

$ gcc-3 -mno-cygwin spawn.c -o spawn
$ ./fdev "./spawn ./isatty"
isatty(0)=64
isatty(1)=64
isatty(2)=64

Andy

--
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: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Christopher Faylor]

On Sun, Sep 12, 2010 at 10:29:56PM +0100, Andy Koppe wrote:
>On 14 July 2010 23:38, Daniel Colascione wrote:
>>there is a very long-standing issue with Cygwin pty devices: while
>>Cygwin programs report true from isatty() when called on a Cygwin PTY,
>>MSVCRT applications do *not*.  From their point of view, Cygwin ptys
>>are not ttys, which has led to all sorts of trouble over the years.
>>Because Windows lacks a pseudoconsole facility, it's not possible to
>>solve the problem in general (though some people, like the author of
>>conin, have taken some steps in that direction).
>>
>>However, due to the way the CRT works, we can fool it into thinking a
>>passed-in file descriptor is actually a tty.  All you need to do is use
>>3 for the value of *lpReserved2, then follow it with three flag bytes,
>>then three HANDLE values --- corresponding respectively to flags[fd0],
>>flags[fd1], flags[fd2] and fh[0], fh[fd1] and fh[fd2].  ??This
>>information would be followed by the normal child_info structure.  If
>>stdin, stdout, or stderr is a Cygwin PTY, Cygwin can manually set the
>>FDEV bit (described in the old MSDOS headers) in corresponding flag
>>byte, which will make _isatty() return true in the child.
>>
>>(Not that I've actually tried it --- it's just an idea.)
>
>This does appear to work! Proof-of-concept code attached, along with a
>couple of tests.  Running in mintty:

I'll say it again more forcefully this time: I thought of this many
years ago.  I went as far as looking into what was expected to be passed
in *Reserved2 and eventually figured out what to pass in those fields
for Cygwin's use without stepping on Windows crt.

I never tried to implement it in full because I don't like the idea of
lying to a windows process.  I think it could cause very strange
behavior for programs that think that 'isatty()' means that they are
attached to a console.

So this wasn't just an idea which went unimplemented waiting for tuits.
It went unimplemented because I thought it was a bad idea.

cgf


--
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: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Daniel Colascione]

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

On 9/12/10 3:41 PM, Christopher Faylor wrote:
> So this wasn't just an idea which went unimplemented waiting for tuits.
> It went unimplemented because I thought it was a bad idea.

It is a lie, but it's also a distinction without a difference.  What
kind of misbehavior could we expect to be caused by lying to a program
this way? Most programs that care to use console-specific functionality
will test for a console by using GetFileType() or just get the console
by opening "CONIN$". It would be very unusual to make decisions about
win32-level functionality based on a call to the C runtime file
descriptor library.

Furthermore, in the rare instance that a program *does* misbehave, by
simply running "cat | program", we restore the old behavior.

The one case I can see that might be a problem is the
"Console and Port I/O" family of functions, at
http://msdn.microsoft.com/en-us/library/7x2hy4cx.aspx.

If they work, I think the likelihood of the lie breaking an application
is slim. If they are broken, then I'll agree with cgf that the hack is
probably a bad idea, at least as something to enable by default.


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

Re: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Christopher Faylor]

On Sun, Sep 12, 2010 at 03:55:12PM -0700, Daniel Colascione wrote:
>On 9/12/10 3:41 PM, Christopher Faylor wrote:
>> So this wasn't just an idea which went unimplemented waiting for tuits.
>> It went unimplemented because I thought it was a bad idea.
>
>It is a lie, but it's also a distinction without a difference.  What
>kind of misbehavior could we expect to be caused by lying to a program
>this way? Most programs that care to use console-specific functionality
>will test for a console by using GetFileType() or just get the console
>by opening "CONIN$". It would be very unusual to make decisions about
>win32-level functionality based on a call to the C runtime file
>descriptor library.

No.  It wouldn't.

>Furthermore, in the rare instance that a program *does* misbehave, by
>simply running "cat | program", we restore the old behavior.
>
>The one case I can see that might be a problem is the
>"Console and Port I/O" family of functions, at
>http://msdn.microsoft.com/en-us/library/7x2hy4cx.aspx.

Those are what I was thinking of actually.

I'm not going to keep looping on this argument, making the same points
over and over.  I'm not willing to add this particular functionality to
Cygwin.

cgf

--
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: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Andy Koppe]

On 13 September 2010 05:12, Christopher Faylor wrote:
> On Sun, Sep 12, 2010 at 03:55:12PM -0700, Daniel Colascione wrote:
>>On 9/12/10 3:41 PM, Christopher Faylor wrote:
>>> So this wasn't just an idea which went unimplemented waiting for tuits.
>>> It went unimplemented because I thought it was a bad idea.
>>
>>It is a lie, but it's also a distinction without a difference.  What
>>kind of misbehavior could we expect to be caused by lying to a program
>>this way? Most programs that care to use console-specific functionality
>>will test for a console by using GetFileType() or just get the console
>>by opening "CONIN$". It would be very unusual to make decisions about
>>win32-level functionality based on a call to the C runtime file
>>descriptor library.
>
> No.  It wouldn't.
>
>>Furthermore, in the rare instance that a program *does* misbehave, by
>>simply running "cat | program", we restore the old behavior.
>>
>>The one case I can see that might be a problem is the
>>"Console and Port I/O" family of functions, at
>>http://msdn.microsoft.com/en-us/library/7x2hy4cx.aspx.
>
> Those are what I was thinking of actually.

Guarding the use of console-specific functions with isatty() is wrong,
because isatty() is true not only for consoles but also for printers
and serial ports, apparently. Not that that would stop anyone ...

(Btw, the _isatty() documentation actually mentions "terminal" as a
character device alongside "console". What could they mean by that?)


> I'm not going to keep looping on this argument, making the same points
> over and over.  I'm not willing to add this particular functionality to
> Cygwin.

Fair enough. Would a standalone utility implementing this hack be
welcome though?

Andy

--
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: {lp,cb}Reserved2 under Windows 7 and file descriptors

[Christopher Faylor]

On Mon, Sep 13, 2010 at 07:11:06AM +0100, Andy Koppe wrote:
>Fair enough. Would a standalone utility implementing this hack be
>welcome though?

Yes.  That would help alleviate my concerns about dropping this into
Cygwin itself.  If we don't see strange problems after a few months
of use, I might be persuaded to change my mind.

However, to repeat myself, I really think that the method that the
Console program uses is the most foolproof way to get real ttys in
Cygwin so I'd much rather implement something along those lines.

cgf

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