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