http://bugs.winehq.org/show_bug.cgi?id=10941 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #20 from Eric Pouech <eric.pouech(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.