Marcus Meissner wrote:
Hi,
This patch adds a XTERM backend to wineconsole.
Some problems:
- In full screen text applications (like IDA), the cursor shows sometimes up in the wrong spot.
- Scrolling does not work yet (so winedbg doesn't really work).
- Uses config.h.
I still have some questions...
from a technical point of view, what didn't you use an ncurse (for example) lib to handle the TERM issues ? the old code you grabbed doesn't work correctly for all TERM configurations... rewriting everythind isn't the solution IMO
from a more usage point of view, it seemed that TERM support for wineconsole was more intended for supporting an existing UNIX console (like when starting 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. furthermore, how to you plan to choose, when starting wineconsole, from the Win32 and the xterm backend ?
in other words, I'm more in favor of : - Win32 backend for normal usage - reusing current UNIX console when run in TERM mode (and not xterm), and with the support of text mode lib (like ncurses)
A+
On Wed, Nov 28, 2001 at 08:46:47PM +0100, eric pouech wrote:
Marcus Meissner wrote:
Hi,
This patch adds a XTERM backend to wineconsole.
Some problems:
- In full screen text applications (like IDA), the cursor shows sometimes up in the wrong spot.
- Scrolling does not work yet (so winedbg doesn't really work).
- Uses config.h.
I still have some questions...
from a technical point of view, what didn't you use an ncurse (for example) lib to handle the TERM issues ? the old code you grabbed doesn't work correctly for all TERM configurations... rewriting everythind isn't the solution IMO
Basically I just want my application to run. I need full screen, PC font, color, mouse support and speed. xterm was the easiest method to get it in this case.
The old engine and its control codes does work basically fine if started within an xterm. It only enabled 'complex' output if it could start xterm. I did not have any screenbuffer/window distinction, true.
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. That it is not ncurses is mostly due to the fact that I did not program ncurses yet.
I will try an ncurses port, but my time is rather limited :(
from a more usage point of view, it seemed that TERM support for wineconsole was more intended for supporting an existing UNIX console (like when starting 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?
The old driver had knowledge of complex operations and switched on the xterm in this case.
furthermore, how to you plan to choose, when starting wineconsole, from the Win32 and the xterm backend ?
Dunno.
in other words, I'm more in favor of :
- Win32 backend for normal usage
- reusing current UNIX console when run in TERM mode (and not xterm), and with the support of text mode lib (like ncurses)
I'll think on it.
Please discard the patch in the meantime.
Ciao, Marcus
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 -
Marcus Meissner