hawk.ro / stories / XScreenSaver on VMS

Modern XScreenSaver on VMS

Some success... (this is running on VAXstation 4000 VLC)

Some time ago, upon release of XScreenSaver 5.35 by jwz, I remarked on a minor compilation problem and part of his answer was:

[...] and honestly I'm not sure if it even compiles on VMS any more.
That was enough reason to try (even though I did not think of this before) and, of course, the first try failed. The DCL file (MAKEVMS.COM) as well as CONFIG.H-VMS are intended for "OpenVMS V 6.x system with DEC C 5.x compiler". I was using OpenVMS V 7.3 with Compaq C 6.4 compiler. Slightly newer.
However, I think the main problem is not the VMS/DEC C version but the fact that XScreenSaver was continuously updated, while the build and configuration files stayed the same. Also C and X may have changed somewhat in the past 10-20 years.

CONFIG.H-VMS;1       21-MAR-2005 01:20:00.00
...
MAKEVMS.COM;1        26-JUL-1997 22:15:26.00
These come from XScreenSaver 5.35 released in May 2016. I'm glad they're there.

First steps - [.UTILS] - first problems

          socklen_t addrlen;
        ..^
%CC-E-MISSINGTYPE, Missing type specifier or type qualifier.
                At line number 104 in USERS:[HAWK.TMP.XSSO.UTILS]ASYNC_NETDB.H;1.

Quick fix: defined socklen_t as unsigned int in async_netdb.h (#ifdef VMS...)

Then, this happened:
	  gettimeofday(&now);
	..^
%CC-E-TOOFEWARGS, In this statement, "gettimeofday" expects 2 arguments, but 1
 are supplied.
		At line number 67 in DUA1:[HAWK.TMP.XSSO.UTILS]ERASE.C;1.

On this system, gettimeofday expects 2 arguments but there is no timezone struct defined in time.h. According to DEC/Compaq/HP documentation the second argument should be "A NULL pointer. If this argument is not a NULL pointer, it is ignored".

I noticed that there is a VMS-GTOD.C file that implements gettimeofday, but it's no longer included from most files (and it wouldn't work anyway). My current solution for this is to define the timezone struct inside utils.h in a vms-defs.h file that is conditionally included from utils.h and from yarandom.h (because yarandom doesn't #include utils.h).

Next come some warnings about fork, execvb and others being used in grabclient - I'll ignore those for the time being, I assume grabclient is used for screensaver hacks that modify the existing display, so I accept that those won't work.

The rest fits better in a list:

This (mostly) concludes [.UTILS] compilation. Remaining problems: grabclient use of fork (that doesn't exist in VMS) and use_subwindow_mode_p defined in both grabclient and grabscreen. I have noticed that because the last step of the compile procedure is creating a library of all the .OBJ files. Since grabclient has another problem with fork, I'll ignore this for now.

[.HACKS]

Compiling. Nice to see that COMPILE_DECC.COM seems to have been updated (I assume automatically) and it tries to compile every source file in the directory. Some notes:

Linking is where I see if the previous efforts were in vain. Since LINK_DECC.COM wasn't updated, it no longer fits:

Eventually I wrote a simple script to generate another "LINK_DECC.COM" file (without X11R4 detection/use) that I modified by hand for the few hacks requiring xlockmore or other special treatment. Most of the "simple" hacks work fine, at least standalone. More (too many?) notes regarding hacks are further down.

[.DRIVER]

The (VMS) scripts in here are 19 years old! Some files have been renamed, I assume demo-xm.c is the replacement for demo.c and demo-xm-widgets.c seems to have replaced dialogs-xm.c
Then something rather strange happened:

	  Bool enabled_p;
	..^
%CC-E-MISSINGTYPE, Missing type specifier or type qualifier.
		At line number 28 in DUA1:[HAWK.TMP.XSSO.DRIVER]TYPES.H;1.
First of many errors
a lot of messages about missing types, similar to the one above, all coming from types.h. Is types.h included too early? That's unlikely. This took a while to figure out. Eventually I realised that (on VMS) Xlib.h includes types.h (not sys/types.h). COMPILE_DECC.COM specifies the current directory to be searched for includes so when the compiler processes Xlib it includes types.h from xscreensaver.
#if defined(VMS) || defined(__VMS)
#include <types.h>
#include <decw$include/X.h>
#else
#include <sys/types.h>
#include <X11/X.h>
#endif /* VMS */
relevant part of VMS' Xlib.h
Solved by renaming types.h to jwztypes.h (and modifying auth.h and prefs.h with the new name).
In lock.c, vms_passwd_valid_p gets char *pw but tries to validate with typed_passwd:
static Bool
vms_passwd_valid_p(char *pw, Bool verbose_p)
{
  return (validate_user (getenv("USER"), typed_passwd) == 1);
}
changed to pw.

subprocs.c tries to include <sys/param.h> - hidden behind #ifdef

xscreensaver.c includes Xlibint.h that includes <Xproto.h> instead of <X11/Xproto.h>. The compiler complains that Xproto.h can't be found, solved by adding SYS$COMMON:[DECW$INCLUDE] to the list of includes on the command line.
Also on xscreensaver.c, it uses open but doesn't inlcude fcntl.h - added

on linking xscreensaver-remote, xscreensaver_command is not found. Now it's included in remote.c - compiled and added to link.com --- to be revised

--- it is at this point that I decided to take a break from this ---

Conclusion - not good

It seems that even though jwz's code is pretty portable, there still are problems, mainly with respect to X/DECWindows. For now (undefined interval) I decided to take a break from this.
Some notes about various hacks:

That's it for now, contact me if you want the butchered code :)


Published 2016-12-27 by Mihai Gaitos - contacthawk.ro