Improve support for native console programs

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start the Win32 Python (not the Cygwin port) inside mintty

What is the expected output? What do you see instead?
The interactive Python prompt should be displayed. Instead, nothing happens
and the shell remains suspended until I press Ctrl-C.

What version of the product are you using? On what operating system?
0.3.5-1

Please provide any additional information below.
Win32 Python is works fine under Console2
(http://sourceforge.net/projects/console/), which is a different Windows
terminal emulator.

Original issue reported on code.google.com by sami.kyo...@gmail.com on 17 Feb 2009 at 3:07

[GoogleCodeExporter]

This is due to MinTTY being based on Cygwin pty's, which do not play well with
Windows console apps. I'm not sure I entirely understand the issue, but 
basically
it's because the pty emulation is based on pipes, which means that a Win32
application running in MinTTY sees a pipe rather than a console as its input, 
so it
behaves differently.

You'll see the same issue in rxvt and xterm, and you can find plenty of posts 
on this
on the Cygwin mailing list.

Console2 takes a different approach: it doesn't do its own terminal emulation;
instead it runs a hidden Windows console window, grabs the screen contents from 
that,
and puts it into a nicer window. That means, however, that you're still getting 
many
of the limitations of that such as low speed and the somewhat non-standard 
terminal
emulation of the console-based Cygwin terminal.

It's not clear that it is possible to fix this. The Cygwin guys would probably 
have
done it if there was.

Original comment by andy.koppe on 17 Feb 2009 at 5:47

• Changed state: Accepted
• Added labels: Priority-None, Difficulty-Insane

[GoogleCodeExporter]

Thanks for your explanation. It does seem like it would be non-trivial to 
support
apps such as these inside minTTY.

I wonder would it be possible to somehow identify these problematic 
applications when
they are launched and just run them in a separate Windows console window? You
probably would not get proper IO redirection this way, but at least interactive
applications would remain usable.

Original comment by sami.kyo...@gmail.com on 19 Feb 2009 at 12:09

[GoogleCodeExporter]

That might indeed be possible, by inspecting the executable using objdump or 
some
such, but that would be a job for the shell, not the terminal.

Original comment by andy.koppe on 3 Mar 2009 at 2:24

• Changed title: Interactive non-Cygwin programs don't work

[GoogleCodeExporter]

I'm wondering, how hard would it be to make MinTTY work with MSYS instead of 
Cygwin?
Would this amount to the same work as making MinTTY work with any Windows 
console
program, or does MSYS also have ptys, to porting from Cygwin to MSYS would be a
doable task?

Original comment by sschuberth on 28 Mar 2009 at 7:29

[GoogleCodeExporter]

I'm not sure. Apparently MSYS is a cut-down fork of Cygwin 1.3.3, but I don't 
know
whether they removed ptys. I suspect not though, because there is an rxvt for 
MSYS. I
did have a brief attempt at compiling mintty on msys, but didn't get anywhere 
because
for some reason the 'winres' resource compiler would just hang on my system. 
Let me
know how you get on if you're having a go at it.

Original comment by andy.koppe on 28 Mar 2009 at 7:44

[GoogleCodeExporter]

Have you used MSYS / MinGW from http://www.mingw.org/, or did you install the
gcc-mingw packages in Cygwin? Maybe the latter works better for you, and using
"-mno-cygwin" you'll be able to compile programs under Cygwin that do not 
depend on
"cygwin1.dll".

Original comment by sschuberth on 8 Apr 2009 at 10:24

[GoogleCodeExporter]

I'd installed the MSYS/MingW. Compiling with -mno-cygwin doesn't work, because 
then
all sorts of POSIX facilities are missing:

child.h:4:25: sys/termios.h: No such file or directory
child.c:10:17: pwd.h: No such file or directory
child.c:11:17: pty.h: No such file or directory
child.c:13:23: sys/ioctl.h: No such file or directory
child.c:14:22: sys/wait.h: No such file or directory
child.c:15:18: argz.h: No such file or directory
child.c:16:18: utmp.h: No such file or directory
child.c:18:21: pthread.h: No such file or directory

To have any chance of this working, MinTTY would needs to be built for MSYS. The
'About MSYS' page at http://mingw.org/node/18 has this to say on the topic:

"To build an application for MSYS (as opposed to using MSYS), users will need to
install msysDVLPR. It contains the headers and libraries to for MSYS along with 
an
old version of GCC and Binutils. Resulting programs will only run under MSYS.
Msysdvlpr should never be treated as a targeted platform. It should also be 
noted
that msysdvlpr is unlikely to be updated in the near future."

Original comment by andy.koppe on 26 Apr 2009 at 12:28

[GoogleCodeExporter]

My apologies if this info is obvious, or stupid, or whatever.  I'm not a Win32 
programmer so it's hard for me to judge.  I'm just hoping that maybe the 
difficulty 
of the bug can reduced a little from "insane".  If this issue could be 
resolved, it 
would certainly distinguish mintty from other console apps under cygwin.

Regarding the approach of intercepting/overriding the console API calls:
There is an open source Win32 API Monitoring application available at:
    http://jacquelin.potier.free.fr/winapioverride32/
This can be used to determine the minimum calls that would have to be 
overridden in 
order to get a specific application (eg. the Win32 python console) working.
The site contains quite extensive documentation (in addition to the source), 
including a description of how they implement the API interception:
    http://jacquelin.potier.free.fr/winapioverride32/doc/dev.htm

Though that technique might not be the best for mintty, as it sets up the 
override 
for calls from a specific designated application only.

I read that you should be able to override the console functions merely by 
placing a 
replacement kernel32.dll in the dll search path, ahead of the system dll.  
Apparently 
a registry key "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session 
Manager\KnownDLLs" indicates DLL files that cannot be overridden in this way.  
kernel32.dll is listed there and must be removed for this technique to work.  I 
personally tried this on WinXP with kernel32.dll, but I wasn't able to get any 
proof 
my substitute dll was called.  No doubt I goofed somewhere.
The KnownDlls registry key is discussed on these pages:
    http://blogs.msdn.com/larryosterman/archive/2004/07/19/187752.aspx
    http://support.microsoft.com/kb/q164501/

I gather that the executable PATH is also used to search for DLLs on windows.  
So I 
thought mintty could add the path to a substitute kernel32.dll to the PATH 
environment var, and all child applications (shells, console apps) would 
inherit it 
and call the console functions in the substitute kernel32.dll instead of the 
real 
one.  Then the substitute console functions could either use standard file 
descriptors (0,1,2) or use additional environment vars to identify the correct 
information to use to communicate with mintty.  The replacement console 
functions 
could translate console API requests into terminal control sequences on the 
communication channels.

The initial goal would only be to provide just enough functionality that 
console 
applications realise they're talking to a console window of some kind and set 
their 
buffering accordingly.  But better support for the windows console API could be 
added 
over time to fix less common problems.

I guess non-console functions would need to be setup to forward the call to the 
real 
kernel32.dll.

Original comment by barry.do...@gmail.com on 1 May 2009 at 8:08

[GoogleCodeExporter]

Thank you very much Barry for researching this and providing those links. 
Interesting
stuff. This is roughly what I had in mind though when I rated this as "Insane". 
;)

Messing with KnownDLLs and overriding kernel32.dll is rather risky and
security-critical stuff. That would need a great big health warning and 
multiple "are
you sure?" checks. And it would likely turn out to be quite fragile due to
kernel32.dll changes between Windows releases.

Another possible point of attack I've seen mentioned is the client-server 
protocol
that apparently exists between console apps and 'winsrv.dll', which implements 
the
console window, but I haven't found any details on it. (In Windows 7 the server 
seems
to have been spun out into 'conhost.exe'.)

Two more approaches are explained here, along with their limitations:
http://homepages.tesco.net/~J.deBoynePollard/FGA/capture-console-win32.html

Finally, getting hold of the console input/output, difficult as it is, isn't
necessarily all that's needed. While it should be fine for simple interactive
programs such as the Python interpreter, there are likely differences
incompatibilities in terminal emulation which would cause fancier programs to 
fail. I
guess that's not worth worrying about at this point though.

Original comment by andy.koppe on 1 May 2009 at 7:11

[GoogleCodeExporter]

I also didn't find any significant info on winsrv.dll (for now, anyway).

It's clear that even if it could eventually be made reliable and stable, an 
attempt 
at fixing this by overriding console API functions would initially be quite 
dodgy.  
It might work with some applications but fail with others, and might break when 
certain OS upgrades are installed or be incompatible with certain versions of 
windows.  Not to mention the scary installation procedure (all the "are you 
sure?" 
stuff)...

Since mintty is a simple, fast, reliable tool (in my mind anyway), dodginess 
just 
won't fit well with it.
I'd like to suggest the possibility of a separate tool to provide the interface 
between programs using the windows console API, and a cygwin pty-based console. 
 It 
wouldn't necessarily have to be limited to work with mintty.
I'm too occupied with other projects, and probably too lacking in relevant 
skills, to 
consider taking this on myself at this time.  But I'll certainly grant kudos to 
anyone who can produce a working implementation which allows a few basic 
console API 
programs (like the Win32 python console) to work with mintty.

Original comment by barry.do...@gmail.com on 7 May 2009 at 3:30

[GoogleCodeExporter]

Thanks Barry. I agree with the idea of trying this as a separate tool, and I 
actually
suggested the same thing in a separate discussion on the Cygwin mailing list:

http://article.gmane.org/gmane.os.cygwin/106409

There, Barry Kelly outlined how the console API could be overridden using debug
functions:

> You could intercept the calls to the console APIs by finding out where
> the imports resolve to using GetProcAddress etc. (i.e. somewhere inside
> where kernel32.dll is mapped to in the process), then adjusting the page
> permissions (VirtualProtect etc.) and rewriting the entrypoint code
> (save original 5 bytes of code, insert JMP <your-stub-here>, and at
> <your-stub-here> save the parameters, update your stuff, execute the
> missing code (the code you skipped - may need adjustment owing to
> code-relative addressing modes in e.g. Jcc instructions), then JMP back.
>
> That's all assuming you have access to the innards of the process, most
> likely with debugging APIs like CreateRemoteThread, DebugActiveProcess /
> CreateProcess w/ debug, and WaitForDebugEvent / ContinueDebugEvent
> debugging loop.
>
> Doing all this could be fun, but I reckon it would amount to a stack of
> hacks. It also requires overbearing privileges.

I also have neither the low-level Windows skills nor spare hacking time to do 
this.
So, as the two Barrys were saying, there's a fun and worthwhile project here for
someone to have a go at.

Original comment by andy.koppe on 8 May 2009 at 4:47

[GoogleCodeExporter]

There's actually a very simple workaround for the original problem with Win32 
Python:
invoke it with option -i.

This explicitly tells it to run in interactive mode. The reason it doesn't work
otherwise is that it checks whether stdin is a console. With mintty and other
pty-based terminals the answer is no, because Cygwin uses pipes to emulate 
ptys, so
Python enters non-interactive mode.

The things one learns off Twitter ...

Original comment by andy.koppe on 16 May 2009 at 6:03

[GoogleCodeExporter]

Unfortunately, not all Windows programs have a workaround like -i to force them 
to act interactively.

My two cents:

The real solution is to use Cygwin programs under Cygwin terminals (mintty, 
rxvt, xterm, PuTTYcyg) and use Windows programs under Windows consoles (the 
built-in 
console, console.sf.net, etc).  So, if you want to use an interactive Python 
interface on Cygwin, use the Cygwin Python instead.

It would be great to have the "one true terminal/console for Windows", 
simultaneously presenting a Windows console device and a Cygwin pty depending 
on the 
"foreground process".  I'm betting that this is not possible to build, or if it 
is, that not possible to make it behave correctly under all circumstances.  
That said, I 
promise not to stop anyone from trying!  Read the console.sf.net source to see 
how they implement a Windows console device, and then read 
http://www.linusakesson.net/programming/tty/index.php and Cygwin's 
implementation of pty's on top of Windows IO primitives.

Original comment by medgar123 on 17 Sep 2009 at 2:27

[GoogleCodeExporter]

Thanks Mark, good points.

The fundamental problem here is that Windows doesn't have  something like a 
"pseudo
console" interface that would allow any program to impersonate a console. (Mind 
you,
it would still be a lot of work to actually implement that interface. For 
example,
Windows does command line history in the console rather than the shell.)

Switching between showing the terminal's own screen buffer and that of a hidden
console depending on foreground process is an interesting idea. However, 
there'd need
to be a way to ensure that Cygwin programs are wired up to the pty while Windows
programs are connected to the console.

Hmmm, I think this could actually be done as a standalone program, and without
requiring the black magic discussed further up this thread. Like Console2, it 
would
create a hidden console and grab the screen contents from that, but instead of
painting it directly into a Win32 window, it would paint it using terminal 
control
sequences. Users would need to invoke it as a wrapper around the Windows 
program, e.g.:

$ console edit foo.txt

I think in principle this approach should work with any of the pty-based Cygwin
terminals. The main challenge would be in keeping the overhead of polling and
painting the console buffer to an acceptable level.

Any volunteers? :)

Original comment by andy.koppe on 19 Sep 2009 at 3:54

[GoogleCodeExporter]

My knowledge of this issue is limited, but maybe the following idea can help. I 
believe the problem is that the _isatty() function of MSVCRT (and possibly 
whatever 
is meant to replace it in more recent versions) only returns true when 
stdin/out are 
connected to "character devices". The only "character device" besides "real" 
console 
windows I could find were serial ports. A while ago I experimented with using 
emulated loop-back COM ports to this end (my goal was to port some *nix 
terminal 
emulator to Windows for use with MSYS), for instance using com0com (http://
com0com.sourceforge.net/). As I recall, _isatty() returned true when 
redirecting 
stdin/out to these devices. My theory was that then the other end of the 
loop-back 
could be connected to a terminal emulator, but I lost motivation before getting 
this 
far. This is essentially the same as using pseudo terminals on *nix, so I don't 
think it's too ugly a solution (there is no limit to the number of emulated 
devices 
and they can be named and accessed through UNC paths). I haven't tested this 
thoroughly, and I can't say if it solves the problem in every case (or if it 
solves 
the problem at all, since I only used dummy programs to check the output of 
_isatty
()), but the idea might be worth investigating.

Original comment by om...@elowar.com on 4 Oct 2009 at 1:10

[GoogleCodeExporter]

Interesting stuff, thanks! This would address the problem with any programs 
similar
to python but without something like the -i option for overriding the _isatty()
detection. It wouldn't, however, help with programs that use the low-level 
console
API. Also, shame that a kernel-mode driver is needed to implement it, 
especially with
the driver signature requirements on newer Windows.

Original comment by andy.koppe on 4 Oct 2009 at 5:26

[GoogleCodeExporter]

Original comment by andy.koppe on 3 Nov 2009 at 8:37

• Changed title: Interactive non-Cygwin programs often don't work

[GoogleCodeExporter]

Issue 146 has been merged into this issue.

Original comment by andy.koppe on 6 Nov 2009 at 7:18

[GoogleCodeExporter]

Issue 153 has been merged into this issue.

Original comment by andy.koppe on 13 Nov 2009 at 9:14

[GoogleCodeExporter]

The console WinEvents API allows keeping track of changes to a console's screen
buffer without polling: 
http://msdn.microsoft.com/en-us/library/ms682102%28VS.85%29.aspx

Original comment by andy.koppe on 15 Nov 2009 at 8:19

[GoogleCodeExporter]

I've put together a little utility called 'conin' that allows programs 
depending on
stdin being a console to be used in mintty. More details at
http://groups.google.com/group/mintty-discuss/browse_thread/thread/1f9cf480117b8
a0b

Original comment by andy.koppe on 12 Dec 2009 at 2:38

[GoogleCodeExporter]

Issue 158 has been merged into this issue.

Original comment by andy.koppe on 20 Jan 2010 at 7:26

[GoogleCodeExporter]

An updated version of 'conin' with added locale/charset support can be found at
http://mintty.googlecode.com/files/conin-0.0.2.zip.

Original comment by andy.koppe on 20 Jan 2010 at 7:47

[GoogleCodeExporter]

same trick of -i for python can be used for mingw bash
just put mintty + cygwin dll in mingw bin directory
then launch it
with mintty bash --login -i

Original comment by sher...@gmail.com on 8 Mar 2010 at 3:36

[GoogleCodeExporter]

peraphs cursors keys and tabs are working in a strange way

Original comment by sher...@gmail.com on 8 Mar 2010 at 3:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

A very simple workaround for this whole issue: invoke the program in question 
through 
'cygstart', which runs it in a separate console window. (Thanks to Mark Edgar 
for that 
one.)

Original comment by andy.koppe on 7 Jun 2010 at 6:24

[GoogleCodeExporter]

Issue 212 has been merged into this issue.

Original comment by andy.koppe on 22 Aug 2010 at 6:45

[GoogleCodeExporter]

I'm changing this one to Enhancement, because "Windows console replacement" 
isn't actually part of mintty's job description. It's a terminal emulator, 
designed primarily for Cygwin programs and for remote connections to Unix 
systems. Any support for Windows console programs is a bonus.

To summarise earlier discussions: there are two main ways this whole issue 
could be tackled. One is to override the console APIs in console programs; the 
other is to have a hidden console device and grab its screen content. Both are 
likely to be a lot of work.

Microsoft Research have a library called Detours for overriding APIs in other 
programs. Unfortunately this is non-Free, but http://easyhook.codeplex.com 
looks like it may provide a suitable alternative. The overriding could range 
from just replacing isatty() to the wholesale reimplementation of all the 
Windows console functions. I suspect this would need to be done as a standalone 
wrapper that the user would need to invoke, because mintty doesn't have control 
over processes invoked by the shell.

Grabbing the screen buffer of a hidden console is what http://console.sf.net 
does, along with turning terminal input into console input events (which the 
'conin' utility does too). This approach could be implemented directly in 
mintty, perhaps with a control sequence for switching between terminal mode and 
console mode. But I think it would be more useful as a standalone utility 
because that would also help with running console programs in 'screen' and 
other terminals or when sshing into Cygwin.

I'm afraid it's rather unlikely that I'll find the tuits needed for this issue.

Original comment by andy.koppe on 3 Sep 2010 at 9:12

• Changed title: Improve support for native console programs
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Issue 218 has been merged into this issue.

Original comment by andy.koppe on 12 Sep 2010 at 4:50

[GoogleCodeExporter]

Issue 230 has been merged into this issue.

Original comment by andy.koppe on 27 Oct 2010 at 12:19

[GoogleCodeExporter]

There is a BSD licensed SSH server[1] for Windows that wraps NT consoles, it 
even has no problems with edit.com[2]. The code is rather clean but in c++. It 
could be extracted to standalone utility if someone has the time.

[1] http://www.kpym.com/2/kpym/
[2] http://www.kpym.com/2/kpym/screenshots.htm

Original comment by mwisnicki@gmail.com on 27 Oct 2010 at 2:10

[GoogleCodeExporter]

Issue 234 has been merged into this issue.

Original comment by andy.koppe on 16 Nov 2010 at 6:18

[GoogleCodeExporter]

Issue 238 has been merged into this issue.

Original comment by andy.koppe on 13 Dec 2010 at 4:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The attached test case calls WriteConsole using both stdout handle and win32 
console handle. None of them print the string in mintty, but CreateFile is 
successful, and AllocConsole fails without calling FreeConsole first. That is, 
mintty does have a hidden win32 console attached, but when I read this issue it 
was like it doesn't. Can anyone clarify?

Original comment by br.renatosilva on 14 Dec 2010 at 2:45

Attachments:

• test.c

[GoogleCodeExporter]

The WriteConsole to stdout fails because stdout is connected to a Cygwin pseudo 
terminal (pty) device and hence a Windows pipe. The WriteConsole to CONOUT$ 
succeeds without visible result because there indeed is a hidden console 
window. In Cygwin, this is allocated by the exec function, which mintty invokes 
to execute the shell command in the child process.

The exec function does this when it is called from a process that doesn't have 
a console already. The reason is that otherwise some programs will allocate 
their own visible console, resulting in very annoying console popups. This 
includes programs  where I/O via the standard streams connected to pipes work 
just fine. Examples of that are the Windows 'net' program and MinGW's 'windres' 
(the resource compiler).

MSYS was forked from Cygwin before the trick with the invisible console was 
implemented, so there mintty allocates one itself. Since mintty isn't as clever 
about it as the Cygwin DLL, you can actually see that console flashing up very 
briefly at startup. Rxvt does much the same. I'd actually tried to get away 
without the hidden console, only to run into the problem with the popup 
consoles again.

Mintty itself doesn't touch the hidden console, in fact it doesn't even have a 
handle for it as it's only allocated in the child process.

Original comment by andy.koppe on 14 Dec 2010 at 10:00

[GoogleCodeExporter]

@mwisnicki: KpyM uses the same hidden-console approach as Console2, where 
screen content is grabbed with ReadConsoleOutput() and input events are 
generated with WriteConsoleInput().

There's actually been a Cygwin-specific attempt at using this approach in a 
wrapper that renders console screen content with terminal escape sequences and 
that translates terminal input to console input events: ttyfier, as discussed 
at http://sources.redhat.com/ml/cygwin/2006-03/msg00164.html.

Original comment by andy.koppe on 14 Dec 2010 at 10:16

[GoogleCodeExporter]

Issue 240 has been merged into this issue.

Original comment by andy.koppe on 3 Jan 2011 at 10:03

[GoogleCodeExporter]

Issue 244 has been merged into this issue.

Original comment by andy.koppe on 23 Jan 2011 at 7:40

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I've been trying to run the cygwin version of emacsclient from within mintty 
with a cygwin version of emacs running in the background.  Issuing calls to 
emacsclient appear to do nothing until C-c is issued, to which the prompt 
simply becomes active again.  Should this work or is this related to the issue 
described above?

Original comment by develope...@gmail.com on 20 Feb 2011 at 5:53

[GoogleCodeExporter]

If it's the Cygwin version and there aren't multiple installs of Cygwin 
involved, it ought to work. Probably best to ask on the Cygwin mailing list, 
where the Cygwin emacs maintainer can help.

Original comment by andy.koppe on 20 Feb 2011 at 6:14

[GoogleCodeExporter]

The sample conin utility seems like a usable workaround with Windows sqlplus, 
and it seems to fit in with the intent of mintty. 

Original comment by Jonathan...@gmail.com on 31 Mar 2011 at 6:08

[GoogleCodeExporter]

The sample conin v0.0.2 utility doesn't work with Activestate Perl commandline 
debugger switch -d. It just hangs there (no output at all). Also perl <STDIN> 
doesn't work with MINTTY.EXE Ctrl+C crashes the whole thing :( Too bad there is 
no workaround for this. I've been using Mintty for the very beginning.

Original comment by white.he...@gmail.com on 6 Jun 2011 at 5:40

[GoogleCodeExporter]

There is of course the workaround of using Cygwin perl, but you probably know 
that.

Original comment by andy.koppe on 6 Jun 2011 at 7:25

[GoogleCodeExporter]

Issue 316 has been merged into this issue.

Original comment by andy.koppe on 24 Feb 2012 at 5:54

[GoogleCodeExporter]

Issue 311 has been merged into this issue.

Original comment by andy.koppe on 24 Feb 2012 at 6:09

[GoogleCodeExporter]

I created a standalone utility for Cygwin and MSYS like that described in 
comment 29.  It creates a hidden console, like http://console.sf.net, and polls 
it for changes.  It's at https://github.com/rprichard/winpty.

Original comment by ryan.pri...@gmail.com on 2 Apr 2012 at 2:44

[GoogleCodeExporter]

@ryan.prichard Apologies, I don't appear to be finding time to try winpty (and 
I don't actually have a need for it myself), but it sounds good. Please 
consider posting about it on the Cygwin (and MSYS) mailing lists, as the 
utility might help not just mintty users but also those of other terminals as 
well as sshd. You're also much more likely to get feedback there, and it would 
be great if this ended up as a Cygwin package.

Original comment by andy.koppe on 13 Apr 2012 at 11:38