Re: mintty/Windows interoperability (was: Re: default terminal)

[Andy Koppe <andy dot koppe at gmail dot com>]

On 2 June 2010 21:39, Thomas Wolff wrote:
> Before making it the only default, however, there's still two issues to
> consider concerning interoperability with Windows programs:
>
> Â * The known limitation with certain Windows (or even DOS) programs
> Â Â due to the incompatibility of some of the multiple Windows output
> Â Â methods with pty. Is anyone still trying to find a wrapper that
> Â Â might solve this for input and output?

I don't know of any attempt at this since 'ttyfier'. As you know, I
did have a go at the input side only with 'conin', but that wasn't
much of a success. Grabbing the screen buffer from a hidden console
using ReadConsoleOutput and displaying it using terminal escape
sequences seems fairly straightforward in principle, but it would
still be a load of work. I can't commit to that.

(See also http://code.google.com/p/mintty/issues/detail?id=56 for
other ideas to tackle this.)


> Â * Another issue with even those Windows/DOS programs that do work in
> Â Â general: They assume the Windows ANSI encoding so their output
> Â Â (and input assumption) will not match the mintty character
> Â Â encoding in most cases. (Test case: configure Windows UI to
> Â Â "German", reboot (grumble)

Unfortunately the common (i.e. cheaper) variants don't allow you to
change the UI language.


>     run mintty in UTF-8, enter 'xcopy'
> Â Â (without parameters), see error message "Unzulâssige
> Â Â Parameteranzahl"). This works fine in the Cygwin Console because
> Â Â the I/O method used by those programs bypasses cygwin - the Cygwin
> Â Â Console is actually a dual-character set environment. My initial
> Â Â idea that Windows could be convinced to change that for mintty
> Â Â with 'chcp.com 65001' failed.

Ah, 'chcp' actually is a cmd.exe builtin, so you need to run it like
this: 'cmd /c chcp 65001'. I can't test the xcopy error message, but
this did at least yield correct umlauts in filenames when doing a 'cmd
/c dir'.


>     I discussed it with Andy already and
> Â Â he suggested a fork point somewhere in cygwin (maybe winsup or
> Â Â newlib?) where a Windows/DOS program is being distinguished from a
> Â Â cygwin program anyway, and where a wrapper might be activated
> Â Â implicitly.

When a Windows process is invoked from a Cygwin process using exec()
or spawn(P_OVERLAY, ...), the Cygwin process "hangs around as a 'stub'
presenting it's
pid as the win32 process's pid, to allow cygwin tools to kill the
win32 process." (From winsup/cygwin/how-spawn-works.txt.)

My thinking was that using a couple of extra pipes, that process could
in theory translate between the console's codepage and the locale
charset. The place to hook that in would be spawn_guts() in
winsup/cygwin/spawn.cc. That function is a scary place though, and
I've got no idea whether such an approach could work.


>     The best thing to do then would be to wrap the spawned
> Â Â Windows/DOS program into something like 'luit'. A work-around
> Â Â would also be to switch mintty encoding dynamically but that would
> Â Â not work with multiple programs producing output simultaneously,
> Â Â for example from a background process.

There might be another possibility: when the invisible console is
created in fhandler_console::need_invisible, set its input and output
codepages according to the locale charset (using SetConsoleCP and
SetConsoleOutputCP). Obviously that could only work for locale
charsets that do have an equivalent Windows codepage, or at least
something close (like CP1252 vis-a-vis ISO-8859-1).

In the end though, these ideas are all imperfect workarounds. Given
that there is a straightforward answer to any issue with console
programs ("use a console"), I find it hard to justify much effort
going into them.

Andy