19 Oct
2015
19 Oct
'15
11:46 a.m.
On 2015-10-19 20:43, Paul Koning wrote:
The amount of swearwords from TOPS-20 people exceed all others combined,
in my experience. So if they intended CTERM to be something reasonable
for TOPS-20 it was an utter failure. :-)
And it's really silly and sad, considering that something like telnet is
very simple and straight forward, and can be done right on both VMS and
TOPS-20, and will in the end work much better for people connecting from
one to the other, than using CTERM...
(I have the same issues with CTERM under RSX. telnet makes so much more
sense.)
Johnny
On Oct 19, 2015, at 2:30 PM, Johnny Billquist
<bqt at Update.UU.SE> wrote:
On 2015-10-19 19:42, Paul Koning wrote:
You can certainly view it as an RPC, and given that Cterm ended up basically doing VMS,
looking at it as the RPC version of the VMS terminal driver is reasonably accurate. But
the original version aimed to support both VMS and TOPS-20 as primary clients, and other
operating systems as well. So it was supposed to be an RPC version of the union of all
terminal drivers. Which means that a full CTERM server (as opposed to client) would be
hard to do for everyone, even VMS. ...
CTERM was an attempt to wrap a single protocol around the terribly inconsistent semantics
of the terminal drivers in all the DEC operating systems, and to export as much as
possible to the server end. ...
An interesting way to describe it.
I've always looked at CTERM as an RPC service that essentially have all the functions
of the VMS terminal driver. Makes it easy to implement in VMS, as you have a 1:1 mapping.
Makes it horrible for everyone else, since other systems do not have the same
functionality in the terminal driver, and now have to implement all the remote procedure
calls of the VMS terminal driver, and somehow map that into how the native terminal driver
works...