/ 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
%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:
%CC-E-TOOFEWARGS, In this statement, "gettimeofday" expects 2 arguments, but 1
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:
- resources.c doesn't have XK_Left (and other XK_) constants declared. Solved by #include <X11/keysymdef.h> in resources.c and #define XK_MISCELLANY in config.h
- #define HAVE_FCNTL 1
- #define HAVE_UNISTD_H 1
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.
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:
- fps.obj is required for everything
- screenhack-xlock no longer(?) exists, replaced with simple screenhack
- it's bubbles-default, not bubbles_default; however it still draws empty circles (something to do with pixmap?)
- it's hopalong, not hop
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.
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:
%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)
#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:
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
- replaced demo with demo-xm - not good
- xscreensaver requires prefs
--- 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:
- Abstractile requires quite a lot of memory - the default PGFLQUOTA of 32768 (=16MB of virtual memory) on VAX is not enough for it. And of course, on a system with 16MB of physical RAM it will start swapping heavily.
- celtic is using rint - defined as floor, but it's rather slow anyway.
- flow crashes with "floating overflow" after a few frames.
- FONTGLIDE: no scalable fonts found! (pattern: -*-*-*-*-*-*-0-0-0-0-p-0-iso8859-1) - this only happens on real VAX with DECWindows. Also no text to display (after Loading... but I didn't dig into this; I assume "iso8859" might be the problem)
- hyperball and hypercube also use rint but work fine (if a little bit slow for hyperball on the VLC) with floor
- piecewise - rint
- testx11 works after compiling [.glx]rotactor.c and adding its .obj to the linker list
- Slow hacks: anemone, anemotaxis, cloudlife, celtic, coral (extremely slow), cwaves (extremely), eruption (extremely), euler2d, fiberlamp (extremely), flag, flow, fluidballs (extremely), fuzzyflakes (only on the VLC), galaxy, halftone, hexadrop (on the VLC), ifs (especially on the VLC), interaggregate, interference, julia, kumppa, lisa (on the VLC), metaballs (extremely), moire2 (extremely on the VLC), nerverot, piecewise (only on the VLC), pyro takes a funny break while computing "explosions" (i.e. right before one explodes), rd-bomb (extremely), speedmine, strange, swirl, whirlwindwarp, wormhole (on the VLC), xflame (extremely), xmatrix (extremely), xspirograph (on the VLC),
- Hacks using float variant of math functions: analogtv, binaryring, fireworkx, intermomentary, substrate, xanalogtv
- Hacks using grabclient don't work: blitspin, boxfit, bumps, decayscreen, distort, ripples, rotzoomer, slidescreen, slip, spotlight, tessellimage, twang, xanalogtv, zoom
- Changed images:
- Bubbles - plain circles. Oh, right, it requirex pixmap
- Compass - black band, rightside doesn't move - that is an interesting phenomenon, should check
- Crystal - only on the VLC it seems to remain in it's "building cache" mode? Problem is on display side (the VLC has 8bit display) - having the emulated VAX output on the VLC shows the glitch; the real HW displaying on modern X works
- Noseguy is linedrawn (no fill color, pixmap issues?) - but looks better like this!
- Pacman - pacman and ghosts drawn as rectangles (pixmap?). Also, after killing PM, the ghosts continue running over him, he doesn't reappear.
- A good effect only visible on real old hardware: swirl still uses colormap rotation (visible only on 8bpp displays)
- xflame is skewed sideways when displaying on the VLC
- xlyap - black screen, but maybe it's too slow
That's it for now, contact me
if you want the butchered code :)
Published 2016-12-27 by Mihai Gaitos - contacthawk.ro