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