<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Le 31/03/2022 à 20:16, Alexandre
      Julliard a écrit :<br>
    </div>
    <blockquote type="cite" cite="mid:87ilrung27.fsf@wine">
      <pre class="moz-quote-pre" wrap="">Francois Gouget <a class="moz-txt-link-rfc2396E" href="mailto:fgouget@codeweavers.com"><fgouget@codeweavers.com></a> writes:

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Signed-off-by: Francois Gouget <a class="moz-txt-link-rfc2396E" href="mailto:fgouget@codeweavers.com"><fgouget@codeweavers.com></a>

That's great. I can now reproduce these failures.
The easiest way to do so from a terminal is something like this:

  nohup ./wine ... 2>&1 | cat

With this winetest patch user32:input succeeds... sometimes.
I don't think this means the patch is wrong.

Rather the issue is that user32:input itself 'forks' without passing 
DETACHED_PROCESS to CreateProcess(), causing consoles to appear in the 
middle of the test which randomly leads to failures.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Do these consoles also appear on Windows then?

</pre>
    </blockquote>
    <p><font face="Helvetica, Arial, sans-serif">basically we should
        have the following hierarchy of processes (for a testbot
        invocation)<br>
      </font></p>
    <p><font face="Helvetica, Arial, sans-serif">  testagentd
        Unix/windows<br>
           \- TestLauncher (CUI)<br>
              \- unit test (CUI)<br>
                 \- unit test can recurse upon itself (CUI)<br>
        <br>
      </font></p>
    <p><font face="Helvetica, Arial, sans-serif">according to
<a class="moz-txt-link-freetext" href="https://testbot.winehq.org/JobDetails.pl?Key=111732&f201=exe64.report&f301=task.log#k301">https://testbot.winehq.org/JobDetails.pl?Key=111732&f201=exe64.report&f301=task.log#k301</a></font></p>
    <p><font face="Helvetica, Arial, sans-serif">(it's a program to
        output various information about console (attached / detached,
        other processes attached to console, user32 information about
        console, info about std handles...)</font></p>
    <p><font face="Helvetica, Arial, sans-serif">the info is written
        using various ways (prefix gives the way: w> using write(1),
        W> using WriteFile(STD_OUTPUT_HANDLE), d>
        wine_dbg_output...)</font></p>
    <p><font face="Helvetica, Arial, sans-serif"><br>
      </font></p>
    <p>a) when the console is created</p>
    <p>under Windows, the console is created when TestLaunched is
      spawned. Seems logical: first CUI process, testagentd is likely
      run detached.</p>
    <p>in wine env, the console is created at least for the unit test
      (test as written cannot get information from testlauncher back)</p>
    <p>as testagentd (on unix) is likely detached (from unix tty),
      TestLauncher is then created detached from unix but also windows
      standpoint ; meaning the the w-console is only created for unit
      test.</p>
    <p>in both cases, the respawn from within the unit test should reuse
      the same console</p>
    <p>b) it then means that the unit test (because it's launched with
      console creation) does not (currently) honor the std handle
      inheritance (hence providing different output information)<br>
    </p>
    <p>that would explain the discrepancies on output prefix (windows
      with wW> as those handles are inherited from TestLauncher), and
      wine (d> using unix fd 1)</p>
    <p>(under the assumption that in both wine and windows the
      redirection for running a tests are done in a similar way)</p>
    <p><br>
    </p>
    <p>we exchanged with Jacek what to do when wine foo is started as
      initial wine process and foo is a CUI</p>
    <p>on one hand, it would be a bad idea to let CreateProcess create a
      console. cases when script is run in a headless context, or
      detached from any tty...<br>
    </p>
    <p>on the other hand (as this case shows), not creating a console is
      not always the best situation<br>
    </p>
    <p><br>
    </p>
    <p>from these considerations, I would recommand that we mimic
      windows' behavior: when run under wine only, testagend should
      spawn TestLauncher with wineconsole (we know we can force a
      user32/wine console creation):</p>
    <p>./wine wineconsole TestLauncher... (instead of ./wine
      TestLauncher)</p>
    <p><br>
    </p>
    <p>François: what would be the best way to do it? (tweaking
      platform_unix/platform_run() seems to be more widely used than
      just running wine?</p>
    <p><br>
    </p>
    <p>A+<br>
    </p>
    <p><br>
    </p>
  </body>
</html>