under Windows, from cmd, if you do "app > file", then <app> is started with STARTF_USESTDHANDLES and stdout set to file handle to <file>
native cmd doesn't do it for console handles
for example, extrac32 /D prints the list of files in .cab to stdout (our implem matches native)
so under windows: 'extrac32 /D <cab>' will print nothing onto the console, but 'extrac32 /D <cab> > <file>' get out the list written into file. so I'd expect GUI apps should not be "surprised" to get valid handles in std handles (it could be DISK or PIPE types, or even CHAR)
IMO, we need at least to support the 'extrac32 /D <cab> > <file>' from unix shell to mimic cmd's behavior ; so keeping output with redirection to the console (without the unicode translation to proper codepage) is a direct consequence of supporting point above
we have bugs in the case we get wrong handles (it's partly fixed in previous patches in this series)
so, I'll update get_initial_console() to return the unix fd in case of non GUI (with on element I still need to look at: I'm not sure that in the 'app > file' example above the handle to file has the inheritable attribute set)
that leaves way to fix to start open. I've been toying and testing various approaches, but couldn't convince myself of best option:
* when using start, depending if child is CUI or GUI, we have to use a different set of handles (current handles for console in case of CUI, the handles to unix fd for the GUI child) * in RTL_CURRENT_PROCESS_PARAMETERS, we can only pass one set * I've considered: * passing the unix handles in params won't work as kernelbase:init_console will erase them (in start's kernelbase.DllMain) * reopen the unix handles with wine_server_fd_to_handle() in start in case of gui child ; works, but not very clean - it has been frown upon in previous attempts (note that ntdll/unix/process.c already does something similar) * pass as command line options to start the unix handles values (so that start passes them in GUI child; and closes them if CUI child) (works, but needs a bit of rework of unix/env.c to change command line options on the fly) * change the logic of console allocation: * no longer do it in kernelbase.DllMain->init_console * force all CUI initial app to be launched with start * call start with the std handles set the unix handles * add a new magic pid to AttachConsole() (eg -2) to attach to underlying unix console, supposing the current process std handles are bound to the unix fd) (need also to mark tty handles... could use bits in ConsoleFlags) * in start, if cui child, create console with AttachConsole(-2), then create child; if gui child, create child (and then create console to keep attachconsole(parent) still available) * works as well, but it's a bit larger
what do you think?