[Info-vax] VMS terminal support (was: AlphaVM-free emulator with all additional peripheral components)

[John E. Malmberg]

On 8/1/2012 5:18 AM, Johnny Billquist wrote:
>
> My point was that there is no response "seven bit". And believe me, I've
> read the manuals backwards and forwards plenty of times.
> I was curious on how people expected VMS to be able to set eightbit,
> based on the information in DA1. Maybe something clever that I had
> missed, but based on your responses, as well as the fact that VMS do not
> set eightbit even if I have all the capabilities set correctly when I
> test seems to prove that VMS does indeed not do this, as it can't.

VMS only seems to be able designed to detect a specific set of VT series 
terminals that were sold by them or the company that now sells them.  In 
some cases it can get the geometry of the terminal, in others it can not.

SSH passes a terminal identification string and the geometry, and maybe 
some other attributes to the end system.

Putty lies by default and tells the target system it is an xterm, even 
though by default it uses a reversed foreground and background.

This lie means that the default color output on Linux can be a bit 
unreadable on Putty.

> If someone else can show VMS doing more, and even better, under which
> circumstances, I'm curious to look at how it is done. The contents of
> DA1 does not provide enough information, with the possible exception
> that if you get a CSI as the eight bit character, that is a pretty good
> indication that maybe eightbit should be set. (That bit of information
> is, by the way, what RSX use to set EBC, which is actually exactly how
> much it really tells.)

Unfortunately it does not, so creating an algorithm to do so is up to 
someone else.

The only reliable way that I can see to get the current terminal 
geometry is to move the cursor to various locations and then read it 
back.  And with "linked" screens active, even that can return false 
information.  That is also something needed to detect broken wrap.

And there are a number of terminal properties that an application would 
be interested in that do not seem to be supported by the 
terminfo/termcap database or ncurses.

Set term/inquire has some unfortunate side effects, such as sometimes 
setting the terminal geometry back to 24 * 80, depending on what it finds.

The Curses library in VMS is broken.  It does not matter what terminal 
type you tell it to return values for, it always returns the values for 
a VT100.  So even changing the terminal settings will not affect a C 
program that uses it.

In the GNV sourceforge CVS directory for the VMS (gnu_vms subtree) 
specific changes to BASH-4.2 is a replacement curses implementation that 
actually reads the VMS terminal database and has an alias for xterm, and 
possibly some other models.

I did what I could, but many of the termcap/terminfo settings are not 
documented at all.

Linux does not seem to even attempt to auto-detect a terminal type.

> All the rest I've already run over in my past messages here.
>
> And yes, me personally, I enjoy hacking on terminals, and find the
> interface pretty fun to play with. As well as serial communication in
> general.

Serial communications is still used for many consoles and debugging or 
diagnostic ports.  The terminal server market is apparently alive and well.

One of the complaints about the current generation of low cost tablets 
is that there is not a serial port that would allow technicians to use 
them instead of carrying around a laptop.  In some cases an application 
vendor is making a proprietary cable for serial communications.  But a 
general solution is not available.

The D-Rats Amateur radio system uses serial communications, but can not 
be used with either a Android tablet or iPad/iPod for that reason.

The future Microsoft Surface tablet supports a serial port through USB 
and may be able to capture a bit of that market that has been written 
off by others.  How big is it?  I do not know.

It looks like some Android hardware may supports host mode, which is 
required for connecting to a serial port.  Software support is limited 
to a number of Google approved devices, which currently does not appear 
to support a serial port.

Regards,
-John