http://bugs.winehq.org/show_bug.cgi?id=10941
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED
--- Comment #20 from Eric Pouech eric.pouech@gmail.com --- got a glimpse of what's going on...
globally, the first std handles are created as unbound console handles msvcrt fd for 0, 1, 2 are created on these handles, then stdin, stderr, stdout FILE* are created on top the 3 fd:s, then the C++ cout, cerr are in turn built on top the corresponding FILE*
on FreeConsole(), depending on the various code paths, these std handles can be closed or not on AllocConsole(), the std handles are erased with the handles to the new console
an unbound console handle (ie the first allocated ones) have the property to write to the current process console, even if has been destroyed and recreated in between
the C++ std::cout (and FILE* stdout and fd 1) are still opened on the first created handles... and will stop to work as expected if they are closed in AllocConsole, but will continue to work if they are not closed
the code paths taken for ./wine AllocBug.exe and ./wine wineconsole AllocBug.exe both end up in closing the unbound handles, hence no output
the code path taken for ./wine cmd /c AllocBug.exe does not close the unbound handles, hence it works
hacking wine to not close the handles and the buggy code paths let the test program work. this will need likely some more testing before going upstream