Discussion:
Screen management in C
Add Reply
David Meyer
2024-12-27 14:24:05 UTC
Reply
Permalink
If I want to do screen management in a C program on OpenVMS, is it
better to use one of the curses packages in the C run-time library, or
the SMG$ run-time library? If the latter, is there any documentation on
how to call SMG$ routines from C?
--
David Meyer
Takarazuka, Japan
***@sdf.org
Arne Vajhøj
2024-12-27 15:17:27 UTC
Reply
Permalink
Post by David Meyer
If I want to do screen management in a C program on OpenVMS, is it
better to use one of the curses packages in the C run-time library, or
the SMG$ run-time library? If the latter, is there any documentation on
how to call SMG$ routines from C?
If you do not have any existing code using curses or personal
experience with curses, then I would suggest SMG$.

There is an entire manual about SMG$:

https://docs.vmssoftware.com/vsi-openvms-rtl-screen-management-smg-manual/

There is a C header file with prototypes:

#include <smg$routines.h>

Because SMG$ are supporting Pascal/Basic/Cobol/Fortran then
many arguments are pass by descriptor and you will need to setup
those in C, so some familiarity with descriptors will be required.

Arne
Craig A. Berry
2024-12-27 16:12:42 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by David Meyer
If I want to do screen management in a C program on OpenVMS, is it
better to use one of the curses packages in the C run-time library, or
the SMG$ run-time library? If the latter, is there any documentation on
how to call SMG$ routines from C?
If you do not have any existing code using curses or personal
experience with curses, then I would suggest SMG$.
https://docs.vmssoftware.com/vsi-openvms-rtl-screen-management-smg-manual/
#include <smg$routines.h>
Because SMG$ are supporting Pascal/Basic/Cobol/Fortran then
many arguments are pass by descriptor and you will need to setup
those in C, so some familiarity with descriptors will be required.
This has been discussed previously here:

https://groups.google.com/g/comp.os.vms/c/ufBEqvGdglU

That discussion has pointers to various examples, and Neil Rieck has
another example:

https://neilrieck.net/demo_vms_html/vt_smg_demo_c.html
Arne Vajhøj
2024-12-27 19:34:12 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Arne Vajhøj
Post by David Meyer
If I want to do screen management in a C program on OpenVMS, is it
better to use one of the curses packages in the C run-time library, or
the SMG$ run-time library? If the latter, is there any documentation on
how to call SMG$ routines from C?
If you do not have any existing code using curses or personal
experience with curses, then I would suggest SMG$.
https://docs.vmssoftware.com/vsi-openvms-rtl-screen-management-smg-
manual/
#include <smg$routines.h>
Because SMG$ are supporting Pascal/Basic/Cobol/Fortran then
many arguments are pass by descriptor and you will need to setup
those in C, so some familiarity with descriptors will be required.
https://groups.google.com/g/comp.os.vms/c/ufBEqvGdglU
That discussion has pointers to various examples,
In general VMS Pascal/VMS Basic code should be maybe 25% shorter
than equivalent C code. But with a descriptor centric API like
SMG$ then it may be more like 40% shorter.

One could make a nice wrapper in C++ encapsulating the context
and convert between stl::string / C char array and descriptors.

But then a full screen VT UI is a concept that has been obsolete
for 30 years, so maybe there is little point.

Arne
Single Stage to Orbit
2024-12-27 20:54:24 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Craig A. Berry
https://groups.google.com/g/comp.os.vms/c/ufBEqvGdglU
That discussion has pointers to various examples,
In general VMS Pascal/VMS Basic code should be maybe 25% shorter
than equivalent C code. But with a descriptor centric API like
SMG$ then it may be more like 40% shorter.
One could make a nice wrapper in C++ encapsulating the context
and convert between stl::string / C char array and descriptors.
But then a full screen VT UI is a concept that has been obsolete
for 30 years, so maybe there is little point.
People are still writing apps using the console.
--
Tactical Nuclear Kittens
Arne Vajhøj
2024-12-28 00:32:40 UTC
Reply
Permalink
Post by Single Stage to Orbit
Post by Arne Vajhøj
Post by Craig A. Berry
https://groups.google.com/g/comp.os.vms/c/ufBEqvGdglU
That discussion has pointers to various examples,
In general VMS Pascal/VMS Basic code should be maybe 25% shorter
than equivalent C code. But with a descriptor centric API like
SMG$ then it may be more like 40% shorter.
One could make a nice wrapper in C++ encapsulating the context
and convert between stl::string / C char array and descriptors.
But then a full screen VT UI is a concept that has been obsolete
for 30 years, so maybe there is little point.
People are still writing apps using the console.
There is still a need to write command line tools. Mostly
for system administrators and developers, but still there.

But full screen VT UI applications? I doubt many of those
get written today. Whether custom code using SMG$ or one
of TDMS/FMS/DECForms. The end users expectations for UI
has changed. GUI or Web.

Arne
Chris Townley
2024-12-28 01:10:12 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Single Stage to Orbit
Post by Arne Vajhøj
Post by Craig A. Berry
https://groups.google.com/g/comp.os.vms/c/ufBEqvGdglU
That discussion has pointers to various examples,
In general VMS Pascal/VMS Basic code should be maybe 25% shorter
than equivalent C code. But with a descriptor centric API like
SMG$ then it may be more like 40% shorter.
One could make a nice wrapper in C++ encapsulating the context
and convert between stl::string / C char array and descriptors.
But then a full screen VT UI is a concept that has been obsolete
for 30 years, so maybe there is little point.
People are still writing apps using the console.
There is still a need to write command line tools. Mostly
for system administrators and developers, but still there.
But full screen VT UI applications? I doubt many of those
get written today. Whether custom code using SMG$ or one
of TDMS/FMS/DECForms. The end users expectations for UI
has changed. GUI or Web.
Arne
In the mid naughties I used SMG to provide a better UI for HHTs on the
shop floor - using a terminal emulator on the HHTs

Far better than the earlier implementation.

This was in Basic, where I wrote a couple of functions to front end it,
then called the SMG routines.

Went down well on the shop floor
--
Chris
Arne Vajhøj
2024-12-28 01:25:41 UTC
Reply
Permalink
Post by Chris Townley
Post by Arne Vajhøj
Post by Single Stage to Orbit
Post by Arne Vajhøj
But then a full screen VT UI is a concept that has been obsolete
for 30 years, so maybe there is little point.
People are still writing apps using the console.
There is still a need to write command line tools. Mostly
for system administrators and developers, but still there.
But full screen VT UI applications? I doubt many of those
get written today. Whether custom code using SMG$ or one
of TDMS/FMS/DECForms. The end users expectations for UI
has changed. GUI or Web.
In the mid naughties I used SMG to provide a better UI for HHTs on the
shop floor - using a terminal emulator on the HHTs
Far better than the earlier implementation.
This was in Basic, where I wrote a couple of functions to front end it,
then called the SMG routines.
Went down well on the shop floor
Before VB6/Delphi, Web and smartphones/tablets, then full screen VT UI
was what most people were using - X GUI was rare. But that was then.

Arne
Dave Froble
2024-12-30 01:08:55 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Single Stage to Orbit
Post by Arne Vajhøj
Post by Craig A. Berry
https://groups.google.com/g/comp.os.vms/c/ufBEqvGdglU
That discussion has pointers to various examples,
In general VMS Pascal/VMS Basic code should be maybe 25% shorter
than equivalent C code. But with a descriptor centric API like
SMG$ then it may be more like 40% shorter.
One could make a nice wrapper in C++ encapsulating the context
and convert between stl::string / C char array and descriptors.
But then a full screen VT UI is a concept that has been obsolete
for 30 years, so maybe there is little point.
People are still writing apps using the console.
There is still a need to write command line tools. Mostly
for system administrators and developers, but still there.
But full screen VT UI applications? I doubt many of those
get written today. Whether custom code using SMG$ or one
of TDMS/FMS/DECForms. The end users expectations for UI
has changed. GUI or Web.
Arne
In the mid naughties I used SMG to provide a better UI for HHTs on the shop
floor - using a terminal emulator on the HHTs
Far better than the earlier implementation.
This was in Basic, where I wrote a couple of functions to front end it, then
called the SMG routines.
Went down well on the shop floor
And let me guess, a WEENDOZE GUI might not work so well on the shop floor?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Chris Townley
2024-12-30 01:39:36 UTC
Reply
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by Single Stage to Orbit
Post by Arne Vajhøj
Post by Craig A. Berry
https://groups.google.com/g/comp.os.vms/c/ufBEqvGdglU
That discussion has pointers to various examples,
In general VMS Pascal/VMS Basic code should be maybe 25% shorter
than equivalent C code. But with a descriptor centric API like
SMG$ then it may be more like 40% shorter.
One could make a nice wrapper in C++ encapsulating the context
and convert between stl::string / C char array and descriptors.
But then a full screen VT UI is a concept that has been obsolete
for 30 years, so maybe there is little point.
People are still writing apps using the console.
There is still a need to write command line tools. Mostly
for system administrators and developers, but still there.
But full screen VT UI applications? I doubt many of those
get written today. Whether custom code using SMG$ or one
of TDMS/FMS/DECForms. The end users expectations for UI
has changed. GUI or Web.
Arne
In the mid naughties I used SMG to provide a better UI for HHTs on the shop
floor - using a terminal emulator on the HHTs
Far better than the earlier implementation.
This was in Basic, where I wrote a couple of functions to front end it, then
called the SMG routines.
Went down well on the shop floor
And let me guess, a WEENDOZE GUI might not work so well on the shop floor?
Not that we got a chance, but I don't think it would have - especially
on a 12 X 21 character display!
--
Chris
Lawrence D'Oliveiro
2024-12-27 23:06:22 UTC
Reply
Permalink
But then a full screen VT UI is a concept that has been obsolete for 30
years
*cough* emacs -nw *cough*

Still useful over remote SSH.
Arne Vajhøj
2024-12-28 00:34:43 UTC
Reply
Permalink
Post by Lawrence D'Oliveiro
But then a full screen VT UI is a concept that has been obsolete for 30
years
*cough* emacs -nw *cough*
Still useful over remote SSH.
OK. Editors are a type of application where full screen VT UI
can still make sense.

Arne
Lawrence D'Oliveiro
2024-12-28 02:03:06 UTC
Reply
Permalink
Post by Lawrence D'Oliveiro
But then a full screen VT UI is a concept that has been obsolete for
30 years
*cough* emacs -nw *cough*
Still useful over remote SSH.
OK. Editors are a type of application where full screen VT UI can still
make sense.
Command-line multiplexors (e.g. screen and tmux) also effectively operate
full-screen, even if they’re just multiplexing among simple command lines.
Simon Clubley
2025-01-02 13:31:56 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Lawrence D'Oliveiro
But then a full screen VT UI is a concept that has been obsolete for 30
years
*cough* emacs -nw *cough*
Still useful over remote SSH.
OK. Editors are a type of application where full screen VT UI
can still make sense.
There's also a reason why RedHat still ships tools like nmtui as part
of the OS.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2024-12-28 16:52:46 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Craig A. Berry
Post by Arne Vajhøj
Because SMG$ are supporting Pascal/Basic/Cobol/Fortran then
many arguments are pass by descriptor and you will need to setup
those in C, so some familiarity with descriptors will be required.
https://groups.google.com/g/comp.os.vms/c/ufBEqvGdglU
That discussion has pointers to various examples,
In general VMS Pascal/VMS Basic code should be maybe 25% shorter
than equivalent C code. But with a descriptor centric API like
SMG$ then it may be more like 40% shorter.
One could make a nice wrapper in C++ encapsulating the context
and convert between stl::string / C char array and descriptors.
If anyone want to try, then I suggest:

$ CXX/POINTER=32 ...

or you will regret it.

Arne
Arne Vajhøj
2024-12-31 02:31:41 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by Craig A. Berry
Post by Arne Vajhøj
Because SMG$ are supporting Pascal/Basic/Cobol/Fortran then
many arguments are pass by descriptor and you will need to setup
those in C, so some familiarity with descriptors will be required.
https://groups.google.com/g/comp.os.vms/c/ufBEqvGdglU
That discussion has pointers to various examples,
In general VMS Pascal/VMS Basic code should be maybe 25% shorter
than equivalent C code. But with a descriptor centric API like
SMG$ then it may be more like 40% shorter.
One could make a nice wrapper in C++ encapsulating the context
and convert between stl::string / C char array and descriptors.
$ CXX/POINTER=32 ...
or you will regret it.
So I tried based on:
* almost 1:1 between wrapper methods and SMG$ functions
* integer in by reference -> by value
* integer out by reference -> integer return value
* string in by descriptor -> char* or stl::string in
* string out by descriptor -> stl::string return value
* status code -> throw exception
* expose displayid, pasteboardid and keyboardid so wrapper
can be mixed with custom SMG$ function calls
* use original SMG$ constants

Example:

#include <iostream>

using namespace std;

#include "smg.h"

int main(int argc, char *argv[])
{
try
{
SMG smg(true);
smg.PutString(1, 1, "AA");
smg.PutString(1, 3, "BB", SMG$M_BOLD);
smg.PutString(1, 5, "CC", SMG$M_UNDERLINE);
smg.PutString(1, 7, "DD", SMG$M_REVERSE);
smg.DrawRectangle(17, 1, 5, 78);
smg.DrawHorLine(19, 2, 76);
smg.PutString(18, 2, "ABC");
smg.PutString(20, 2, "123");
smg.PutString(2, 1, ">>>> ");
string reply = smg.GetString(2, 6);
smg.PutString(3, 1, "You entered: " + reply);
smg.PutString(4, 1, "Hit PF1 to exit");
while(smg.GetKey() != SMG$K_TRM_PF1);
}
catch(SMGexception& ex)
{
cout << ex.what() << endl;
}
return 0;
}

If anyone is interested I will make the code available.

Arne
Lawrence D'Oliveiro
2024-12-31 03:38:59 UTC
Reply
Permalink
Post by Arne Vajhøj
while(smg.GetKey() != SMG$K_TRM_PF1);
Is it possible to hook this kind of thing into an event loop? Some
equivalent of select/poll?

That would make it easier to do things like handle multiple terminals at
once.
Arne Vajhøj
2024-12-31 04:06:10 UTC
Reply
Permalink
Post by Lawrence D'Oliveiro
Post by Arne Vajhøj
while(smg.GetKey() != SMG$K_TRM_PF1);
Is it possible to hook this kind of thing into an event loop? Some
equivalent of select/poll?
That would make it easier to do things like handle multiple terminals at
once.
I think that would be using a screwdriver to hammer a nail in with.

One could create a loop around smg$read_keystroke, replace
all smg$read_string call with lots of application code,
open multiple virtual keyboards to multiple terminals
(input device is an argument), use smg$read_keystroke
with a timeout and try multiple virtual keyboards.

It would require lots of code and perform poorly. And
I don't really see the use case.

Arne
Lawrence D'Oliveiro
2024-12-31 05:13:54 UTC
Reply
Permalink
One could create a loop around smg$read_keystroke, replace all
smg$read_string call with lots of application code,
open multiple virtual keyboards to multiple terminals (input device is
an argument), use smg$read_keystroke with a timeout and try multiple
virtual keyboards.
That’s why a poll/select-type architecture would be much, much simpler.
Stephen Hoffman
2024-12-28 04:04:46 UTC
Reply
Permalink
Post by David Meyer
If I want to do screen management in a C program on OpenVMS, is it
better to use one of the curses packages in the C run-time library, or
the SMG$ run-time library? If the latter, is there any documentation on
how to call SMG$ routines from C?
Using HTTP via CGI or Tomcat or otherwise would be one potential
choice, possibly viewing the UI using the old Mosaic port.

The older curses would be portable and familiar to C developers, though
that well predates the more common and familiar ncurses.

Or use X11 with CDE or Motif, though that too is quite dated.

Maybe port termbox2 <https://github.com/termbox/termbox2> to OpenVMS as
an alternative, and the effort involved with porting that code to
OpenVMS should also increase familiarity with OpenVMS programming.

SMG has been mentioned, and that has been discussed here over the
decades. Including previous discussions of the SMG calls that cause the
most confusion.

If you want the full OpenVMS experience, scrounge yourself copies of
the FMS or DECforms layered products somewhere, and write yourself a
truly non-portable app.
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...