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