On 08/03/12 15:14, Matthias Melcher wrote:
>
> On 03.08.2012, at 23:20, Cliff Yapp <cliffy...@gmail.com> wrote:
>
>>
>> Since you guys are knowledgeable about terminal emulation issues, I'd be
>> curious
>> if you have a sense on how hard it would be to implement (using FTGL +
>> GTerm's
>> core functionality + whatever additional bits make sense) an actual
>> cross-platform
>> terminal emulator that would (say) allow console emacs and vim to operate on
>> Windows platforms the same way they do on Linux/BSD/OSX?
I'm not sure what interface windows oriented emacs/vi use to interact
with the screen.
If they're running in a DOS window, then they're likely using simple
stdout/stderr (which should be easy to support), and perhaps are using
the INT 21/INT 9/INT 10 interfaces (etc) along with WIN32 console
functions
calls to do things like cursor positioning, scrolling and the like.
I think DOS windows are also emulators themselves of ye olde and musty
video cards. (Remember the ones that had video memory at 0xb800:0000
for "color" cards, and 0xb000:0000 for monochrome? Ah, memories..)
Actually, modern graphics cards still support this memory-text mode
stuff;
linux makes good use of it, as does, what is it, Alt-TAB or Alt-ESC or
something where you can switch a modern windows DOS window to full text
mode.
Anyway, all that is probably very tricky.
Then there's the whole other world of Unix shells on Windows, which
do who knows what to emulate pty's and such. I don't know how far
they go simulating unix.. but I'm sure it gets very implementation
dependent.
I imagine though if one is writing a terminal emulator, one really
only is interested in keyboard events, stdin/out at the very basic
level,
and not concerned with ptys and signals at all.. the software emulation
layer probably handles all that internally.
So supporting that might not be so hard.. hard to say.
> Oh boy! For a terminal emulation, you need io streams (stdin, stdout, stderr),
> and means of asynchronous notifications.
Mmm, not sure the terminal emulator would handle that.. if cygwin
has its own character cooking and pseudo tty code, it would handle
all the weird ^U/^Z/^W stuff, and would simply echo the correct ANSI/tty
stuff needed, which is all the terminal emulator would have to handle.
Streams, ptys, keyboard generated signals etc. are all software
emulations.
However, things like window resizing have interesting implications..
I forget what goes on there, but in unix I think it involves ioctls
telling the software layer the window changed size. Not sure what
happens
in WIN32, but I imagine something similar at both the INT 10/INT 21
interface,
and perhaps a window console library interface as well.
That all said, I have no direct knowledge of all this.
When I mucked around with terminal emulation on IBM PCs, I was
simply talking directly to the graphics card and depending minimally
on the BIOS for things like keyboard interaction.. and I wrote DOS
applications (pre-windows) that used ANSI.SYS and INT calls to read
the keyboard, determine scroll regions, etc.
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
