From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [IPv6:2001:4860:4864:20::30]) by sourceware.org (Postfix) with ESMTPS id 816FC3858D1E for ; Thu, 22 Dec 2022 04:16:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 816FC3858D1E 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-oa1-x30.google.com with SMTP id 586e51a60fabf-144b21f5e5fso1194658fac.12 for ; Wed, 21 Dec 2022 20:16:08 -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=dmXvWKO1j6lJXf8Wf6CzKiRCDEzjuQ8c6eFyLMVNCQs=; b=Lw1IZKejKV5qzB/88Tq4TQEm+3Doj7h0hsdECCImgCoP4DzsaWKrWJo0KlJ5rU1OlS 44PbmpzmUBhvOMBNaInmCF10Xxq5myi1LuBPbcNO3FOJ4dVt70cwe4rzx2V6azmvCufh fn63hhf067zSnhC6RqSwNLnFJVuyNdNG3Vs6BA0CfRrh9hFRy9WAiHf+/x8baRHWlkf+ lOTAVs6Zhz5G9RKb8BDK07Dl3JZ5cR85J9q2x9vNE3BDWOVKYE2Ni6IFfZCtz0wMcCLM T/1+q11GywRy0SMsS+RwRfnNL5FmbGdqe9QDKDzxLHM1U2+ECDl2osYsDNM2yeJTjJe5 pT/A== 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=dmXvWKO1j6lJXf8Wf6CzKiRCDEzjuQ8c6eFyLMVNCQs=; b=I5ARzPlnboLGtD4lD3vb5uLzfFU0bRqnDZjM24a/H1Inpf2IxiVumkPRfoNOzVktBt GPaMfbhTnhzu6nd7jGeLFFe7Wb8Lbq+XzGwjCChgvQ4XTmF/u5aDaRkBShTs8jjV+Tca LCfkINsKaIks9OQAgjcz7onG/WuxRKIMJJtBidsZFLb41ACV7v8y7xriwVcccjfEETtO Z9Dfgs2BWkyTJkiUb/I+FctwFzFdFHhvihG+lyQ60HdOHMQl7Htfpm+yjJP4XB1DTug7 0ZVCUXexv2gInETWYUinsv97drYVGnusu4lu5MvuvBcLvDbu2VaCARJj5yLX+ymU8H6U 1epw== X-Gm-Message-State: AFqh2koK0BEy7d3anXRajlQAi47I2s0O8xnV30xyKFHMn8DXtZb3Xuxg THZ5fhK5dDTSUd+XV9lEVOQ= X-Google-Smtp-Source: AMrXdXvs4zyqc3Bi7e9rReIW6xOv9d1RQKDllQZRO0LMFzIZLsko1yCzmNKoLB/ulv+2vqz1yOdyjw== X-Received: by 2002:a05:6870:1713:b0:143:b833:b5c9 with SMTP id h19-20020a056870171300b00143b833b5c9mr9629602oae.59.1671682567667; Wed, 21 Dec 2022 20:16:07 -0800 (PST) Received: from [127.0.0.1] ([70.133.144.146]) by smtp.gmail.com with ESMTPSA id j9-20020a056870168900b0014be94a12d0sm6931677oae.44.2022.12.21.20.16.06 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 21 Dec 2022 20:16:07 -0800 (PST) Message-ID: <63A3DA04.4060804@gmail.com> Date: Wed, 21 Dec 2022 22:16:04 -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: fortran@gcc.gnu.org, NightStrike , Eric Pouech , DejaGnu mailing list Subject: Re: testsuite under wine References: <639FE88D.7090408@gmail.com> <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com> In-Reply-To: <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.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,KAM_SHORT,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: [Bringing the DejaGnu list back into the discussion...] Jacek Caban wrote: > Hi all, > > > I'm responsible for Wine changes that cause your problems. I'm also > CCing Eric, who is Wine console expert, maybe he has better ideas. > Eric, see [1] if you're interested in the context. > > > Recent Wine versions implement Windows pseudo-consoles, see [2] for a > bit more details. It's generally Microsoft's semi-recent API that's > intended to be more compatible with POSIX than what was present in > previous versions of Windows. In theory, with that implemented, we > could just plug tty fds that we get from Unix and have Unix consoles > working using those Windows APIs. I would expect that to work very well with MinGW. > In practice, it's not quite as good as promised and we need some > tweaks to make it work nicely. We could improve those tweaks, but > there are architectural limitations that will come to play sooner or > later. Of course; "not quite as good as promised" seems to be a typical experience with Microsoft and their APIs. > > I think that the long-term solution is that Wine should properly honor > > the TERM environment variable and not produce escape codes that the > > declared terminal does not support. > > > 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. Alternately, could we have a "transparent" mode in conhost where most processing is bypassed? Setting TERM=dumb in the environment could reasonably activate this mode, or some other Wine-specific setting could be used. (maybe "WINETERM=raw"?) > I'm not really familiar with DejaGnu, but if you want to match > application output, that's probably not what you're looking for. DejaGnu is mostly designed to drive text-mode interactive programs through simulated user interactions, for which Expect is extremely useful, although the tests at issue here are simpler than this general case. Here, the compiler under test is used to build a test program, which is then run, its output collected, and that collected output compared to an expected pattern. In Windows terms (as I remember), this is equivalent to writing out a batch file that compiles a test program, then runs the test program with output redirected to a temporary file, running that batch file, and reading/checking the output file. POSIX allows DejaGnu to dispense with the batch file and the output temporary file. (If you think these issues are fun, wait until someone tries to test a MinGW port of GDB...) > The reason the previous workaround of compiling Wine without ncurses > worked is that if made Wine treat tty stdin/stdout in a way very > similar to regular pipes, so no extra processing was performed. This > was more of a side effect than a design choice. It should be possible > to provide some way to achieve that with the new Wine architecture. > I'm attaching an example of Wine patch that would allow it. With that > patch, you may disable conhost.exe (via winecfg or > WINEDLLOVERRIDES=conhost.exe=d environment variable) and achieve > something similar to previous workaround. If Wine makes proper use of ncurses, then setting TERM=dumb should have the effect of eliminating escape codes from the output. Why does it not do so? > Long term, I think that it would be best to get rid of console > behaviour expectations by using Windows build of DejaGnu. My > understanding is that it requires Cygwin, so the stack would be: > Windows DejaGnu on Cygwin on Wine on Linux. This would make all > similar mismatches in expectations non-existent. Cygwin is tricky to > run on Wine, there are a few known problems like [3], but we're > getting there. That could also introduce new problems, since it would be relying on Expect's Windows port. (DejaGnu happens to work on Windows because Expect is portable to Windows, or at least Cygwin.) There are some ongoing efforts to reduce gratuitous POSIX dependencies in DejaGnu, i.e. to use Tcl's portability aids where appropriate, mostly because using [file join $a $b $c] (for example) clearly indicates that $a, $b, and $c are file names, while simply [join [list $a $b $c] "/"] or "$a/$b/$c" says nothing about the meaning of the operation. > Jacek > > > [1] https://gcc.gnu.org/pipermail/fortran/2022-December/058645.html > > [2] > https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ > > > [3] https://bugs.winehq.org/show_bug.cgi?id=47808 -- Jacob