[Info-vax] VMS 5.5-2, DECwindows and remote X displays

[NOSKCAJ::RENSIE]

On Sun, 22 Jul 2018 18:15:49 -0400, Stephen Hoffman wrote:

> On 2018-07-22 22:04:04 +0000, hans.huebner at gmail.com said:
> 
>> Am Sonntag, 22. Juli 2018 17:54:42 UTC-4 schrieb Stephen Hoffman:
>>> On 2018-07-22 21:21:58 +0000, hans.huebner at gmail.com said:
>>>> I would like to run VMS 5.5-2 with DECwindows using a remote X
>>>> display> Ah, okay.   So you're trying to display the session manager
>>>> remotely.
>>> That's fairly typical.
>> 
>> While this is a typical thing to want, my particular problem is that I
>> want to do this using VMS 5.5-2, which does not have CDE or a display
>> manager.  The reason why I want this is VAX LISP, which links against
>> the DECwindows shared libraries of VMS 5.5 - On VMS 7.3, it does not
>> even start in graphical mode.
> 
> What is the error that this Lisp package is encountering with the newer
> DECwindows?   Maybe something to do with the removal of Adobe Postscript
> support?
> 
>> I'm m using Xorg using -ac to disable access control.  I am open to
>> suggestions as to what X server may work better with VMS 5.5, too.
> 
> I seriously doubt that switch disables enough here.
> 
> Or try Xming.  Again, with all security disabled.
> 
> Magic cookies, everything.
> 
> Check the X server log for details on the failures, too.
> 
>> I understand that newer versions of DECwindows play nicer with X
>> terminals, but I'm particularly interested in this old version.
> 
> Or use the command line?  That's how things were commonly done back
> then, after all.

Back in those days, both Unix and VMS too-readily assumed control of
the desktop; the stock Xstartup or Xsession script (I forget which)
would unilaterally a) reset the X server's font path and b) replace
the RESOURCE_MANAGER property of the root window.

So, in addition to the advice already given here, you could try
defeating WSINIT in sys$common:[sysmgr]decw$private_apps_setup.com
by redefining

$ decw$sessioninit == "run sys$system:decw$wsinit"

or saving both your font path and resources before calling the
login box and restoring them after.

Use: xset q | grep fp
to return your current fontpath; and

Use: xrdb -query
to return your current resources

But first, try to catch the error.  In addition to tailing the
X server's log, *do* check the client log in your home directory
sys$login:decw$sm.log.  Default is on, but if off, turn on the
log file for the session manager; again see private_apps_setup.com

$ decw$sessionlog == "true"

Not being able to find a font is enough to cause some clients to
abort so look for missing font errors in the log files and then
aliasing a font you do have to the missing ones using fonts.alias .

If VMS is serving fonts over a transport your X server understands
check connection-to and listing of fonts from the fonserver with
xlsfonts.  Serving X fonts is more trouble than its worth but once
important for licensing restrictions.  Better just have local
fonts on your X server.  Xorg has DECW support.

Lastly, do compare (as others have suggested) different X servers.
It will help understand which end X server/client the problem is.