delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2015/05/01/14:52:17

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:from:to:subject:date:message-id:references
:in-reply-to:content-type:content-transfer-encoding
:mime-version; q=dns; s=default; b=b1o+YWR3tjsFRF/drAeP4fkxSeyMI
sRDcW9WSDXbCGUQUjEl+UxxvA9IyxofsLwC6aJSUAFL7vGJ7jp17ej/NZi1riUlo
gi1Z9FVVS0beYusLSvWl5vMFOWrdUxGPHh51HU0p3B7rKpb3RVPKxY9jqp85WAp1
iKx3b2vnNMS0Es=
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:from:to:subject:date:message-id:references
:in-reply-to:content-type:content-transfer-encoding
:mime-version; s=default; bh=mMQFM/nbWbmwiiSafFqlC2TyNDE=; b=dWH
QK0+4kTmjI5r3Fo7VYwJPyZBHUx2Rs/ZYihNROcJ9KL9FPxffY4/Hy0ELuOD+V4u
neF+t+x5Ln99AQsrLyZlhrlEEoab0s5nRlI5VGxeBbsYochelMAT5dyfe3F0B3Ie
2vF7DubcVCbirMO2TBkCvnX3r9cKet+4C5BsG7Qg=
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=0.8 required=5.0 tests=BAYES_50,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2
X-HELO: na01-bn1-obe.outbound.protection.outlook.com
From: Rich Eizenhoefer <riche AT microsoft DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: RE: From Microsoft: Windows 10 Console and Cygwin
Date: Fri, 1 May 2015 18:51:52 +0000
Message-ID: <BN3PR03MB1430B88AED4339821C7D95BEB4D50@BN3PR03MB1430.namprd03.prod.outlook.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>
In-Reply-To: <20150430082231.GB19795@calimero.vinschen.de>
authentication-results: cygwin.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1429;
x-microsoft-antispam-prvs: <BN3PR03MB14297BB70CE07AB97DAC4553B4D50 AT BN3PR03MB1429 DOT namprd03 DOT prod DOT outlook DOT com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401001)(5005006)(3002001);SRVR:BN3PR03MB1429;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1429;
x-forefront-prvs: 0563F2E8B7
x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(13464003)(24454002)(164054003)(51704005)(377454003)(92566002)(76176999)(50986999)(19580405001)(19580395003)(99286002)(93886004)(54356999)(77156002)(5890100001)(2950100001)(62966003)(102836002)(76576001)(2501003)(15975445007)(5001960100002)(107886002)(86612001)(33656002)(2351001)(2656002)(106116001)(450100001)(46102003)(86362001)(74316001)(40100003)(122556002)(110136002)(87936001)(3826002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR03MB1429;H:BN3PR03MB1430.namprd03.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en;
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2015 18:51:52.8455 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1429
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id t41IqCxu016159

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 AT cygwin DOT com] 
Sent: Thursday, April 30, 2015 1:23 AM
To: cygwin AT cygwin DOT 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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019