From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id 0A26A3858D33 for ; Sat, 7 Jan 2023 03:58:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0A26A3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-x231.google.com with SMTP id d127so2646998oif.12 for ; Fri, 06 Jan 2023 19:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:subject:cc:to :mime-version:user-agent:reply-to:from:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=P88QmqzJjoEUeEUnq+x/miuYMBy6HGrJfnEqkLr/jIY=; b=hmGjS3u0jaKERVbW9YIME2cQbqWO2ehu7k8qjkXj9vZIdo8O2ewYClJYCBMBQQatxH DwV0J4HTtfGPSesZU5xE78ImnwPcdTCxjKGkw5zEQ5/y2EonWWozc0Td16FjfrKnK06R XzRjy09EK0vqcX7x3zXl6IrPudkiTICA6nusCL1xBOruX9butmUrrWHCsN6o8GwVD7yQ yH1ZMsNjF8P1yr2nAPqRYljIlUtmrUShLOA/l8g7ROIXDk0X2CRxqDWK/tTDqwwIGkoB y3yd5AMZIHHIC9yPB1/9al8CdrwqMzZOtiz/3wTWM5iHWaRxOKtwBPgm86FkagyyzRbd qynA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:subject:cc:to :mime-version:user-agent:reply-to:from:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=P88QmqzJjoEUeEUnq+x/miuYMBy6HGrJfnEqkLr/jIY=; b=uo78PcdhozvOQRsMlwPts8cqPIUkQhRehXVTR0kqJxhS61Jxknq5fWW9KsNw8pMRmP d7+FwTlB0+Kpg6C+xmOhY61ql5qffZ5YWySBiPjYikNfl4S8WsEfRvqpWr3FhmOPOI4B lXhH0dEzIgA+tF4uR48TZwc3aer9I69RYzk2oxvlONi0Fgsib6sfd4K2EDmmdY4orcQL AT6Ni2mj1D0VC1Ix0OKcJxcIYqyX+iXt63O71TL18pLez3ghKxRIiLtdvGDIHieNYbKx kkiEO1dgTOWAhuZu4RRq1CNQq2ir3ho0k8ynsd+DWwOgIT3HkfCvMxknX8lWzG8Uo5Jr s2zg== X-Gm-Message-State: AFqh2kpdmaZkSHg4FWGoE+Thy0wAQMNvx93PyRAoiiq1JB0lUzn/OP6j rrrquX0msS4uUxmdyDKfcKY= X-Google-Smtp-Source: AMrXdXukVr9Q9bP9GEriwLk5zOQwGzTGzdjOLYXHCcLmk3gVOfWtVX65fSxiRwEdXID8jbr/93x0ow== X-Received: by 2002:a05:6808:997:b0:360:3cfa:5a24 with SMTP id a23-20020a056808099700b003603cfa5a24mr24615020oic.18.1673063897226; Fri, 06 Jan 2023 19:58:17 -0800 (PST) Received: from [127.0.0.1] ([70.133.144.146]) by smtp.gmail.com with ESMTPSA id i16-20020a056808031000b00360bf540072sm1155694oie.0.2023.01.06.19.58.15 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 06 Jan 2023 19:58:16 -0800 (PST) Message-ID: <63B8EDD6.5010709@gmail.com> Date: Fri, 06 Jan 2023 21:58:14 -0600 From: Jacob Bachmeyer Reply-To: jcb62281@gmail.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 SeaMonkey/1.1.17 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Jacek Caban CC: Eric Pouech , fortran@gcc.gnu.org, NightStrike , DejaGnu mailing list Subject: Re: testsuite under wine 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: Jacek Caban wrote: > Hi Jacob, > > Sorry for the delay. Not a problem. > 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. >>> 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. >> (Actually, an option to explicitly select an X11 Wine console window >> might be helpful for people that want to invoke a Windows CUI program >> from a graphical menu; otherwise, you might end up with the CUI >> silently appearing on the console from which the X session was >> started... I know adding xterm to the mix solves this, but it is a >> use case.) > > Currently, you'd run it through wineconsole explicitly. And yes, it's > not perfect and default behaviour could be improved, but it's > challenging architecturally. There were some improvements to that code > in current release cycle, which moved things in the right direction, > but also proved this stuff to be hard to change without breaking anything. I see. >> I think the best goal here is that, for the standard handles, Wine >> I/O should be equivalent to a network connection (telnet?) to a >> Windows box. For CUI, Wine should actually use curses or at least >> terminfo, to allow the escape codes produced to match the user's >> terminal. The user's terminal might not always be a VT100-alike and >> custom simulated terminals could be very reasonable for testing >> curses TUI programs. (To my knowledge, there are as yet no >> testsuites that actually /do/ that, but the composition seems >> reasonable to me.) > > > As I said, compatibility with other terminals could be improved, but > curses does not fit the role. Anyway, for sake of testing, the > attached patch disables escapes hiding the cursor during screen > updates which seem the most problematic. With this patch, some tests > may work without disabling conhost (but other discussed problems are > expected). Agreed that curses may not be feasible for Wine to use, but terminfo would still be a good solution to replace the hardcoded terminal escape strings in 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. -- Jacob