On Mon Jun 12 16:39:46 2023 +0000, eric pouech wrote:
I didn't go that far as it seems to me that some apps use the std handles for logging and debug output (when the handles are present) (I discussed this offline with @gofman recently and it seems he had some concerns about this) If we want to go the way of erasing the console for GUI processes as your patch proposes, I think we'd need more tests for checking inheritedhandles to parent's console without connecting console handle (is the console object inherited ? and are the std handles still usable? when passed in process info) (what your patch does is likely inherit console's object in server, but doesn't set it as current console in kernelbase ; so more tests required) (iow shall we close incoming ->ConsoleHandle? and/or std handles). I'll write some more tests for that and post the results in this MR. I fully agree for considering unix console as genuine consoles for CUI programs. For GUI, is we erase the console the question is closed. If we don't, that's more an opened question.
posted https://gitlab.winehq.org/wine/wine/-/merge_requests/3057 with extended tests
it shows: - for GUI, the std handles open to console are not inherited - but can be forced to be even if ConsoleHandle is NULL (didn't check if the handle was anyway opened in child process)
so your patch proposal looks ok on ConsoleHandle management side (even if it would be better to close the console handle before zero:ing it out), but fails to close & zero out std handles for consoles in gui subsystem
A) I'm not sure we need to go that far (and simply detaching from console, but keeping the std handles open should suffice - and it should keep the logging active as listed above) B) if we want to be 100% compatible with native, needed semantics are the ones of DETACHED_PROCESS (so perhaps native does the checks on parent or kernel side and forces DETACHED_PROCESS for GUI children)
so for the time being, I would favor A over B.