Re: testsuite under wine

Jacek Caban wrote:
> 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.

Wait... Windows has handles that clearly have distinct types but does 
not actually have a universal write()?  [... rant elided ...]

Now this is starting to look like the best approach would be a special 
console mode similar to a pseudoconsole, selected by an explicit 
command-line option when Wine is started, that does not emit the normal 
escape sequences, ignores TERM, and is effectively just a pass-through 
to a raw POSIX fd.  This will /not/ work correctly if the tested program 
tries to use much more than the simple WriteConsole(), but would be 
explicitly documented as existing for testing purposes, not for regular 
use, so losing cursor motion and collapsing all output into a single 
stream in chronological order seems reasonable.

If I understand correctly, this /would/ work for testing GDB:  the GDB 
tests run GDB in a line-oriented mode.


-- Jacob