PATCH: xterm support for wineconsole
eric.pouech at wanadoo.fr
Wed Nov 28 15:39:41 CST 2001
> The old engine and its control codes does work basically fine if started
> within an xterm.
well, some functions key (like Fx) didn't work here with xterm...
> I did not have any screenbuffer/window distinction, true.
well, that's not needed. you need to refresh the content of the window
when you switch screenbuffer, which your patch should do fine
> And I do not consider it final. I am also still unhappy with it, since
> it does not work with the screenbuffer/window paradigm yet.
the window isn't there, but I don't see we could to it with a TERM
> That it is
> not ncurses is mostly due to the fact that I did not program ncurses yet.
neither do I, but it doesn't seem too complex ;-)
> I will try an ncurses port, but my time is rather limited :(
> > a command line tool and use the current TERM for interacting with it), which
> > would mean in wineconsole case passing to wineconsole the handles of current
> > TERM.
> TERM support?
as of today, when a Win32 pgm tries to use the Console API, two
1 pgm is run from wineconsole (and not wine), then a new window is
and pgm is run inside
2 pgm is run with wine, and in this case, the std in/out handles are in
the ones of the starting TERM
so, the main idea was to enhance mode 2 and handle it from within
in that case, we don't know which TERM configuration is used (hence the
of (n)curses)). that's what I called TERM support (but, it seems to be
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
More information about the wine-devel