Comments (44)
Windows 7 Beta x86 (not tested on x64)
Original comment by [email protected]
on 15 Jan 2009 at 11:52
from mintty.
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 ...
Original comment by andy.koppe
on 15 Jan 2009 at 8:15
- Changed state: Accepted
- Added labels: Priority-Low
from mintty.
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?
Original comment by [email protected]
on 16 Jan 2009 at 7:20
Attachments:
from mintty.
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 ...
Original comment by andy.koppe
on 31 Jan 2009 at 6:53
from mintty.
[deleted comment]
from mintty.
Still happening on Windows 7 beta build 7057.
Installed in C:\cygwin\bin\mintty.exe
[sergio@lenobo ~]$ mintty.exe --version
MinTTY 0.3.8
Original comment by [email protected]
on 26 Mar 2009 at 9:56
from mintty.
Original comment by andy.koppe
on 26 Mar 2009 at 10:14
- Added labels: Priority-High
- Removed labels: Priority-Low
from mintty.
Tested on Windows 7 build 7068 with MinTTY 0.4-alpha1. Same issue.
Original comment by [email protected]
on 31 Mar 2009 at 3:00
from mintty.
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.
Original comment by cuviper
on 31 Mar 2009 at 3:22
from mintty.
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.
Original comment by andy.koppe
on 31 Mar 2009 at 5:47
- Added labels: Milestone-0.4.0
from mintty.
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.
Original comment by cuviper
on 31 Mar 2009 at 7:01
from mintty.
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.
Original comment by andy.koppe
on 1 Apr 2009 at 10:03
- Changed state: Fixed
- Added labels: Difficulty-Medium
from mintty.
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.
Original comment by [email protected]
on 2 Apr 2009 at 12:20
from mintty.
Beta1 is in the download area now.
Original comment by andy.koppe
on 2 Apr 2009 at 5:38
from mintty.
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.
Original comment by [email protected]
on 2 Apr 2009 at 6:16
from mintty.
Ah, shouldn't have compiled it on cygwin-1.7. I've replaced the download now.
Thanks,
Andy
Original comment by andy.koppe
on 2 Apr 2009 at 6:33
from mintty.
Unfortunately I'm still getting the same error.
Original comment by [email protected]
on 2 Apr 2009 at 6:41
from mintty.
You might have got the old download from cache, as the download counter was
still on
'0' before I just downloaded it myself.
Original comment by andy.koppe
on 2 Apr 2009 at 6:48
from mintty.
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
Original comment by [email protected]
on 2 Apr 2009 at 8:18
from mintty.
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.
Original comment by andy.koppe
on 2 Apr 2009 at 11:12
- Changed state: Accepted
from mintty.
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
Original comment by [email protected]
on 2 Apr 2009 at 6:50
from mintty.
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.)
Original comment by andy.koppe
on 2 Apr 2009 at 9:14
from mintty.
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.
Original comment by cuviper
on 3 Apr 2009 at 3:44
from mintty.
[deleted comment]
from mintty.
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.
Original comment by [email protected]
on 4 Apr 2009 at 6:13
from mintty.
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.
Original comment by andy.koppe
on 4 Apr 2009 at 7:37
from mintty.
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?
Original comment by [email protected]
on 4 Apr 2009 at 8:08
from mintty.
Mine is 64-bit, US English...
Original comment by cuviper
on 4 Apr 2009 at 8:43
from mintty.
It's not that then ...
Original comment by andy.koppe
on 4 Apr 2009 at 8:49
from mintty.
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.
Original comment by cuviper
on 4 Apr 2009 at 8:02
from mintty.
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.
Original comment by andy.koppe
on 4 Apr 2009 at 8:58
from mintty.
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...
Original comment by cuviper
on 6 Apr 2009 at 4:41
from mintty.
Fresh install of latest build 7077 x64 seems to work with 0.4-beta1!! I'm a
happy
camper. Thanks for the help.
Original comment by [email protected]
on 10 Apr 2009 at 9:00
from mintty.
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.
Original comment by andy.koppe
on 15 Apr 2009 at 3:02
from mintty.
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.)
Original comment by andy.koppe
on 15 Apr 2009 at 6:08
- Changed state: Fixed
from mintty.
Took fix to 0.3 branch in r247.
Original comment by andy.koppe
on 24 Apr 2009 at 8:44
- Added labels: Milestone-0.3.9
- Removed labels: Milestone-0.4.0
from mintty.
Original comment by andy.koppe
on 25 Apr 2009 at 12:03
- Changed state: Verified
from mintty.
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.
Original comment by [email protected]
on 1 Apr 2010 at 1:27
from mintty.
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.
Original comment by andy.koppe
on 1 Apr 2010 at 4:42
from mintty.
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.
Original comment by [email protected]
on 13 Oct 2010 at 5:48
from mintty.
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".
Original comment by [email protected]
on 8 Nov 2012 at 3:36
from mintty.
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.
Original comment by [email protected]
on 8 Nov 2012 at 3:44
from mintty.
@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.
Original comment by andy.koppe
on 17 Nov 2012 at 1:43
from mintty.
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.
Original comment by [email protected]
on 14 Jul 2013 at 9:53
from mintty.
Related Issues (20)
- Is it possible to add setting for 'Treat CJK ambiguous characters as wide' as in putty? HOT 2
- Delete and tabs fail together HOT 1
- Forward key combinations to parent process HOT 2
- Fixing Paths on Mintty install - cannot find my vimrc file HOT 2
- "--hold" should show that the program has been exited HOT 3
- Please use DrawThemeTextEx when glass is enabled. HOT 3
- Command windows remain open on Windows 10 Build 9926 HOT 2
- Drag on Drop files or folders HOT 1
- Split Window HOT 1
- "Backspace sends ^H" not applied at startup HOT 1
- Unable (or unclear how) to set "default bold" color HOT 1
- Patch for /trunk/wintext.c
- mintty cannot find cygwin1.dll or yeilds an error code 0x000007b if cygwin1.dll is in the same file as mintty. HOT 1
- Move to Github? HOT 1
- mintty, tmux causes vim to go bonkers. HOT 1
- In case processes are still running when trying to close a session, say which ones HOT 3
- Cannot rename Ctrl-Backspace terminal sequence in Emacs? HOT 2
- Configuration file item to exclude characters from word selection HOT 1
- Enter one-line summary HOT 2
- disabling zoom short-cuts should disable ctrl+mouse-wheel up/down font zoom as well. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mintty.