winpty injection

[Thomas Wolff]

Am 16.08.2018 um 10:54 schrieb Johannes Schindelin:
> Hi Thomas,
>
> On Thu, 16 Aug 2018, Thomas Wolff wrote:
>
>> Am 09.04.2018 um 11:57 schrieb Corinna Vinschen:
>>> On Apr  6 21:22, Johannes Schindelin wrote:
>>>> 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/
> And of course this will not apply to any Windows 7 or Windows 8 users. Or
> to users who are for some reason stuck with a Windows 10 that is not
> updated to the latest and greatest update.
>
> Don't get me wrong, I am delighted what my colleagues do there, they are
> doing great work, and Windows 10 will offer very nice features that Cygwin
> can use to make things more reliable and/or faster.
>
> Cygwin wants to support more Windows versions, though, so winpty will
> still be needed, methinks.
Sure, I wasn't suggesting winpty might become obsolete. I only meant to 
refer to the "implicit winpty injection" solution I had suggested to be 
embedded into cygwin. With ConPTY, cygwin might provide better 
integration of native Windows apps at least on newer Windows systems.