On Wed, Dec 21, 2022 at 12:38 PM Jacek Caban <ja...@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.
