Based on patches by Eric Pouech and Torge Matthies.

Signed-off-by: Jacek Caban <jacek@codeweavers.com>
---
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...

Eric, Torge, I hope you will review this.

 dlls/kernel32/tests/console.c |  3 ---
 dlls/kernelbase/console.c     | 21 +++++++++++++++------
 dlls/kernelbase/process.c     | 11 +++++++----
 include/wine/condrv.h         |  5 +++--
 programs/conhost/conhost.c    | 11 ++++++++---
 programs/conhost/conhost.h    |  1 +
 6 files changed, 34 insertions(+), 18 deletions(-)

two comments:

- the value for ConsoleHandle in child process for a GUI exec is not consistent depending on passed flags:

  + it's going to be 0 value when CREATE_NO_WINDOW is passed

  + it's value is untouched when 0 is passed (at least none of CREATE_NO_WINDOW, DETACH_PROCESS, CREATE_NEW_CONSOLE)

under windows, it's always zeroed out (as the remaining todo_wine in test_CreateProcessCUI shows)

- 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

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

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

(just to share it here)

https://bugs.winehq.org/show_bug.cgi?id=52771

https://bugs.winehq.org/show_bug.cgi?id=52761

https://bugs.winehq.org/show_bug.cgi?id=52743