RFC: console & curses

Eric Pouech eric.pouech at wanadoo.fr
Tue Nov 19 14:38:02 CST 2002

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

why such a directive proposal ?
4 => C is rather natural and doesn't need further explanation (one day,
we could envisage to support it no longer, but that's another story)
1 => A greatly facilitates the console creation (ncurses requires both
terminal control and moreover to keep the process group leader running
as long as all the children - hooked to the same terminal - are
running). Very few programs use AllocConsole (and even use it). The only
issue may be with winedbg which may allocate its own console on startup
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'
3 => A here again it's easier to deal with. if trying to run a curses
backend, we should ensure that two different wineconsoles are not
currently hooked to the same terminal

If you have any comments, speak up now !!

N1: 3/ can be seen from various aspects as a specific case of 1/, but
implementation could implement it as 2/)
N2: one could try running wineconsole USER backend with ttydrv instead
of x11drv, but that's out of the scope of this (maybe for Dimi's fun
projects list
N3: IMO what's missing is that winedbg should check if has inheried a
real console. If so, it should detach from it and recreate a new one.

More information about the wine-devel mailing list