PATCH: xterm support for wineconsole

eric pouech 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
interface

> 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 :(
no hurry

> > 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
situations are
handled:
1 pgm is run from wineconsole (and not wine), then a new window is
associated
  and pgm is run inside
2 pgm is run with wine, and in this case, the std in/out handles are in
fact
  the ones of the starting TERM
so, the main idea was to enhance mode 2 and handle it from within
wineconsole
in that case, we don't know which TERM configuration is used (hence the
benefits
of (n)curses)). that's what I called TERM support (but, it seems to be
misleading)
A+

-- 
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle




More information about the wine-devel mailing list