From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89403 invoked by alias); 16 Aug 2018 10:36:36 -0000 Mailing-List: contact cygwin-developers-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com Received: (qmail 89391 invoked by uid 89); 16 Aug 2018 10:36:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=apps, 16082018, 16.08.2018, integration X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.17.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Aug 2018 10:36:33 +0000 Received: from [192.168.178.45] ([95.91.209.148]) by mrelayeu.kundenserver.de (mreue105 [212.227.15.183]) with ESMTPSA (Nemesis) id 0M5gZk-1g5i5v00ee-00xfPA; Thu, 16 Aug 2018 12:36:31 +0200 Subject: Re: winpty injection To: Johannes Schindelin , cygwin-developers@cygwin.com References: <20180405084733.GP2833@calimero.vinschen.de> <848d804d-8dad-a176-4fa9-a51e1544da3a@towo.net> <075cb1a4-7508-306b-a3a6-a1d9db939ba9@towo.net> <8dbc29b9-eb6e-9385-9ef4-cd7bc00099f2@towo.net> <20180409095725.GP18998@calimero.vinschen.de> <93edc44c-89fa-e08f-76d6-1729b4373ea6@towo.net> From: Thomas Wolff Message-ID: Date: Thu, 16 Aug 2018 10:36:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00002.txt.bz2 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.