On 1/7/23 04:58, Jacob Bachmeyer wrote:
On 12/24/22 06:33, Jacob Bachmeyer wrote:
Jacek Caban wrote:
[...]
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).
This type of thing is a general problem with testing curses
programs, so the only difference would be effectively adding curses
to programs that are not expected to use it. Yes, this could break
testsuites that should work, so some kind of full bypass would be
very helpful; you already have this if wine is run inside a pipeline.
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.
I see two aspects to this, and I think both of them have value as
improvements to Wine:
1. Programs that only use the standard handles (a la ISO C)
probably do not /want/ full compatibility with Windows, so their
I/O should be direct to the underlying POSIX fds. Note that line
endings are still an issue here, but are /not/ Wine's problem---the
program's I/O library module is generating Windows-style line
endings because it was written for Windows.
That's what my earlier patch allows. Note that there are weird
implications like the fact that in this mode, a Windows equivalent
of isatty(1) will return 0 and a number of Windows console functions
will not work, so the setup would be kind of weird from Windows
point of view. I'm afraid that it will not be satisfactory for more
complex things (gdb?).
It would probably be a good idea to map the Windows equivalent of
isatty(3) to the underlying isatty(3) call in this mode, so that an
underlying pty will be correctly reflected, although this is a future
improvement. As for the setup being kind of weird from a Windows
point of view, I suggest comparing it to the scenario of running a
program under a telnet session on a Windows host, prior to the
introduction of pseudoconsoles, which I understand was also quite
weird by Windows standards.
For isatty alone it's not impossible, bit also not as easy as it may
seem. In our usual conhost mode, this just works very differently and
only conhost operates of actual host tty fds (a good analogy for this
is how Linux driver 'writes' to pty master device), so isatty() itself
operates on handles that don't have native tty fds associated. Making
this work without conhost for Windows isatty() itself could be done,
but it's way more tricky for lower level console APIs. For example
something like this:
if (VerifyConsoleIoHandle(handle))
WriteConsole(handle, ...);
else
WriteFile(handle, ...);
is a valid logic on Windows (this is how msvcrt write() works). If we
somehow hack VerifyConsoleIoHandle to return TRUE in this special
mode, things would break unless we'd also support WriteConsole(), so
we'd then need more hacks to support that as well. And if we really
want to support even more low level functions properly, we need conhost.