Jacek Caban wrote:
Hi Jacob,
Sorry for the delay.
Not a problem.
On 12/24/22 06:33, Jacob Bachmeyer wrote:
Jacek Caban wrote:
[...]
The terminfo database access functions tparm(), tigetflag(),
tigetnum(), and tigetstr() all return values to their callers for
further processing and the information needed to perform curses-style
terminal initialization is stored as string capabilities in the
terminfo database.
Yes, we should consider some form of better TERM compatibility.
I still suggest using terminfo here. This seems to be exactly the
problem it is supposed to solve.
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.
(Actually, an option to explicitly select an X11 Wine console window
might be helpful for people that want to invoke a Windows CUI program
from a graphical menu; otherwise, you might end up with the CUI
silently appearing on the console from which the X session was
started... I know adding xterm to the mix solves this, but it is a
use case.)
Currently, you'd run it through wineconsole explicitly. And yes, it's
not perfect and default behaviour could be improved, but it's
challenging architecturally. There were some improvements to that code
in current release cycle, which moved things in the right direction,
but also proved this stuff to be hard to change without breaking anything.
I see.
I think the best goal here is that, for the standard handles, Wine
I/O should be equivalent to a network connection (telnet?) to a
Windows box. For CUI, Wine should actually use curses or at least
terminfo, to allow the escape codes produced to match the user's
terminal. The user's terminal might not always be a VT100-alike and
custom simulated terminals could be very reasonable for testing
curses TUI programs. (To my knowledge, there are as yet no
testsuites that actually /do/ that, but the composition seems
reasonable to me.)
As I said, compatibility with other terminals could be improved, but
curses does not fit the role. Anyway, for sake of testing, the
attached patch disables escapes hiding the cursor during screen
updates which seem the most problematic. With this patch, some tests
may work without disabling conhost (but other discussed problems are
expected).
Agreed that curses may not be feasible for Wine to use, but terminfo
would still be a good solution to replace the hardcoded terminal escape
strings in conhost.
[...]
BTW, if Expect ever plans a Windows port that's not based on Cygwin,
it will likely need to use conhost-based pseudo consoles. It would
then face exactly the same problem as when using Wine. Maybe long-term
solution fits there? Problematic cursor hide/show escapes should be
trivial to filter. Other differences may be more challenging.
My understanding is that Expect does not have a native Windows port
precisely because Windows, until recently, did not have ptys or anything
like them. Those other differences may still preclude a native Windows
port of Expect.
-- Jacob
