From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7922 invoked by alias); 2 May 2015 13:38:37 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 7914 invoked by uid 89); 2 May 2015 13:38:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 02 May 2015 13:38:36 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id E3D2FA80A70; Sat, 2 May 2015 15:38:33 +0200 (CEST) Date: Sat, 02 May 2015 13:47:00 -0000 From: Corinna Vinschen To: Rich Eizenhoefer Cc: cygwin@cygwin.com Subject: Re: From Microsoft: Windows 10 Console and Cygwin Message-ID: <20150502133833.GB12723@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: Rich Eizenhoefer , cygwin@cygwin.com References: <20150429200616.GL3657@calimero.vinschen.de> <20150430082231.GB19795@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-05/txt/msg00030.txt.bz2 --LyciRD1jyfeSSjG0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3351 Hi Rich, thanks for your help. On May 1 18:51, Rich Eizenhoefer wrote: > Hi Corinna, >=20 > 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 --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --LyciRD1jyfeSSjG0 Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVRNNZAAoJEPU2Bp2uRE+g2NIP/ikijiDdEDDN+3fGG8Yeey6T hp7nPk640YrZd3mdJRl/3qU8sjPXr5t6ZMGXHoha/XKWJkppCVgjccNNF5dppPTV /GkTY0k5Gm4sL+JQ0A/r0/pW8/neMs6K+8Am7lkbiyqvLPKaOF2OifQJfjpL4cBC qmswykckwDyvvCyYbJc3paGMkVuv5gMqoCaWnjlCackkemth7QHG//kQIoHGc3B6 pLE9VIk+r0WeN0fjlzIOfcAGObmvCOhRkQnMjBbb1G9xwJxFDyPE6LH0CcmOV9Bg FmJZw5A0J1k2jhwxXkTX7dM6boyb87ylmEg9L6gJYMnPcrzpu/oTvAahTSJ8M0Ix BAF7qTixjdht1gfEyks8D4bODYKaqx4wdVGskicSE64Mfb0BYuxwfeO4Ld4mNRvJ HMAIed0hVyBbyiv811+FUFJ0gpsaERue6B9s+yS4/K7WO/P5uoW52XJN5bY9PIp4 qWapnNF7LzQswTgYNAb+rf+i4y3/hUHeopHep3G15c0cuE3dQHjuGHX385YnbqA1 kkfJZwwnmcYKsn4FNWyMKXS84bAYswE0uARGBTcDfMJ+pRstzrmRBc9l06BF7HMO qPArusI1KEwKXE5226NtIYwsnpP6KhAoBI9qgpmcz/B/p82HB0ZP2abg+NaBB4mZ Jynt+OyPDSPmgV5VMGg3 =MBdL -----END PGP SIGNATURE----- --LyciRD1jyfeSSjG0--