[Info-vax] Windows terminal revamped and open sourced

[Stephen Hoffman]

On 2019-05-11 17:32:44 +0000, Jan-Erik Sderholm said:

> Den 2019-05-11 kl. 19:18, skrev Stephen Hoffman:
> 
>> There are a number of open-source terminals available, and for various 
>> platforms....
> 
>> As for terminal emulation features found on other platforms, Unix and 
>> macOS already do as well or better than OpenVMS.  The integrated 
>> terminal emulator on macOS provides UTF-8 support, for instance...
> 
> I do not think that comparision is fair. MacOS is a client-only OS (right?)

I'm comparing the vendor-provided OpenVMS terminal emulator DECterm 
packaged with DECwindows with the vendor-provided macOS Terminal.app 
terminal emulator packaged with macOS.

> That is, you run your term emulator on/from the same MacOS environment.

Terminal.app is one of the main interfaces into macOS itself, just as 
this Microsoft Windows terminal emulator will be for the newer Windows 
environments and users, and particularly for the folks using WSL2.   
And for folks with OpenVMS workstations, DECterm is used the same way.  
It's used for local work across all these platforms.

When I was developing directly on OpenVMS on an OpenVMS workstation, I 
was using DECterm exactly the same as I am now using the macOS 
Terminal.app terminal emulator to work with an on macOS.

DECterm was used for remote sessions connected via telnet and ssh and 
DECnet, as is the macOS Terminal.app environment with ssh and telnet.

Yes, DECterm also allows remote X sessions and that can be handy for 
some cases, though I do not usually use that; that's a comparatively 
heavyweight connection. A remote DECterm is a way to avoid the "fun" of 
a weak or buggy terminal emulator, particularly when dealing with those 
OpenVMS apps that use the more arcane control sequences.  Some of the 
old DEC StorageWorks controllers and related tooling didn't work very 
well in much other than vtterm, for that matter—though I do expect 
various terminal emulators have caught up there.

> VMS is a server-only OS. You do not expect *VMS* to come with a 
> built-in emulator.

So long as OpenVMS is available with DECwindows, there will be a 
built-in emulator.  That emulator is currently DECterm.

> And such as the free Putty does support UTF-8, FWIW...

DECterm does not.

> Does anyone expect a "terminal emulator" that actually runs *on* VMS?

DECterm does.  As does xterm.  There are probably others.  And for the 
folks using DECwindows locally, you will expect a terminal emulator.





Collected but-I-digress comments.

The base install of macOS client has more server features than does 
OpenVMS.  Apache, networking, SMB services, CUPS, IP networking, ssh 
server, Xsan, remote management, all built in. It's also a full Unix 
system.  But you're right, it's not what most folks would consider a 
server, and the server add-on package that was a spectacularly easy way 
to manage and maintain the latent features was retired with the macOS 
10.14 Mojave release.

The world went UTF-8 for character encoding, and not to DEC MCS / ISO 
Latin-1.  DCL hasn't gotten to UTF-8, and it'll may be be easier to 
replace DCL that than to update all of what's limiting.

As has been mentioned elsewhere, X, telnet and DECnet are all insecure 
network connections.  And telnet and ftp are now no longer integrated 
and are now packaged as add-ons for recent macOS releases, due in no 
small part to the insecurity.

Whether the existing DCL and related baggage can survive in the 
hypothetical updated DCL environment?  While ASCII is a proper subset 
of UTF-8, there'll be issues with migrating existing code code as 
little of the existing DCL can deal with multi-byte characters.

Many folks classically using PuTTY and Reflections and related tooling 
and using Windows as a client for accessing OpenVMS or other systems 
remotely don't use their terminal emulators for local access.  This 
because connecting from the DOS box into a system that used ANSI 
control sequences just never worked well, so everybody used an 
emulator.  Terminal emulation tends to be used differently on macOS, 
Linux, OpenVMS and other platforms.  And this will now be the case on 
Windows, with this Microsoft terminal emulator and with the WSL2 and 
newer work.  Many of the existing Windows-as-a-server-client users 
accessing remote serial connections via telnet or ssh probably won't 
change their existing usage of Windows here.  Some folks will, though.  
The folks looking to use WSL2 will use this new terminal emulator.

This is yet another detail that makes Windows more interesting to the 
folks using Linux and Unix systems for various purposes.



-- 
Pure Personal Opinion | HoffmanLabs LLC