> On Oct 19, 2015, at 2:30 PM, Johnny Billquist <[email protected]> wrote:
>
> On 2015-10-19 19:42, Paul Koning wrote:
>> ...
>> 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...
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.
paul
