Re: testsuite under wine

[NightStrike]

On Wed, Dec 21, 2022 at 12:38 PM Jacek Caban <jacek@codeweavers.com> 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. 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.
>
>
>  > 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. I'm not really familiar with DejaGnu, but if you want to
> match application output, that's probably not what you're looking for.
>
>
> 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.
>
>
> 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.
>
>
> 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

First, a big giant thank you for this patch.  I confirmed that I can
use this to replace the "return immediately from init_console" hack,
and it applies cleanly to 7.20.

Second, the problems with extra \r's still remain, but I think we've
generally come to think that that part isn't Wine and is instead
either the testsuite or deja.  So I'll keep those replies to Jacob's
previous message.