Re: testsuite under wine

[Jacob Bachmeyer <jcb62281@gmail.com>]

Eric Pouech wrote:
> 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)

Right.  So that is the name of the program that manages consoles in 
Windows.  I knew it was not cmd.exe itself.  I was testing an 
understanding that conhost.exe in Wine is essentially similar to GNU 
screen, in that both emulate a console/terminal using a *nix terminal.  
If so, then it should be possible to delegate the actual output 
(including reductions like the example "\rA\rB\rC" to "\rC") to the 
ncurses library and get proper sensitivity to TERM "for free" as well.

To do that, conhost.exe would need to translate the Windows console 
buffer manipulations into curses operations, or possibly lower-level 
terminfo operations, if you still want to roll your own optimization 
code.  If this were done, you could check if the current terminal has 
sufficient support to properly emulate a Windows console and switch to 
"raw" mode if the needed terminfo capabilities are not found.  Setting 
TERM=dumb in the environment would then force the use of "raw" mode.

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

Jacek Caban mentioned Windows pseudo-consoles, apparently a new 
feature.  Would those be a better "fit" for this type of scenario or are 
they considerably more complex than POSIX ptys and the apparent 
equivalence is false?  Does the pseudo-console appear like a regular 
console to the child process or does the child need special support to 
run with a pseudo-console?

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

The problem with this solution in general is that Expect does not 
normally use the shell to spawn subprocesses, although the shell could 
be explicitly invoked (as "/bin/sh -c '...'").  Fortunately, in the 
specific case that is causing this issue at the moment, the programs 
tested are not being run interactively, so it would be possible to use 
Tcl's open(n), which uses a pipe, instead of Expect's spawn, which uses 
a pty.  Running the program is done by a callback in testsuite code, 
rather than the DejaGnu framework itself, so any patch here needs to be 
applied to the testsuite.  Note that this workaround only works for 
non-interactive programs; it will not work when someone decides they 
want to test MinGW GDB using Wine.


-- Jacob