http://bugs.winehq.org/show_bug.cgi?id=28192
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@orange.fr
--- Comment #1 from Eric Pouech eric.pouech@orange.fr 2011-10-23 03:05:10 CDT --- The reason of this bug is rather different from what's explained in #1. Basically, regedit is compiled as a GUI program, but wants to use the console.
What cmd does is: - if the child program (to be spawned from command line) is a CUI, then cmd launches it, and waits for its termination - if the child program (to be spawned from command line) is a GUI, then cmd launches it, and prompts the user for the next command without waiting for its termination
This what happens here (and explains the arrival of the child output after the prompt)
From various testings (in comparaison to windows):
- cmd behavior is correct - there is no such a beast as regedit on windows (ie a program that could be both used as a CUI and GUI program) - windows' regedit is a GUI program (as wine's regedit) - a GUI program, when launched from cmd, is no longer attached to cmd's console (didn't test yet whether it's cmd implementation, or Kernel32.CreateProcess's implementation) ; even if the output is redirected to a file, nothing is written to it (so I"d rather think it's cmd that doesn't ask for console & handle inheritance in case of a GUI child) (to be confirmed by further testings)
From the possible fixes:
A/ change regedit so that it no longer output to console (even if we keep the commands) B/ in cmd, when launching a GUI program, call WaitForInputIdle (in case it's a used as a CUI program)
B/ is the simplest fix, but is rather different from windows behavior (as we need to inherit console in child process) A/ seems closer to windows behavior, but we'll miss all the outputs from regedit, which is a pain.
Better ideas welcomed.
A+