On 12/23/22 04:51, Jacob Bachmeyer wrote:
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.
Yes, an analogy to screen is right in many aspects, but there are also
architectural difference that require implementation to be very
different. ncurses operates on tty file descriptors backed by OS kernel.
conhost needs to be able to operate on Windows names pipes, which are
not associated with any file descriptor in Wine.
Also my point was that if you capture the output sent by the application
to the terminal and match that to a pattern, then any processing made by
conhost could cause problems. Please correct me if I'm wrong, but my
understanding is that, in the above hypothetical example, a test case
doing printf(stdout, "\rA\rB\rC") and matching output to "\rA\rB\rC"
would be considered valid (and fail on Wine). That's why we're trying to
figure out a solution that bypasses conhost and makes the application
write directly to stdout, like usual native application would do. Such
mode would be less compatible with Windows, but if tests only does
simple I/O and no other console interactions, it should work fine.
Interpreting TERM=dumb would be a possible solution to enter that mode.
Jacek
