http://bugs.winehq.org/show_bug.cgi?id=10941
Summary: Wine does not print in a newly allocated console window Product: Wine Version: 0.9.52. Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-console AssignedTo: wine-bugs@winehq.org ReportedBy: mail2benny@gmail.com
Created an attachment (id=9867) --> (http://bugs.winehq.org/attachment.cgi?id=9867) The binary which recreates the bug
Wine does not print in a newly allocated console window using the function FreeConsole(); and AllocConsole();
I've written a program which recreates the bug. I'll post the binary and the source. (compiled on Dev-C++ 4.9.9.2, in Wine)
http://bugs.winehq.org/show_bug.cgi?id=10941
--- Comment #1 from Benny mail2benny@gmail.com 2007-12-29 07:26:24 --- Created an attachment (id=9868) --> (http://bugs.winehq.org/attachment.cgi?id=9868) The Source of the program that recreates the bug
http://bugs.winehq.org/show_bug.cgi?id=10941
Benny mail2benny@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal
http://bugs.winehq.org/show_bug.cgi?id=10941
Benny mail2benny@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Wine does not print in a |Wine does not print in a |newly allocated console |newl allocated console |window |window using AllocConsole()
http://bugs.winehq.org/show_bug.cgi?id=10941
Benny mail2benny@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Wine does not print in a |Wine does not print in a new |newl allocated console |allocated console window |window using AllocConsole() |using AllocConsole()
http://bugs.winehq.org/show_bug.cgi?id=10941
Kirill K. Smirnov lich@math.spbu.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lich@math.spbu.ru
--- Comment #2 from Kirill K. Smirnov lich@math.spbu.ru 2007-12-30 20:59:07 --- An article: http://www.williamwilling.com/blog/?p=74 states, that using msvcrt of STL IO functions over reallocated console is not an easy thing as it looks.
I really do not know why this works under windows without magic of wrapping classes.
http://bugs.winehq.org/show_bug.cgi?id=10941
--- Comment #3 from Benny mail2benny@gmail.com 2008-01-02 11:58:50 --- Its even weirder... As long you cout in a "AllocConsole()" everything is ok and everything is printed. If you cout in a "FreeConsole()" you cant cout in a new "AllocConsole()" anymore...
http://bugs.winehq.org/show_bug.cgi?id=10941
--- Comment #4 from Benny mail2benny@gmail.com 2008-01-02 12:38:32 --- This last comment was meant for a windows environment.
http://bugs.winehq.org/show_bug.cgi?id=10941
--- Comment #5 from Benny mail2benny@gmail.com 2008-01-02 12:39:00 --- This last comment was meant for a windows environment.
http://bugs.winehq.org/show_bug.cgi?id=10941
James Hawkins truiken@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|_obsolete_console |kernel32
http://bugs.winehq.org/show_bug.cgi?id=10941
scguy318 nodisgod@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nodisgod@yahoo.com
--- Comment #6 from scguy318 nodisgod@yahoo.com 2008-01-12 19:48:38 --- Could this bug be related to bug #10404 in any way?
http://bugs.winehq.org/show_bug.cgi?id=10941
--- Comment #7 from Benny mail2benny@gmail.com 2008-01-13 07:24:54 --- This could be, likely, yet there is not enough information, at the moment,to confirm.
http://bugs.winehq.org/show_bug.cgi?id=10941
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |ABANDONED
--- Comment #8 from Austin English austinenglish@gmail.com 2008-06-05 11:28:20 --- Is this still an issue in 1.0-rc3 or newer wine?
http://bugs.winehq.org/show_bug.cgi?id=10941
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|ABANDONED |
--- Comment #9 from Austin English austinenglish@gmail.com 2008-06-05 11:28:42 --- Whooops, didn't mean to do that :-).
http://bugs.winehq.org/show_bug.cgi?id=10941
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords| |download, testcase
--- Comment #10 from Austin English austinenglish@gmail.com 2008-06-05 12:35:43 --- Confirming in git. In current git, it'll make a new console, but the output is still sent to the first console. Running with wine cmd makes no difference (in windows, works if ran from explorer or cmd).
http://bugs.winehq.org/show_bug.cgi?id=10941
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@orange.fr
--- Comment #11 from Eric Pouech eric.pouech@orange.fr 2008-06-07 02:21:21 --- I fear that in window, the default handles *values* for the console (loaded and stored with GetStdHandles and friend) are the same for the two consoles, hence letting msvcrt handling it transparently could someone verify this in windows if the assumption is correct, the next question is: is it by chance or by design? in response to #3, it sounds logical if msvcrt invalidates the cout stream as the underlying handle is no longer valid (as the call to FreeConsole() has closed it) A+
http://bugs.winehq.org/show_bug.cgi?id=10941
--- Comment #12 from Austin English austinenglish@gmail.com 2008-12-07 18:18:00 --- Still present in 1.1.10.
http://bugs.winehq.org/show_bug.cgi?id=10941
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
--- Comment #13 from André H. nerv@dawncrow.de 2010-01-20 06:39:19 --- Still present in 1.1.36
http://bugs.winehq.org/show_bug.cgi?id=10941
butraxz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |butraxz@gmail.com
--- Comment #14 from butraxz@gmail.com 2012-05-17 15:11:23 CDT --- This bug has not been updated for two years. Is this still an issue i current (1.5.4) or newer wine ? You may also close this as abandoned if you feel that that this is issue is no longer relevant to you.
http://bugs.winehq.org/show_bug.cgi?id=10941
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #15 from Bruno Jesus 00cpxxx@gmail.com 2012-05-18 01:17:03 CDT --- Still present in wine 1.5.4.
http://bugs.winehq.org/show_bug.cgi?id=10941
--- Comment #16 from Eric Pouech eric.pouech@orange.fr 2012-05-18 02:18:24 CDT --- we should keep it open (unless we demonstrate that the expected behavior is not intentional in windows..., or doesn't work on a newest OS, and it that it'll have to be closed WONTFIX)
https://bugs.winehq.org/show_bug.cgi?id=10941
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source
https://bugs.winehq.org/show_bug.cgi?id=10941
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #17 from super_man@post.com --- Well the new text isnt shown at the new console that its created.
wine 1.9.5
https://bugs.winehq.org/show_bug.cgi?id=10941
--- Comment #18 from Gijs Vermeulen gijsvrm@gmail.com --- With wine-6.15, if I run the binary from the OP directly, it doesn't show the printed text in the new console. However, if I run the binary through cmd, it works correctly.
http://bugs.winehq.org/show_bug.cgi?id=10941
--- Comment #19 from Gijs Vermeulen gijsvrm@gmail.com --- Situation is still the same as in my previous comment with wine-10.6.
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