Re: testsuite under wine

[Eric Pouech <eric.pouech@orange.fr>]

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 <g>

(Note: conhost(.exe) is not wine specific, it's part of the way windows 
handle the console input/output)

but I agree that wine should provide a (simple) way to disable windows' 
console for cases like this

>
> 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"?)
an alternate solution to Jacob's patch is to run wine with none of the 
fd 0,1,2 opened on a (p)tty (assuming dejagnu doesn't require fd 0 from 
console). So something like ./wine what_ever_you_need | tee /dev/null 
2>1 < /dev/null would do
HTH