Hi all,
2008/2/14, Dmitry Timoshkov dmitry@codeweavers.com:
"Maarten Lankhorst" m.b.lankhorst@gmail.com wrote:
It worked before ba896e75d7fce68e5183007b65eae7e35490ccd4. (Around wine 0.9.33 or so) After that it was broken. I have a wine 0.9.9 that when run does create a seperate console for dos apps. My guess is that somewhere in the initialisation allocconsole would have to be called.
You need to talk to Alexandre since that's his patch. Still, there is no AllocConsole() call removed by that commit, so it has nothing to do with the regression.
I've done a bunch of tests with a simple mingw app linked with -mconsole and found the following results (in xp sp2 vmware): - Asynchronous calls are not available for console handles (ReadFile only works in synchronous mode, ReadFileEx doesn't work) - I can do WaitForSingleObject(GetStdHandle(STD_INPUT_HANDLE), INFINITE); and it will only return when there is data to be read, like a key being pressed. in wine it will return immediately, this causes the breakage of dos apps after wine 0.9.33.
These things make me think that the old behavior of wine is more correct then the current one, with relation to console handles.
-Maarten.
"Maarten Lankhorst" m.b.lankhorst@gmail.com writes:
These things make me think that the old behavior of wine is more correct then the current one, with relation to console handles.
The behavior hasn't changed for console handles, but the default case is to run on the unix stdio handles, not true console ones. That's a feature, we don't want to create a separate window for a simple command line app.
There are two bugs here: one is that the unix stdio should be presented to the app as a real console as far as possible, the other is that the code should work correctly on non-console handles because even if we fix the first one we can always redirect i/o. The second bug should be easier to fix so I'd suggest to start with that.
-
Alexandre Julliard -
Maarten Lankhorst