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 35F143858425 for ; Fri, 23 Dec 2022 23:34:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 35F143858425 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=fIdFGaSoS6ZPQ9r1HbIL0hGx1pDzvGtkZtlA7qklxPA=; b=nratmc6hJcNPsKisw3Rz+CmpDh p0bCucysxzB5BsrKFstFVJh/CAq0vecCRTqLYvS8nf4yZ3iJckgkw6fluZcE787SRYDqn0AklEFK4 ypyQQIhjJv4W9kVXcBlgQ1p2Dr4eLi/2/cb2yRF5dv+L87PZ1Ry0GIwiXxqx7iloHsQA=; 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 1p8rYG-001TBv-0s; Fri, 23 Dec 2022 17:34:08 -0600 Message-ID: <446e92cc-4942-5095-b92e-bed4db13f615@codeweavers.com> Date: Sat, 24 Dec 2022 00:32:53 +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, Eric Pouech Cc: 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> From: Jacek Caban In-Reply-To: <63A525CE.4070408@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.8 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: On 12/23/22 04:51, Jacob Bachmeyer wrote: > Eric Pouech wrote: >> Le 22/12/2022 à 05:16, Jacob Bachmeyer a écrit : >>>> I think that it would not be enough. The way Windows consoles work >>>> is that we manage complete internal screen buffer and emit output >>>> that synchronizes the buffer with Unix terminal inside conhost.exe >>>> process. It means that its output heavily processed and may be very >>>> different from what application writes to its console handle. While >>>> escape codes discussed in this thread are the most prominent >>>> difference (and that part could, in theory, be improved on our >>>> side), there are more differences. For example, if application >>>> writes "\rA\rB\rC", conhost will process it, update its internal >>>> buffer which changes just one character and cursor position, and >>>> emit sequence to update it in Unix terminal, which could be just >>>> "\rC" (or even "C" if cursor was already at the beginning of the >>>> line). Another example would be long lines: conhost will emit >>>> additional EOLs instead of depending on embedder to wrap the line. >>> >>> So conhost is essentially a Wine-specific screen(1) in that sense, >>> except that it translates Windows screen buffer manipulations >>> instead of VT100 escape codes?  As I understand ncurses also >>> implements most of this; perhaps simply delegating output to ncurses >>> would solve the problem?  If output were simply delegated to >>> ncurses, (as I understand) setting TERM=dumb should be effective to >>> eliminate escape codes from the output, since the "dumb" terminal >>> does not support them. >> >> unfortunately, things are not as simple as that: on one hand we need >> to mimic Windows behavior, and on the other hand let apps running in >> wine behave like regular posix applications >> >> (Note: conhost(.exe) is not wine specific, it's part of the way >> windows handle the console input/output) > > Right.  So that is the name of the program that manages consoles in > Windows.  I knew it was not cmd.exe itself.  I was testing an > understanding that conhost.exe in Wine is essentially similar to GNU > screen, in that both emulate a console/terminal using a *nix > terminal.  If so, then it should be possible to delegate the actual > output (including reductions like the example "\rA\rB\rC" to "\rC") to > the ncurses library and get proper sensitivity to TERM "for free" as > well. > > To do that, conhost.exe would need to translate the Windows console > buffer manipulations into curses operations, or possibly lower-level > terminfo operations, if you still want to roll your own optimization > code.  If this were done, you could check if the current terminal has > sufficient support to properly emulate a Windows console and switch to > "raw" mode if the needed terminfo capabilities are not found.  Setting > TERM=dumb in the environment would then force the use of "raw" mode. Yes, an analogy to screen is right in many aspects, but there are also architectural difference that require implementation to be very different. ncurses operates on tty file descriptors backed by OS kernel. conhost needs to be able to operate on Windows names pipes, which are not associated with any file descriptor in Wine. 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). 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. Jacek