X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Thu, 15 Jul 2010 10:19:41 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: {lp,cb}Reserved2 under Windows 7 and file descriptors Message-ID: <20100715081941.GE6944@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <000801cb2383$9c3ad3a0$d4b07ae0$@gmail.com> <20100714184922 DOT GA13548 AT ednor DOT casa DOT cgf DOT cx> <001001cb23a5$3a879090$af96b1b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <001001cb23a5$3a879090$af96b1b0$@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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