winpty injection

Thomas Wolff towo@towo.net
Thu Aug 16 07:41:00 GMT 2018


Am 09.04.2018 um 11:57 schrieb Corinna Vinschen:
> On Apr  6 21:22, Johannes Schindelin wrote:
>> Hi Thomas,
>>
>> On Fri, 6 Apr 2018, Thomas Wolff wrote:
>>
>>> Am 06.04.2018 um 12:31 schrieb Johannes Schindelin:
>>>> On Fri, 6 Apr 2018, Thomas Wolff wrote:
>>>>
>>>>> These symptoms suggest to me: winpty is not the culprit, but its
>>>>> presence in the invocation chain seems to trigger the effect in a
>>>>> yet unclear way.
>>>> Sure, `winpty` is not the culprit.
>>>>
>>> Actually, as it turns out, winpty *is* the culprit. I've raised winpty
>>> issue https://github.com/rprichard/winpty/issues/140 about it.
>> I am not sure you understand the issue here. The `winpty` helper opens a
>> Win32 console for the native Windows application to use. Then it polls
>> this (hidden) console for changes and tries to reflect them in the Cygwin
>> pty.
>>
>> If that Windows application writes something to that console containing
>> Escape sequences, then those Escape sequences occupy certain cells in that
>> matrix of rows and columns making up that console.
>>
>> However, if the Windows application uses random-access functions to put
>> individual characters into cells specified by given absolute positions,
>> winpty cannot tell the difference. So what winpty would be asked to
>> consider an ANSI sequence may never have been an ANSI sequence.
>>
>> Sure, this is a construed example, but it shows that you should not be so
>> sure that winpty *can* detect ANSI sequences and handle them in a way that
>> *you* want.
>> [...]
>> In the least, therefore, it should be configurable. And I would even argue
>> that the default behavior should remain the same as current in Cygwin: do
>> not use winpty by default.
>>
>> Of course, this is just my opinion, and I am but a user and infrequent
>> contributor to Cygwin. But I would hope that the Cygwin maintainers use a
>> lot of care and reluctant deliberation when considering a potentially
>> disruptive change such as this, a change that may very well occupy a lot
>> of time in dealing with the unwanted fallout.
> Point taken.  Nicely explained.
>
> However, that makes calling winpty from Cygwin a somewhat questionable
> endeavor.  Adding optional code paths which are in all likelyhood not
> used very often, thus not tested very often, thus bound to rot, are not
> really something I'm looking forward to.
It seems that the new Windows ConPTY API will be a more reliable 
solution to these issues:
https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introducing-the-windows-pseudo-console-conpty/



More information about the Cygwin-developers mailing list