So, in what environment, and using what equipment, is that color
support of any practical use?
In every decent terminal emulator created or modified in the past 15-20 years.
Ayup. Color support is available in the OpenVMS terminal emulator
DECterm, and that particularly terminal emulator been around for a very
Are you still using monochrome terminal environments only ?
In a legacy-software manufacturing environment still running
AlphaServer DS20 servers and Rdb, monochrome terminal displays are not
particularly surprising. If this parallels what is common in many
manufacturing organizations, it'll continue to be used and largely
unmodified, until the manufacturing line itself is replaced. When the
manufacturing line is replaced, either the application code will be
ported and updated to the newer hardware, or it'll be replaced with a
different application. In short, a number of manufacturing and
process-control environments are still running monochrome UIs and
various OpenVMS environments — manufacturing, as well as other areas —
are still running real VT terminals and DECserver LAT widgets and
hardware from way back then. Stuff that nobody'd pick or choose or
use now, but it works for them.
Colour within a terminal environment greatly enhances the readability
of the information you are displaying. It's such an enhancement over
monochrome text displays that I consider it essential to any prototype
HELP replacement (if I get motivated enough to prototype some ideas of
Ayup. Source code editing with syntax highlighting, or any number of
other UI-related tasks. Yes, this syntax highlighting is certainly
not for everybody, but many of us have become quite fond of it.
There are also implications here around accessibility, as even folks
that can see can't necessarily see colors.
Now imagine VMS help if it were similarly enhanced.
Rather than imagining, just go use a system that does support . The
local production servers have red command-line prompts, for instance.
PS1="\[\e[1;31m\]\u@\H $\[\e[0m\] "
Cryptic as is common with the bash shell, and embedded ANSI sequences
are never fun in any context.
Somewhat slightly easier than embedding ANSI control sequences, tput
rummages the terminal tables for that data.
Bluebld="$(tput bold; tput setaf 63)"
Grn="$(tput setaf 34)"
export PS1='\[$Bluebld\]\h: \w$ \[$Grn\]'
alias clear='tput clear'
OpenVMS lacked tput in the GNV bash port when last I checked, and there
is nothing similar to tput in DCL.
Unfortunately all my research so far has reminded me just how much code
you have to write if you want to try and do something like this on VMS
and then create executables which anyone can run.
This is what I've been griping about for some years.
Compared with higher-level tools and frameworks available elsewhere,
the amount of source code I have to write and debug and support and
charge my customers for is... excessive.
Then there are discussions of the differences in the tooling.
I'm (potentially) interested in prototyping something in the future
which anyone can try out, but not interested enough to write and debug
5 zillion lines of low level boilerplate code.
Boiler-plate code — glue code — is pretty much the definition of C
using OpenVMS features, or BASIC or Fortran using OpenVMS features for
Does the missed support create the ANSI escape codes for color handling?
Yes, but it's more than that because it fully integrates colour support
into the curses environment. I don't like curses as such but I've been
looking at alternatives to SMG$ and that was the only possibility
shipped with VMS or a layered product which I have found so far.
One of the more recent implementation of curses is new curses or more
commonly known as ncurses, though the effort to port ncurses over to
OpenVMS has not been completed.
Further up the stack are Qt, GTK+ and suchlike. As for the available
GUI on OpenVMS, the X implementation is very old. On the plus side, X
on OpenVMS is so old, CVE-2006-0745 and some others likely don't apply.
I'd still want to look at CVE-1999-0526 and all of others, though.
(And if I were a national intelligence agency or a well-funded entity,
I already would have checked the whole list of CVEs against OpenVMS.)
Dealing with curses or ncurses is no fun, as you spend way too much
time with the displays which means the incentives run contrary to UI
testing and tweaks to improve the user interface design. This is were
tools to help design the UI shine, and where the separation of the UI
from the rest of the app code — so-called MVC or otherwise — also
assist with making the apps easier to understand and use, and to
require less documentation for end-users, and related.
So it is used for hardware VT-terminals with color support or on
emulators having support for those ESC codes?
Anything which supports colours.
Ayup. This UI and this design — VT-style terminals and code written
for VT terminals that's been combined with terminal emulators, the late
adoption of UI changes and of ease-of-use, extremely late adoption of
open source — has been a substantial part of the OpenVMS market for
decades. Embedded systems seldom have modern UIs, and efforts toward
improving ease of use tend to be limited. Manufacturing organizations
particularly tend to update their servers and software once every
couple of decades, with incremental replacements and variously only for
failing hardware or software or critical patches in the interim. In
recent years, these approaches can encounter issues, such as SCADA
systems routinely getting owned due to shifts in the computing
Oh, and somewhere up-thread Steven was rummaging through
SYS$COMMON:[DECC$LIB.REFERENCE...] for evidence of support, and the
predecessors to VSI — OpenVMS antebellum? — stopped maintaining that
area a little over a decade ago. Search that with caution, unless
you're using the Freeware libext tool from Freeware V7. libext works
around a limitation of the librarian, an OpenVMS component closely
linked to another facet of the hypothetical replacement of the HELP
tool. Whether VSI reverses that decision to no longer maintain the
reference area, or provides tools to more directly rummage that data is
fodder for other discussions. Maybe extending SEARCH to search and
properly format text library contents? Better header file integration
with LSEDIT or another IDE? Lots of possibilities here. But that's
all fodder for another discussion. But then if the reference area is
no longer being maintained, then the directory should have been
removed. Leaving deprecated code or data or buggy examples around just
never works out.
Pure Personal Opinion | HoffmanLabs LLC