ReadFile and other issues

eric pouech eric.pouech at
Wed Aug 22 13:23:59 CDT 2001

Alexandre Julliard wrote:
> "Eric Pouech"<eric.pouech at> writes:
> > if we want to go into this, there are a few points to agree on first:
> > - since console handles can be inherited, the Wine console window should
> > be run in a different process than the one which uses the console (and
> > add communication means between the first process, and the process
> > rendering the console)
> > - how should we know a program needs either a simple or a complex
> > console (we could use a registry key in the per process area)
> We need a separate process yes. I was thinking of something like a
> 'wineconsole' Winelib app. Then if you want to run an app with a
> separate console you use wineconsole instead of wine to start it.
> A new wineconsole could also be launched when the app does an
> AllocConsole, or some other function that requires a complex console.
hmm I suppose that CREATE_NEW_CONSOLE flag in CreateProcess should be
handled that way too... I don't think we should have the ability
to change on the fly from a simple to a complex console: current code 
switches to a complex console when a "complex" operation is requested 
(cursor motion...)

so, if I try to sump up... by default, we start wine with a simple 
console... if another console is requested (AllocConsole, 
CreateProcess(...,CREATE_NEW_CONSOLE,...), ...), then we create a

default behavior (simple console) at startup could be modified by
- a per application specific entry in the registry
- or using launching thru the wineconsole winelib program

we keep the default inheritance rules for console handles... a simple
console is inherited as simple (a complex as complex), except for

> The communication with the console can probably go through the
> server. Input events can simply be put in the queue by wineconsole
> using WriteConsoleInput. 
fairly acceptable ;-) except that in line editing mode we need to lock
the input buffer on a single thread (that's the way the queue is
at least, on NT 2000 - didn't check the others) (the granularity for
getting access to the queue is not the input record, but the line (up to

> Output should probably go to a server screen
> buffer object, which would then signal wineconsole that its contents
> changed.
I was thinking of either a anonmymous file or an anonymous mapping for
the content of the screen buffer... with an array attribute and char
may be some additional info on each row to indicate the rendering
program about the rows which have been modified...

the WriteFile on a screen buffer handle should be done as already
for ReadFile on console input handles... fail the regular read operation
and fall back to WriteConsole

Eric Pouech (
"The future will be better tomorrow", Vice President Dan Quayle

More information about the wine-devel mailing list