"Eric Pouech"eric.pouech@voila.fr 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.
The communication with the console can probably go through the server. Input events can simply be put in the queue by wineconsole using WriteConsoleInput. Output should probably go to a server screen buffer object, which would then signal wineconsole that its contents changed.
Alexandre Julliard wrote:
"Eric Pouech"eric.pouech@voila.fr 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 complex console
default behavior (simple console) at startup could be modified by either: - 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 CREATE_NEW_CONSOLE
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 handled, 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 '\n'))
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 discussed for ReadFile on console input handles... fail the regular read operation and fall back to WriteConsole
A+
-
Alexandre Julliard -
eric pouech