This document is intended to provide you with advice on how to configure the use of X-Windows between an emulator instance (either Tru64 or OpenVMS) and it’s Windows or Linux host.
For the purposes of this document, the following definitions apply:
| Term | Description |
|---|---|
| Host | The system on which the emulator runs, and also on which the X11 session is displayed |
| Guest | The emulated system, on which the X11 clients run |
There are various ways of methods and styles when using a separate system (X11 Server System, “Host”) to display applications running on an emulator (X11 Client System, “Guest”). The first thing to decide is if the entire “desktop environment” is to be transported to the Host. The entire desktop environment means a sessions begins with a graphical login window. The user must authenticate himself using credentials associated with the Guest. After authentication, a session manager, either CDE or DECwindows/Motif is started. Transporting the entire desktop environment will be referred to henceforth as the “Desktop Environment Session” (DES).
If transporting the DES is the goal, there are three ways of doing it:
If the DES is not to be transported to the Host, but rather only individual application windows, each application must be started on the Guest, possibly using a remote execution protocol such as rsh.
If the Host has multiple Windows screens (i.e. monitors), and you are planning to transport the DES, you must additionally decide if you want all (or some subset) of the Windows screens to appear to the Guest as one large screen, or as several screens. One large screen allows windows to span the Windows screens, and be moved anywhere within the one large logical screen. Configuring several logical screens means that applications on the Guest must explicitly be directed to screens other than the first, for example, using “<Host>:0.1” as the display target would cause the application window to be directed to the 2nd logical screen.
A DES should almost certainly be encapsulated in a single window, with or without a frame. This can be combined with XDMCP (the X11 Display Manager Control Protocol), if the Guest supports it.
| XDMCP | XDMCP allows the system on which an X-Server is running (the Host) to send a DES initiation request to the system (“Guest”) on which the user would like to run X-applications locally. The session is almost identical to sitting in front of the display connected to the original Alpha hardware. When a new session has been started, the standardX login screen is presented, and the user must authenticate himself. |
| NO XDMCP |
|
Without XDMCP, each application to be run on the guest system must be started individually. This is can be done from Windows using Putty with X11 tunneling enabled, if the Guest supports SSH. If the guest is running Tru64 V4.x or OpenVMS V7.1, it will not have an ssh-daemon. You have several choices in this case:
Keep in mind that both rsh and telnet transmit everything, including passwords, in clear text over the network.
X11 does not contain any provision for encrypting network traffic. This means you must satisfy one of the following conditions:
If you wish to use theWindows host as the X11-display for the emulator, I recommend setting up a virtual network on the Windows host using the “vmini” network driver.
You must use the “vmini” driver, because other virtual network drivers do not work with CHARON.
NOTE: be sure to disable any firewall on the virtual network devices
The procedure for configuring the host depends completely on whether it is running Windows or Linux.
This part will be enhanced/described later
In principle, it should be a relatively simple matter to configure the Linux host, because X11 is currently a standard Linux component. This will change soon, though, as many Linux distributions are evaluating new windowing systems, such as Wayland (RedHat, Fedora) or Mir (Ubuntu), which may not offer X11 compatibility.
You will need to install an X-Server on the Windows host. There are a variety to choose from. The Free and Open Source Software (FOSS) choices include Xming, VcXsrv, and the X-Server available as a package with Cygwin. There are many commercial packages available, including Hummingbird-Exceed, Reflection-X, X-WIN32 and MKS X-Server.
The Cygwin, Xming, and VcXsrv servers are all based on the X-Org open-source XServer. Xming and VcXsrv in particular are very similar. Xming actually has two versions, a current version (7.5.0.77) with bug-fixes and new features, for which a donation (suggested amount: GBP 10) is required. Without making a donation, and getting a donor password, you can only download and older version (6.9.0.31) from sourceforge (http://sourceforge.net/projects/xming). VcXsrv, on the other hand, seems to be relatively current, with bug fixes and new functionality.
This article will concentrate on using VcXsrv. Much will also apply to Xming, and to a certain extent, to the Cygwin server.
To install, download the Windows installer and run as “administrator”.
Start the VcXsrv “Xlaunch” program by clicking on Start → All Programs → VcXsrv → XLaunch.
A “Display settings” window will appear and lead you through a series of configuration screens. The first is “display settings”. There are four choices:
If you intend to use the XDMCP protocol, you can choose any but “Multiple windows”.
On the next screen (“start clients”), select XDMCP if you want it.
If you selected XDMCP, the next screen allows you to specify the system to which the XDMCP session should be initiated. I recommend enabling the “Terminate on server reset” option, which will cause the VcXsrv server to shutdown on logout. Otherwise,
the X-server may get into an endless loop when a session is terminated.
On the next screen (“Extra settings”), leave “Clipboard”, “Primary Selection”, and “Native opengl” selected. Do not select “Disable access control” unless you have a good reason to. In the “Additional parameters for VcXsrv” entry box, add “-from <address-of-windows-host>” if the Windows host has more than one IPaddress, otherwise VcXsrv will fail with an error message.
On the next and last screen, click on “Save configuration” and save to a permanent file somewhere thatmakes sense, such as C:\Xlaunch-Configs\<name>.xlaunch. After that you can click on “Cancel” to close the XLaunch dialog.
Set up a desktop icon by starting a “Windows Explorer” window, browsing to the VcXsrv installation directory, inmost cases “C:\Program Files\VcXsrv”, rightclicking-and-dragging the xlaunch.exe file to the desktop. Rename the icon to something that makes sense, and then right-click on it and select “Properties”. Append “-run <path-to-xlaunch-config-file>” in the “Target” Field, which already contains the path to the xlaunch command.
To configureVcXsrv to use severalmonitors as one large screen, add “-multimonitors” to the command line parameters. In an XLaunch file itmust be added to “ExtraParams”.
To add it to a VcXsrv desktop icon, right-click on the icon and select “Properties”. Add “-multimonitors” to the other parameters in the “Target” field.
To configure VcXsrv to use several monitors as distinct screens, add "-screen 0 @1 -screen 1 @2" (for two monitors) to the command line parameters. You can also add the “-xinerama” parameter – it depends if the X client programs are Xineramaaware.
Both V4 and V5 support XDMCP. You have two choices of how to start the DES:
The steps below apply to both scenarios above:
Make sure there is a symbolic link from /sbin/rc3.d/S95xlogin to /sbin/init.d/xlogin. If not, create it using:
|
After satisfying the above requirements, you can use VcXsrv to initiate the DES via XDMCP. If you prefer to configure the Guest to start the DES, you must add a line to the “/var/dt/Xservers” file of the form:
|
where <hostname> is the name the you entered in /etc/hosts for the Host.
This approach may be preferable. If the XDM on Tru64 cannot start the DES, for example because the X-Server is not running on the Host, it will wait patiently until the X-Server becomes ready. When a DES is terminated, Tru64 immediately starts a new one.
This part will be described later
Depending on the OpenVMS version, various methods and mechanisms may or may not be available.
Currently, this document contains information aboutV7.1 and V7.3-2. As new versions are tested, this document will be kept up to date. I tested V7.1 using the default UCX version 4.1 without any patches. The DECwindows patches (see the Links section of the Appendix) were installed.
The commands below are all written in UPPERCASE, in order to differentiate them better. You can enter the commands using any mix of case you like, except in quoted strings, where case is significant.
On V7.1, run SYS$MANAGER:UCX$CONFIG, onV7.3-2, run SYS$MANAGER:TCPIP$CONFIG.
No matter how you intend to configure a VMS guest to use a remote X-Server, you will almost certainly want to add all relevant IP-addresses to the VMS UCX/TCPIP hosts database. This is done from the SYSTEM account by entering “UCX” on the command line on V7.1, or “TCPIP” on V7.3-2. You will then see the corresponding prompt “UCX> “ or “TCPIP> “, below represented as “PROMPT> “.
To add a host/IP-address to the database, enter the following command:
|
Putting the “hostname” in quotes cases it to be entered in lowercase, assuming you also use lowercase characters, which is a Good Idea. The alias will be all uppercase.
After adding a host, you can ping it from within UCX/TCPIP using the command:
|
V7.1 reports “...host is alive” upon success. V7.3-2 uses the standard UNIX answer syntax, and sends ICMP packets until interrupted using CTRL-C.
The Proxy Database is also managed from within UCX/TCPIP.
If you want to be able to execute VMS commands remotely using the “RSH” protocol, you will need to make entries to the Proxy Database. The Proxy Database allows you to associate a remote user on a remote system with a local user, and allow remote execution from that remote user.
The add an entry to the database, enter the following command:
|
For example, to add a proxy for user “urban” on remote host “windows-privnet” for the VMS user “SYSTEM”, enter the following command:
|
The quote-characters are important. Please note that VMS will convert all non-quoted characters in commands to uppercase. A proxy entry for the remote user “URBAN” will not match the remote user “urban”.
After you have create such a proxy entry, you can test it from a Linux or Windows system with the command:
|
which should display a directory listing of SYSTEM’s login directory.
On Windows, you will need the “rsh_vista.zip” utility (see links below).
If you want to run a command on an OpenVMS Guest, use the rsh program. On Fedora/RedHat Linux, you will probably need to install the rsh package. On Windows, you will need the “rsh_vista.zip” package (see links below). On a Windows host, assuming you have unpacked “rsh_vista.zip” into “C:\Program Files\Rsh”, you can create a shortcut to the rsh.exe program by opening a Windows Explorer window, navigating to the above directory, right-clicking and dragging “rsh.exe” to the desktop. When you release the mouse button, you will get a pop-up menu from which you should choose “Create shortcuts here”. Right-click on the new desktop icon and select properties. In the “Target” field append -l <user> target-host “<command>” after the path to the program in quotes.
The entire field should look as follows:
|
You should also change the value in the “Run” field from “Normal window” to “Minimized”, which avoids having the CMD-window pop up when the icon is executed.
On the VMS guest, you will probably need to write a small DCL command procedure in order to set up the remote display before starting a DECwindows program. For example, to start a DES, the following DCL procedure can be used:
|
This works on V7.1 and V7.3-2. If you only wish to start a single application, such as a DECterm, you can substitute “DECW$TERMINAL” for “DECW$STARTLOGIN” above.
The standard UCX version on VMS V7.1 is 4.1, which does not support XDMCP. You can use the above procedure to start the DES.
V7.3-2, with the default TCPIP services version 5.4, supports XDMCP. In order to use it, you will need to configure XDM. Please note that I was unable to get XDMCP to work without disabling access control in VcXsrv (adding “-ac” to command line parameters).
To configure VMS V7.3-2 to respond to XDMCP requests, begin by entering the following commands (“$” is the DCL prompt):
|
Next, edit XACCESS.TXT and add the IP-address of the Host at the bottom.
Next, edit XSERVERS.TXT and comment out any lines at the bottom that would start a remote X session, for example “rufus.compaq.com:0 foreign”.
Finally, restart the XDM service using the following commands:
|
You might be tempted to add a line to XSERVERS.TXT to have the VMS system automatically start the DES, however I was unable to get this to work reliably.