X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=NLnqJQhHaBLrcyX9V5aJft64PjPtr2PWDSc5EuWV2o9bSB+PTEPRB
	Jy4kvVOgr7/AGpT+YaCrS09sM0hBQmlYURCL40+uptb6qd+gUnpA635HmtpQm3m+
	cV9kCbNhioelP9lt2CUfjO84QshbZJ8trj/1WT3VQMfYCV258MifP0=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=IKss2k5Zua6xLXtvIM9+2j+yhm4=; b=GNHvgmZLorExfS9ONs/WcB72ANks
	+qRdH2yKUknd2I1dXwUmhe6tk6J+TnuhXUEK/MHilkTvT7OSazOEQjfCXP53WQJt
	9MyV6+8xBH1ixGJ2qqBpzNMMY9dZyN5BU70vJUscPpsklH/d7wJeZOHnBb46aykK
	08+0J51CT8NwVbg=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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
Date:	Sat, 2 May 2015 15:38:33 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	Rich Eizenhoefer <riche AT microsoft DOT com>
Cc:	cygwin AT cygwin DOT com
Subject:	Re: From Microsoft: Windows 10 Console and Cygwin
Message-ID:	<20150502133833.GB12723@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	Rich Eizenhoefer <riche AT microsoft DOT com>, cygwin AT cygwin DOT com
References:	<BY1PR03MB1436C656CEF12387D40CD74EB4D70 AT BY1PR03MB1436 DOT namprd03 DOT prod DOT outlook DOT com> <20150429200616 DOT GL3657 AT calimero DOT vinschen DOT de> <BN3PR03MB14300D5567A2F7D86BB69A28B4D70 AT BN3PR03MB1430 DOT namprd03 DOT prod DOT outlook DOT com> <20150430082231 DOT GB19795 AT calimero DOT vinschen DOT de> <BN3PR03MB1430B88AED4339821C7D95BEB4D50 AT BN3PR03MB1430 DOT namprd03 DOT prod DOT outlook DOT com>
MIME-Version:	1.0
In-Reply-To:	<BN3PR03MB1430B88AED4339821C7D95BEB4D50@BN3PR03MB1430.namprd03.prod.outlook.com>
User-Agent:	Mutt/1.5.23 (2014-03-12)

--LyciRD1jyfeSSjG0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

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

- Raw text -