<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 4/5/22 17:00, Eric Pouech wrote:<br>
</div>
<blockquote type="cite"
cite="mid:98626607-f5cd-73d0-344f-20f305442e7b@orange.fr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Le 05/04/2022 à 14:34, Jacek Caban a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:551f158f-6eba-54a9-963e-c401ae73d79a@codeweavers.com">
<br>
Based on patches by Eric Pouech and Torge Matthies. <br>
<br>
Signed-off-by: Jacek Caban <a class="moz-txt-link-rfc2396E"
href="mailto:jacek@codeweavers.com" moz-do-not-send="true"><jacek@codeweavers.com></a>
<br>
--- <br>
Both Eric and Torge sent patches for this and both used
ConsoleFlags for passing the information. While reviewing both
series, I was wondering if using ConsoleHandle instead would be
cleaner and I think it is. I ended up having a complete third
version... <br>
<br>
Eric, Torge, I hope you will review this. <br>
<br>
dlls/kernel32/tests/console.c | 3 --- <br>
dlls/kernelbase/console.c | 21 +++++++++++++++------ <br>
dlls/kernelbase/process.c | 11 +++++++---- <br>
include/wine/condrv.h | 5 +++-- <br>
programs/conhost/conhost.c | 11 ++++++++--- <br>
programs/conhost/conhost.h | 1 + <br>
6 files changed, 34 insertions(+), 18 deletions(-) <br>
<br>
</blockquote>
<p><font face="Helvetica, Arial, sans-serif">two comments:</font></p>
<p><font face="Helvetica, Arial, sans-serif">- the value for
ConsoleHandle in child process for a GUI exec is not
consistent depending on passed flags:</font></p>
<p><font face="Helvetica, Arial, sans-serif"> + it's going to be
0 value when CREATE_NO_WINDOW is passed</font></p>
<p><font face="Helvetica, Arial, sans-serif"> + it's value is
untouched when 0 is passed (at least none of CREATE_NO_WINDOW,
DETACH_PROCESS, CREATE_NEW_CONSOLE)</font></p>
<p><font face="Helvetica, Arial, sans-serif">under windows, it's
always zeroed out (as the remaining todo_wine in
test_CreateProcessCUI shows)<br>
</font></p>
<font face="Helvetica, Arial, sans-serif">the attached (modified)
patch implements this behavior; but it's quite a change...<br>
</font></blockquote>
<p><br>
</p>
<p>Yes, it's quite a change, but since we already opened that can of
worms, I think we should handle that case properly as well.
Handling GUI processes deserves a separated patch, I was hoping
that you could follow up with that fix.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:98626607-f5cd-73d0-344f-20f305442e7b@orange.fr"><font
face="Helvetica, Arial, sans-serif"></font>
<p><font face="Helvetica, Arial, sans-serif">- just for the
record: I wonder if in dlls/ntdll/unix/process.c we shouldn't
also detach from the unix controling terminal in
CONSOLE_HANDLE_ALLOC_NO_WINDOW case (but it would be impacting
with next patch as ctrl-c would no longer be working). so I'd
say no</font></p>
</blockquote>
<p><br>
</p>
<p>Good point, I missed that part.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:98626607-f5cd-73d0-344f-20f305442e7b@orange.fr">
<p><font face="Helvetica, Arial, sans-serif"></font>this 'next' -
aka third - patch, just creates a window less console in some
cases for an initial process and should fix (or at least
improve) a couple of open bugs </p>
<p>(to make it short, in scenario like "wine foo >& log
< /dev/null", it prevents foo and the subprocesses when in
cui subsystem to create visible consoles)<br>
</p>
<p>(just to share it here)</p>
</blockquote>
<p><br>
</p>
<p>To recap our private conversation, there are nice things about
that solution: it makes such invocation more similar to a more
common situation on Windows and I like that aspect. My main
concern is that it will make invoking Wine in situations when
there is no Unix console available much more expensive, because
we'd need to create an extra conhost process that would be useless
in majority of cases. I know that we have some users using Wine as
part of their Unix scripts, likely ran in the background, for whom
it's likely to provide worse performance due to need to create
twice as many Wine processes. It may not be a deal breaker, but I
think it's a concern that we should consider.</p>
<p><br>
</p>
<p>One possible solution to that would be, for example, to have
something like CONSOLE_HANDLE_SHELL_NO_WINDOW, which would be
inherited by CreateProcess(0) and prevent from creating an actual
new console. This would achieve most of this patch's goals with
lower runtime price.<br>
</p>
<p><br>
</p>
<p>Other possible solution is more specific to Wine tests, which are
causing most of those problems. We could just build tests as GUI
applications and avoid the problem in the first place. It's not a
general solution, through. We could maybe have wineconsole
--no-window option that, instead of using AllocConsole, would use
CREATE_NO_WINDOW. This would essentially give user an opt-in
option to achieve the same outcome as your patch.<br>
</p>
<p><br>
</p>
<p>Anyway, none of above is perfect. I just thrown more ideas to the
pool, hoping for your and/or other's opinions.<br>
</p>
<p><br>
</p>
<p>I think that the root of the problem is that there is no single
right thing when Wine is invoked by Unix process with no Unix
console available (when Unix console is available, the choice to
use it is mostly uncontroversial). In some cases, creating a
console window is desired, while for others it's not. Currently
user is able to force console window creation by running
explicitly wineconsole, but the opposite is not possible under
assumption that "default" is good for other cases. This is an
equivalent of creating the process with DETACHED_PROCESS on
Windows.</p>
<p><br>
</p>
<p>Thanks,</p>
<p>Jacek<br>
</p>
</body>
</html>