NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/os/linux/16843

Text File | 1992-11-16 | 3.6 KB | 83 lines

Newsgroups: comp.os.linux
Path: sparky!uunet!mcsun!fuug!prime!mits!kennu
From: [e-mail] (Kenneth Falck)
Subject: Re: Second Monitor
Organization: Microdata International Telecomm Service, Helsinki, Finland
Date: Mon, 16 Nov 1992 16:05:27 GMT
Message-ID: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail] (Usenet poster)
Nntp-Posting-Host: mits.mdata.fi
Lines: 70

[e-mail] (Lars Wirzenius) writes:
> [e-mail] (Kenneth Falck) writes:
> >Btw, I also thought of something else; as console.c contains the VT100/
> >VT220/whatever emulation code, couldn't it's services be made available
> >to external processes?
>
> It already is, they only have to write to the console. :-)
>
> Frankly, I don't see the need for comm programs to do terminal
> emulation, that belongs properly to the console driver so that it can
> be done only once.  People not running on the console (i.e. they are
> using real terminals) either have the real thing, or they can use
> screen which does vt100 emulation.
>
> I much prefer the kermit way, where all incoming data is passed
> directly to the console, and vice versa (except that one char is
> reserved for special purposes on outgoing data).  I don't think
> minicom's built in terminal emulation is worth it (especially since it
> might not work as well as the console's).

Well, I've gotten used to the kermit way, too (I use a self-made terminal
program though, I want to remap outgoing strings), but sometimes I miss
things like a scroll-back buffer and saving incoming data from the modem
in a log file, stripping the VTxxx control codes. And a status line might
sometimes be useful...

Of course, in most cases you can disable the control codes from the remote
system, and maybe someone will write a nice multiwindow text-mode console
interface with back-scrolling and all... But still, there might be cases
when a VT220 handling routine would be useful; you'd just make a syscall
giving a buffer of characters and the current state of the screen as
parameters, and receive the new state & the control codes stripped off
the buffer... Well, something like that.

As for more ideas I'm too lazy or have too little time to carry out,
how about if the complete console interface could be externally replaced
by a "window manager" process, like I've understood you can do with X
window systems.

That way, it'd be easier to develop new interfaces when you wouldn't have
to recompile the kernel and distribute them as patches...

Uh well, I'm not too familiar with the ways the kernel and processes
can communicate; I don't know would this be possible without really
extensive rewriting and redesign.


By the way, I just bought the October issue of UNIX Review, and they
mention Linux in the `Net worth' column by Steven Baker on page 15.
Well, I might as well quote that part of it, in case someone is
interested...:

[...]
"While the commercial market has all but decided, the research and
hacker communities now have two flavors of BSD UNIX on the 386 from
which to choose (the non-commercial version is widely available on the
Internet). A creative soul has written the core of the System V Release
3.0 UNIX kernel for the 386 called Linux and also made it available
on Internet. Meanwhile, Mark Williams is set to release a 386 version
of Coherent, its UNIX look-alike priced at a mere $99."
[...]

Well, at least they got the 386-requirement part correct :-)

> --
> [e-mail]  (finger [e-mail])
>    MS-DOS, you can't live with it, you can live without it.

--
[e-mail]