Re: testsuite under wine

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