C

X on Non-UNIX Platforms

This book concentrates on X as it runs on UNIX systems. But X is OS-independent. Our office equipment consists mostly of UNIX systems and X terminals, but we also have Macintosh computers, PCs, and NeXT machines. X runs on all of them.

• We have one PC user who runs an X server on top of his Microsoft Windows environment. He runs PC applications locally, but also displays X windows alongside his MS-Windows windows. He runs project management software on the PC, while he writes and debugs UNIX programs and reads his mail using X applications.
• We have a diehard Macintosh user who runs an X server on top of his Macintosh operating system. He works primarily with Macintosh programs but occasionally needs to edit troff files on a UNIX system and preview them with an X-based previewer.
• We have a NeXT user who runs a full X distribution on top of the NeXTstep environment. She uses the NeXT environment for its newsreader, dictionary, and mailer, while she uses the X environment for compiling and testing X programs.

Each of these users has the advantage of keeping his or her favorite user environment, while also maintaining the same connectivity that co-workers have with workstations or X terminals.

Convenience is not the only advantage to running X on other operating systems. Probably the most significant advantage is price. Offices can upgrade to X without having to invest in new hardware. X server software might cost anywhere from $200 to $500, as opposed to $1000 for a low-end X terminal. As for disadvantages ... X servers running on PCs and Macs are noticeably slow compared to X terminals, sometimes painfully slow. PC monitors are generally smaller than X terminal monitors and the resolution is much worse. And the low-cost advantage isn't always valid, since a PC has to meet many requirements before an X server can run with reasonable performance.

Currently, the PC and Macintosh users at our office run only X servers, relying on a UNIX host to run clients for them to display. However, X clients and libraries have recently been ported to the PC platform (notably with Quarterdeck's Desqview/X product), and Macintosh X clients are also available. This gives us the ability also do it the other way around—that is, to display display both PC and Macintosh programs on X terminals. The potential is immense. X allows the sort of interconnectivity between operating systems that was previously limited largely to file sharing and remote logins.

Since there are so many products out there, this appendix only covers generalities about X running on other platforms. For more information, look for the monthly posting on comp.windows.x on X servers for PCs, Macs and Amigas. This document is also kept on export.lcs.mit.edu in the file /contrib/XServers-NonUNIX.txt.Z.

C.1 X on DOS-based PCs

Most X software available on PCs running DOS is server software. There are two types of PC X servers on the market: those that run on top of DOS directly, and those that run on top of Microsoft Windows.

The X servers that run on top of DOS replace the entire desktop, and returning to DOS usually requires exiting (or suspending) X. The X servers that run on top of Windows, on the other hand, provide an integrated environment with access to both X and Microsoft Windows applications simultaneously. Some Windows-based X servers also let you cut-and-paste between the X environment and the Windows environment.

If the PC will be used primarily for running X—that is, as an economical X terminal—then the DOS-based X servers are probably sufficient for your needs. If the PC will frequently be used to run Windows applications as well, however, Windows-based X servers give you the best of both worlds.

Desqview/X by Quarterdeck Office Systems provides the first distribution of both X clients and servers for PCs running MS/DOS. Desqview/X runs on top of Quarterdeck's Desqview multi-tasking GUI, integrating DOS applications, MS-Windows applications, and X applications. You can use Desqview/X to remotely execute PC applications as X clients and display them on any connected X server.

C.1.1 Requirements for PC X Servers

We mentioned that PCs have to meet serveral requirements before they can run X servers. In general, before you can run a PC X server, you have to meet the following requirements:

Processor

The PC should have a 80386 or ’486 CPU processor. (Some vendors also support ’286 machines, but no one recommends it.)

Monitor

The PC needs an enhanced video display. Most vendors require either a VGA or Super VGA display. Some vendors also support EGA and 8514 graphics. Note that what the PC world calls a “high resolution” monitor still has lower resolution than a low-resolution X terminal.

Mouse

The PC must have a two-button or three-button mouse.

Memory

The PC must have 640K bytes of base memory, plus either 1.4 megabytes of usable extended memory for DOS-based X servers, or 2 megabytes of memory for Windows-based X servers.

Disk Space

The PC must have a hard disk with at least 3 megabytes of free disk space (sometimes up to 5 if you want all the fonts installed).

Networking

The PC needs to have TCP/IP installed. Some vendors supply TCP/IP packaged with the X server, but most of those that do charge extra for it. Furthermore, beware that not all implementations of TCP/IP are equal—if you have other applications on your PC that require TCP/IP, you may find that a vendor's proprietary version does not work properly with them. Networking packages supported by most vendors are FTP Software's PC/TCP, Excelan's LAN WorkPlace Network Software for PC DOS TCP/IP Transport System, and Sun Microsystem's PC-NFS. (Other frequently supported TCP/IP packages are Beame & Whiteside and WIN/TCP.)

Ethernet Card

The PC requires an Ethernet card supported by the selected TCP/IP package. Not all Ethernet cards are equal, but most TCP/IP vendors support 3COM, DEC DEPCA, Intel PC586, Ungermann-Bass NIC, Western Digital, and the XIRCOM Pocket Ethernet Adapter.

Be aware of these requirements before you invest in PC X servers for your site. It may turn out that it's cheaper to buy an X terminal.

C.1.2 Installing and Configuring PC X Servers

Installing and configuring the actual PC X servers themselves is generally a breeze. Most packages are designed to be installed with one command, prompting for information as you go along. The procedure varies from manufacturer to manufacturer, but you usually need to supply the following in order to complete installation:

• Type of VGA monitor
• Resolution of VGA monitor
• Type of TCP/IP package (Note that if the one you have isn't listed as an option, you're out of luck.)
• Name and IP address of PC. (You may have to give it the pathname of your hosts file on the PC.)
• Name and IP address of the name server
• An access control list (if applicable). (Some products provide their own host-based security by allowing only the listed hosts to connect to the server.)

In addition, you can choose the following preferences:

• Virtual screen, for X servers that support it. This means that the X server will pretend that your screen is larger than it is, with a portion of the “virtual” screen hidden but accessible by moving the mouse to that area. This is useful if you are running any applications requiring a full-page display on a standard sized monitor.
• Session startup with XDMCP (for those that support it) or with remote execution. We strongly recommend using XDMCP. See Section 3.3 for information on setting up xdm.

Most manufacturers will happily provide technical support if you have problems. We strongly advise calling the manufacturer if you have problems getting a PC X server to work. Manufacturers are the ones who is most likely to be aware of incompatibilities between their product and other software you have installed on your PC.

As far as the network is concerned, if you can ftp or telnet to the host machine from the PC using the software that came with your TCP/IP package, you don't have to do any other configuring from the PC end for the X connection to work. On the host end, you need to enter the PC's IP address into the network configuration, as you would for an X terminal; see Section A.6 for more information.

Windows-based X servers may require some special network configuration before they will run properly. The way this is done is heavily dependent on your vendor's implementation, but it may involve changes in both the Windows configuration file win.ini and in autoexec.bat.

C.1.3 Problems Particular to PC X Servers

The following are problems that we've encountered with PC X servers:

• Most PC X servers give you 4 bits per pixel for color displays. This confuses many X programs. See Section 7.1.1.3 for more information.
• If you use remote execution to start your X session instead of xdm, you might have a special problem with xrdb. Most PC X servers reset the server when the last X client has terminated. This is fine, except that it puts you in a Catch-22 situation with xrdb: you want xrdb to run and complete executing before you run any other clients (since you need to have those resources loaded), but then the server resets, losing all the resources you just loaded!

  There are many solutions to this problem if you don't want to just use xdm. Probably the easiest solution is to use the -retain option to xrdb. Another is to use rexec to run a script rather than individual X clients. A third option is to start up a “dummy” client to keep running while xrdb does its stuff, preferably one whose defaults you don't mind.

• Some PC TCP/IP products limit the number of connections allowed. For example, FTP Software's PC/TCP limits the PC to four TCP/IP connections, which isn't enough for any decent X session. You have to see your TCP/IP vendor's documentation for information on how to increase this default. For PC/TCP, the solution is to start up the kernel program in autoexec.bat using the -t option to specify the number of connections to allow. For example, for our 3COM 3c501 Ethernet card, the command was:

  3c501 /t 8

  This increased the number of TCP/IP connections to eight.

C.2 X on Macintosh Computers

Full X distributions are available on Macintosh computers that run UNIX as well as the Macintosh OS. Two UNIX products for the Macintosh are System-V based A/UX by Apple Computer, and BSD-based MachTen from Tenon Intersystems.

If you don't have a full UNIX distribution, you can still run an X server, or set up the Macintosh to run an X client. There are currently two X server products for the Macintosh: MacX and eXodus. MacX is a Macintosh X server that is available from Apple Computer (it is also bundled with their System V-based UNIX operating system, A/UX, as of version 2.0.1). eXodus is a Macintosh X server distributed by White Pine Software.

There are also currently two X client products for the Macintosh: Planet X and Xgator. Planet X is distributed by InterCon Systems and Xgator is distributed by Cayman Systems. The advantage of a Macintosh X client is that you can run Macintosh programs on your X terminal. Unfortunately, only one user can access the same Macintosh at a time, so the Macintosh becomes disabled while the X client is running, and no other X users can start up the client software while someone else is using it.

Macintosh-based X servers and clients alike require either a direct Ethernet connection or a LocalTalk connection to a LocalTalk/IP gateway such as Cayman's GatorBox. The Communications Toolbox must also be installed (standard with System 7), with the MacTCP tool installed and configured properly.^* (eXodus works with DECnet as well as TCP/IP.)

C.2.1 Macintosh-based X Servers

Both X servers for the Macintosh, MacX and eXodus, can run either “rootless” or “rooted.” By “rootless,” we mean that X clients open directly on the Macintosh desktop, intermixed with other Macintosh windows. The Macintosh OS acts as a window manager for both X and Macintosh windows. By “rooted”, we mean that a typical X root window is active, either enclosed entirely within a Macintosh window, or available through a pull-down menu. An X window manager can be used in a rooted window (such as twm, mwm or olwm).

Some X programs may have problems with a rootless environment; to run those programs, use rooted screens only. MacX defines 4 screens: screen 0 is rootless monochrome, screen 1 is rooted monochrome, screen 2 is rootless color, and screen 3 is rooted color. eXodus allows you to define up to 6 screens as either rooted or rootless.

One of the most obvious problems with using a Macintosh as an X server is that the Macintosh mouse only has one button. MacX uses the left-arrow and right-arrow keys to act as the second and third mouse button (respectively). eXodus provides a little more flexibility for configuring mouse behavior. In addition, there are third-party mice for Macintosh computers that have two or three buttons.

(Users of OPEN LOOK programs can use the props utility to change the behavior of the SELECT mouse button so that it brings up menus instead of selecting the default item when pressed on a menu button. This is a good tip for all 1- and 2- button mouse users. Mac users who also run olwm might also want to use props to turn off “pointer jumping,” by which olwm and olvwm move the mouse pointer automatically to follow scrollbars and pop-up notices.)

You can get upgrades to MacX from aux.support.apple.com, in the /aux.patches/supported/MacX directory. You are encouraged to retrieve the MacX upgrades only if you already have a legal license for MacX. (Only the server is redistributed on the ftp site, which is useless without the fonts or a font conversion utility anyway.)

If you use either MacroMaker or QuickKeys on your Mac, it is strongly recommended that you disable it. MacroMaker and QuickKeys translate keystrokes, conflicting with the X server.

C.2.2 MacTCP and the Communications Toolbox

To run Macintosh X products, you generally need to have MacTCP running. MacTCP was developed by Apple, and is distributed by several third-party vendors. It is also bundled with MacX.

MacTCP runs under the Communications Toolbox. The following tips are important to note when installing MacTCP:

1. You must install the Communications Toolbox correctly. Under System 7, the Communications Toolbox is already installed as part of the base OS distribution. If you need to install the Communications Toolbox for a Macintosh that is not running System 7, however, you can't simply create a Communications folder under your System folder and copy the MacTCP tool in there. You must run the installation utility that is bundled with the Communications Toolbox.

   If you don't install the Communications Toolbox correctly, you'll never get a message that tells you it's improperly installed. Instead, you'll get an error message such as “No Communications Tools Installed,” which misleadingly implies that the Toolbox is installed correctly but MacTCP isn't.

2. You need to copy the MacTCP tool to the new Communications folder within the system folder, and copy the MacTCP and AdminTCP files to the System folder (under System 7, these files reside in the Control Panels folder). We strongly recommend that you do not copy these files from another Macintosh, but take them directly from the distribution floppies. If you do copy them from another Mac, make sure not to take the MacTCP Preferences file.
3. Configure MacTCP using the AdminTCP control panel document. (AdminTCP is identical to MacTCP, except that you can use AdminTCP to lock the configuration after it is properly configured.) Here is where you specify things like your IP address, subnet mask, name server, etc.
4. Reboot and try running a MacTCP program.
5. Once you have confirmed that MacTCP is properly configured, put a lock on it and throw the AdminTCP file in the trash.

A possible conflict with MacTCP is that if you are also running NCSA Telnet, you need to be sure that you are running the version that is MacTCP-compatible. That means that you need to install the version of NCSA Telnet entitled something like Telnet 2.4 – MacTCP. If you don't do this, then after running an application that uses MacTCP, you won't be able to run NCSA Telnet again until you reboot.

Notes on configuring MacTCP are available on sumex-aim.stanford.edu in the file /info-mac/report/mac-tcp-info.txt.

C.3 X on NeXT Computers

The NeXT machine does not technically belong in a chapter about non-UNIX machines, since it is based on UNIX. The NeXT machine also has built-in Ethernet and TCP/IP, so a lot of the issues for running X on PCs and Macs don't apply to the NeXT. However, we discuss them here because NeXT X distributions are a different breed from other UNIX distributions, since they have to deal with the NeXTstep interface.

A public domain R4 X distribution for the NeXT called XNeXT is available through anonymous ftp from cunixf.cc.columbia.edu. (Although an R5 server is currently available for the NeXTstation Turbo, it is not yet available for other NeXT machines.)

There are also three commercial products for the NeXT. These are co-Xist by Pencom Software, Cub'X by Cub'X Systemes (distributed in the U.S. by Interactive Technology), and eXodus from White Pine Software. Cub'X and co-Xist are full X distributions including servers, clients, and libraries, With OSF/Motif clients and libraries also available. eXodus is just a server with a select group of clients.

All three commercial implementations meld X with the NeXTstep interface much in the way Macintosh and Windows-based X servers do, in a “rootless” mode. XNeXT, on the other hand, supplants the NeXTstep interface and requires you to “hot-key” to switch between the two modes.

Regardless of what X server you choose to run on the NeXT, you should make sure that the second mouse button is enabled in NeXTstep (through the Preferences application), or it won't be available to the X server.