testsuite under wine

testsuite under wine

[NightStrike]

When I run the testsuite under wine, I'm getting a lot of ANSI escape
sequences.  We had fixed this long ago, but it seems to be back.  Any
idea what I should change in my configuration to have this not happen?
 This is for build=host=x86_64-pc-linux-gnu and
target=x86_64-w64-mingw32, with the testsuite running under wine64
v7.20.  Example output, where you can see the output in between the
escape sequences is correct:

FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -Os  output pattern test
Output was:
^[[?25lC^[[?25h^[[?25lF^[[?25h^[[?25lI^[[?25h^[[?25l_^[[?25h^[[?25ls^[[?25h^[[?25le^[[?25h^[[?25lt^[[?25h^[[?25lp^[[?25h^[[?25lo^[[?25h^[[?25li^[[?25h^[[?25ln^[[?25h
^[[?25lt^[[?25h^[[?25le^[[?25h^[[?25lr^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lR^[[?25h^[[?25le^[[?25h^[[?25ls^[[?25h^[[?25lu^[[?25h^[[?25ll^[[?25h^[[?25l
t^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25ls^[[?25h^[[?25lh^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25ll^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lb^[[?25h^[[?25le^[[?25h^[[?25
l^[[K^[[1C^[[?25h^[[?25lt^[[?25h^[[?25lh^[[?25h^[[?25le^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25la^[[?25h^[[?25ld^[[?25h^[[?25ld^[[?25h^[[?25lr^[[?25h^[[?25le^[[?25h^[[?2
5ls^[[?25h^[[?25ls^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lo^[[?25h^[[?25lf^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25la^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lC^[[?25h^[[?25l^[[K
^[[1C^[[?25h^[[?25ld^[[?25h^[[?25le^[[?25h^[[?25ls^[[?25h^[[?25lc^[[?25h^[[?25lr^[[?25h^[[?25li^[[?25h^[[?25lp^[[?25h^[[?25lt^[[?25h^[[?25lo^[[?25h^[[?25lr^[[?25h^[[
?25l^[[K^[[1C^[[?25h^[[?25lf^[[?25h^[[?25lo^[[?25h^[[?25lr^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25la^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lF^[[?25h^[[?25lo^[[?25h^[[?25lr^
[[?25h^[[?25lt^[[?25h^[[?25lr^[[?25h^[[?25la^[[?25h^[[?25ln^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25lp^[[?25h^[[?25lo^[[?25h^[[?25li^[[?25h^[[?25ln^[[?25h^[[?25lt^[[?25h^
[[?25le^[[?25h^[[?25lr^[[?25h^[[?25l.^[[?25h^M^M

Should match:
CFI_setpointer: Result shall be the address of a C descriptor for a
Fortran pointer.

Re: testsuite under wine

[Thomas Koenig]

On 16.12.22 03:20, NightStrike via Fortran wrote:

> When I run the testsuite under wine, I'm getting a lot of ANSI escape
> sequences.  We had fixed this long ago, but it seems to be back.  Any
> idea what I should change in my configuration to have this not happen?

This should probably be fixed properly in some *.exp file, but you can
try setting the GCC_COLORS environment variable to an empty string
before running the test.

Regards

	Thomas

Re: testsuite under wine

[NightStrike]

On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
>
> On 16.12.22 03:20, NightStrike via Fortran wrote:
>
> > When I run the testsuite under wine, I'm getting a lot of ANSI escape
> > sequences.  We had fixed this long ago, but it seems to be back.  Any
> > idea what I should change in my configuration to have this not happen?
>
> This should probably be fixed properly in some *.exp file, but you can
> try setting the GCC_COLORS environment variable to an empty string
> before running the test.

That didn't help.  It looks like this is always escape 25h to start
the output and 25l to end it, which I think is turning the cursor on
and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code).  I
apparently fixed this previously by building wine with
--without-curses
(https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that
option to wine was removed.  Is there a way to hack this on the Deja
side to ignore the escapes?  Or to tell it to run in a way that makes
wine not emit them?

Re: testsuite under wine

[Thomas Koenig]

On 17.12.22 01:26, NightStrike wrote:
> On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
>>
>> On 16.12.22 03:20, NightStrike via Fortran wrote:
>>
>>> When I run the testsuite under wine, I'm getting a lot of ANSI escape
>>> sequences.  We had fixed this long ago, but it seems to be back.  Any
>>> idea what I should change in my configuration to have this not happen?
>>
>> This should probably be fixed properly in some *.exp file, but you can
>> try setting the GCC_COLORS environment variable to an empty string
>> before running the test.
> 
> That didn't help.  It looks like this is always escape 25h to start
> the output and 25l to end it, which I think is turning the cursor on
> and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code).  I
> apparently fixed this previously by building wine with
> --without-curses
> (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that
> option to wine was removed.  Is there a way to hack this on the Deja
> side to ignore the escapes?  Or to tell it to run in a way that makes
> wine not emit them?

Truth is, I don't know.

I have included the gcc mailing list in this reply, where more
knowledgeable people can be found :-)

Re: testsuite under wine

[NightStrike]

On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
>
> On 17.12.22 01:26, NightStrike wrote:
> > On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
> >>
> >> On 16.12.22 03:20, NightStrike via Fortran wrote:
> >>
> >>> When I run the testsuite under wine, I'm getting a lot of ANSI escape
> >>> sequences.  We had fixed this long ago, but it seems to be back.  Any
> >>> idea what I should change in my configuration to have this not happen?
> >>
> >> This should probably be fixed properly in some *.exp file, but you can
> >> try setting the GCC_COLORS environment variable to an empty string
> >> before running the test.
> >
> > That didn't help.  It looks like this is always escape 25h to start
> > the output and 25l to end it, which I think is turning the cursor on
> > and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code).  I
> > apparently fixed this previously by building wine with
> > --without-curses
> > (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that
> > option to wine was removed.  Is there a way to hack this on the Deja
> > side to ignore the escapes?  Or to tell it to run in a way that makes
> > wine not emit them?
>
> Truth is, I don't know.
>
> I have included the gcc mailing list in this reply, where more
> knowledgeable people can be found :-)

Thanks.  I'm including the dejagnu list, maybe someone there can help, too.

For clarity, this is an example of what I see:

Output was:
^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[
?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1
^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
^M^M

Should match:
My_R1    : 78 56 34 12.*
My_R2    : 12 34 56 78.*
Local_R1 : 78 56 34 12.*
Local_R2 : 12 34 56 78.*
Local_R1 : 78 56 34 12.*
Local_R2 : 12 34 56 78.*
Local_R1 : 78 56 34 12.*
Local_R2 : 12 34 56 78.*

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
>   
>> On 17.12.22 01:26, NightStrike wrote:
>>     
>>> On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>       
>>>> On 16.12.22 03:20, NightStrike via Fortran wrote:
>>>>
>>>>         
>>>>> When I run the testsuite under wine, I'm getting a lot of ANSI escape
>>>>> sequences.  We had fixed this long ago, but it seems to be back.  Any
>>>>> idea what I should change in my configuration to have this not happen?
>>>>>           
>>>> This should probably be fixed properly in some *.exp file, but you can
>>>> try setting the GCC_COLORS environment variable to an empty string
>>>> before running the test.
>>>>         
>>> That didn't help.  It looks like this is always escape 25h to start
>>> the output and 25l to end it, which I think is turning the cursor on
>>> and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code).  I
>>> apparently fixed this previously by building wine with
>>> --without-curses
>>> (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that
>>> option to wine was removed.  Is there a way to hack this on the Deja
>>> side to ignore the escapes?  Or to tell it to run in a way that makes
>>> wine not emit them?
>>>       
>> Truth is, I don't know.
>>
>> I have included the gcc mailing list in this reply, where more
>> knowledgeable people can be found :-)
>>     
>
> Thanks.  I'm including the dejagnu list, maybe someone there can help, too.
>
> For clarity, this is an example of what I see:
>
> Output was:
> ^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[
> ?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> ^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1
> ^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
> [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
> [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
> [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
> [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
> [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
> [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> ^M^M
>
> Should match:
> My_R1    : 78 56 34 12.*
> My_R2    : 12 34 56 78.*
> Local_R1 : 78 56 34 12.*
> Local_R2 : 12 34 56 78.*
> Local_R1 : 78 56 34 12.*
> Local_R2 : 12 34 56 78.*
> Local_R1 : 78 56 34 12.*
> Local_R2 : 12 34 56 78.*
>   

DejaGnu cannot routinely strip escape sequences because they could be 
part of the intended output---or strictly forbidden in the intended 
output.  Further, I suspect that the comparison is being carried out in 
the testsuite code rather than the framework, but the thread that 
arrived on the DejaGnu list does not mention what test is failing or 
what testsuite is being run.  Based on the inclusion of 
fortran@gcc.gnu.org, I am guessing this is an issue with the GNU Fortran 
tests.

This is either a testsuite problem or an environment problem.  The GNU 
Fortran I/O module certainly has interesting behavior here.  Try setting 
TERM=dumb in the environment while running the testsuite.  If that fixes 
the problem, it may be appropriate to add "set ::env(TERM) dumb" to the 
tool init file for GNU Fortran.


-- Jacob

Re: testsuite under wine

[NightStrike]

On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>
> NightStrike wrote:
> > On Sat, Dec 17, 2022 at 5:52 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
> >
> >> On 17.12.22 01:26, NightStrike wrote:
> >>
> >>> On Fri, Dec 16, 2022 at 1:44 AM Thomas Koenig <tkoenig@netcologne.de> wrote:
> >>>
> >>>> On 16.12.22 03:20, NightStrike via Fortran wrote:
> >>>>
> >>>>
> >>>>> When I run the testsuite under wine, I'm getting a lot of ANSI escape
> >>>>> sequences.  We had fixed this long ago, but it seems to be back.  Any
> >>>>> idea what I should change in my configuration to have this not happen?
> >>>>>
> >>>> This should probably be fixed properly in some *.exp file, but you can
> >>>> try setting the GCC_COLORS environment variable to an empty string
> >>>> before running the test.
> >>>>
> >>> That didn't help.  It looks like this is always escape 25h to start
> >>> the output and 25l to end it, which I think is turning the cursor on
> >>> and off (based on https://en.wikipedia.org/wiki/ANSI_escape_code).  I
> >>> apparently fixed this previously by building wine with
> >>> --without-curses
> >>> (https://www.mail-archive.com/gcc@gcc.gnu.org/msg86366.html), but that
> >>> option to wine was removed.  Is there a way to hack this on the Deja
> >>> side to ignore the escapes?  Or to tell it to run in a way that makes
> >>> wine not emit them?
> >>>
> >> Truth is, I don't know.
> >>
> >> I have included the gcc mailing list in this reply, where more
> >> knowledgeable people can be found :-)
> >>
> >
> > Thanks.  I'm including the dejagnu list, maybe someone there can help, too.
> >
> > For clarity, this is an example of what I see:
> >
> > Output was:
> > ^[[mM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[
> > ?25h^[[?25l8^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> > ^[[?25lM^[[?25h^[[?25ly^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1
> > ^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
> > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
> > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
> > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
> > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l1^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^[
> > [?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^M^M
> > ^[[?25lL^[[?25h^[[?25lo^[[?25h^[[?25lc^[[?25h^[[?25la^[[?25h^[[?25ll^[[?25h^[[?25l_^[[?25h^[[?25lR^[[?25h^[[?25l2^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l:^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l1^[[?25h^[[?25l2^[[?25h^[
> > [?25l^[[K^[[1C^[[?25h^[[?25l3^[[?25h^[[?25l4^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l5^[[?25h^[[?25l6^[[?25h^[[?25l^[[K^[[1C^[[?25h^[[?25l7^[[?25h^[[?25l8^[[?25h^M^M
> > ^M^M
> >
> > Should match:
> > My_R1    : 78 56 34 12.*
> > My_R2    : 12 34 56 78.*
> > Local_R1 : 78 56 34 12.*
> > Local_R2 : 12 34 56 78.*
> > Local_R1 : 78 56 34 12.*
> > Local_R2 : 12 34 56 78.*
> > Local_R1 : 78 56 34 12.*
> > Local_R2 : 12 34 56 78.*
> >
>
> DejaGnu cannot routinely strip escape sequences because they could be
> part of the intended output---or strictly forbidden in the intended
> output.  Further, I suspect that the comparison is being carried out in
> the testsuite code rather than the framework, but the thread that
> arrived on the DejaGnu list does not mention what test is failing or
> what testsuite is being run.  Based on the inclusion of
> fortran@gcc.gnu.org, I am guessing this is an issue with the GNU Fortran
> tests.

Every GCC language testsuite has these failures, I just singled out
Fortran because I was interested in it.

> This is either a testsuite problem or an environment problem.  The GNU
> Fortran I/O module certainly has interesting behavior here.  Try setting
> TERM=dumb in the environment while running the testsuite.  If that fixes
> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the
> tool init file for GNU Fortran.

Setting TERM doesn't help.  Wine tries to emulate the windows console,
which requires outputting this stuff.  It does so any time there's a
pty, and I believe that Deja creates a pty when running the tests.
Wine people suggested if I could somehow run the test as "wine ./a.exe
| cat", that it would prevent this behavior, but I couldn't find a way
to do that.  For now, I modified Wine to kludge out the code that
creates the console, and a long term solution needs to be on the Wine
side.  I was just hoping for a less dirty hack from the Deja side.

Note that there are other problems, too.  It seems that when Deja is
matching against "\n", it doesn't handle the different line endings of
Windows correctly in a cross environment.  Is there a way that I can
set how to interpret \n in a target-board file?  This affects fortran
and other language tests also.

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>   
>> [...]
>> This is either a testsuite problem or an environment problem.  The GNU
>> Fortran I/O module certainly has interesting behavior here.  Try setting
>> TERM=dumb in the environment while running the testsuite.  If that fixes
>> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the
>> tool init file for GNU Fortran.
>>     
>
> Setting TERM doesn't help.  Wine tries to emulate the windows console,
> which requires outputting this stuff.  It does so any time there's a
> pty, and I believe that Deja creates a pty when running the tests.
>   

That is a bug in Wine:  the escapes should be suppressed entirely if the 
terminal does not support them---and the "dumb" terminal does not 
support them.

> Wine people suggested if I could somehow run the test as "wine ./a.exe
> | cat", that it would prevent this behavior, but I couldn't find a way
> to do that.

Actually... I think you can, as long as the programs to be run do not 
require input, but you will need to modify the testsuite to spawn 
programs differently when using Wine.  There is probably a "spawn" 
command somewhere in the testsuite.  You will want to change that to add 
a conditional for cross-testing using Wine and to use a pipeline in that 
case.  Something like:

8<------
if { ![isnative] && ![isremote target] && [istarget *-*-mingw*] } { # or similar pattern
    spawn -open [open "| wine ${command} </dev/null" r]
} else {
    # the original "spawn" command
    spawn $command
}
8<------


If these are "dg" tests, the code you need to change should be in the 
${tool}_load procedure in the tool init file, most likely in 
testsuite/lib.  Again, this can work only if the test programs are 
non-interactive, since Tcl does not allow running a subprocess with both 
input and output on pipes connected to the main program.  (Expect does, 
but uses a pty instead of a pair of pipes to accomplish this.)  The 
above example connects the child process's stdin to /dev/null and its 
stdout to a pipe to the Tcl interpreter running the testsuite; Expect 
then wraps the file handle in an Expect spawn handle and the rest of the 
code can use the 'expect' command as normal to read its output.

Also, "wine" should probably be instead a global variable WINE that can 
be set to a specific Wine executable if needed, but the best long-term 
solution is probably to fix the console emulation in Wine.

There may be more layers of indirection involved, possibly back into the 
framework; I am somewhat less familiar with the details of the GCC 
testsuite, so it would be very helpful if you could point me to one of 
the tests in question.  This may turn into a feature request for general 
framework support for emulated targets using "interposition emulators" 
such as Wine or QEMU.  I will think about that, but it probably will not 
be in 1.6.4.

>   For now, I modified Wine to kludge out the code that
> creates the console, and a long term solution needs to be on the Wine
> side.  I was just hoping for a less dirty hack from the Deja side.
>   

I think that the long-term solution is that Wine should properly honor 
the TERM environment variable and not produce escape codes that the 
declared terminal does not support.

> Note that there are other problems, too.  It seems that when Deja is
> matching against "\n", it doesn't handle the different line endings of
> Windows correctly in a cross environment.  Is there a way that I can
> set how to interpret \n in a target-board file?  This affects fortran
> and other language tests also.

No---problems related to line endings are bugs in the testsuite.  This 
caveat is documented in *Note: (dejagnu)Writing a test case.  The manual 
explains:  "Note that terminal settings may result in the insertion of 
additional `\r' characters, usually translating `\n' to `\r\n'."

At the terminal layer, POSIX can *also* use "\r\n" sequences, since some 
terminals historically needed them, even though the standard line ending 
*within* a POSIX system is "\n" by itself.  Because a pty simply 
presents the "terminal" side of the interface to the controlling 
program, Expect can receive "\r\n" when the subprocess emits "\n"; the 
translation is performed by the kernel terminal driver and DejaGnu 
testsuites must be prepared to receive (and discard) excess carriage 
returns in the general case.


-- Jacob

RE: testsuite under wine

[Torbjorn SVENSSON]

Hi,

> -----Original Message-----
> From: dejagnu-bounces+torbjorn.svensson=st.com@gnu.org <dejagnu-
> bounces+torbjorn.svensson=st.com@gnu.org> On Behalf Of Jacob Bachmeyer
> Sent: den 19 december 2022 05:29
> To: NightStrike <nightstrike@gmail.com>
> Cc: Thomas Koenig <tkoenig@netcologne.de>; fortran@gcc.gnu.org; gcc
> mailing list <gcc@gcc.gnu.org>; dejagnu@gnu.org
> Subject: Re: testsuite under wine
> 
> NightStrike wrote:
> > On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer
> <jcb62281@gmail.com> wrote:
> >
> >> [...]
> >> This is either a testsuite problem or an environment problem.  The GNU
> >> Fortran I/O module certainly has interesting behavior here.  Try setting
> >> TERM=dumb in the environment while running the testsuite.  If that fixes
> >> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the
> >> tool init file for GNU Fortran.
> >>
> >
> > Setting TERM doesn't help.  Wine tries to emulate the windows console,
> > which requires outputting this stuff.  It does so any time there's a
> > pty, and I believe that Deja creates a pty when running the tests.
> >
> 
> That is a bug in Wine:  the escapes should be suppressed entirely if the
> terminal does not support them---and the "dumb" terminal does not
> support them.

I'm not sure if this helps anyone, but I experienced something similar with Cygwin a while back.
What I had to do in order to have expect working when testing GCC on Windows 10 was to defined the "CYGWIN" environment variable to "disable_pcon" (https://cygwin.com/cygwin-ug-net/using-cygwinenv.html). If I did not define this variable, then Cygwin would inject an escape sequence that would make all pattern checks fail on the output.

I don't know if Cygwin might has changed this behavior, but it was an issue in the past anyway.

Kind regards,
Torbjörn

Re: testsuite under wine

[NightStrike]

On Mon, Dec 19, 2022 at 5:43 AM Torbjorn SVENSSON
<torbjorn.svensson@st.com> wrote:
> I'm not sure if this helps anyone, but I experienced something similar with Cygwin a while back.
> What I had to do in order to have expect working when testing GCC on Windows 10 was to defined the "CYGWIN" environment variable to "disable_pcon" (https://cygwin.com/cygwin-ug-net/using-cygwinenv.html). If I did not define this variable, then Cygwin would inject an escape sequence that would make all pattern checks fail on the output.
>
> I don't know if Cygwin might has changed this behavior, but it was an issue in the past anyway.

This is extremely helpful for when I start testing natively, thank
you.  I think in general the problem is the same, but Wine doesn't
immediately have a comparable workaround.

Re: testsuite under wine

[NightStrike]

On Sun, Dec 18, 2022 at 11:29 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>
> NightStrike wrote:
> > On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> >
> >> [...]
> >> This is either a testsuite problem or an environment problem.  The GNU
> >> Fortran I/O module certainly has interesting behavior here.  Try setting
> >> TERM=dumb in the environment while running the testsuite.  If that fixes
> >> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the
> >> tool init file for GNU Fortran.
> >>
> >
> > Setting TERM doesn't help.  Wine tries to emulate the windows console,
> > which requires outputting this stuff.  It does so any time there's a
> > pty, and I believe that Deja creates a pty when running the tests.
> >
>
> That is a bug in Wine:  the escapes should be suppressed entirely if the
> terminal does not support them---and the "dumb" terminal does not
> support them.

I think it's a paradigm difference.  I'm just guessing here, but Wine
runs in a terminal that doesn't know about TERM.  It's mimicking the
"cmd.exe" that you'd run on a native Windows system (I think... I'd
welcome corrections from those more knowledgeable).  In theory, the
effect would be the same if I set up a remote target board to ssh to a
windows system and get dropped into a cmd.exe shell (I used to run
this way... it'd take about a week to run the whole testsuite. It
sucked...)


[...snip for now, I'm working on getting reasonable output back to
you, including an example of a case that fails, and how it responds to
your suggestion. Stay tuned...]


> >   For now, I modified Wine to kludge out the code that
> > creates the console, and a long term solution needs to be on the Wine
> > side.  I was just hoping for a less dirty hack from the Deja side.
> >
>
> I think that the long-term solution is that Wine should properly honor
> the TERM environment variable and not produce escape codes that the
> declared terminal does not support.

Agreed, just trying to get by for now.

> > Note that there are other problems, too.  It seems that when Deja is
> > matching against "\n", it doesn't handle the different line endings of
> > Windows correctly in a cross environment.  Is there a way that I can
> > set how to interpret \n in a target-board file?  This affects fortran
> > and other language tests also.
>
> No---problems related to line endings are bugs in the testsuite.  This
> caveat is documented in *Note: (dejagnu)Writing a test case.  The manual
> explains:  "Note that terminal settings may result in the insertion of
> additional `\r' characters, usually translating `\n' to `\r\n'."
>
> At the terminal layer, POSIX can *also* use "\r\n" sequences, since some
> terminals historically needed them, even though the standard line ending
> *within* a POSIX system is "\n" by itself.  Because a pty simply
> presents the "terminal" side of the interface to the controlling
> program, Expect can receive "\r\n" when the subprocess emits "\n"; the
> translation is performed by the kernel terminal driver and DejaGnu
> testsuites must be prepared to receive (and discard) excess carriage
> returns in the general case.

Here's one that tries to handle different line endings (most tests do
not do this):

gfortran.dg/parameter_array_dummy.f90

which uses:
! { dg-output " *1 aa(\n|\r\n|\r)" }
! { dg-output " *2 ab(\n|\r\n|\r)" }
! { dg-output " *3 aaab(\n|\r\n|\r)" }
! { dg-output " *4 abaa(\n|\r\n|\r)" }
! { dg-output " *5 ababab(\n|\r\n|\r)" }

But this results in:

FAIL: gfortran.dg/parameter_array_dummy.f90   -O0  output pattern test
Output was:
           1 aa^M^M
           2 ab^M^M
           3 aaab^M^M
           4 abaa^M^M
           5 ababab^M^M

Should match:
 *1 aa(
|^M
|^M) *2 ab(
|^M
|^M) *3 aaab(
|^M
|^M) *4 abaa(
|^M
|^M) *5 ababab(
|^M
|^M)


The problem being that we are getting "0x0d 0x0d 0x0a", or \r\r\n.
(Other examples fail differently, for instance there's a Rust test
that outputs \r\r\n\n... but let's start with this one).

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> On Sun, Dec 18, 2022 at 11:29 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>   
>> NightStrike wrote:
>>     
>>> On Sat, Dec 17, 2022 at 10:44 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>>>
>>>       
>>>> [...]
>>>> This is either a testsuite problem or an environment problem.  The GNU
>>>> Fortran I/O module certainly has interesting behavior here.  Try setting
>>>> TERM=dumb in the environment while running the testsuite.  If that fixes
>>>> the problem, it may be appropriate to add "set ::env(TERM) dumb" to the
>>>> tool init file for GNU Fortran.
>>>>
>>>>         
>>> Setting TERM doesn't help.  Wine tries to emulate the windows console,
>>> which requires outputting this stuff.  It does so any time there's a
>>> pty, and I believe that Deja creates a pty when running the tests.
>>>
>>>       
>> That is a bug in Wine:  the escapes should be suppressed entirely if the
>> terminal does not support them---and the "dumb" terminal does not
>> support them.
>>     
>
> I think it's a paradigm difference.  I'm just guessing here, but Wine
> runs in a terminal that doesn't know about TERM.

Terminals never know about TERM.  TERM exists to inform programs what 
terminal type they are running with.  X11 terminal emulators *set* TERM 
in the environment given to their child processes to identify themselves 
for this reason.

> It's mimicking the "cmd.exe" that you'd run on a native Windows system (I think... I'd welcome corrections from those more knowledgeable).

Yes, but Wine must emulate a console window with the terminal that it 
has, which is not necessarily a VT100-alike, therefore it should be 
checking the TERM variable at the minimum, and preferably using terminfo 
to adapt whatever escape sequences the terminal in use actually expects, 
or gracefully degrade when the terminal simply does not support the 
needed features.

(Minor technical note:  while cmd.exe is a console program, it does not 
actually provide the console; that is a different part of the NT system, 
but I am not certain exactly what.  Wine is trying to emulate the 
Windows console, not cmd.exe.)

> In theory, the effect would be the same if I set up a remote target board to ssh to a windows system and get dropped into a cmd.exe shell (I used to run this way... it'd take about a week to run the whole testsuite. It sucked...)
>   

Ah yes, Windows has some serious performance problems related to 
spawning processes.  :-D  I once cross-compiled GNU libc from a Windows 
(98SE) host while setting up my first GNU/Linux system.  It took about 
three days and the machine needed a universal Windows fix-it (reboot) 
afterwards due to memory leaks resulting in swap thrashing that 
continued even after all application programs had been closed---just a 
desktop, disk light on almost solidly, mouse pointer lagging mouse 
movement visibly.  Later, on the same hardware but using a Linux kernel, 
rebuilding glibc took the expected two hours.  Also, the same hardware 
semi-regularly locked up solid (even the mouse pointer would not move) 
with Windows... and not even once with GNU/Linux/XFree86.  [...snip 
extended rant...]

> [...]
>>> Note that there are other problems, too.  It seems that when Deja is
>>> matching against "\n", it doesn't handle the different line endings of
>>> Windows correctly in a cross environment.  Is there a way that I can
>>> set how to interpret \n in a target-board file?  This affects fortran
>>> and other language tests also.
>>>       
>> No---problems related to line endings are bugs in the testsuite.  This
>> caveat is documented in *Note: (dejagnu)Writing a test case.  The manual
>> explains:  "Note that terminal settings may result in the insertion of
>> additional `\r' characters, usually translating `\n' to `\r\n'."
>>
>> At the terminal layer, POSIX can *also* use "\r\n" sequences, since some
>> terminals historically needed them, even though the standard line ending
>> *within* a POSIX system is "\n" by itself.  Because a pty simply
>> presents the "terminal" side of the interface to the controlling
>> program, Expect can receive "\r\n" when the subprocess emits "\n"; the
>> translation is performed by the kernel terminal driver and DejaGnu
>> testsuites must be prepared to receive (and discard) excess carriage
>> returns in the general case.
>>     
>
> Here's one that tries to handle different line endings (most tests do
> not do this):
>
> gfortran.dg/parameter_array_dummy.f90
>
> which uses:
> ! { dg-output " *1 aa(\n|\r\n|\r)" }
> ! { dg-output " *2 ab(\n|\r\n|\r)" }
> ! { dg-output " *3 aaab(\n|\r\n|\r)" }
> ! { dg-output " *4 abaa(\n|\r\n|\r)" }
> ! { dg-output " *5 ababab(\n|\r\n|\r)" }
>
> But this results in:
>
> FAIL: gfortran.dg/parameter_array_dummy.f90   -O0  output pattern test
> [...]
>
> The problem being that we are getting "0x0d 0x0d 0x0a", or \r\r\n.
>   

These are testsuite bugs.

This detail also (finally) tells me that the framework /is/ involved 
here after all, so there are possibilities for enhancing lib/dg.exp to 
reduce these issues.  One possibility could be to use "$" in dg-output 
patterns as an end-of-line marker, internally substituted with a known 
EOL pattern for the platform being tested.  (Not yet implemented, and 
testsuites using it would not be able to run with older framework 
versions.)  Another solution is to note that dg-output matching does 
*not* use Expect and is actually batch-oriented:  the test program is 
run (and its output gathered) using ${tool}_load, and then the patterns 
are matched against that returned output.  This means that the Expect 
caveats described in the manual for normal tests do not apply here, and 
a simple EOL subpattern is usable:  "[\r\n]+" (using that subpattern 
with Expect *will* cause subtle timing-related bugs)

> (Other examples fail differently, for instance there's a Rust test
> that outputs \r\r\n\n... but let's start with this one).
>   

I believe that dg-output could reliably match that with an "[\r\n]+" 
subpattern, too.  :-)

One last detail that might help you:  ${tool}_load has a chance to apply 
regsub(n) to the output before returning it.  If the testsuite should 
ignore escape sequences, and you can match them with a Tcl regexp, you 
could use a similar conditional as my previous suggestion to prune the 
output before dg.exp examines it.


-- Jacob

Re: testsuite under wine

[Jacek Caban]

[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]

Hi all,


I'm responsible for Wine changes that cause your problems. I'm also 
CCing Eric, who is Wine console expert, maybe he has better ideas. Eric, 
see [1] if you're interested in the context.


Recent Wine versions implement Windows pseudo-consoles, see [2] for a 
bit more details. It's generally Microsoft's semi-recent API that's 
intended to be more compatible with POSIX than what was present in 
previous versions of Windows. In theory, with that implemented, we could 
just plug tty fds that we get from Unix and have Unix consoles working 
using those Windows APIs. In practice, it's not quite as good as 
promised and we need some tweaks to make it work nicely. We could 
improve those tweaks, but there are architectural limitations that will 
come to play sooner or later.


 > I think that the long-term solution is that Wine should properly honor
 > the TERM environment variable and not produce escape codes that the
 > declared terminal does not support.


I think that it would not be enough. The way Windows consoles work is 
that we manage complete internal screen buffer and emit output that 
synchronizes the buffer with Unix terminal inside conhost.exe process. 
It means that its output heavily processed and may be very different 
from what application writes to its console handle. While escape codes 
discussed in this thread are the most prominent difference (and that 
part could, in theory, be improved on our side), there are more 
differences. For example, if application writes "\rA\rB\rC", conhost 
will process it, update its internal buffer which changes just one 
character and cursor position, and emit sequence to update it in Unix 
terminal, which could be just "\rC" (or even "C" if cursor was already 
at the beginning of the line). Another example would be long lines: 
conhost will emit additional EOLs instead of depending on embedder to 
wrap the line. I'm not really familiar with DejaGnu, but if you want to 
match application output, that's probably not what you're looking for.


The reason the previous workaround of compiling Wine without ncurses 
worked is that if made Wine treat tty stdin/stdout in a way very similar 
to regular pipes, so no extra processing was performed. This was more of 
a side effect than a design choice. It should be possible to provide 
some way to achieve that with the new Wine architecture. I'm attaching 
an example of Wine patch that would allow it. With that patch, you may 
disable conhost.exe (via winecfg or WINEDLLOVERRIDES=conhost.exe=d 
environment variable) and achieve something similar to previous workaround.


Long term, I think that it would be best to get rid of console behaviour 
expectations by using Windows build of DejaGnu. My understanding is that 
it requires Cygwin, so the stack would be: Windows DejaGnu on Cygwin on 
Wine on Linux. This would make all similar mismatches in expectations 
non-existent. Cygwin is tricky to run on Wine, there are a few known 
problems like [3], but we're getting there.


Jacek


[1] https://gcc.gnu.org/pipermail/fortran/2022-December/058645.html

[2] 
https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/

[3] https://bugs.winehq.org/show_bug.cgi?id=47808

[-- Attachment #2: console.diff --]
[-- Type: text/x-patch, Size: 2400 bytes --]

diff --git a/dlls/kernelbase/console.c b/dlls/kernelbase/console.c
index 7cd87f53b3c..61569fda9a6 100644
--- a/dlls/kernelbase/console.c
+++ b/dlls/kernelbase/console.c
@@ -2307,33 +2307,45 @@ void init_console( void )
         COORD size;
 
         if (is_tty_handle( params->hStdInput ))
-        {
             tty_in = params->hStdInput;
-            params->hStdInput = NULL;
-        }
         if (is_tty_handle( params->hStdOutput ))
-        {
             tty_out = params->hStdOutput;
-            params->hStdOutput = NULL;
-        }
-        if (is_tty_handle( params->hStdError ))
-        {
-            if (tty_out) CloseHandle( params->hStdError );
-            else tty_out = params->hStdError;
-            params->hStdError = NULL;
-        }
+        else if (is_tty_handle( params->hStdError ))
+            tty_out = params->hStdError;
 
         size.X = params->dwXCountChars;
         size.Y = params->dwYCountChars;
         TRACE( "creating unix console (size %u %u)\n", size.X, size.Y );
         params->ConsoleHandle = create_pseudo_console( size, tty_in, tty_out, NULL, 0, &process );
-        CloseHandle( process );
-        CloseHandle( tty_in );
-        CloseHandle( tty_out );
-
-        if (params->ConsoleHandle && create_console_connection( params->ConsoleHandle ))
+        if (params->ConsoleHandle)
+        {
+            CloseHandle( process );
+
+            if (is_tty_handle( params->hStdInput ))
+            {
+                CloseHandle( params->hStdInput );
+                params->hStdInput = NULL;
+            }
+            if (is_tty_handle( params->hStdOutput ))
+            {
+                CloseHandle( params->hStdOutput );
+                params->hStdOutput = NULL;
+            }
+            if (is_tty_handle( params->hStdError ))
+            {
+                CloseHandle( params->hStdError );
+                params->hStdError = NULL;
+            }
+
+            if (params->ConsoleHandle && create_console_connection( params->ConsoleHandle ))
+            {
+                init_console_std_handles( FALSE );
+            }
+        }
+        else
         {
-            init_console_std_handles( FALSE );
+            WARN( "Failed to create console process\n" );
+            params->ConsoleHandle = CONSOLE_HANDLE_SHELL_NO_WINDOW;
         }
     }
     else if (params->ConsoleHandle == CONSOLE_HANDLE_ALLOC ||

Re: testsuite under wine

[NightStrike]

On Wed, Dec 21, 2022 at 12:38 PM Jacek Caban <jacek@codeweavers.com> wrote:
>
> Hi all,
>
>
> I'm responsible for Wine changes that cause your problems. I'm also
> CCing Eric, who is Wine console expert, maybe he has better ideas. Eric,
> see [1] if you're interested in the context.
>
>
> Recent Wine versions implement Windows pseudo-consoles, see [2] for a
> bit more details. It's generally Microsoft's semi-recent API that's
> intended to be more compatible with POSIX than what was present in
> previous versions of Windows. In theory, with that implemented, we could
> just plug tty fds that we get from Unix and have Unix consoles working
> using those Windows APIs. In practice, it's not quite as good as
> promised and we need some tweaks to make it work nicely. We could
> improve those tweaks, but there are architectural limitations that will
> come to play sooner or later.
>
>
>  > I think that the long-term solution is that Wine should properly honor
>  > the TERM environment variable and not produce escape codes that the
>  > declared terminal does not support.
>
>
> I think that it would not be enough. The way Windows consoles work is
> that we manage complete internal screen buffer and emit output that
> synchronizes the buffer with Unix terminal inside conhost.exe process.
> It means that its output heavily processed and may be very different
> from what application writes to its console handle. While escape codes
> discussed in this thread are the most prominent difference (and that
> part could, in theory, be improved on our side), there are more
> differences. For example, if application writes "\rA\rB\rC", conhost
> will process it, update its internal buffer which changes just one
> character and cursor position, and emit sequence to update it in Unix
> terminal, which could be just "\rC" (or even "C" if cursor was already
> at the beginning of the line). Another example would be long lines:
> conhost will emit additional EOLs instead of depending on embedder to
> wrap the line. I'm not really familiar with DejaGnu, but if you want to
> match application output, that's probably not what you're looking for.
>
>
> The reason the previous workaround of compiling Wine without ncurses
> worked is that if made Wine treat tty stdin/stdout in a way very similar
> to regular pipes, so no extra processing was performed. This was more of
> a side effect than a design choice. It should be possible to provide
> some way to achieve that with the new Wine architecture. I'm attaching
> an example of Wine patch that would allow it. With that patch, you may
> disable conhost.exe (via winecfg or WINEDLLOVERRIDES=conhost.exe=d
> environment variable) and achieve something similar to previous workaround.
>
>
> Long term, I think that it would be best to get rid of console behaviour
> expectations by using Windows build of DejaGnu. My understanding is that
> it requires Cygwin, so the stack would be: Windows DejaGnu on Cygwin on
> Wine on Linux. This would make all similar mismatches in expectations
> non-existent. Cygwin is tricky to run on Wine, there are a few known
> problems like [3], but we're getting there.
>
>
> Jacek
>
>
> [1] https://gcc.gnu.org/pipermail/fortran/2022-December/058645.html
>
> [2]
> https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/
>
> [3] https://bugs.winehq.org/show_bug.cgi?id=47808

First, a big giant thank you for this patch.  I confirmed that I can
use this to replace the "return immediately from init_console" hack,
and it applies cleanly to 7.20.

Second, the problems with extra \r's still remain, but I think we've
generally come to think that that part isn't Wine and is instead
either the testsuite or deja.  So I'll keep those replies to Jacob's
previous message.

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> [...]
> Second, the problems with extra \r's still remain, but I think we've
> generally come to think that that part isn't Wine and is instead
> either the testsuite or deja.  So I'll keep those replies to Jacob's
> previous message.
>   

Most likely, it is a combination of the MinGW libc (which emits "\r\n" 
for end-of-line in accordance with Windows convention) and the kernel 
terminal driver (which passes "\r" and translates "\n" to "\r\n" in 
accordance with POSIX convention).  Wine, short of trying to translate 
"\r\n" back to "\n" in accordance with POSIX conventions (and likely 
making an even bigger mess---does Wine know if a handle is supposed to 
be text or binary?) cannot really fix this, so the testsuite needs to 
handle non-POSIX-standard line endings.  (The Rust tests probably have 
an outright bug if the newlines are being duplicated.)


-- Jacob

Re: testsuite under wine

[NightStrike]

On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>
> NightStrike wrote:
> > [...]
> > Second, the problems with extra \r's still remain, but I think we've
> > generally come to think that that part isn't Wine and is instead
> > either the testsuite or deja.  So I'll keep those replies to Jacob's
> > previous message.
> >
>
> Most likely, it is a combination of the MinGW libc (which emits "\r\n"
> for end-of-line in accordance with Windows convention) and the kernel
> terminal driver (which passes "\r" and translates "\n" to "\r\n" in
> accordance with POSIX convention).  Wine, short of trying to translate
> "\r\n" back to "\n" in accordance with POSIX conventions (and likely
> making an even bigger mess---does Wine know if a handle is supposed to
> be text or binary?) cannot really fix this, so the testsuite needs to
> handle non-POSIX-standard line endings.  (The Rust tests probably have
> an outright bug if the newlines are being duplicated.)

You may be onto something here.  I ran wine under script as `script -c
"wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r
prepended to the \r\n.  I was making the mistake previously of running
wine manually and capturing it to a file as `wine64 ./a.exe > out`,
which as several have pointed out in this thread, that would disable
the quirk, so of course it didn't reveal any problems.  I'm behind,
but I'll catch up to you guys eventually :)

So at least we know for sure that this particular instance of extra
characters is coming from Wine.  Maybe Wine can be smart enough to
only translate \n into \r\n instead of translating \r\n into \r\r\n.
Jacek / Eric, comments here?  I'm happy to try another patch, the
first one was great.

Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so...  yeah.  Could
be the rust test, could be the rust frontend, could be another weird
Wine interaction.

Re: testsuite under wine

[Eric Pouech]

Le 23/12/2022 à 11:36, NightStrike a écrit :
> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>> NightStrike wrote:
>>> [...]
>>> Second, the problems with extra \r's still remain, but I think we've
>>> generally come to think that that part isn't Wine and is instead
>>> either the testsuite or deja.  So I'll keep those replies to Jacob's
>>> previous message.
>>>
>> Most likely, it is a combination of the MinGW libc (which emits "\r\n"
>> for end-of-line in accordance with Windows convention) and the kernel
>> terminal driver (which passes "\r" and translates "\n" to "\r\n" in
>> accordance with POSIX convention).  Wine, short of trying to translate
>> "\r\n" back to "\n" in accordance with POSIX conventions (and likely
>> making an even bigger mess---does Wine know if a handle is supposed to
>> be text or binary?) cannot really fix this, so the testsuite needs to
>> handle non-POSIX-standard line endings.  (The Rust tests probably have
>> an outright bug if the newlines are being duplicated.)
> You may be onto something here.  I ran wine under script as `script -c
> "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r
> prepended to the \r\n.  I was making the mistake previously of running
> wine manually and capturing it to a file as `wine64 ./a.exe > out`,
> which as several have pointed out in this thread, that would disable
> the quirk, so of course it didn't reveal any problems.  I'm behind,
> but I'll catch up to you guys eventually :)
>
> So at least we know for sure that this particular instance of extra
> characters is coming from Wine.  Maybe Wine can be smart enough to
> only translate \n into \r\n instead of translating \r\n into \r\r\n.
> Jacek / Eric, comments here?  I'm happy to try another patch, the
> first one was great.
>
actually, it depends on how the file has been opened by the application. 
if it's done in binary mode, no \n => \r\n translation takes place

but it the file is opened in text mode, wine just does what the 
application requires, which is \n => \r\n translation

(and by default, stdout and stderr are opened in text mode)


IMO, you should not expect more from Wine. Wine's goal is to run windows 
application on Unix ; it's not to run windows applications on Unix and 
requiring that they behave as they had been written for Linux semantics


anyway, we (wine) have to go back to blackboard to figure out a solution 
for disabling nicely conhost


in the meantime, you could use (without any patch to wine), some wrapper 
(bash) script like:

#!/bin/bash

# assumes wine is in $PATH

case "$1" in
     --unix-raw) shift; cat | wine $* 1> >(tee /dev/null) 2> >(tee 
/dev/null >&2);;
     --unix-lf)  shift; cat | wine $* 1> >(tee /dev/null | sed 's/\r$//' 
) 2> >(tee /dev/null | sed 's/\r$//' >&2);;
     *) wine $*;;
esac

using --unix-raw will just disable conhost (hence shall remove most of 
the ansi sequences reported)

using --unix-lf will also disable conhost and replace \r\n with \n

this shall put wine in the behavior as you expect, and still allow using 
proper redirection and piping on the shell script if needed (without 
alterning wine's behavior)

(this could be further improved by not adding a pipe for fd:s that are 
not tty, or adapted to be triggered when, say, TERM=dumb)

HTH

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>   
>> NightStrike wrote:
>>     
>>> [...]
>>> Second, the problems with extra \r's still remain, but I think we've
>>> generally come to think that that part isn't Wine and is instead
>>> either the testsuite or deja.  So I'll keep those replies to Jacob's
>>> previous message.
>>>
>>>       
>> Most likely, it is a combination of the MinGW libc (which emits "\r\n"
>> for end-of-line in accordance with Windows convention) and the kernel
>> terminal driver (which passes "\r" and translates "\n" to "\r\n" in
>> accordance with POSIX convention).  Wine, short of trying to translate
>> "\r\n" back to "\n" in accordance with POSIX conventions (and likely
>> making an even bigger mess---does Wine know if a handle is supposed to
>> be text or binary?) cannot really fix this, so the testsuite needs to
>> handle non-POSIX-standard line endings.  (The Rust tests probably have
>> an outright bug if the newlines are being duplicated.)
>>     
>
> You may be onto something here.  I ran wine under script as `script -c
> "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r
> prepended to the \r\n.  I was making the mistake previously of running
> wine manually and capturing it to a file as `wine64 ./a.exe > out`,
> which as several have pointed out in this thread, that would disable
> the quirk, so of course it didn't reveal any problems.  I'm behind,
> but I'll catch up to you guys eventually :)
>   

So close, and yet so far...  script(1) /also/ uses a pty, so it is 
getting the same translations as Expect and therefore DejaGnu.

> So at least we know for sure that this particular instance of extra
> characters is coming from Wine.  Maybe Wine can be smart enough to
> only translate \n into \r\n instead of translating \r\n into \r\r\n.
> Jacek / Eric, comments here?  I'm happy to try another patch, the
> first one was great.
>   

I doubt that Wine is doing that translation.  MinGW libc produces output 
conformant to Windows conventions, so printf("\n") on a text handle 
emits "\r\n", which Wine passes along.  POSIX convention is that "\n" is 
translated to "\r\n" in the kernel terminal driver upon output, so the 
kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding 
"\r\r\n" at the pty master end.  This is why DejaGnu testsuites must be 
prepared to discard excess carriage returns.  The first CR came from 
MinGW libc; the second CR came from the kernel terminal driver; the LF 
was ultimately passed through.

> Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so...  yeah.  Could
> be the rust test, could be the rust frontend, could be another weird
> Wine interaction.
>   

That is probably either a Rust bug or the intended behavior.  Does the 
test produce "\n\n" or "\r\n\n" when run natively?  (Note that the 
terminal driver could reasonably optimize:  once one CR has been 
produced, any number of LF may follow:  the cursor is assumed to remain 
at the left edge.  It is possible that the kernel terminal driver could 
even strip the second CR in "\r\n\r\n" since its only effect on an 
actual serial terminal would be wasting transmission time.)


-- Jacob

Re: testsuite under wine

[Mark Wielaard]

Hi,

On Fri, Dec 23, 2022 at 10:00:36PM -0600, Jacob Bachmeyer via Gcc wrote:
> NightStrike wrote:
> > Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so...  yeah.  Could
> > be the rust test, could be the rust frontend, could be another weird
> > Wine interaction.
> 
> That is probably either a Rust bug or the intended behavior.

Note that in rust a string tokens or doc comments with an "Isolated
CR" (a \r not immediately followed by an \n) is an error and the
testsuite contains a couple of tests to make sure the compiler detects
that. Which might cause even more confusion.

Cheers,

Mark

Re: testsuite under wine

[NightStrike]

On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> NightStrike wrote:
> > On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> >> NightStrike wrote:
> >>
> >>> [...]
> >>> Second, the problems with extra \r's still remain, but I think we've
> >>> generally come to think that that part isn't Wine and is instead
> >>> either the testsuite or deja.  So I'll keep those replies to Jacob's
> >>> previous message.
> >>>
> >>>
> >> Most likely, it is a combination of the MinGW libc (which emits "\r\n"
> >> for end-of-line in accordance with Windows convention) and the kernel
> >> terminal driver (which passes "\r" and translates "\n" to "\r\n" in
> >> accordance with POSIX convention).  Wine, short of trying to translate
> >> "\r\n" back to "\n" in accordance with POSIX conventions (and likely
> >> making an even bigger mess---does Wine know if a handle is supposed to
> >> be text or binary?) cannot really fix this, so the testsuite needs to
> >> handle non-POSIX-standard line endings.  (The Rust tests probably have
> >> an outright bug if the newlines are being duplicated.)
> >>
> >
> > You may be onto something here.  I ran wine under script as `script -c
> > "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r
> > prepended to the \r\n.  I was making the mistake previously of running
> > wine manually and capturing it to a file as `wine64 ./a.exe > out`,
> > which as several have pointed out in this thread, that would disable
> > the quirk, so of course it didn't reveal any problems.  I'm behind,
> > but I'll catch up to you guys eventually :)
> >
>
> So close, and yet so far...  script(1) /also/ uses a pty, so it is
> getting the same translations as Expect and therefore DejaGnu.
>
> > So at least we know for sure that this particular instance of extra
> > characters is coming from Wine.  Maybe Wine can be smart enough to
> > only translate \n into \r\n instead of translating \r\n into \r\r\n.
> > Jacek / Eric, comments here?  I'm happy to try another patch, the
> > first one was great.
> >
>
> I doubt that Wine is doing that translation.  MinGW libc produces output
> conformant to Windows conventions, so printf("\n") on a text handle
> emits "\r\n", which Wine passes along.  POSIX convention is that "\n" is
> translated to "\r\n" in the kernel terminal driver upon output, so the
> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
> "\r\r\n" at the pty master end.  This is why DejaGnu testsuites must be
> prepared to discard excess carriage returns.  The first CR came from
> MinGW libc; the second CR came from the kernel terminal driver; the LF
> was ultimately passed through.

Jacek and I have been digging into this on IRC, and he's been very
helpful in trying to get further, but we're still stuck.  We tried to
be more introspective, inserting strace both as "strace script wine"
and as "script strace wine".  We tried running just "wine a.exe"
without any extra glue, and logging the raw SSH packets from putty.
After many iterations on these and other tests, Jacek finally had the
idea to try removing Windows entirely from the equation, and we ran
with a purely unix program / compiler combination:

#include <unistd.h>

int main()
{
        write(1, "test\r\n", 6);
        return 0;
}

(and also as "test\n", 5)

In both versions, the following was observed:

case 1) ./a.out | xxd
case 2) script -c ./a.out out; xxd out
case 3) enable putting logging, ./a.out

In case 1, xxd showed no extra \r's.  In cases 2 and 3, there was an
extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).

So, is it possible after all of this back and forth regarding mingw,
wine, and others, that it's down to the write() system call that's
inserting extra \r's?  Is this expected?

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>   
>> NightStrike wrote:
>>     
>>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>>>       
>>>> [...]
>>> So at least we know for sure that this particular instance of extra
>>> characters is coming from Wine.  Maybe Wine can be smart enough to
>>> only translate \n into \r\n instead of translating \r\n into \r\r\n.
>>> Jacek / Eric, comments here?  I'm happy to try another patch, the
>>> first one was great.
>>>
>>>       
>> I doubt that Wine is doing that translation.  MinGW libc produces output
>> conformant to Windows conventions, so printf("\n") on a text handle
>> emits "\r\n", which Wine passes along.  POSIX convention is that "\n" is
>> translated to "\r\n" in the kernel terminal driver upon output, so the
>> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
>> "\r\r\n" at the pty master end.  This is why DejaGnu testsuites must be
>> prepared to discard excess carriage returns.  The first CR came from
>> MinGW libc; the second CR came from the kernel terminal driver; the LF
>> was ultimately passed through.
>>     
>
> Jacek and I have been digging into this on IRC, and he's been very
> helpful in trying to get further, but we're still stuck.  We tried to
> be more introspective, inserting strace both as "strace script wine"
> and as "script strace wine".  We tried running just "wine a.exe"
> without any extra glue, and logging the raw SSH packets from putty.
> After many iterations on these and other tests, Jacek finally had the
> idea to try removing Windows entirely from the equation, and we ran
> with a purely unix program / compiler combination:
>
> #include <unistd.h>
>
> int main()
> {
>         write(1, "test\r\n", 6);
>         return 0;
> }
>
> (and also as "test\n", 5)
>
> In both versions, the following was observed:
>
> case 1) ./a.out | xxd
> case 2) script -c ./a.out out; xxd out
> case 3) enable putting logging, ./a.out
>
> In case 1, xxd showed no extra \r's.  In cases 2 and 3, there was an
> extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
>
> So, is it possible after all of this back and forth regarding mingw,
> wine, and others, that it's down to the write() system call that's
> inserting extra \r's?  Is this expected?
>   

"This is why DejaGnu testsuites must be prepared to discard excess 
carriage returns."

The write(2) system call inserts nothing and simply hands off the buffer 
to the relevant part of the kernel I/O subsystem.  (The kernel in POSIX 
is *not* a monolithic black box.)  When stdout for your test program is 
a pty slave, that relevant part is the kernel terminal driver.  The 
kernel terminal driver is converting "\n" to "\r\n" upon output to the 
associated port, since hardware terminals typically *do* require CRLF.  
The associated port in this case is virtual and part of the kernel pty 
subsystem, which presents octets written to that port to its associated 
pty master device.  The user-visible pty slave device acts just like a 
serial terminal, including all translations normally done for handling 
serial terminals.

A pty is conceptually a null-modem cable connected between two 
infinitely-fast serial ports on the same machine, although the slave 
will still report an actual baud rate if queried.  (Run "stty" with no 
arguments under script(1), an ssh session, or an X11 terminal emulator 
to see what a pty slave looks like on your machine.)

In your case 1, the pty subsystem is not used and output is collected 
over a pipe.  Using "./a.out > out; xxd out" would produce the same 
results.  In cases 2 and 3, there is a pty involved, either set up by 
script(1) or by sshd (assuming you meant "enable putty logging" in case 
3) that performs the standard terminal translations.  In all cases, 
strace(1) will show the exact string written to the pty slave device, 
which will not include any extra CRs because *those* *are* *inserted* 
*by* *the* *kernel* *terminal* *driver* as the data is transferred to 
the pty master device's read queue.

This insertion of carriage returns is expected and standardized behavior 
in POSIX and is the reason Unix could use bare LF as end-of-line even 
though hardware terminals always needed CRLF.  CP/M (and therefore 
MS-DOS which began its existence as a cheap CP/M knockoff) did not have 
this translation layer and instead dumped the complexity of a two-octet 
end-of-line sequence on user programs, leading to much confusion even 
today.  This is not a Wine issue, although the terminal escape sequences 
in your original issue *were* from Wine.  Note that the number of excess 
carriage returns that a DejaGnu testsuite must be prepared to discard is 
unspecified because running tests on remote targets may result in *any* 
*number* of CRs preceding each LF by the time the results reach the test 
driver machine in more complex testing lab environments.


-- Jacob

Re: testsuite under wine

[Jerry D]

On 1/5/23 7:33 PM, Jacob Bachmeyer via Fortran wrote:
> NightStrike wrote:
>> On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> 
>> wrote:
>>> NightStrike wrote:
>>>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer 
>>>> <jcb62281@gmail.com> wrote:
>>>>> [...]
>>>> So at least we know for sure that this particular instance of extra
>>>> characters is coming from Wine.  Maybe Wine can be smart enough to
>>>> only translate \n into \r\n instead of translating \r\n into \r\r\n.
>>>> Jacek / Eric, comments here?  I'm happy to try another patch, the
>>>> first one was great.
>>>>
>>> I doubt that Wine is doing that translation.  MinGW libc produces output
>>> conformant to Windows conventions, so printf("\n") on a text handle
>>> emits "\r\n", which Wine passes along.  POSIX convention is that "\n" is
>>> translated to "\r\n" in the kernel terminal driver upon output, so the
>>> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
>>> "\r\r\n" at the pty master end.  This is why DejaGnu testsuites must be
>>> prepared to discard excess carriage returns.  The first CR came from
>>> MinGW libc; the second CR came from the kernel terminal driver; the LF
>>> was ultimately passed through.
>>
>> Jacek and I have been digging into this on IRC, and he's been very
>> helpful in trying to get further, but we're still stuck.  We tried to
>> be more introspective, inserting strace both as "strace script wine"
>> and as "script strace wine".  We tried running just "wine a.exe"
>> without any extra glue, and logging the raw SSH packets from putty.
>> After many iterations on these and other tests, Jacek finally had the
>> idea to try removing Windows entirely from the equation, and we ran
>> with a purely unix program / compiler combination:
>>
>> #include <unistd.h>
>>
>> int main()
>> {
>>         write(1, "test\r\n", 6);
>>         return 0;
>> }
>>
>> (and also as "test\n", 5)
>>
>> In both versions, the following was observed:
>>
>> case 1) ./a.out | xxd
>> case 2) script -c ./a.out out; xxd out
>> case 3) enable putting logging, ./a.out
>>
>> In case 1, xxd showed no extra \r's.  In cases 2 and 3, there was an
>> extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
>>
>> So, is it possible after all of this back and forth regarding mingw,
>> wine, and others, that it's down to the write() system call that's
>> inserting extra \r's?  Is this expected?
> 
> "This is why DejaGnu testsuites must be prepared to discard excess 
> carriage returns."
> 
> The write(2) system call inserts nothing and simply hands off the buffer 
> to the relevant part of the kernel I/O subsystem.  (The kernel in POSIX 
> is *not* a monolithic black box.)  When stdout for your test program is 
> a pty slave, that relevant part is the kernel terminal driver.  The 
> kernel terminal driver is converting "\n" to "\r\n" upon output to the 
> associated port, since hardware terminals typically *do* require CRLF. 
> The associated port in this case is virtual and part of the kernel pty 
> subsystem, which presents octets written to that port to its associated 
> pty master device.  The user-visible pty slave device acts just like a 
> serial terminal, including all translations normally done for handling 
> serial terminals.
> 
> A pty is conceptually a null-modem cable connected between two 
> infinitely-fast serial ports on the same machine, although the slave 
> will still report an actual baud rate if queried.  (Run "stty" with no 
> arguments under script(1), an ssh session, or an X11 terminal emulator 
> to see what a pty slave looks like on your machine.)
> 
> In your case 1, the pty subsystem is not used and output is collected 
> over a pipe.  Using "./a.out > out; xxd out" would produce the same 
> results.  In cases 2 and 3, there is a pty involved, either set up by 
> script(1) or by sshd (assuming you meant "enable putty logging" in case 
> 3) that performs the standard terminal translations.  In all cases, 
> strace(1) will show the exact string written to the pty slave device, 
> which will not include any extra CRs because *those* *are* *inserted* 
> *by* *the* *kernel* *terminal* *driver* as the data is transferred to 
> the pty master device's read queue.
> 
> This insertion of carriage returns is expected and standardized behavior 
> in POSIX and is the reason Unix could use bare LF as end-of-line even 
> though hardware terminals always needed CRLF.  CP/M (and therefore 
> MS-DOS which began its existence as a cheap CP/M knockoff) did not have 
> this translation layer and instead dumped the complexity of a two-octet 
> end-of-line sequence on user programs, leading to much confusion even 
> today.  This is not a Wine issue, although the terminal escape sequences 
> in your original issue *were* from Wine.  Note that the number of excess 
> carriage returns that a DejaGnu testsuite must be prepared to discard is 
> unspecified because running tests on remote targets may result in *any* 
> *number* of CRs preceding each LF by the time the results reach the test 
> driver machine in more complex testing lab environments.
> 
> 
> -- Jacob

Agree

Re: testsuite under wine

[NightStrike]

On Thu, Jan 5, 2023 at 10:33 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>
> NightStrike wrote:
> > On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> >
> >> NightStrike wrote:
> >>
> >>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
> >>>
> >>>> [...]
> >>> So at least we know for sure that this particular instance of extra
> >>> characters is coming from Wine.  Maybe Wine can be smart enough to
> >>> only translate \n into \r\n instead of translating \r\n into \r\r\n.
> >>> Jacek / Eric, comments here?  I'm happy to try another patch, the
> >>> first one was great.
> >>>
> >>>
> >> I doubt that Wine is doing that translation.  MinGW libc produces output
> >> conformant to Windows conventions, so printf("\n") on a text handle
> >> emits "\r\n", which Wine passes along.  POSIX convention is that "\n" is
> >> translated to "\r\n" in the kernel terminal driver upon output, so the
> >> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
> >> "\r\r\n" at the pty master end.  This is why DejaGnu testsuites must be
> >> prepared to discard excess carriage returns.  The first CR came from
> >> MinGW libc; the second CR came from the kernel terminal driver; the LF
> >> was ultimately passed through.
> >>
> >
> > Jacek and I have been digging into this on IRC, and he's been very
> > helpful in trying to get further, but we're still stuck.  We tried to
> > be more introspective, inserting strace both as "strace script wine"
> > and as "script strace wine".  We tried running just "wine a.exe"
> > without any extra glue, and logging the raw SSH packets from putty.
> > After many iterations on these and other tests, Jacek finally had the
> > idea to try removing Windows entirely from the equation, and we ran
> > with a purely unix program / compiler combination:
> >
> > #include <unistd.h>
> >
> > int main()
> > {
> >         write(1, "test\r\n", 6);
> >         return 0;
> > }
> >
> > (and also as "test\n", 5)
> >
> > In both versions, the following was observed:
> >
> > case 1) ./a.out | xxd
> > case 2) script -c ./a.out out; xxd out
> > case 3) enable putting logging, ./a.out
> >
> > In case 1, xxd showed no extra \r's.  In cases 2 and 3, there was an
> > extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
> >
> > So, is it possible after all of this back and forth regarding mingw,
> > wine, and others, that it's down to the write() system call that's
> > inserting extra \r's?  Is this expected?
> >
>
> "This is why DejaGnu testsuites must be prepared to discard excess
> carriage returns."
>
> The write(2) system call inserts nothing and simply hands off the buffer
> to the relevant part of the kernel I/O subsystem.  (The kernel in POSIX
> is *not* a monolithic black box.)  When stdout for your test program is
> a pty slave, that relevant part is the kernel terminal driver.  The
> kernel terminal driver is converting "\n" to "\r\n" upon output to the
> associated port, since hardware terminals typically *do* require CRLF.
> The associated port in this case is virtual and part of the kernel pty
> subsystem, which presents octets written to that port to its associated
> pty master device.  The user-visible pty slave device acts just like a
> serial terminal, including all translations normally done for handling
> serial terminals.
>
> A pty is conceptually a null-modem cable connected between two
> infinitely-fast serial ports on the same machine, although the slave
> will still report an actual baud rate if queried.  (Run "stty" with no
> arguments under script(1), an ssh session, or an X11 terminal emulator
> to see what a pty slave looks like on your machine.)
>
> In your case 1, the pty subsystem is not used and output is collected
> over a pipe.  Using "./a.out > out; xxd out" would produce the same
> results.  In cases 2 and 3, there is a pty involved, either set up by
> script(1) or by sshd (assuming you meant "enable putty logging" in case
> 3) that performs the standard terminal translations.  In all cases,
> strace(1) will show the exact string written to the pty slave device,
> which will not include any extra CRs because *those* *are* *inserted*
> *by* *the* *kernel* *terminal* *driver* as the data is transferred to
> the pty master device's read queue.
>
> This insertion of carriage returns is expected and standardized behavior
> in POSIX and is the reason Unix could use bare LF as end-of-line even
> though hardware terminals always needed CRLF.  CP/M (and therefore
> MS-DOS which began its existence as a cheap CP/M knockoff) did not have
> this translation layer and instead dumped the complexity of a two-octet
> end-of-line sequence on user programs, leading to much confusion even
> today.  This is not a Wine issue, although the terminal escape sequences
> in your original issue *were* from Wine.  Note that the number of excess
> carriage returns that a DejaGnu testsuite must be prepared to discard is
> unspecified because running tests on remote targets may result in *any*
> *number* of CRs preceding each LF by the time the results reach the test
> driver machine in more complex testing lab environments.

First, I just want to thank you for your patience.  You are putting a
lot of effort into these replies, and it is appreciated.

I did another little test to try to better understand your point.  I
ran a linux native testsuite under a simulator that just sets SIM to "
".  This resulted in extra ^M's also, although many tests pass because
they're already looking for \r\n to accommodate windows.  So I think
I've come around to grasp what you've been heroically re-explaining...

So if we have to modify every test in the entire testsuite to check
for zero or more \r's followed by zero or more \n's, would it be
better to add a dg-output-line proc that does this automatically
everywhere?  I feel like changing every output pattern test won't be
too maintainable.  You had mentioned previously modifying ${tool}_load
to filter out extra \r's, but I couldn't see where or how to do that.

For completeness, setting a random selection of tests to look for
\r*\n? worked (this would cover even deprecated systems that only use
CR as well as flagging the weird rust case of \r\r\n\n as bad).

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> [...]
> I did another little test to try to better understand your point.  I
> ran a linux native testsuite under a simulator that just sets SIM to "
> ".  This resulted in extra ^M's also, although many tests pass because
> they're already looking for \r\n to accommodate windows.  So I think
> I've come around to grasp what you've been heroically re-explaining...
>
> So if we have to modify every test in the entire testsuite to check
> for zero or more \r's followed by zero or more \n's, would it be
> better to add a dg-output-line proc that does this automatically
> everywhere?

Two problems:  first, you need zero-or-more \r and *one*-or-more \n.  
Second, dg-output is not defined as an anchored match, and therefore 
cannot do this automatically.

>   I feel like changing every output pattern test won't be
> too maintainable.  You had mentioned previously modifying ${tool}_load
> to filter out extra \r's, but I couldn't see where or how to do that.
>
> For completeness, setting a random selection of tests to look for
> \r*\n? worked (this would cover even deprecated systems that only use
> CR as well as flagging the weird rust case of \r\r\n\n as bad).

Do not worry about classic Mac OS---running DejaGnu on that platform is 
not possible, nor is it possible to run test programs remotely on that 
platform.  Classic Mac OS is a pure-GUI system with no command interface 
whatsoever.  Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl 
exec(n) command.  Due to limitations of the platform, porting Expect to 
classic Mac OS is simply not possible.  Any compatibility layer would be 
reasonably expected to translate CR<->LF, if, for example, someone wrote 
a telnet server (and associated POSIX-alike environment) for Mac OS.

The later Mac OS X is a quasi-POSIX mostly compatible with the GNU 
system that uses POSIX line endings.  DejaGnu should run normally there.

Are there other systems that used bare CR as end-of-line?  If not, the 
correct pattern is therefore {\r*\n} (here written using braces as 
quotes around the pattern).


-- Jacob

Re: testsuite under wine

[NightStrike]

On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>
> NightStrike wrote:
> > [...]
> > I did another little test to try to better understand your point.  I
> > ran a linux native testsuite under a simulator that just sets SIM to "
> > ".  This resulted in extra ^M's also, although many tests pass because
> > they're already looking for \r\n to accommodate windows.  So I think
> > I've come around to grasp what you've been heroically re-explaining...
> >
> > So if we have to modify every test in the entire testsuite to check
> > for zero or more \r's followed by zero or more \n's, would it be
> > better to add a dg-output-line proc that does this automatically
> > everywhere?
>
> Two problems:  first, you need zero-or-more \r and *one*-or-more \n.
> Second, dg-output is not defined as an anchored match, and therefore
> cannot do this automatically.

"or more" \n is valid?  That would make the rust bug of \r\r\n\n pass
when I assume it shouldn't.

> >   I feel like changing every output pattern test won't be
> > too maintainable.  You had mentioned previously modifying ${tool}_load
> > to filter out extra \r's, but I couldn't see where or how to do that.
> >
> > For completeness, setting a random selection of tests to look for
> > \r*\n? worked (this would cover even deprecated systems that only use
> > CR as well as flagging the weird rust case of \r\r\n\n as bad).
>
> Do not worry about classic Mac OS---running DejaGnu on that platform is
> not possible, nor is it possible to run test programs remotely on that
> platform.  Classic Mac OS is a pure-GUI system with no command interface
> whatsoever.  Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl
> exec(n) command.  Due to limitations of the platform, porting Expect to
> classic Mac OS is simply not possible.  Any compatibility layer would be
> reasonably expected to translate CR<->LF, if, for example, someone wrote
> a telnet server (and associated POSIX-alike environment) for Mac OS.
>
> The later Mac OS X is a quasi-POSIX mostly compatible with the GNU
> system that uses POSIX line endings.  DejaGnu should run normally there.
>
> Are there other systems that used bare CR as end-of-line?  If not, the
> correct pattern is therefore {\r*\n} (here written using braces as
> quotes around the pattern).

Maybe none that matter.  From
https://en.wikipedia.org/wiki/Newline#Representation:

Commodore 8-bit machines (C64, C128), Acorn BBC, ZX Spectrum, TRS-80,
Apple II series, Oberon, the classic Mac OS, MIT Lisp Machine and OS-9

The article also goes on to mention that OpenVMS and RSX-11 can be
configured to use CR.

Re: testsuite under wine

[Jacob Bachmeyer]

NightStrike wrote:
> On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>   
>> NightStrike wrote:
>>     
>>> [...]
>>> I did another little test to try to better understand your point.  I
>>> ran a linux native testsuite under a simulator that just sets SIM to "
>>> ".  This resulted in extra ^M's also, although many tests pass because
>>> they're already looking for \r\n to accommodate windows.  So I think
>>> I've come around to grasp what you've been heroically re-explaining...
>>>
>>> So if we have to modify every test in the entire testsuite to check
>>> for zero or more \r's followed by zero or more \n's, would it be
>>> better to add a dg-output-line proc that does this automatically
>>> everywhere?
>>>       
>> Two problems:  first, you need zero-or-more \r and *one*-or-more \n.
>> Second, dg-output is not defined as an anchored match, and therefore
>> cannot do this automatically.
>>     
>
> "or more" \n is valid?

Only if you are ignoring blank lines.  Note that you had earlier said 
zero-or-more \r and zero-or-more \n, which would be a pattern that can 
match with zero length.

>   That would make the rust bug of \r\r\n\n pass
> when I assume it shouldn't.
>   

The pattern that I suggested as correct is zero-or-more \r followed by 
exactly one \n.  If you are ignoring blank lines in buffered text, but 
/not/ in live Expect, you can use {[\r\n]+} (any non-empty sequence of 
\r and \n) but this will /not/ work with live Expect, because it can 
match a prefix of the intended text.

>>>   I feel like changing every output pattern test won't be
>>> too maintainable.  You had mentioned previously modifying ${tool}_load
>>> to filter out extra \r's, but I couldn't see where or how to do that.
>>>
>>> For completeness, setting a random selection of tests to look for
>>> \r*\n? worked (this would cover even deprecated systems that only use
>>> CR as well as flagging the weird rust case of \r\r\n\n as bad).
>>>       
>> Do not worry about classic Mac OS---running DejaGnu on that platform is
>> not possible, nor is it possible to run test programs remotely on that
>> platform.  Classic Mac OS is a pure-GUI system with no command interface
>> whatsoever.  Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl
>> exec(n) command.  Due to limitations of the platform, porting Expect to
>> classic Mac OS is simply not possible.  Any compatibility layer would be
>> reasonably expected to translate CR<->LF, if, for example, someone wrote
>> a telnet server (and associated POSIX-alike environment) for Mac OS.
>>
>> The later Mac OS X is a quasi-POSIX mostly compatible with the GNU
>> system that uses POSIX line endings.  DejaGnu should run normally there.
>>
>> Are there other systems that used bare CR as end-of-line?  If not, the
>> correct pattern is therefore {\r*\n} (here written using braces as
>> quotes around the pattern).
>>     
>
> Maybe none that matter.  From
> https://en.wikipedia.org/wiki/Newline#Representation:
>
> Commodore 8-bit machines (C64, C128), Acorn BBC, ZX Spectrum, TRS-80,
> Apple II series, Oberon, the classic Mac OS, MIT Lisp Machine and OS-9
>   

DejaGnu is not going to run on any of those, and remote testing with any 
of those as targets gets ... "interesting" ... very quickly.

Oberon, similarly to classic MacOS simply does not have a command line, 
although it /does/ have enough infrastructure that implementing some 
kind of line-oriented command interface could be feasible and some 
Oberon versions do have network capability.  Nonetheless, the entire 
Oberon system is written in its own language, so a testsuite for an 
Oberon target would be expected to be specially written accordingly.

I already mentioned classic MacOS.

Lisp Machines evaluate similarly to Oberon, using their own language for 
all software (in this case, Lisp) with the additional element of being 
highly unlikely to be found outside of a computer museum, having never 
been common.

OS-9 is interesting, but is an oddball nonfree system with niche uses.  
Nonetheless, it does have a shell, so it fits in with the others 
mentioned below.

The rest are various 8-bit systems, where some level of remote testing 
might be possible over a serial line, but see stty(1) and the icrnl and 
inlcr options for that case (the POSIX terminal driver can translate 
incoming CR to LF and vice versa).

> The article also goes on to mention that OpenVMS and RSX-11 can be
> configured to use CR.
>   

Those systems actually store each line as a separate record; the /same/ 
file can be read with LF or CRLF by simply asking, if I read that 
article correctly.


-- Jacob

Re: testsuite under wine

[Jerry D]

On 1/4/23 6:50 PM, NightStrike via Fortran wrote:
> On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>> NightStrike wrote:
>>> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>>>> NightStrike wrote:
>>>>
>>>>> [...]
>>>>> Second, the problems with extra \r's still remain, but I think we've
>>>>> generally come to think that that part isn't Wine and is instead
>>>>> either the testsuite or deja.  So I'll keep those replies to Jacob's
>>>>> previous message.
>>>>>
>>>>>
>>>> Most likely, it is a combination of the MinGW libc (which emits "\r\n"
>>>> for end-of-line in accordance with Windows convention) and the kernel
>>>> terminal driver (which passes "\r" and translates "\n" to "\r\n" in
>>>> accordance with POSIX convention).  Wine, short of trying to translate
>>>> "\r\n" back to "\n" in accordance with POSIX conventions (and likely
>>>> making an even bigger mess---does Wine know if a handle is supposed to
>>>> be text or binary?) cannot really fix this, so the testsuite needs to
>>>> handle non-POSIX-standard line endings.  (The Rust tests probably have
>>>> an outright bug if the newlines are being duplicated.)
>>>>
>>>
>>> You may be onto something here.  I ran wine under script as `script -c
>>> "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r
>>> prepended to the \r\n.  I was making the mistake previously of running
>>> wine manually and capturing it to a file as `wine64 ./a.exe > out`,
>>> which as several have pointed out in this thread, that would disable
>>> the quirk, so of course it didn't reveal any problems.  I'm behind,
>>> but I'll catch up to you guys eventually :)
>>>
>>
>> So close, and yet so far...  script(1) /also/ uses a pty, so it is
>> getting the same translations as Expect and therefore DejaGnu.
>>
>>> So at least we know for sure that this particular instance of extra
>>> characters is coming from Wine.  Maybe Wine can be smart enough to
>>> only translate \n into \r\n instead of translating \r\n into \r\r\n.
>>> Jacek / Eric, comments here?  I'm happy to try another patch, the
>>> first one was great.
>>>
>>
>> I doubt that Wine is doing that translation.  MinGW libc produces output
>> conformant to Windows conventions, so printf("\n") on a text handle
>> emits "\r\n", which Wine passes along.  POSIX convention is that "\n" is
>> translated to "\r\n" in the kernel terminal driver upon output, so the
>> kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
>> "\r\r\n" at the pty master end.  This is why DejaGnu testsuites must be
>> prepared to discard excess carriage returns.  The first CR came from
>> MinGW libc; the second CR came from the kernel terminal driver; the LF
>> was ultimately passed through.
> 
> Jacek and I have been digging into this on IRC, and he's been very
> helpful in trying to get further, but we're still stuck.  We tried to
> be more introspective, inserting strace both as "strace script wine"
> and as "script strace wine".  We tried running just "wine a.exe"
> without any extra glue, and logging the raw SSH packets from putty.
> After many iterations on these and other tests, Jacek finally had the
> idea to try removing Windows entirely from the equation, and we ran
> with a purely unix program / compiler combination:
> 
> #include <unistd.h>
> 
> int main()
> {
>          write(1, "test\r\n", 6);
>          return 0;
> }
> 
> (and also as "test\n", 5)
> 
> In both versions, the following was observed:
> 
> case 1) ./a.out | xxd
> case 2) script -c ./a.out out; xxd out
> case 3) enable putting logging, ./a.out
> 
> In case 1, xxd showed no extra \r's.  In cases 2 and 3, there was an
> extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
> 
> So, is it possible after all of this back and forth regarding mingw,
> wine, and others, that it's down to the write() system call that's
> inserting extra \r's?  Is this expected?

I have reproduced this test with C.  I suspect that the 'write' function 
was written to accommodate non standard behavior of windows which 
expects a CR-LF.  This means that POSIX compliant code is adjusted by 
the C or gfortran libraries to emit a extra CR so that on Windows it 
will just work ok.  So the test is doing exactly what you are telling it 
to do.  An LF causes the run times to add a CR in front.

With libgfortran I remember implementing some of this code myself and 
this is the reason, to keep applications happy on Windows.

So the gfortran tests we wrote to accept either a CR or a CR-LF, and in 
the test code to only issue a normal line ending which on UNIX will be 
an LF and Windows an CR-LF.

I lose track of details in between looking ta the test cases. let me 
know one of them to study that is gfortran side and will see what it is 
doing.

Jerry

Re: testsuite under wine

[Jacob Bachmeyer]

[Bringing the DejaGnu list back into the discussion...]

Jacek Caban wrote:
> Hi all,
>
>
> I'm responsible for Wine changes that cause your problems. I'm also 
> CCing Eric, who is Wine console expert, maybe he has better ideas. 
> Eric, see [1] if you're interested in the context.
>
>
> Recent Wine versions implement Windows pseudo-consoles, see [2] for a 
> bit more details. It's generally Microsoft's semi-recent API that's 
> intended to be more compatible with POSIX than what was present in 
> previous versions of Windows. In theory, with that implemented, we 
> could just plug tty fds that we get from Unix and have Unix consoles 
> working using those Windows APIs.

I would expect that to work very well with MinGW.

> In practice, it's not quite as good as promised and we need some 
> tweaks to make it work nicely. We could improve those tweaks, but 
> there are architectural limitations that will come to play sooner or 
> later.

Of course; "not quite as good as promised" seems to be a typical 
experience with Microsoft and their APIs.

> > I think that the long-term solution is that Wine should properly honor
> > the TERM environment variable and not produce escape codes that the
> > declared terminal does not support.
>
>
> I think that it would not be enough. The way Windows consoles work is 
> that we manage complete internal screen buffer and emit output that 
> synchronizes the buffer with Unix terminal inside conhost.exe process. 
> It means that its output heavily processed and may be very different 
> from what application writes to its console handle. While escape codes 
> discussed in this thread are the most prominent difference (and that 
> part could, in theory, be improved on our side), there are more 
> differences. For example, if application writes "\rA\rB\rC", conhost 
> will process it, update its internal buffer which changes just one 
> character and cursor position, and emit sequence to update it in Unix 
> terminal, which could be just "\rC" (or even "C" if cursor was already 
> at the beginning of the line). Another example would be long lines: 
> conhost will emit additional EOLs instead of depending on embedder to 
> wrap the line.

So conhost is essentially a Wine-specific screen(1) in that sense, 
except that it translates Windows screen buffer manipulations instead of 
VT100 escape codes?  As I understand ncurses also implements most of 
this; perhaps simply delegating output to ncurses would solve the 
problem?  If output were simply delegated to ncurses, (as I understand) 
setting TERM=dumb should be effective to eliminate escape codes from the 
output, since the "dumb" terminal does not support them.

Alternately, could we have a "transparent" mode in conhost where most 
processing is bypassed?  Setting TERM=dumb in the environment could 
reasonably activate this mode, or some other Wine-specific setting could 
be used.  (maybe "WINETERM=raw"?)

> I'm not really familiar with DejaGnu, but if you want to match 
> application output, that's probably not what you're looking for.

DejaGnu is mostly designed to drive text-mode interactive programs 
through simulated user interactions, for which Expect is extremely 
useful, although the tests at issue here are simpler than this general 
case.  Here, the compiler under test is used to build a test program, 
which is then run, its output collected, and that collected output 
compared to an expected pattern.  In Windows terms (as I remember), this 
is equivalent to writing out a batch file that compiles a test program, 
then runs the test program with output redirected to a temporary file, 
running that batch file, and reading/checking the output file.  POSIX 
allows DejaGnu to dispense with the batch file and the output temporary 
file.

(If you think these issues are fun, wait until someone tries to test a 
MinGW port of GDB...)

> The reason the previous workaround of compiling Wine without ncurses 
> worked is that if made Wine treat tty stdin/stdout in a way very 
> similar to regular pipes, so no extra processing was performed. This 
> was more of a side effect than a design choice. It should be possible 
> to provide some way to achieve that with the new Wine architecture. 
> I'm attaching an example of Wine patch that would allow it. With that 
> patch, you may disable conhost.exe (via winecfg or 
> WINEDLLOVERRIDES=conhost.exe=d environment variable) and achieve 
> something similar to previous workaround.

If Wine makes proper use of ncurses, then setting TERM=dumb should have 
the effect of eliminating escape codes from the output.  Why does it not 
do so?

> Long term, I think that it would be best to get rid of console 
> behaviour expectations by using Windows build of DejaGnu. My 
> understanding is that it requires Cygwin, so the stack would be: 
> Windows DejaGnu on Cygwin on Wine on Linux. This would make all 
> similar mismatches in expectations non-existent. Cygwin is tricky to 
> run on Wine, there are a few known problems like [3], but we're 
> getting there.

That could also introduce new problems, since it would be relying on 
Expect's Windows port.  (DejaGnu happens to work on Windows because 
Expect is portable to Windows, or at least Cygwin.)  There are some 
ongoing efforts to reduce gratuitous POSIX dependencies in DejaGnu, i.e. 
to use Tcl's portability aids where appropriate, mostly because using 
[file join $a $b $c] (for example) clearly indicates that $a, $b, and $c 
are file names, while simply [join [list $a $b $c] "/"] or "$a/$b/$c" 
says nothing about the meaning of the operation.

> Jacek
>
>
> [1] https://gcc.gnu.org/pipermail/fortran/2022-December/058645.html
>
> [2] 
> https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ 
>
>
> [3] https://bugs.winehq.org/show_bug.cgi?id=47808


-- Jacob

Re: testsuite under wine

[Eric Pouech]

Le 22/12/2022 à 05:16, Jacob Bachmeyer a écrit :
>
>> I think that it would not be enough. The way Windows consoles work is 
>> that we manage complete internal screen buffer and emit output that 
>> synchronizes the buffer with Unix terminal inside conhost.exe 
>> process. It means that its output heavily processed and may be very 
>> different from what application writes to its console handle. While 
>> escape codes discussed in this thread are the most prominent 
>> difference (and that part could, in theory, be improved on our side), 
>> there are more differences. For example, if application writes 
>> "\rA\rB\rC", conhost will process it, update its internal buffer 
>> which changes just one character and cursor position, and emit 
>> sequence to update it in Unix terminal, which could be just "\rC" (or 
>> even "C" if cursor was already at the beginning of the line). Another 
>> example would be long lines: conhost will emit additional EOLs 
>> instead of depending on embedder to wrap the line.
>
> So conhost is essentially a Wine-specific screen(1) in that sense, 
> except that it translates Windows screen buffer manipulations instead 
> of VT100 escape codes?  As I understand ncurses also implements most 
> of this; perhaps simply delegating output to ncurses would solve the 
> problem?  If output were simply delegated to ncurses, (as I 
> understand) setting TERM=dumb should be effective to eliminate escape 
> codes from the output, since the "dumb" terminal does not support them.

unfortunately, things are not as simple as that: on one hand we need to 
mimic Windows behavior, and on the other hand let apps running in wine 
behave like regular posix applications <g>

(Note: conhost(.exe) is not wine specific, it's part of the way windows 
handle the console input/output)

but I agree that wine should provide a (simple) way to disable windows' 
console for cases like this

>
> Alternately, could we have a "transparent" mode in conhost where most 
> processing is bypassed?  Setting TERM=dumb in the environment could 
> reasonably activate this mode, or some other Wine-specific setting 
> could be used.  (maybe "WINETERM=raw"?)
an alternate solution to Jacob's patch is to run wine with none of the 
fd 0,1,2 opened on a (p)tty (assuming dejagnu doesn't require fd 0 from 
console). So something like ./wine what_ever_you_need | tee /dev/null 
2>1 < /dev/null would do
HTH

Re: testsuite under wine

[Jacob Bachmeyer]

Eric Pouech wrote:
> Le 22/12/2022 à 05:16, Jacob Bachmeyer a écrit :
>>> I think that it would not be enough. The way Windows consoles work 
>>> is that we manage complete internal screen buffer and emit output 
>>> that synchronizes the buffer with Unix terminal inside conhost.exe 
>>> process. It means that its output heavily processed and may be very 
>>> different from what application writes to its console handle. While 
>>> escape codes discussed in this thread are the most prominent 
>>> difference (and that part could, in theory, be improved on our 
>>> side), there are more differences. For example, if application 
>>> writes "\rA\rB\rC", conhost will process it, update its internal 
>>> buffer which changes just one character and cursor position, and 
>>> emit sequence to update it in Unix terminal, which could be just 
>>> "\rC" (or even "C" if cursor was already at the beginning of the 
>>> line). Another example would be long lines: conhost will emit 
>>> additional EOLs instead of depending on embedder to wrap the line.
>>
>> So conhost is essentially a Wine-specific screen(1) in that sense, 
>> except that it translates Windows screen buffer manipulations instead 
>> of VT100 escape codes?  As I understand ncurses also implements most 
>> of this; perhaps simply delegating output to ncurses would solve the 
>> problem?  If output were simply delegated to ncurses, (as I 
>> understand) setting TERM=dumb should be effective to eliminate escape 
>> codes from the output, since the "dumb" terminal does not support them.
>
> unfortunately, things are not as simple as that: on one hand we need 
> to mimic Windows behavior, and on the other hand let apps running in 
> wine behave like regular posix applications <g>
>
> (Note: conhost(.exe) is not wine specific, it's part of the way 
> windows handle the console input/output)

Right.  So that is the name of the program that manages consoles in 
Windows.  I knew it was not cmd.exe itself.  I was testing an 
understanding that conhost.exe in Wine is essentially similar to GNU 
screen, in that both emulate a console/terminal using a *nix terminal.  
If so, then it should be possible to delegate the actual output 
(including reductions like the example "\rA\rB\rC" to "\rC") to the 
ncurses library and get proper sensitivity to TERM "for free" as well.

To do that, conhost.exe would need to translate the Windows console 
buffer manipulations into curses operations, or possibly lower-level 
terminfo operations, if you still want to roll your own optimization 
code.  If this were done, you could check if the current terminal has 
sufficient support to properly emulate a Windows console and switch to 
"raw" mode if the needed terminfo capabilities are not found.  Setting 
TERM=dumb in the environment would then force the use of "raw" mode.

> but I agree that wine should provide a (simple) way to disable 
> windows' console for cases like this

Jacek Caban mentioned Windows pseudo-consoles, apparently a new 
feature.  Would those be a better "fit" for this type of scenario or are 
they considerably more complex than POSIX ptys and the apparent 
equivalence is false?  Does the pseudo-console appear like a regular 
console to the child process or does the child need special support to 
run with a pseudo-console?

>> Alternately, could we have a "transparent" mode in conhost where most 
>> processing is bypassed?  Setting TERM=dumb in the environment could 
>> reasonably activate this mode, or some other Wine-specific setting 
>> could be used.  (maybe "WINETERM=raw"?)
> an alternate solution to Jacob's patch is to run wine with none of the 
> fd 0,1,2 opened on a (p)tty (assuming dejagnu doesn't require fd 0 
> from console). So something like ./wine what_ever_you_need | tee 
> /dev/null 2>1 < /dev/null would do

The problem with this solution in general is that Expect does not 
normally use the shell to spawn subprocesses, although the shell could 
be explicitly invoked (as "/bin/sh -c '...'").  Fortunately, in the 
specific case that is causing this issue at the moment, the programs 
tested are not being run interactively, so it would be possible to use 
Tcl's open(n), which uses a pipe, instead of Expect's spawn, which uses 
a pty.  Running the program is done by a callback in testsuite code, 
rather than the DejaGnu framework itself, so any patch here needs to be 
applied to the testsuite.  Note that this workaround only works for 
non-interactive programs; it will not work when someone decides they 
want to test MinGW GDB using Wine.


-- Jacob

Re: testsuite under wine

[Jacek Caban]

On 12/23/22 04:51, Jacob Bachmeyer wrote:
> Eric Pouech wrote:
>> Le 22/12/2022 à 05:16, Jacob Bachmeyer a écrit :
>>>> I think that it would not be enough. The way Windows consoles work 
>>>> is that we manage complete internal screen buffer and emit output 
>>>> that synchronizes the buffer with Unix terminal inside conhost.exe 
>>>> process. It means that its output heavily processed and may be very 
>>>> different from what application writes to its console handle. While 
>>>> escape codes discussed in this thread are the most prominent 
>>>> difference (and that part could, in theory, be improved on our 
>>>> side), there are more differences. For example, if application 
>>>> writes "\rA\rB\rC", conhost will process it, update its internal 
>>>> buffer which changes just one character and cursor position, and 
>>>> emit sequence to update it in Unix terminal, which could be just 
>>>> "\rC" (or even "C" if cursor was already at the beginning of the 
>>>> line). Another example would be long lines: conhost will emit 
>>>> additional EOLs instead of depending on embedder to wrap the line.
>>>
>>> So conhost is essentially a Wine-specific screen(1) in that sense, 
>>> except that it translates Windows screen buffer manipulations 
>>> instead of VT100 escape codes?  As I understand ncurses also 
>>> implements most of this; perhaps simply delegating output to ncurses 
>>> would solve the problem?  If output were simply delegated to 
>>> ncurses, (as I understand) setting TERM=dumb should be effective to 
>>> eliminate escape codes from the output, since the "dumb" terminal 
>>> does not support them.
>>
>> unfortunately, things are not as simple as that: on one hand we need 
>> to mimic Windows behavior, and on the other hand let apps running in 
>> wine behave like regular posix applications <g>
>>
>> (Note: conhost(.exe) is not wine specific, it's part of the way 
>> windows handle the console input/output)
>
> Right.  So that is the name of the program that manages consoles in 
> Windows.  I knew it was not cmd.exe itself.  I was testing an 
> understanding that conhost.exe in Wine is essentially similar to GNU 
> screen, in that both emulate a console/terminal using a *nix 
> terminal.  If so, then it should be possible to delegate the actual 
> output (including reductions like the example "\rA\rB\rC" to "\rC") to 
> the ncurses library and get proper sensitivity to TERM "for free" as 
> well.
>
> To do that, conhost.exe would need to translate the Windows console 
> buffer manipulations into curses operations, or possibly lower-level 
> terminfo operations, if you still want to roll your own optimization 
> code.  If this were done, you could check if the current terminal has 
> sufficient support to properly emulate a Windows console and switch to 
> "raw" mode if the needed terminfo capabilities are not found.  Setting 
> TERM=dumb in the environment would then force the use of "raw" mode.


Yes, an analogy to screen is right in many aspects, but there are also 
architectural difference that require implementation to be very 
different. ncurses operates on tty file descriptors backed by OS kernel. 
conhost needs to be able to operate on Windows names pipes, which are 
not associated with any file descriptor in Wine.


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). 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.


Jacek

Re: testsuite under wine

[Jacob Bachmeyer]

Jacek Caban wrote:
> On 12/23/22 04:51, Jacob Bachmeyer wrote:
>> Eric Pouech wrote:
>>> Le 22/12/2022 à 05:16, Jacob Bachmeyer a écrit :
>>>>> I think that it would not be enough. The way Windows consoles work 
>>>>> is that we manage complete internal screen buffer and emit output 
>>>>> that synchronizes the buffer with Unix terminal inside conhost.exe 
>>>>> process. It means that its output heavily processed and may be 
>>>>> very different from what application writes to its console handle. 
>>>>> While escape codes discussed in this thread are the most prominent 
>>>>> difference (and that part could, in theory, be improved on our 
>>>>> side), there are more differences. For example, if application 
>>>>> writes "\rA\rB\rC", conhost will process it, update its internal 
>>>>> buffer which changes just one character and cursor position, and 
>>>>> emit sequence to update it in Unix terminal, which could be just 
>>>>> "\rC" (or even "C" if cursor was already at the beginning of the 
>>>>> line). Another example would be long lines: conhost will emit 
>>>>> additional EOLs instead of depending on embedder to wrap the line.
>>>>
>>>> So conhost is essentially a Wine-specific screen(1) in that sense, 
>>>> except that it translates Windows screen buffer manipulations 
>>>> instead of VT100 escape codes?  As I understand ncurses also 
>>>> implements most of this; perhaps simply delegating output to 
>>>> ncurses would solve the problem?  If output were simply delegated 
>>>> to ncurses, (as I understand) setting TERM=dumb should be effective 
>>>> to eliminate escape codes from the output, since the "dumb" 
>>>> terminal does not support them.
>>>
>>> unfortunately, things are not as simple as that: on one hand we need 
>>> to mimic Windows behavior, and on the other hand let apps running in 
>>> wine behave like regular posix applications <g>
>>>
>>> (Note: conhost(.exe) is not wine specific, it's part of the way 
>>> windows handle the console input/output)
>>
>> Right.  So that is the name of the program that manages consoles in 
>> Windows.  I knew it was not cmd.exe itself.  I was testing an 
>> understanding that conhost.exe in Wine is essentially similar to GNU 
>> screen, in that both emulate a console/terminal using a *nix 
>> terminal.  If so, then it should be possible to delegate the actual 
>> output (including reductions like the example "\rA\rB\rC" to "\rC") 
>> to the ncurses library and get proper sensitivity to TERM "for free" 
>> as well.
>>
>> To do that, conhost.exe would need to translate the Windows console 
>> buffer manipulations into curses operations, or possibly lower-level 
>> terminfo operations, if you still want to roll your own optimization 
>> code.  If this were done, you could check if the current terminal has 
>> sufficient support to properly emulate a Windows console and switch 
>> to "raw" mode if the needed terminfo capabilities are not found.  
>> Setting TERM=dumb in the environment would then force the use of 
>> "raw" mode.
>
>
> Yes, an analogy to screen is right in many aspects, but there are also 
> architectural difference that require implementation to be very 
> different. ncurses operates on tty file descriptors backed by OS 
> kernel. conhost needs to be able to operate on Windows names pipes, 
> which are not associated with any file descriptor in Wine.

Please explain this.  Programs using curses make calls into the curses 
library, which ultimately produces I/O on a tty file descriptor.  It 
seems to me that conhost is in the same position as the curses library:  
programs use Windows API calls for the console which [...across an IPC 
bridge of some type?...] result in dispatches in conhost that ultimately 
produce I/O on a tty file descriptor.  Does conhost not actually hold 
the file descriptor, instead performing translations and sending the 
result back to the client process, which writes it out?

If full curses is not usable for architectural reasons, terminfo would 
still be an improvement.  Its setupterm() call may send any known init 
strings, but it could be given either the write end of a pipe or a file 
descriptor open on /dev/null if that is a problem.  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.

> 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.

2.  Programs using Windows CUI probably should be mapped to curses; as I 
see it, conhost currently is implementing a subset of curses, poorly 
since it does not use terminfo.  Wine should use curses if $TERM 
supports curses and either pop up an X11 Wine console window or bail out 
if a CUI call is made and $TERM does not support curses.  (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.)

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.)

Finding that NightStrike's MinGW test cases are transparently using CUI 
would be a MinGW issue, not a Wine issue.

It has been a long time since I have looked at Windows API, but I am 
guessing that there is both some equivalent to "fwrite(stdout, ...)" 
(ok, so likely something like 
"WriteToHandle(GetStandardHandle(STANDARD_HANDLE_OUTPUT),...)" if I 
remember the Windows API "style" and its affinity for RSI-supporting 
names correctly) and a more complex API for CUI that is more closely 
akin to curses.  Could you delay initializing conhost until the program 
actually attempts to use CUI features?  For this option, CUIInit() ends 
up calling newterm() and using curses if that succeeds, (possibly, after 
considerable future implementation effort) popping up a Wine console 
window using X11 if $DISPLAY is usable, or bailing out if neither way to 
get a full Windows console works.  Until CUIInit() is called, the 
standard handles are just that and simply mapped through to the 
underlying POSIX handles.

Is this architecturally feasible for Wine to do?


-- Jacob

Re: testsuite under wine

[Jacek Caban]

[-- Attachment #1: Type: text/plain, Size: 10754 bytes --]

Hi Jacob,

Sorry for the delay.

On 12/24/22 06:33, Jacob Bachmeyer wrote:
> Jacek Caban wrote:
>> On 12/23/22 04:51, Jacob Bachmeyer wrote:
>>> Eric Pouech wrote:
>>>> Le 22/12/2022 à 05:16, Jacob Bachmeyer a écrit :
>>>>>> I think that it would not be enough. The way Windows consoles 
>>>>>> work is that we manage complete internal screen buffer and emit 
>>>>>> output that synchronizes the buffer with Unix terminal inside 
>>>>>> conhost.exe process. It means that its output heavily processed 
>>>>>> and may be very different from what application writes to its 
>>>>>> console handle. While escape codes discussed in this thread are 
>>>>>> the most prominent difference (and that part could, in theory, be 
>>>>>> improved on our side), there are more differences. For example, 
>>>>>> if application writes "\rA\rB\rC", conhost will process it, 
>>>>>> update its internal buffer which changes just one character and 
>>>>>> cursor position, and emit sequence to update it in Unix terminal, 
>>>>>> which could be just "\rC" (or even "C" if cursor was already at 
>>>>>> the beginning of the line). Another example would be long lines: 
>>>>>> conhost will emit additional EOLs instead of depending on 
>>>>>> embedder to wrap the line.
>>>>>
>>>>> So conhost is essentially a Wine-specific screen(1) in that sense, 
>>>>> except that it translates Windows screen buffer manipulations 
>>>>> instead of VT100 escape codes?  As I understand ncurses also 
>>>>> implements most of this; perhaps simply delegating output to 
>>>>> ncurses would solve the problem?  If output were simply delegated 
>>>>> to ncurses, (as I understand) setting TERM=dumb should be 
>>>>> effective to eliminate escape codes from the output, since the 
>>>>> "dumb" terminal does not support them.
>>>>
>>>> unfortunately, things are not as simple as that: on one hand we 
>>>> need to mimic Windows behavior, and on the other hand let apps 
>>>> running in wine behave like regular posix applications <g>
>>>>
>>>> (Note: conhost(.exe) is not wine specific, it's part of the way 
>>>> windows handle the console input/output)
>>>
>>> Right.  So that is the name of the program that manages consoles in 
>>> Windows.  I knew it was not cmd.exe itself.  I was testing an 
>>> understanding that conhost.exe in Wine is essentially similar to GNU 
>>> screen, in that both emulate a console/terminal using a *nix 
>>> terminal.  If so, then it should be possible to delegate the actual 
>>> output (including reductions like the example "\rA\rB\rC" to "\rC") 
>>> to the ncurses library and get proper sensitivity to TERM "for free" 
>>> as well.
>>>
>>> To do that, conhost.exe would need to translate the Windows console 
>>> buffer manipulations into curses operations, or possibly lower-level 
>>> terminfo operations, if you still want to roll your own optimization 
>>> code.  If this were done, you could check if the current terminal 
>>> has sufficient support to properly emulate a Windows console and 
>>> switch to "raw" mode if the needed terminfo capabilities are not 
>>> found.  Setting TERM=dumb in the environment would then force the 
>>> use of "raw" mode.
>>
>>
>> Yes, an analogy to screen is right in many aspects, but there are 
>> also architectural difference that require implementation to be very 
>> different. ncurses operates on tty file descriptors backed by OS 
>> kernel. conhost needs to be able to operate on Windows names pipes, 
>> which are not associated with any file descriptor in Wine.
>
> Please explain this.  Programs using curses make calls into the curses 
> library, which ultimately produces I/O on a tty file descriptor.  It 
> seems to me that conhost is in the same position as the curses 
> library:  programs use Windows API calls for the console which 
> [...across an IPC bridge of some type?...] result in dispatches in 
> conhost that ultimately produce I/O on a tty file descriptor.  Does 
> conhost not actually hold the file descriptor, instead performing 
> translations and sending the result back to the client process, which 
> writes it out?


There may be no file descriptor as far as conhost is concerned, it 
operates on generic Windows handles. For example, named pipes are purely 
a wineserver object (a shared process implementing some of kernel-alike 
tasks via IPC), there is no file descriptor involved. But when a file 
descriptor is available, it's optimized so that conhost holds fd and 
writes to it directly. It's an implementation details of a different layer.


> If full curses is not usable for architectural reasons, terminfo would 
> still be an improvement.  Its setupterm() call may send any known init 
> strings, but it could be given either the write end of a pipe or a 
> file descriptor open on /dev/null if that is a problem.


See above, there may be no fd, so curses does not solve the problem.


> 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.


>> 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?).


> (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 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).


>
> Finding that NightStrike's MinGW test cases are transparently using 
> CUI would be a MinGW issue, not a Wine issue.
>
> It has been a long time since I have looked at Windows API, but I am 
> guessing that there is both some equivalent to "fwrite(stdout, ...)" 
> (ok, so likely something like 
> "WriteToHandle(GetStandardHandle(STANDARD_HANDLE_OUTPUT),...)" if I 
> remember the Windows API "style" and its affinity for RSI-supporting 
> names correctly) and a more complex API for CUI that is more closely 
> akin to curses.  Could you delay initializing conhost until the 
> program actually attempts to use CUI features? For this option, 
> CUIInit() ends up calling newterm() and using curses if that succeeds, 
> (possibly, after considerable future implementation effort) popping up 
> a Wine console window using X11 if $DISPLAY is usable, or bailing out 
> if neither way to get a full Windows console works.  Until CUIInit() 
> is called, the standard handles are just that and simply mapped 
> through to the underlying POSIX handles.
>
> Is this architecturally feasible for Wine to do? 


No, at least not without ugly hacks. Some decisions need to be made 
early, conhost can't just miss the first part of output. Going straight 
to conhost for handling POSIX tty so that console works as expected by 
Windows applications is what users want. Even if application doesn't 
need full compatibility, conhost still does the job (except for this 
very specific use case).


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.


Thanks,

Jacek

[-- Attachment #2: conhost.diff --]
[-- Type: text/x-patch, Size: 522 bytes --]

diff --git a/programs/conhost/conhost.c b/programs/conhost/conhost.c
index 769f998f404..dd04640d570 100644
--- a/programs/conhost/conhost.c
+++ b/programs/conhost/conhost.c
@@ -195,7 +195,7 @@ static void *tty_alloc_buffer( struct console *console, size_t size )
 
 static void hide_tty_cursor( struct console *console )
 {
-    if (console->tty_cursor_visible)
+    if (console->tty_cursor_visible && !console->is_unix)
     {
         tty_write(  console, "\x1b[?25l", 6 );
         console->tty_cursor_visible = FALSE;

Re: testsuite under wine

[Jacob Bachmeyer]

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

Re: testsuite under wine

[Jacek Caban]

Hi Jacob,

On 1/7/23 04:58, Jacob Bachmeyer wrote:
>> 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.


Yes, that's something we should look into.


>>>> 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.


>> [...]
>>
>> 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. 


Sure, I'd be interested how well my latest patch works for NightStrike. 
It should give us overview about how much conhost interferes with test 
results in practice when we get easy stuff out of the way.


Thanks,

Jacek

Re: testsuite under wine

[NightStrike]

On Mon, Jan 9, 2023 at 11:05 AM Jacek Caban <jacek@codeweavers.com> wrote:
> Sure, I'd be interested how well my latest patch works for NightStrike.
> It should give us overview about how much conhost interferes with test
> results in practice when we get easy stuff out of the way.

Generally, more tests run and pass, but most still fail for different
reasons.  IOW, the cursor hiding escapes are gone, but the EOLs still
don't match until we modify the tests themselves.  Here are the result
summaries, full logs available to anyone who wants them.

Unmodified Wine 7.20:
                === gcc Summary ===

# of expected passes            166686
# of unexpected failures        1865
# of unexpected successes       12
# of expected failures          1226
# of unresolved testcases       787
# of unsupported tests          3111

                === gfortran Summary ===

# of expected passes            66391
# of unexpected failures        637
# of unexpected successes       8
# of expected failures          257
# of unresolved testcases       6
# of unsupported tests          247

                === g++ Summary ===

# of expected passes            218092
# of unexpected failures        1410
# of unexpected successes       4
# of expected failures          2149
# of unresolved testcases       63
# of unsupported tests          11318

                === gm2 Summary ===

# of expected passes            7126
# of unexpected failures        2563
# of unresolved testcases       2065

                === libatomic Summary ===

# of expected passes            53
# of unexpected failures        1

                === libstdc++ Summary ===

# of expected passes            14139
# of unexpected failures        474
# of unexpected successes       2
# of expected failures          98
# of unresolved testcases       1
# of unsupported tests          835

                === rust Summary ===

# of expected passes            4565
# of unexpected failures        403
# of expected failures          39


Modified Wine 7.20 using your latest one liner patch:
                === gcc Summary ===

# of expected passes            168207
# of unexpected failures        1867
# of unexpected successes       12
# of expected failures          1235
# of unresolved testcases       760
# of unsupported tests          3118

                === gfortran Summary ===

# of expected passes            66409
# of unexpected failures        619
# of unexpected successes       8
# of expected failures          257
# of unresolved testcases       6
# of unsupported tests          247

                === g++ Summary ===

# of expected passes            220403
# of unexpected failures        1116
# of unexpected successes       4
# of expected failures          2063
# of unresolved testcases       47
# of unsupported tests          10978

                === gm2 Summary ===

# of expected passes            7126
# of unexpected failures        2563
# of unresolved testcases       2065

                === libatomic Summary ===

# of expected passes            53
# of unexpected failures        1
runtest completed at Tue Jan 10 00:05:49 2023

                === libstdc++ Summary ===

# of expected passes            14139
# of unexpected failures        474
# of unexpected successes       2
# of expected failures          98
# of unresolved testcases       1
# of unsupported tests          835

                === rust Summary ===

# of expected passes            4568
# of unexpected failures        394
# of expected failures          39

Re: testsuite under wine

[NightStrike]

Better presentation thanks to Jacob

On Tue, Jan 10, 2023 at 4:19 AM NightStrike <nightstrike@gmail.com> wrote:
>
> On Mon, Jan 9, 2023 at 11:05 AM Jacek Caban <jacek@codeweavers.com> wrote:
> > Sure, I'd be interested how well my latest patch works for NightStrike.
> > It should give us overview about how much conhost interferes with test
> > results in practice when we get easy stuff out of the way.
>
> Generally, more tests run and pass, but most still fail for different
> reasons.  IOW, the cursor hiding escapes are gone, but the EOLs still
> don't match until we modify the tests themselves.  Here are the result
> summaries, full logs available to anyone who wants them.
>
> Unmodified Wine 7.20:

            __________________________________________________
           /    PASS   FAIL  ?PASS  ?FAIL  UNSUP  UNRES UNTEST
           |--------------------------------------------------
      gcc  |  166638   1765     12   1226   3107    787      0 !E!
 gfortran  |   64445    608      8    238    247      6      0
      gm2  |    7126   2563      0      0      0   2065      0
      g++  |  217936   1336      4   2144  11318     63      0 !E! !W!
libatomic  |      53      1      0      0      0      0      0 !W!
libstdc++  |   14139    263      2     93    835      1      0
     rust  |    4185    403      0     39      0      0      0 !W!
           |--------------------------------------------------
           |  474522   6939     26   3740  15507   2922      0
           \__________________________________________________

> Modified Wine 7.20 using your latest one liner patch:

            __________________________________________________
           /    PASS   FAIL  ?PASS  ?FAIL  UNSUP  UNRES UNTEST
           |--------------------------------------------------
      gcc  |  168207   1867     12   1235   3118    760      0 !E! !W!
 gfortran  |   66403    619      8    257    247      6      0 !W!
      gm2  |    7126   2563      0      0      0   2065      0
      g++  |  220403   1116      4   2063  10978     47      0 !E! !W!
libatomic  |      53      1      0      0      0      0      0 !W!
libstdc++  |   14139    474      2     98    835      1      0 !W!
     rust  |    4568    394      0     39      0      0      0 !W!
           |--------------------------------------------------
           |  480899   7034     26   3692  15178   2879      0
           \__________________________________________________

Re: testsuite under wine

[NightStrike]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

On Tue, Jan 10, 2023, 04:19 NightStrike <nightstrike@gmail.com> wrote:

> On Mon, Jan 9, 2023 at 11:05 AM Jacek Caban <jacek@codeweavers.com> wrote:
> > Sure, I'd be interested how well my latest patch works for NightStrike.
> > It should give us overview about how much conhost interferes with test
> > results in practice when we get easy stuff out of the way.
>
> Generally, more tests run and pass, but most still fail for different
> reasons.  IOW, the cursor hiding escapes are gone, but the EOLs still
> don't match until we modify the tests themselves.
>

Quick update that I found more tests that fail with what I assume are Wine
escape codes, K and C. (Ie ^[[K).  I can't figure out under what context
they appear, and I don't know what they are for.

>

Re: testsuite under wine

[NightStrike]

On Wed, Jan 11, 2023 at 1:41 PM NightStrike <nightstrike@gmail.com> wrote:
>
>
>
> On Tue, Jan 10, 2023, 04:19 NightStrike <nightstrike@gmail.com> wrote:
>>
>> On Mon, Jan 9, 2023 at 11:05 AM Jacek Caban <jacek@codeweavers.com> wrote:
>> > Sure, I'd be interested how well my latest patch works for NightStrike.
>> > It should give us overview about how much conhost interferes with test
>> > results in practice when we get easy stuff out of the way.
>>
>> Generally, more tests run and pass, but most still fail for different
>> reasons.  IOW, the cursor hiding escapes are gone, but the EOLs still
>> don't match until we modify the tests themselves.
>
>
> Quick update that I found more tests that fail with what I assume are Wine escape codes, K and C. (Ie ^[[K).  I can't figure out under what context they appear, and I don't know what they are for.

With Jacek's latest patch:

            __________________________________________________
           /    PASS   FAIL  ?PASS  ?FAIL  UNSUP  UNRES UNTEST
           |--------------------------------------------------
    acats  |       0      0      0      0      0      0      0
      gcc  |  164293   1652      6   1150   3213    810      0 !E! !W!
      gdc  |    4167   1658      0      0   1553    121      0
 gfortran  |   66811    210      8    257    247      0      0 !W!
      gm2  |    1168   6673      0      0      0   2065      0
     gnat  |    3360     24      0     23     14      0      0 !W!
      g++  |  226182   1314      4   2346  10900     89      0 !E! !W!
libatomic  |      53      1      0      0      0      0      0 !W!
libstdc++  |   14563     50     26     74    835      1      0 !W!
  obj-c++  |    1502      8      1      1     79      0      0 !W!
     objc  |    1882      9      0      6     70     10      0 !E!
     rust  |    4148    432      0     39      0      0      0 !W!
           |--------------------------------------------------
           |  488129  12031     45   3896  16911   3096      0
           \__________________________________________________

We're making good progress here!

(Note that the numbers above for rust are for the gcc master branch,
but every line ending failure is fixed on the rust dev branch, leaving
only 1 actual bug)

Re: testsuite under wine

[Jacob Bachmeyer]

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

Re: testsuite under wine

[NightStrike]

On Fri, Jan 6, 2023 at 8:46 PM Jacek Caban <jacek@codeweavers.com> wrote:

> 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).

I can confirm that with this patch, the "^[[?25l" sequences are gone
and ^M^M still remains.  So at least this is a less intrusive version
of the first patch that can hopefully be easily upstreamed.

Re: testsuite under wine

[Pedro Alves]

On 2022-12-23 3:51 a.m., Jacob Bachmeyer wrote:
> it will not work when someone decides they want to test MinGW GDB using Wine.

This has been on my wish list for years.  Unfortunately, I can't even get plain cross-compiled MinGW GDB
working properly on a Linux/Bash terminal, as I can't get it (I guess readline) to recognize/accept lines
of input.

E.g., on Ubuntu 22.04, with system Wine ('wine-6.0.3 (Ubuntu 6.0.3~repack-1)') :

$ 
$ wine ./gdb.exe 
...
This GDB was configured as "x86_64-w64-mingw32".
...
(gdb) foobar<ret>
                       << a new line is printed 
                       << more <ret>
                       << C-j is the same
^CQuit                 << ctrl-c works
(gdb)  

^Z
[2]+  Stopped                 wine ./gdb.exe
$ killall gdb.exe

( I've tried this occasionally in the past decade, always with the same result. )

If someone knows a workaround for this, I'd be curious to learn about it.  :-)

Last time I tried, GDBserver worked OK under Wine, and I could connect ("(gdb) target remote ...") a
linux-hosted GDB built with cross Windows debugging support to that GDBserver and debug fine.  So
the Windows debug API seemed to work well enough under Wine, which seemed quite promising.  It's just
the native Windows GDB (and the Windows readline port, I guess) that doesn't seem to accept/recognize
newlines for some reason.  I figure that once we're past that hurdle, testing MinGW GDB under Wine under
linux-hosted DejaGnu would become possible...

Pedro Alves

Re: testsuite under wine

[Eric Pouech]

Le 04/01/2023 à 16:21, Pedro Alves a écrit :
> On 2022-12-23 3:51 a.m., Jacob Bachmeyer wrote:
>> it will not work when someone decides they want to test MinGW GDB using Wine.
> This has been on my wish list for years.  Unfortunately, I can't even get plain cross-compiled MinGW GDB
> working properly on a Linux/Bash terminal, as I can't get it (I guess readline) to recognize/accept lines
> of input.
>
> E.g., on Ubuntu 22.04, with system Wine ('wine-6.0.3 (Ubuntu 6.0.3~repack-1)') :

hi

they've been a couple of improvements in Wine 7.x that will help here

so upgrading might be a solution (wine 8.0 is likely to be released by 
the end of this month...). wine 6.x tree is two year old :-(

(notepad is wine's notepad)

-------------------------------------------

[eric:~/work/output-wine/wine64]$ ./wine --version
wine-8.0-rc2-14-g48c0a75432b
[eric:~/work/output-wine/wine64]$ ./wine 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/gdb.exe notepad
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
     <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from notepad...
(gdb) b WinMain
Breakpoint 1 at 0x140005280: file 
/home/eric/work/wine/programs/notepad/main.c, line 845.
(gdb) run
Starting program: C:\windows\system32\notepad.exe

Breakpoint 1, WinMain (hInstance=0x140000000, prev=prev@entry=0x0, 
cmdline=cmdline@entry=0x34a3b2 "", show=show@entry=1) at 
/home/eric/work/wine/programs/notepad/main.c:845
845     {
(gdb) bt
#0  WinMain (hInstance=0x140000000, prev=prev@entry=0x0, 
cmdline=cmdline@entry=0x34a3b2 "", show=show@entry=1) at 
/home/eric/work/wine/programs/notepad/main.c:845
#1  0x0000000140006d25 in main (argc=<optimized out>, argv=<optimized 
out>) at /home/eric/work/wine/dlls/msvcrt/crt_winmain.c:53
(gdb) b CreateWindowExW
Breakpoint 2 at 0x216a25ee0: CreateWindowExW. (2 locations)
(gdb) c
Continuing.

Breakpoint 2, 0x0000000216a25ee0 in CreateWindowExW () at 
/home/eric/work/wine/dlls/user32/win.c:443
443     }
(gdb) bt
#0  0x0000000216a25ee0 in CreateWindowExW () at 
/home/eric/work/wine/dlls/user32/win.c:443
#1  0x000000014000560a in WinMain (hInstance=0x140000000, 
prev=prev@entry=0x0, cmdline=cmdline@entry=0x34a3b2 "", 
show=show@entry=1) at /home/eric/work/wine/programs/notepad/main.c:893
#2  0x0000000140006d25 in main (argc=<optimized out>, argv=<optimized 
out>) at /home/eric/work/wine/dlls/msvcrt/crt_winmain.c:53
(gdb) q
A debugging session is active.

         Inferior 1 [process 508] will be killed.

Quit anyway? (y or n) y
[eric:~/work/output-wine/wine64]$

Re: testsuite under wine

[Pedro Alves]

On 2023-01-04 3:45 p.m., Eric Pouech wrote:
> Le 04/01/2023 à 16:21, Pedro Alves a écrit :
>> On 2022-12-23 3:51 a.m., Jacob Bachmeyer wrote:
>>> it will not work when someone decides they want to test MinGW GDB using Wine.
>> This has been on my wish list for years.  Unfortunately, I can't even get plain cross-compiled MinGW GDB
>> working properly on a Linux/Bash terminal, as I can't get it (I guess readline) to recognize/accept lines
>> of input.
>>
>> E.g., on Ubuntu 22.04, with system Wine ('wine-6.0.3 (Ubuntu 6.0.3~repack-1)') :
> 
> hi
> 
> they've been a couple of improvements in Wine 7.x that will help here
> 
> so upgrading might be a solution (wine 8.0 is likely to be released by the end of this month...). wine 6.x tree is two year old :-(

...

> 
> (notepad is wine's notepad)
> 
> -------------------------------------------
> 
> [eric:~/work/output-wine/wine64]$ ./wine --version
> wine-8.0-rc2-14-g48c0a75432b
> [eric:~/work/output-wine/wine64]$ ./wine /usr/x86_64-w64-mingw32/sys-root/mingw/bin/gdb.exe notepad
> GNU gdb (GDB) 12.1

(snip gdb working as expected)

Woo, awesome & finally!  Thanks a lot.