Discussion:
Does VMS curses support colour ?
(too old to reply)
Simon Clubley
2017-06-22 01:28:15 UTC
Permalink
Raw Message
It looks like the VMS version of curses is so old that it doesn't
even support colour unless there's a non-standard header somewhere
that I have not found yet. Can anyone confirm the lack of colour
support ?

CC and VMS version:

HP C V7.3-009 on OpenVMS Alpha V8.4

Q&D test program (which works just fine on Linux):

/*
* Test curses colour map
*
* Compile with:
*
* gcc -Wall -o colour_map colour_map.c -lcurses
*/

#include <stdio.h>
#include <stdlib.h>
#include <curses.h>

int main(int argc, char *argv[])
{
int x = 5, i, j, pair = 1;

initscr();
if(has_colors() == FALSE)
{
endwin();
printf("Colours not supported for this terminal type\n");
exit(4);
}
start_color();
mvwprintw(stdscr, 1, 1, "COLORS = %u, COLOR_PAIRS = %u\n", COLORS, COLOR_PAIRS);

if((COLOR_PAIRS < 64) || (COLORS != 8))
{
endwin();
printf("Not enough colour pairs\n");
exit(4);
}

for(i=0; i<8; i++)
{
x = 5;
for(j=0; j<8; j++)
{
if(i != j)
{
init_pair(pair, j /*fg*/, i /*bg*/);

attron(COLOR_PAIR(pair));
mvwprintw(stdscr, i + 5, x, "%s", "text ");
refresh();
attroff(COLOR_PAIR(pair));
pair++;
}
x = x + 5;
}
}
getch();
endwin();
return 0;
}

Output:

$ cc colour_map.c

if(has_colors() == FALSE)
...........^
%CC-I-IMPLICITFUNC, In this statement, the identifier "has_colors" is implicitly declared as a function.
at line number 18 in file DKA100:[SIMON]COLOUR_MAP.C;1

start_color();
........^
%CC-I-IMPLICITFUNC, In this statement, the identifier "start_color" is implicitly declared as a function.
at line number 24 in file DKA100:[SIMON]COLOUR_MAP.C;1

mvwprintw(stdscr, 1, 1, "COLORS = %u, COLOR_PAIRS = %u\n", COLORS, COLOR
_PAIRS);
........^
%CC-I-IMPLICITFUNC, In this statement, the identifier "mvwprintw" is implicitly declared as a function.
at line number 25 in file DKA100:[SIMON]COLOUR_MAP.C;1

mvwprintw(stdscr, 1, 1, "COLORS = %u, COLOR_PAIRS = %u\n", COLORS, COLOR
_PAIRS);
...................................................................^
%CC-E-UNDECLARED, In this statement, "COLORS" is not declared.
at line number 25 in file DKA100:[SIMON]COLOUR_MAP.C;1

mvwprintw(stdscr, 1, 1, "COLORS = %u, COLOR_PAIRS = %u\n", COLORS, COLOR
_PAIRS);
...........................................................................^
%CC-E-UNDECLARED, In this statement, "COLOR_PAIRS" is not declared.
at line number 25 in file DKA100:[SIMON]COLOUR_MAP.C;1

init_pair(pair, j /*fg*/, i /*bg*/);
................................^
%CC-I-IMPLICITFUNC, In this statement, the identifier "init_pair" is implicitly declared as a function.
at line number 40 in file DKA100:[SIMON]COLOUR_MAP.C;1

attron(COLOR_PAIR(pair));
................................^
%CC-I-IMPLICITFUNC, In this statement, the identifier "attron" is implicitly declared as a function.
at line number 42 in file DKA100:[SIMON]COLOUR_MAP.C;1

[snip]

Thanks,

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Steven Schweda
2017-06-22 02:11:02 UTC
Permalink
Raw Message
[...] Can anyone confirm the lack of colour support ?
Seems pretty obvious.

ALP $ search decc_include:*.h has_colors, initscr

******************************
SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]CURSES.H;11

__WINDOW_ptr32 initscr (void);
#define initscr(_p1) decc$bsd_initscr(_p1)
__WINDOW_ptr32 initscr (void);
Simon Clubley
2017-06-22 07:11:34 UTC
Permalink
Raw Message
Post by Steven Schweda
[...] Can anyone confirm the lack of colour support ?
Seems pretty obvious.
ALP $ search decc_include:*.h has_colors, initscr
******************************
SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]CURSES.H;11
__WINDOW_ptr32 initscr (void);
#define initscr(_p1) decc$bsd_initscr(_p1)
__WINDOW_ptr32 initscr (void);
Thank you Steven.

I'd already found the lack of references in curses.h but I was hoping
against hope there was some non-standard header or something else
around which I had not yet found.

For goodness sake, is there _anything_ in VMS which is at least
half-way up to date ? :-(

Thanks,

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Soderholm
2017-06-22 07:28:29 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Steven Schweda
[...] Can anyone confirm the lack of colour support ?
Seems pretty obvious.
ALP $ search decc_include:*.h has_colors, initscr
******************************
SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]CURSES.H;11
__WINDOW_ptr32 initscr (void);
#define initscr(_p1) decc$bsd_initscr(_p1)
__WINDOW_ptr32 initscr (void);
Thank you Steven.
I'd already found the lack of references in curses.h but I was hoping
against hope there was some non-standard header or something else
around which I had not yet found.
For goodness sake, is there _anything_ in VMS which is at least
half-way up to date ? :-(
Thanks,
Simon.
So, in what environment, and using what equipment, is that
color support of any practical use? Does the missed support
create the ANSI escape codes for color handling? So it is
used for hardware VT-terminals with color support or on
emulators having support for those ESC codes?
Simon Clubley
2017-06-22 13:09:08 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
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.

Are you still using monochrome terminal environments only ?
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 mine).

In case you are not familiar with colour in a terminal environment
take a look at the following:

Loading Image...

Now imagine VMS help if it were similarly enhanced.

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.

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.
Post by Jan-Erik Soderholm
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.
Post by Jan-Erik Soderholm
So it is
used for hardware VT-terminals with color support or on
emulators having support for those ESC codes?
Anything which supports colours.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Soderholm
2017-06-22 13:16:45 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Jan-Erik Soderholm
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.
Are you still using monochrome terminal environments only ?
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 mine).
In case you are not familiar with colour in a terminal environment
https://en.wikipedia.org/wiki/File:Slrn.png
Now imagine VMS help if it were similarly enhanced.
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.
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.
Post by Jan-Erik Soderholm
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.
Post by Jan-Erik Soderholm
So it is
used for hardware VT-terminals with color support or on
emulators having support for those ESC codes?
Anything which supports colours.
Anything that still is "a terminal". Not much new development
with VT-type screens as the user interface, I guess. But thanks
for clearifying that anyway. Cannot be even close to the top
of the VSI priority list.
Post by Simon Clubley
Simon.
hb
2017-06-22 15:04:34 UTC
Permalink
Raw Message
Post by Simon Clubley
In case you are not familiar with colour in a terminal environment
https://en.wikipedia.org/wiki/File:Slrn.png
Which is only an example. The wiki entry says Slrn was developed for
VMS. S-lang is available for VMS, as well as jed. There are various jed
modes for especially VMS, (DCL, MMS/MMK, ...) using colours for syntax
highlighting.
Simon Clubley
2017-06-22 18:33:13 UTC
Permalink
Raw Message
Post by hb
Post by Simon Clubley
In case you are not familiar with colour in a terminal environment
https://en.wikipedia.org/wiki/File:Slrn.png
Which is only an example. The wiki entry says Slrn was developed for
VMS. S-lang is available for VMS, as well as jed. There are various jed
modes for especially VMS, (DCL, MMS/MMK, ...) using colours for syntax
highlighting.
It wasn't so much the slrn application and S-lang library I was talking
about, but I was instead using it as an example of how the use of colour
enhances the display of information.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
hb
2017-06-22 21:08:23 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by hb
Post by Simon Clubley
In case you are not familiar with colour in a terminal environment
https://en.wikipedia.org/wiki/File:Slrn.png
Which is only an example. The wiki entry says Slrn was developed for
VMS. S-lang is available for VMS, as well as jed. There are various jed
modes for especially VMS, (DCL, MMS/MMK, ...) using colours for syntax
highlighting.
It wasn't so much the slrn application and S-lang library I was talking
about, but I was instead using it as an example of how the use of colour
enhances the display of information.
Simon.
I think I understood, but maybe I didn't. S-lang obviously supports
colours on VMS. The S-lang sources include the file(s slcurses.c and)
slcurses.h. In slcurses.h I see

$ search [-.src]slcurses.h /match=and #define, has_colors
#define has_colors SLcurses_has_colors

So I try to use it with your demo source and

$ ty first.h
#include "../src/slcurses.h"
#define __CURSES_LOADED 1
$
$ cc colour_map/first=[]first.h/include=[-.src]/name=as_is
$ link colour_map,[-.src]slang/lib
$ run colour_map

And voilà I get the coloured "text".
Simon Clubley
2017-06-23 07:22:09 UTC
Permalink
Raw Message
Post by hb
Post by Simon Clubley
Post by hb
Post by Simon Clubley
In case you are not familiar with colour in a terminal environment
https://en.wikipedia.org/wiki/File:Slrn.png
Which is only an example. The wiki entry says Slrn was developed for
VMS. S-lang is available for VMS, as well as jed. There are various jed
modes for especially VMS, (DCL, MMS/MMK, ...) using colours for syntax
highlighting.
It wasn't so much the slrn application and S-lang library I was talking
about, but I was instead using it as an example of how the use of colour
enhances the display of information.
I think I understood, but maybe I didn't. S-lang obviously supports
colours on VMS. The S-lang sources include the file(s slcurses.c and)
slcurses.h. In slcurses.h I see
The confusion comes from the fact that I had totally missed that S-lang
has some curses enhancements which could be used.

Because I use slrn I used an image of it to demonstrate to Jan-Erik
the difference colour makes and nothing more. I hadn't even considered
that there might be something usable within S-lang.

I would prefer to only use libraries which ship with VMS but you
have still given me another option to consider.

Thank you,

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Soderholm
2017-06-23 09:31:10 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by hb
Post by Simon Clubley
Post by hb
Post by Simon Clubley
In case you are not familiar with colour in a terminal environment
https://en.wikipedia.org/wiki/File:Slrn.png
Which is only an example. The wiki entry says Slrn was developed for
VMS. S-lang is available for VMS, as well as jed. There are various jed
modes for especially VMS, (DCL, MMS/MMK, ...) using colours for syntax
highlighting.
It wasn't so much the slrn application and S-lang library I was talking
about, but I was instead using it as an example of how the use of colour
enhances the display of information.
I think I understood, but maybe I didn't. S-lang obviously supports
colours on VMS. The S-lang sources include the file(s slcurses.c and)
slcurses.h. In slcurses.h I see
The confusion comes from the fact that I had totally missed that S-lang
has some curses enhancements which could be used.
Because I use slrn I used an image of it to demonstrate to Jan-Erik
the difference colour makes and nothing more.
And you totaly missed my point... :-)

New development for VMS is not done on the VT-screen platform.
That is why I do not find *this* (color support for VT-screens)
to be a major issue for VMS today.

I fully understand what colors are and that different colors
looks different from each other. At least to most people... :-)

I see little reason to rewrite all current VT-based VMS utilities
to make use of colors. If you want something more graphical than
MONOTOR, you can run MonDeSi that displays in a web browser.

An example screen copy:
Loading Image...

It is also installed on Decuserve, not responding at the moment:
https://www.decuserve.org/cgiplus-bin/mondesi

The reason that color support is missing from curses on VMS is
probably that there has been no business case that asked for it.
Just provide that business case and I'm sure it can be "fixed".

Regards, and a happy Midsummer to everyone!
https://sweden.se/culture-traditions/midsummer/

Jan-Erik.


I hadn't even considered
Post by Simon Clubley
that there might be something usable within S-lang.
I would prefer to only use libraries which ship with VMS but you
have still given me another option to consider.
Thank you,
Simon.
Mark Daniel
2017-06-23 09:59:14 UTC
Permalink
Raw Message
On 23/6/17 7:01 pm, Jan-Erik Soderholm wrote:
8< snip 8<
Post by Jan-Erik Soderholm
I see little reason to rewrite all current VT-based VMS utilities
to make use of colors. If you want something more graphical than
MONOTOR, you can run MonDeSi that displays in a web browser.
https://wasd.vsm.com.au/wasd_root/src/mondesi/mondesi.png
https://www.decuserve.org/cgiplus-bin/mondesi
8< snip 8<

https://eisner.decuserve.org/cgiplus-bin/mondesi

www.decuserve.org not exactly AWOL but close enough ...

HTTP/1.0 200 OK
Cache-Control: max-age=900
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 23 Jun 2017 09:56:16 GMT
Content-Length: 225
Age: 7

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>

This website is temporarily unavailable, please try again later.

<!-- pageok -->
<!-- 10 -->
<!-- -->
</html>
Craig A. Berry
2017-06-24 02:30:29 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
New development for VMS is not done on the VT-screen platform.
What is your basis for saying that, and what do you use for VMS
development? I'm not saying you're wrong -- I really want to know. I
still use a terminal session for developing on VMS because I've never
found anything else that actually works with reasonable performance and
reliability.

For example, I've heard people here saying that they use jEdit, so a few
minutes ago I downloaded and installed it, and then fired it up. It's
beautiful and made me think for a minute that the desktop on VMS could
come back after all. Then I tried to open a file and edit it.

My 48-line login.com took 12 seconds to load after double-clicking on it
in the file dialog. It took 7 seconds to highlight a word after
double-clicking. Choosing a menu item, or doing page up or page down,
took about 10 seconds each. That's an order of magnitude or two above
tolerable. This is under XQuartz on macOS on a three-year-old Powerbook
Pro connecting to an rx2660 on my local network. Ping latency is 1.5 ms.

I tried NetBeans when it was supported, both the on-VMS version and the
client/server version. I don't recall its being quite this bad, but it
was pretty bad, performance-wise. I'm quite familiar with copying files
back and forth, but that's an awfully crude and error-prone way to edit
files that ultimately need to reside on VMS. There's no up-to-date SMB
server on VMS and most of what I hear about the NFS client is horror
stories. BBEdit as an sftp client shows more promise than most, so I may
have to revisit that.

With all of the above except NetBeans, you still have to have a terminal
session open to compile, link, and run your code, unless it's Java,
Perl, or Python and you develop it elsewhere and only deploy on VMS, but
that seems unlikely to be a very big portion of applications running on VMS.

So, I keep using my custom TPU section that I've been dragging around
for a quarter century. It works ok, but I do wish it could do color
syntax highlighting :-).
Robert A. Brooks
2017-06-24 03:56:20 UTC
Permalink
Raw Message
Post by Craig A. Berry
So, I keep using my custom TPU section that I've been dragging around
for a quarter century.
Young'un!

My EDTINI.EDT file is largely unchanged since 1981, RSTS/E heritage.
--
-- Rob
Henry Crun
2017-06-24 04:31:02 UTC
Permalink
Raw Message
Post by Robert A. Brooks
Post by Craig A. Berry
So, I keep using my custom TPU section that I've been dragging around
for a quarter century.
Young'un!
My EDTINI.EDT file is largely unchanged since 1981, RSTS/E heritage.
...and my TPU section file is (mainly) a carry-over from RSTS, started in '85.
with definitions for right-to-left typing, buffer includes etc.
When did TPU start replacing EDT?
--
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html
Robert A. Brooks
2017-06-24 13:01:47 UTC
Permalink
Raw Message
Post by Henry Crun
Post by Robert A. Brooks
Post by Craig A. Berry
So, I keep using my custom TPU section that I've been dragging around
for a quarter century.
Young'un!
My EDTINI.EDT file is largely unchanged since 1981, RSTS/E heritage.
...and my TPU section file is (mainly) a carry-over from RSTS, started in '85.
with definitions for right-to-left typing, buffer includes etc.
When did TPU start replacing EDT?
I think TPU came with VAX/VMS V4.2. Might have been V4.4, but I'm sure
it was one of those two versions.
--
-- Rob
Jan-Erik Soderholm
2017-06-24 13:07:57 UTC
Permalink
Raw Message
Post by Henry Crun
When did TPU start replacing EDT?
Others know that better than me. What I do know is that
TPU has not finished replacing EDT yet... :-)
Simon Clubley
2017-06-24 19:02:25 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by Henry Crun
When did TPU start replacing EDT?
Others know that better than me. What I do know is that
TPU has not finished replacing EDT yet... :-)
When I moved from RSTS/E to VMS in the early 1990s, EVE and TPU
instantly replaced both EDT and TECO for me and I never looked back.

I still remember thinking after the first day or so of using EVE
and the underlying TPU language how much better it was than what
I had used up to that point; there was an instant positive liking
for EVE/TPU from me.

I've just had an idea, but I will ask that in another thread. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
David Froble
2017-06-24 14:24:05 UTC
Permalink
Raw Message
Post by Henry Crun
Post by Robert A. Brooks
Post by Craig A. Berry
So, I keep using my custom TPU section that I've been dragging around
for a quarter century.
Young'un!
My EDTINI.EDT file is largely unchanged since 1981, RSTS/E heritage.
...and my TPU section file is (mainly) a carry-over from RSTS, started in '85.
with definitions for right-to-left typing, buffer includes etc.
When did TPU start replacing EDT?
Depends who you're asking. For me, it's never happened.
Arne Vajhøj
2017-06-24 19:56:52 UTC
Permalink
Raw Message
Post by Henry Crun
When did TPU start replacing EDT?
I think 4.4, but I am not 100% sure as 4.4 was my first VMS version.

Arne
Craig A. Berry
2017-06-24 13:01:43 UTC
Permalink
Raw Message
Post by Robert A. Brooks
Post by Craig A. Berry
So, I keep using my custom TPU section that I've been dragging around
for a quarter century.
Young'un!
Well I was using EDT before that, obviously :-).
Post by Robert A. Brooks
My EDTINI.EDT file is largely unchanged since 1981, RSTS/E heritage.
Jan-Erik Soderholm
2017-06-24 09:56:09 UTC
Permalink
Raw Message
Post by Craig A. Berry
Post by Jan-Erik Soderholm
New development for VMS is not done on the VT-screen platform.
What is your basis for saying that, and what do you use for VMS
development?
Sorry, I was unclear. *I* use VMS for VMS development. What I meant was
that the users are less and less using VT-screens as their application
user-interface run-time environment.

Maybe "on the VT-screen" should have been "for the VT-screen" above.

Yes, a lot can be done to modernize the VMS development tools, and I
guess that will happen on desktop type of environments. I do not see
a lot of time and money spent on pure VMS application tools, apart
from the server parts to support the desktop IDE's.
Post by Craig A. Berry
I'm not saying you're wrong -- I really want to know.
There you are, I was unclear... :-)
Post by Craig A. Berry
...
With all of the above except NetBeans, you still have to have a terminal
session open to compile, link, and run your code,...
I have done som tests with UltraEdit-32 (would probably be similar with
their UEStudio that shares features). It has full FTP/SFTP/SSH support
builtin so you can directy edit remote files and run terminal sessions
within the IDE itself to run your builds. It has a powerfull scripting
environment so I'm sure you can automate that also.

See: https://www.ultraedit.com/products/ultraedit/features.html#prog

"Robust server support including AIX / AS400 / BS2000 / MVS / HP3000 /
OpenVMS / OS9000 / Stratus VOS / Tandem / UNIX / VShell (and auto-detection
of server type)"

The FTP support is fully integrated in the "Open" and "Save as" dialoges.

Remote debugging isn't there, that has to be done the traditional way.

It does have language files for many different programming languages,
but no VMS specific extensions or so. The language files are open
source and there are already third part files, so technically there
is no issue to make VMS specific language support. See:
https://www.ultraedit.com/downloads/extras/wordfiles.html
Search the page for "VMS"...


Anyway, if not using specifically UEStudio as the foundation, this is
how I see future VMS developments tools and IDEs being built.

Not by adding color support to HELP.

Jan-Erik.
Post by Craig A. Berry
unless it's Java,
Perl, or Python and you develop it elsewhere and only deploy on VMS, but
that seems unlikely to be a very big portion of applications running on VMS.
So, I keep using my custom TPU section that I've been dragging around
for a quarter century. It works ok, but I do wish it could do color
syntax highlighting :-).
hb
2017-06-24 10:58:04 UTC
Permalink
Raw Message
Post by Craig A. Berry
With all of the above except NetBeans, you still have to have a terminal
session open to compile, link, and run your code, unless it's Java,
Perl, or Python and you develop it elsewhere and only deploy on VMS, but
that seems unlikely to be a very big portion of applications running on VMS.
For what it is worth, for/on VMS I use XTerm and jed - in EDT mode, with
my jed modes doing syntax colouring for DCL, MMS/MMK, Linker options,
Modparams, SDL, BLISS and Macro32.

For C, C++ I copy the sources back and forth and use Eclipse on a Linux
system, with some tweaks so that gcc only uses VMS supplied include
files and "builds" are compile only, no assembly nor link. Obviously I
still have to compile and link on VMS, but I can take advantage of all
the Eclipse features while editing the sources. Here for DCL, MMS/MMK
and Linker options I use my Editor plugin.
Stephen Hoffman
2017-06-24 17:34:23 UTC
Permalink
Raw Message
...With all of the above except NetBeans, you still have to have a
terminal session open to compile, link, and run your code, unless it's
Java, Perl, or Python and you develop it elsewhere and only deploy on
VMS, but that seems unlikely to be a very big portion of applications
running on VMS.
So, I keep using my custom TPU section that I've been dragging around
for a quarter century. It works ok, but I do wish it could do color
syntax highlighting :-).
The OpenVMS IDEs I've tried aren't up to the same level of OpenVMS
integration and polish, nor to the same level of performance of various
IDEs running on other platforms. That'll come, of course. Of the
available IDEs, the LSEDIT IDE does perform well, but is severely
lacking in a number of areas. Syntax highlighting, source code
formatting, etc. The portable IDEs definitely have more capabilities
than what is available in LSEDIT. The portable IDEs I've tried do run
faster on on x86-64 systems and I've done some cross-platform
development on OpenVMS using them, though (unsurprisingly) the native
IDEs such as Xcode and Visual Studio do have better performance. I'm
not at all certain whether that performance difference is due to the
hardware underneath OpenVMS, or due to the Java performance, or quite
possibly both. Like you, I've stayed with an older means of source
code development while working on OpenVMS and with all that approach
lacks, because the available tools just haven't gotten sufficient
support and integration from OpenVMS. Better integration involves
access to the documentation, the debugger, the compiler diagnostics and
analysis files, and improvements to the performance of the Java and
other languages, as well as faster underlying hardware. The folks that
are working on the IDEs at VSI and third parties undoubtedly know all
of this too, and — for folks that have worked with Xcode, Visual Studio
or JetBrains — the gaps in the OpenVMS tools that would allow the VSI
and third-party IDEs better integration and better capabilities are
certainly apparent.

For now, vim and LSEDIT and command-line on OpenVMS. Though that's
unfortunately limiting. No, I'm not going back to EDT. But then I'm
sure that SSDs makes EDT work better than it once did.

Yes, there are problems with Xcode, Visual Studio, JetBrains, LSEDIT,
Eclipse, and many (all?) other development tools. None are perfect.
Far from it.

Yes, I know from and use artistic style source code formatter, and
other tools that can be useful on OpenVMS and other platforms, too.
(Add a source code formatter into a check-in hook in your source pool
management tool, too. That gets all the source code consistently
formatted, and reduces that particular aspect of herding cats. But I
digress.)

We're just not in an era when a whole lot of developers are interested
in routinely dealing with command-line application development. I'm
certainly not, and I know how to do it. Nor are we in an era when
that's a particularly efficient way to develop applications. This
having used native IDEs myself. While the need to do command-line
work will never completely go away, the business is entirely headed
toward IDEs. As compared with when I first started looking at and
much of my early experience with IDEs from years ago — back when the
IDEs often entirely stank on their target native platforms — the
available development tools and features and capabilities and
performance and related factors have all changed. The better IDEs are
definitely useful and increasingly so, and make for easier and better
development. And yes, IDEs and better tools and newer languages are a
change from how we've always done things. We're busy automating
ourselves, too. Welcome to computing.
--
Pure Personal Opinion | HoffmanLabs LLC
Bill Gunshannon
2017-06-24 21:34:09 UTC
Permalink
Raw Message
Post by Stephen Hoffman
...With all of the above except NetBeans, you still have to have a
terminal session open to compile, link, and run your code, unless it's
Java, Perl, or Python and you develop it elsewhere and only deploy on
VMS, but that seems unlikely to be a very big portion of applications
running on VMS.
So, I keep using my custom TPU section that I've been dragging around
for a quarter century. It works ok, but I do wish it could do color
syntax highlighting :-).
The OpenVMS IDEs I've tried aren't up to the same level of OpenVMS
integration and polish, nor to the same level of performance of various
IDEs running on other platforms.
Has anyone ever tried to use jGrasp on VMS? It's Java code so it
should work. Of course, requires a GUI so I would assume DECWindows
and a remote terminal of some kind.

bill
Kerry Main
2017-06-25 01:20:41 UTC
Permalink
Raw Message
-----Original Message-----
Stephen Hoffman via Info-vax
Sent: June 24, 2017 1:34 PM
Subject: Re: [Info-vax] Does VMS curses support colour ?
...With all of the above except NetBeans, you still have to have a
terminal session open to compile, link, and run your code, unless it's
Java, Perl, or Python and you develop it elsewhere and only deploy on
VMS, but that seems unlikely to be a very big portion of applications
running on VMS.
So, I keep using my custom TPU section that I've been dragging around
for a quarter century. It works ok, but I do wish it could do color
syntax highlighting :-).
The OpenVMS IDEs I've tried aren't up to the same level of OpenVMS
integration and polish, nor to the same level of performance of various
IDEs running on other platforms. That'll come, of course. Of the
available IDEs, the LSEDIT IDE does perform well, but is severely
lacking in a number of areas. Syntax highlighting, source code
formatting, etc. The portable IDEs definitely have more capabilities
than what is available in LSEDIT. The portable IDEs I've tried do run
faster on on x86-64 systems and I've done some cross-platform
development on OpenVMS using them, though (unsurprisingly) the
native
IDEs such as Xcode and Visual Studio do have better performance. I'm
not at all certain whether that performance difference is due to the
hardware underneath OpenVMS, or due to the Java performance, or quite
possibly both. Like you, I've stayed with an older means of source
code development while working on OpenVMS and with all that
approach
lacks, because the available tools just haven't gotten sufficient
support and integration from OpenVMS. Better integration involves
access to the documentation, the debugger, the compiler diagnostics and
analysis files, and improvements to the performance of the Java and
other languages, as well as faster underlying hardware. The folks that
are working on the IDEs at VSI and third parties undoubtedly know all
of this too, and — for folks that have worked with Xcode, Visual Studio
or JetBrains — the gaps in the OpenVMS tools that would allow the VSI
and third-party IDEs better integration and better capabilities are
certainly apparent.
For now, vim and LSEDIT and command-line on OpenVMS. Though that's
unfortunately limiting. No, I'm not going back to EDT. But then I'm
sure that SSDs makes EDT work better than it once did.
Yes, there are problems with Xcode, Visual Studio, JetBrains, LSEDIT,
Eclipse, and many (all?) other development tools. None are perfect.
Far from it.
Yes, I know from and use artistic style source code formatter, and
other tools that can be useful on OpenVMS and other platforms, too.
(Add a source code formatter into a check-in hook in your source pool
management tool, too. That gets all the source code consistently
formatted, and reduces that particular aspect of herding cats. But I
digress.)
We're just not in an era when a whole lot of developers are interested
in routinely dealing with command-line application development. I'm
certainly not, and I know how to do it. Nor are we in an era when
that's a particularly efficient way to develop applications. This
having used native IDEs myself. While the need to do command-line
work will never completely go away, the business is entirely headed
toward IDEs. As compared with when I first started looking at and
much of my early experience with IDEs from years ago — back when the
IDEs often entirely stank on their target native platforms — the
available development tools and features and capabilities and
performance and related factors have all changed. The better IDEs are
definitely useful and increasingly so, and make for easier and better
development. And yes, IDEs and better tools and newer languages are a
change from how we've always done things. We're busy automating
ourselves, too. Welcome to computing.
Have you tried using NXTware Remote from eCube?

< http://www.ecubesystems.com/products/nxtware-remote.html>
[click on video testimonial from leading credit card company]

" NXTware Remote makes remote agile development possible for OpenVMS, Unix/Linux, and other operating systems from Windows or Linux workstations. It simplifies remote development for C, C++, COBOL, BASIC, Pascal, FORTRAN and Java developers, making them more productive."

"NXTware Remote is a distributed integrated development environment comprised of two components: NXTware Remote Server and NXTware Remote Studio, an Eclipse plug-in. Together, they enable developers to use modern IDEs to analyze and edit code on local workstations then compile, debug and deploy them on any remote server with greater productivity, better code quality and the agility needed to meet future needs."

Bottom line - there are better IDE options for OpenVMS available today if you find EDT / LSE is not enough.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Arne Vajhøj
2017-06-24 19:55:48 UTC
Permalink
Raw Message
Post by Craig A. Berry
Post by Jan-Erik Soderholm
New development for VMS is not done on the VT-screen platform.
What is your basis for saying that, and what do you use for VMS
development? I'm not saying you're wrong -- I really want to know. I
still use a terminal session for developing on VMS because I've never
found anything else that actually works with reasonable performance and
reliability.
It probably varies.

I would expect two large categories:
* those that develop on VMS using VT, DCL and one of EDT/TPU/LSE
like they have for the last 30-40 years
* those that develop on a PC using modern tools and just move files
up and build on VMS
Post by Craig A. Berry
For example, I've heard people here saying that they use jEdit, so a few
minutes ago I downloaded and installed it, and then fired it up. It's
beautiful and made me think for a minute that the desktop on VMS could
come back after all. Then I tried to open a file and edit it.
My 48-line login.com took 12 seconds to load after double-clicking on it
in the file dialog. It took 7 seconds to highlight a word after
double-clicking. Choosing a menu item, or doing page up or page down,
took about 10 seconds each. That's an order of magnitude or two above
tolerable. This is under XQuartz on macOS on a three-year-old Powerbook
Pro connecting to an rx2660 on my local network. Ping latency is 1.5 ms.
Very difficult to troubleshoot based based on this information.

I have seen jEdit work acceptable on VMS.

As all Java applications it like (after VMS standard) huge amount
of memory.
Post by Craig A. Berry
So, I keep using my custom TPU section that I've been dragging around
for a quarter century. It works ok, but I do wish it could do color
syntax highlighting :-).
I also have a highly customized EVE based on what I did in easter 1987.

:-)

Arne
Stephen Hoffman
2017-06-22 16:04:14 UTC
Permalink
Raw Message
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
long time.
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
mine).
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
that matter.
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
environments.

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
Jan-Erik Soderholm
2017-06-22 16:19:10 UTC
Permalink
Raw Message
Post by Stephen Hoffman
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
long time.
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
mine).
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.
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 that matter.
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 environments.
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.
A lot of quite contentless words, as usual.

Yes, *we* happens to use DS20's, but what on earth does that
have to do with anything? You, Stephen, is only using that as
a way to say thay I must be wrong. I do not like that. And
what has *Rdb* to do with color on the screens? Come on, I
do think that you can do better, Stephen.

Ayyway, I do not think we have built any new UI on VT-screens
for a decade. Most new additions are using web UIs.

I stand that color support in curses will be fairly far down
the list of enhancements...

Gosh...
Steven Schweda
2017-06-22 18:57:37 UTC
Permalink
Raw Message
[...] Search that with caution, unless you're using the Freeware
libext tool from Freeware V7. [...]
With my limited access to compiler updates, it hasn't come up much
lately, but I have a CHEADER.COM script which says:

$! 4 January 2009. SMS.
$!
$! Extract C header files from the text libraries (as in the old
$! days).
$!
$! SYS$LIBRARY:DECC$RTLDEF.TLB ->
$! SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]
$!
$! SYS$LIBRARY:SYS$STARLET_C.TLB ->
$! SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C]

Nothing fancy, but it does keep the loose-file collection useful.
For the record:

alp $ show logi decc_include
"DECC_INCLUDE" = "SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]"
(LNM$SYSTEM_TABLE)
= "SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C]"
Craig A. Berry
2017-06-22 11:58:22 UTC
Permalink
Raw Message
Post by Simon Clubley
For goodness sake, is there _anything_ in VMS which is at least
half-way up to date ? :-(
Bill Pedersen was working on a new port of ncurses but I'm
not sure how far it got:

<https://sourceforge.net/p/vms-ports/ncurses/ci/default/tree/>
Steven Schweda
2017-06-22 12:17:50 UTC
Permalink
Raw Message
Post by Simon Clubley
For goodness sake, is there _anything_ in VMS which is at
least half-way up to date ? :-(
Perhaps some things demanded by paying customers.
Post by Simon Clubley
[...] Does the missed support create the ANSI escape codes
for color handling? [...]
Knowing nothing, I'd guess that the termcap/terminfo stuff
is supposed to handle such details (if you have termcap
and/or terminfo on your system).
Jan-Erik Soderholm
2017-06-22 13:04:39 UTC
Permalink
Raw Message
Post by Steven Schweda
Post by Simon Clubley
For goodness sake, is there _anything_ in VMS which is at
least half-way up to date ? :-(
Perhaps some things demanded by paying customers.
Post by Simon Clubley
[...] Does the missed support create the ANSI escape codes
for color handling? [...]
Knowing nothing, I'd guess that the termcap/terminfo stuff
is supposed to handle such details (if you have termcap
and/or terminfo on your system).
OK. My point was if there is anything currently having an issue
on VMS becuse of this lacking color support i C? Who needs it
and why is it needed?
Scott Dorsey
2017-06-22 13:33:07 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by Steven Schweda
Post by Simon Clubley
For goodness sake, is there _anything_ in VMS which is at
least half-way up to date ? :-(
Perhaps some things demanded by paying customers.
Post by Simon Clubley
[...] Does the missed support create the ANSI escape codes
for color handling? [...]
Knowing nothing, I'd guess that the termcap/terminfo stuff
is supposed to handle such details (if you have termcap
and/or terminfo on your system).
OK. My point was if there is anything currently having an issue
on VMS becuse of this lacking color support i C? Who needs it
and why is it needed?
A lot of Unix software uses the color support, most notably things like vim
and some of the data entry stuff. A lot of installers use it now too. I
do not think that it is essential for anything, but it certainly makes many
things easier and so I would call those issues. Not serious ones, but issues.

That said, implementing the seven short functions that are required to
manipulate colors should be an hour or so worth of work for someone familiar
with curses. It's not like porting java.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Stephen Hoffman
2017-06-22 16:24:04 UTC
Permalink
Raw Message
Post by Scott Dorsey
A lot of Unix software uses the color support, most notably things like
vim and some of the data entry stuff.
Various Unix system startups use colors. These UI designs are akin to
system status dashboards. These designs are a whole lot easier to
review quickly than the usual wall of free-format text output by the
Integrity server consoles and the startups of many OpenVMS servers, too.
--
Pure Personal Opinion | HoffmanLabs LLC
John E. Malmberg
2017-06-22 13:36:53 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by Steven Schweda
Post by Simon Clubley
For goodness sake, is there _anything_ in VMS which is at
least half-way up to date ? :-(
Perhaps some things demanded by paying customers.
Post by Simon Clubley
[...] Does the missed support create the ANSI escape codes
for color handling? [...]
Knowing nothing, I'd guess that the termcap/terminfo stuff
is supposed to handle such details (if you have termcap
and/or terminfo on your system).
OK. My point was if there is anything currently having an issue
on VMS becuse of this lacking color support i C? Who needs it
and why is it needed?
The GNV Coreutils and Bash, and other projects provides code to do a
mostly read-only termios emulation on VMS. I have mostly only
implemented what the projects have needed so far.

https://sourceforge.net/p/gnv/bash_vms/ci/V4.2/tree/vms_source/bash/report_termcap.c

https://sourceforge.net/p/gnv/bash_vms/ci/V4.2/tree/vms_source/bash/vms_term.c

Note that some linux termcap entries for VT series terminals do not have
any documentation for what they are for that I could find.

Regards,
-John
***@qsl.net_work
Loading...