From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.codeweavers.com (mail.codeweavers.com [65.103.31.132]) by sourceware.org (Postfix) with ESMTPS id 2FF6E3857400 for ; Mon, 9 Jan 2023 16:05:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2FF6E3857400 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=codeweavers.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=codeweavers.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codeweavers.com; s=6377696661; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RFY10ZLcldDvKnlMR26p9Vj+n6zcEEMbZuWJOkBL/+A=; b=VCcmmmZOsUGCzlEqkO5DXZKQON hMRpsRhEoPM3YhujDw7TQI5WB+qkbq74l2QygSW9NVcZLbQATfLT3rGiRmEnuqPxnkS5c/VsieDoa nt1y6Ei7T7wq6/wnuh/RAop4+hES0Xgm9p4Lh71gg65O7zKTU63dYYhUOtuKQa5hTyPY=; Received: from cw141ip133.vpn.codeweavers.com ([10.69.141.133]) by mail.codeweavers.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pEudu-00BGYc-A2; Mon, 09 Jan 2023 10:05:00 -0600 Message-ID: <3b3bea69-9b71-c1e5-71cd-4e5e588178b4@codeweavers.com> Date: Mon, 9 Jan 2023 17:03:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: testsuite under wine Content-Language: en-GB To: jcb62281@gmail.com Cc: Eric Pouech , fortran@gcc.gnu.org, NightStrike , DejaGnu mailing list References: <639FE88D.7090408@gmail.com> <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com> <63A3DA04.4060804@gmail.com> <0bfd557c-aa07-dac5-86f4-104e71593212@orange.fr> <63A525CE.4070408@gmail.com> <446e92cc-4942-5095-b92e-bed4db13f615@codeweavers.com> <63A68F2E.6080904@gmail.com> <63B8EDD6.5010709@gmail.com> From: Jacek Caban In-Reply-To: <63B8EDD6.5010709@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Jacob, On 1/7/23 04:58, Jacob Bachmeyer wrote: >> On 12/24/22 06:33, Jacob Bachmeyer wrote: >>> Jacek Caban wrote: >>> >> [...] >> >> >>> The terminfo database access functions tparm(), tigetflag(), >>> tigetnum(), and tigetstr() all return values to their callers for >>> further processing and the information needed to perform >>> curses-style terminal initialization is stored as string >>> capabilities in the terminfo database. >> >> Yes, we should consider some form of better TERM compatibility. > > I still suggest using terminfo here.  This seems to be exactly the > problem it is supposed to solve. Yes, that's something we should look into. >>>> Also my point was that if you capture the output sent by the >>>> application to the terminal and match that to a pattern, then any >>>> processing made by conhost could cause problems. Please correct me >>>> if I'm wrong, but my understanding is that, in the above >>>> hypothetical example, a test case doing printf(stdout, "\rA\rB\rC") >>>> and matching output to "\rA\rB\rC" would be considered valid (and >>>> fail on Wine). >>> >>> This type of thing is a general problem with testing curses >>> programs, so the only difference would be effectively adding curses >>> to programs that are not expected to use it.  Yes, this could break >>> testsuites that should work, so some kind of full bypass would be >>> very helpful; you already have this if wine is run inside a pipeline. >>> >>>> That's why we're trying to figure out a solution that bypasses >>>> conhost and makes the application write directly to stdout, like >>>> usual native application would do. Such mode would be less >>>> compatible with Windows, but if tests only does simple I/O and no >>>> other console interactions, it should work fine. Interpreting >>>> TERM=dumb would be a possible solution to enter that mode. >>> >>> I see two aspects to this, and I think both of them have value as >>> improvements to Wine: >>> >>> 1.  Programs that only use the standard handles (a la ISO C) >>> probably do not /want/ full compatibility with Windows, so their I/O >>> should be direct to the underlying POSIX fds.  Note that line >>> endings are still an issue here, but are /not/ Wine's problem---the >>> program's I/O library module is generating Windows-style line >>> endings because it was written for Windows. >> >> That's what my earlier patch allows. Note that there are weird >> implications like the fact that in this mode, a Windows equivalent of >> isatty(1) will return 0 and a number of Windows console functions >> will not work, so the setup would be kind of weird from Windows point >> of view. I'm afraid that it will not be satisfactory for more complex >> things (gdb?). > > It would probably be a good idea to map the Windows equivalent of > isatty(3) to the underlying isatty(3) call in this mode, so that an > underlying pty will be correctly reflected, although this is a future > improvement.  As for the setup being kind of weird from a Windows > point of view, I suggest comparing it to the scenario of running a > program under a telnet session on a Windows host, prior to the > introduction of pseudoconsoles, which I understand was also quite > weird by Windows standards. For isatty alone it's not impossible, bit also not as easy as it may seem. In our usual conhost mode, this just works very differently and only conhost operates of actual host tty fds (a good analogy for this is how Linux driver 'writes' to pty master device), so isatty() itself operates on handles that don't have native tty fds associated. Making this work without conhost for Windows isatty() itself could be done, but it's way more tricky for lower level console APIs. For example something like this: if (VerifyConsoleIoHandle(handle))     WriteConsole(handle, ...); else     WriteFile(handle, ...); is a valid logic on Windows (this is how msvcrt write() works). If we somehow hack VerifyConsoleIoHandle to return TRUE in this special mode, things would break unless we'd also support WriteConsole(), so we'd then need more hacks to support that as well. And if we really want to support even more low level functions properly, we need conhost. >> [...] >> >> BTW, if Expect ever plans a Windows port that's not based on Cygwin, >> it will likely need to use conhost-based pseudo consoles. It would >> then face exactly the same problem as when using Wine. Maybe >> long-term solution fits there? Problematic cursor hide/show escapes >> should be trivial to filter. Other differences may be more challenging. > > My understanding is that Expect does not have a native Windows port > precisely because Windows, until recently, did not have ptys or > anything like them.  Those other differences may still preclude a > native Windows port of Expect. Sure, I'd be interested how well my latest patch works for NightStrike. It should give us overview about how much conhost interferes with test results in practice when we get easy stuff out of the way. Thanks, Jacek