RFC: console & curses
marcus at jet.franken.de
Wed Nov 20 14:32:00 CST 2002
On Tue, Nov 19, 2002 at 09:38:02PM +0100, Eric Pouech wrote:
> I did send a couple of days ago a first patch about the (n)curses
> backend to wineconsole
> Alexandre commented a few implementation issues in it, which may change
> a bit what I started with and how the wineconsole should behave:
> console creation can be invoked from different contexts:
> 1/ the program calls AllocConsole
> 2/ the user starts wine thru wineconsole for his/her (favorite) CUI app
> (using from command line something like 'wineconsole foo')
> 3/ (N1) the program forks a child with CREATE_NEW_CONSOLE flags set in
> 4/ the program doesn't request anything
> on the other hand, wineconsole is now able to handle two types of
> backend for the user interface:
> A/ USER: the one already in place
> B/ Curses: the new one using (n)curses and a regular term for display
> C/ no wineconsole support => by default, the windows input & output
> streams are hooked to stdin and stdout, but we don't provide full
> console support - cursor motion, screen reading...
> now the final question, how to choose between A, B and C. the proposal
> is to fix the choice with:
> 1 => A
> 2 => B
> 3 => A
> 4 => C
> 2 => B we could easily add 2 => A too (with some wineconsole
> parameters). Moreover, if the user wants to have the console in a
> specific xterm, it's doable with xterm -e 'wineconsole blablabla'
Hmm, what is wrong with A for all the first 3 cases?
Even the IDA Disassembler now likes the USER based console.
More information about the wine-devel