This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Am 01.06.2010 01:14, schrieb Charles Wilson:
On 5/31/2010 5:29 PM, Christopher Faylor wrote:
I'm wondering what the rest of the maintainer community thinks, though.

What do you all think about a two step plan of first making mintty part
of the default install and then making it the default terminal?
Sounds good to me.

I absolutely support to promote mintty side-by-side as one of two desktop links.
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?
   * 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), 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 ' 65001' failed. 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. (I might try to work on a patch if I knew where that
     point is.) 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]