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+