Command shell window remains open in Windows 7 Beta about mintty HOT 44 CLOSED

Windows 7 Beta x86 (not tested on x64)

Hi Erik, thanks very much for trying MinTTY on Windows 7 and providing such a
detailed bug report. Clearly there's some sort of incompatibility due to MS 
changing
something in Windows, so the question is, did they change a documented 
behaviour that
should still be the same, or are MinTTY or the Cygwin DLL doing something they
shouldn't be doing.

Is there anything on the "Compatibility" tab of the Shortcut properties that 
makes a
difference to this? Any chance you could use the "Send Feedback" links to try 
and
make MS investigate their side of this?

Apart from that, I guess I ought to be giving 7 a try at some point anyway ...

Played around a bit with Compatibility (why didn't I think of that?). 95-Me 
didn't
let the application start, 2000-Vista gives an error message (check screenshot).

Does it tell you anything?

I am running cygwin's stable packages, I could bump them a bit and see where it
lands. What do you think?

Apologies for the delay in replying, I'd overlooked your post.

That error message doesn't look like anything mintty-specific; seems that
compatibility mode breaks some of Cygwin's trickery.

I've installed the 7 beta and briefly tried a couple of things, i.e. closing the
standard files and calling FreeConsole(), but to no effect. Curiously, the same
problem has been seen with a 2-year old Cygwin installation on XP (but updating 
to
latest stable cured that one).

So, further experiments needed ...

[deleted comment]

Still happening on Windows 7 beta build 7057. 

Installed in C:\cygwin\bin\mintty.exe

[sergio@lenobo ~]$ mintty.exe  --version
MinTTY 0.3.8

Tested on Windows 7 build 7068 with MinTTY 0.4-alpha1. Same issue. 

Closing the extra console ends up closing mintty as well.  However, I 
discovered in
task manager that there's a running conhost.exe associated with mintty, and if 
you
kill that, the console window goes away, with no apparent side effects to the 
mintty.
 I'm half-tempted to throw a "taskkill /F /IM conhost.exe" into my .bashrc...

Still, what happens next is that every new process (cygwin-related or not) 
spawns a
conhost window again, which closes as soon the process exits.  You can start 
running
"cat&" and get as many of these as you like.  These windows steal focus too, 
which
makes this actually worse than just minimizing the original conhost instead of
killing it.

I think this whole problem isn't limited to just mintty though.  I noticed that 
my
sshd service also has a conhost linked to it, though of course I don't see a 
window
since it's a service, not in my session.

BTW, since others have mentioned running cygwin-stable, I should point out that 
I'm
seeing this also on cygwin-1.7.0-44.

Thanks guys for testing this.

It's the child process invoked by mintty for which se7en opens the console. 
Seems MS
suddenly decided that programs for the "console" subsystem should get a console 
when
they're started, and not just when they actually use it, which seems to have 
been the
case before.

xterm is affected by this as well, but rxvt isn't. Turns out rxvt has a 
disgusting
little hack to work around the issue: it opens a console itself and then simply 
hides
its window. Any child processes then inherit that hidden console. So I guess 
this has
been a problem previously (in 9x?), and mintty will just have to do the same.

I've occasionally seen error messages on that console, like errors with DLL
remapping.  (The perils of running betas...)  So, I wonder if there's some sort 
of
new error channel that the cygwin runtime needs to close or hide.  It's not all
stderr messages, but seemingly the very critical messages go to both stderr and 
the
console window.

Added workaround in r230 on trunk. Annoyingly, the console window still 
flickers up
briefly, unless mintty is invoked from a process with a console (hidden or 
otherwise)
in the first place. This needs investigating in the Cygwin runtime really, as
suggested by cuviper.

Thanks Andy! When will this be rolled out in a release? I'm excited to try it. 
I guess 
I could try compiling in the meantime if it's not too complicated on cygwin. 

Beta1 is in the download area now.

Downloaded the beta1 executable. When launching it from C:\cygwin\bin\ I get 
the 
following pop-up error:

The procedure entry point __ctype_ptr__ could not be located in the dynamic 
link 
library cygwin1.dll.

Ah, shouldn't have compiled it on cygwin-1.7. I've replaced the download now. 
Thanks,
Andy

Unfortunately I'm still getting the same error.

You might have got the old download from cache, as the download counter was 
still on
'0' before I just downloaded it myself.

Cool. One step closer. If I run mintty within the cygwin environment (using 
rxvt or 
another mintty windos) it works great. If I launch from Windows (cmd or 
shortcut) I'm 
still getting two windows (one named mintty in the background). I think the 
hack is 
almost there but it'd be nice if I can launch it from a shortcut without 
getting the 
two windows.

Thanks

Oh well. There's probably a difference between Cygwin 1.5 and 1.7 then. I'd 
developed
and tested the workaround on Cygwin 1.7 on Win7 only, which wasn't a terribly 
clever
thing to do. Reopening.

I just installed cygwin 1.7 to test against. I tried both binaries you provided 
last 
night and am seeing the same behavior described in my last post. 

Running cygwin 1.7.0-45  

Right, I've tried it on both 1.5 and 1.7 on two different machines with builds 
7000
and 7057 now, and the window hiding works on all of those, so I'm a bit 
stumped. Have
you got any utilities installed that might be interfering?

Has anyone else had a chance to try this?

(Note besides, with 1.5 there seems to be an issue with the main window not
responding for half a minute or so, but that affects rxvt too and appears to be 
a
problem with utmp stamping.)

Works for me on build 7000 with cygwin 1.7.  I tried both the shortcut and from 
cmd,
and while I do see the console flash up momentarily, it goes away just fine.

[deleted comment]

Are you on 32 or 64bit? I just tested your latest build on fresh installs of 
7057 and 
7068 64bit with cygwin 1.7. Same issue. 

I've tried 32-bit only. Perhaps the difference is to do with localisation? The 
system
locale on mine is set to English(UK) on the "Administrative" tab of the 
"Regional and
Language Options" control panel.

My locali(z)ation :) is English (United States). I've rebooted using the UK 
locatisation and still nothing. Would I need to reinstall Cygwin after changing 
locatisations to test?

Mine is 64-bit, US English...

It's not that then ...

I started digging around the cygwin source code a bit.  There's a slightly 
suspicious
bit of code in frok::parent (fork.cc) where it tries see if there's a console by
opening CONOUT$.  I wonder if Windows 7 is seeing that as a need to create a 
console?

Also, in fhandler_console::need_invisible (fhandler_console.cc), they create a 
hidden
console by doing a temporary CreateWindowStation, switch to that, AllocConsole, 
and
switch back.  I wonder if MinTTY's hack could take the same approach, if we 
still
can't figure out the core issue.

Thanks for going digging!

From what I could see, it was the execve in the forked process that triggers the
console to pop up, but only if the call is successful. There's no popup if you 
pass a
dud command. (This is before the r230 hack went in.)

I bet those hacks in Cygwin are to do with earlier problems with popup 
consoles, as
also evidenced by the CONOUT$ hack in rxvt. (For some reason I couldn't get 
that to
work in mintty, which is why I went for the Win2k console functions instead.)

The window station trick sounds like a good idea (even though I'd never heard of
window stations before).

I've actually seen the console popup problem before, with a Cygwin installation 
on XP
that was a few years old, but updating Cygwin cured that. I guess I should 
raise this
whole issue on the Cygwin mailing list, especially as XWin and xterm are 
affected too.

Ok, the execve call chain looks something like this:

execve(path, argv, envp)
-> spawnve(mode=_P_OVERLAY, path, argv, envp)
-> spawn_guts(path, argv, envp, mode=_P_OVERLAY)
   [...]
   if (mode == _P_DETACH)
     c_flags |= DETACHED_PROCESS;
   else
     fhandler_console::need_invisible ();
   [...]

So it appears need_invisible is actually the culprit that's not working 
anymore...

Fresh install of latest build 7077 x64 seems to work with 0.4-beta1!! I'm a 
happy 
camper. Thanks for the help.

I tried replacing the ShowWindowAsync hack with one based on creating a hidden 
window
station, as suggested by cuviper (to avoid the console flashing up briefly).

Unfortunately it doesn't work: AllocConsole() seems to no longer care about 
whether a
custom window station was selected with SetProcessWindowStation(), and just 
creates
the console window on the default station anyway. Since the Cygwin DLL uses the 
same
trick, this probably is the reason why this whole issue arose in the first 
place.

Setting this to "Fixed" in the hope that the issue reported by Sergio really 
has gone
away with build 7077. (Could try periodic polling of GetConsoleWindow() 
otherwise, in
case the console window is actually opened asynchronously.)

Took fix to 0.3 branch in r247.

I see similar behavior under Vista Enterprise with the current stable Cygwin
(1.7.2-2) and MinTTY (0.6.1).  The behavior occurs if I launch MinTTY from
Cygwin.bat.  If I create a shortcut to mintty.exe, the second console window is 
not
present.

Actually this isn't to do with the Windows 7 issue discussed here. When invoking
mintty from a batch script, you need to do so via the 'start' command, 
otherwise your
script won't exit until mintty does, and that's what keeps the console open. 
See also
"Starting mintty from a batch file" in the manual. I'd recommend using a 
shortcut
though, because with the script you'll still get a console flashing up briefly.

I just posted in mintty group re using mintty in Task Scheduler.  I'm running 
Win7 Ultimate x64 and do not any start command in this OS (as in previous 
OS's).  Also, if I browse via Task Scheduler to any shortcut, the program 
selected in the target of the shortcut, not the shortcut itself.

I'm using in the Task Scheduler:
Action -> program 
        Program/Script:  C:\cygwin\bin\mintty.exe 
        Add arguments:  -e “/usr/local/bin/XX...csh”
where XX[.].csh is a one-line program that calls  "/usr/local/bin/ 
X[.].csh >& log.XX[.] &". A popup just appears for a fraction of a sec, and 
this is just fine for me. 

It's neigh 2013 and this issue still exist in mintty 1.1.2 running on Windows 7.

Invoking mintty from a batch file using start results in 2 console windows + 1 
mintty window.
There's a console window for the executing batch file (this will close if you 
let it after the start mintty ...).
Then a conhost console is created.
Then the mintty console is created.
Closing the conhost window kills mintty; terminating conhost appears to leave 
mintty running.

The sub-system must not be set correctly for mintty; it must be set to console 
application but it is a window application.
You can create a console from a window application then setup the redirection 
for the streams (stdin/stdout/stderr) and it should "Just Work".

The bonus conhost console appears from short-cuts as well.
There are different sorts of short-cuts, this is an area of Windows that I do 
not know well... but the short-cuts created on the desktop & in the start-area 
work but a short-cut created elsewhere does not - it pops up the extra conhost 
console.
I have been unable to determine what is different about the desktop/start 
short-cuts from user-made short-cuts elsewhere that make them work as desired.

@sgbarber This was fixed in 2009, and if it hadn't, there would have been a lot 
of complaints about it. In Cygwin 1.7, the Cygwin DLL's exec() implementation 
contains a Windows 7-specific hack to create a hidden console, whereas for 
Cygwin 1.5 and MSYS, mintty contains such a hack. Mintty is a Windows subsystem 
application specifically so that no console is created for it.

Please enter a new issue for the problem you're encountering, with Cygwin/MSYS 
version, and step-by-step instructions on how to reproduce it.

I just experienced a similar issue and was able to find a solution.

For future reference, "cygwin-console-helper.exe" is required by mintty when 
invoking a shell (i.e. bash). This file is part of cygwin and should be located 
in the /bin directory; it will ensure that the conhost.exe window is 
automatically hidden on startup.