From: Jacob Bachmeyer <jcb62281@gmail.com>
To: Jacek Caban <jacek@codeweavers.com>
Cc: Eric Pouech <eric.pouech@orange.fr>,
fortran@gcc.gnu.org, NightStrike <nightstrike@gmail.com>,
DejaGnu mailing list <dejagnu@gnu.org>
Subject: Re: testsuite under wine
Date: Fri, 06 Jan 2023 21:58:14 -0600 [thread overview]
Message-ID: <63B8EDD6.5010709@gmail.com> (raw)
In-Reply-To: <d794f0da-5b8f-7189-53c3-4545f4ef7380@codeweavers.com>
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
next prev parent reply other threads:[~2023-01-07 3:58 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 2:20 NightStrike
2022-12-16 6:44 ` Thomas Koenig
2022-12-17 0:26 ` NightStrike
2022-12-17 10:52 ` Thomas Koenig
2022-12-17 23:24 ` NightStrike
2022-12-18 3:44 ` Jacob Bachmeyer
2022-12-18 21:13 ` NightStrike
2022-12-19 4:29 ` Jacob Bachmeyer
2022-12-19 10:43 ` Torbjorn SVENSSON
2022-12-19 11:00 ` NightStrike
2022-12-19 11:13 ` NightStrike
2022-12-20 3:51 ` Jacob Bachmeyer
2022-12-21 17:37 ` Jacek Caban
2022-12-22 1:01 ` NightStrike
2022-12-22 4:37 ` Jacob Bachmeyer
2022-12-23 10:36 ` NightStrike
2022-12-23 12:43 ` Eric Pouech
2022-12-24 4:00 ` Jacob Bachmeyer
2022-12-24 11:05 ` Mark Wielaard
2023-01-05 2:50 ` NightStrike
2023-01-06 3:33 ` Jacob Bachmeyer
2023-01-06 3:44 ` Jerry D
2023-01-08 7:12 ` NightStrike
2023-01-11 2:30 ` Jacob Bachmeyer
2023-01-11 9:33 ` NightStrike
2023-01-12 4:11 ` Jacob Bachmeyer
2023-01-06 3:41 ` Jerry D
2022-12-22 4:16 ` Jacob Bachmeyer
2022-12-22 8:40 ` Eric Pouech
2022-12-23 3:51 ` Jacob Bachmeyer
2022-12-23 23:32 ` Jacek Caban
2022-12-24 5:33 ` Jacob Bachmeyer
2023-01-07 1:45 ` Jacek Caban
2023-01-07 3:58 ` Jacob Bachmeyer [this message]
2023-01-09 16:03 ` Jacek Caban
2023-01-10 9:19 ` NightStrike
2023-01-11 9:10 ` NightStrike
2023-01-11 18:41 ` NightStrike
2023-01-14 23:36 ` NightStrike
2023-01-11 2:44 ` Jacob Bachmeyer
2023-01-08 6:47 ` NightStrike
2023-01-04 15:21 ` Pedro Alves
2023-01-04 15:45 ` Eric Pouech
2023-01-04 15:52 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=63B8EDD6.5010709@gmail.com \
--to=jcb62281@gmail.com \
--cc=dejagnu@gnu.org \
--cc=eric.pouech@orange.fr \
--cc=fortran@gcc.gnu.org \
--cc=jacek@codeweavers.com \
--cc=nightstrike@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).