Through an X Window Darkly

• Who Needs X Windows?
• Client-Server at its Core
• The Origins of X
• Many Clients, One Server
• Want Your Own X server?
• The X Window Manager
• Clients xterm et al.
• X and Security
• Getting Started with X Windows
• Common Problems in Getting Started Using X
• What Else?

If you do everything locally on your PC, you don't need it. If you only interact with remote machines through Eudora or Netscape or a newsreader, you don't need it. But if you find yourself wishing that the program you're running remotely could just pop open a window on your screen and show you a graph of its progress, accept input data at a crucial part of the run, and maybe even allow you to cut-and-paste that data from another window generated by different program running on a different machine, then you really do need it -- the X Window System.

Consider SAS, for example. Using SAS on the PC on your desk is great for interactivity and for controlling your statistical analysis while it is running. Provided, of course, your data set is small enough for a PC. Using SAS on a large remote computer is great for computational power and for handling tapes and large data sets. Provided, of course, that you don't mind waiting for SAS to finish processing your data, transferring the results to your PC and graphing them, examining the graph to help you decide what to do next, and then logging back on to the remote computer and starting all over again. Do you want the best of both worlds? Then you want X.

There is no point to using X just to use it. Like any system, X has its drawbacks -- it has a large appetite for network resources and there are some aspects of its configuration, such as security, that you really need to pay attention to. But if you need graphic or multiwindow output from a remote machine, X can be a very convenient way to watch and control those remote processes from your desktop.

The X protocol is platform independent -- both clients and servers exist for many computers, including the Macintosh, Windows, and OS/2, as well as all manner of UNIX. And X is extremely flexible and configurable. (To a fault, actually. X is a hacker's dream. Fortunately, it is quite useful without custom configuration, too.) It is so configurable that my X sessions might have a very different look and feel from yours. On the whole, this is an advantage, because it has encouraged many people to contribute programs and utilities, and quite a number of them are free.

X clients, on the other hand, are the applications programs that tell your X server what to draw and where to draw it. Thus, in X terminology, the application, which may run on the same machine as the X server or may run on another machine, is the client.

Although this is true to the notion that servers should obey the wishes of clients, the way the terms "server" and "client" are defined in X -- with the server being local to your desktop and the client being (possibly) remote -- is just the reverse of the usual client-server structure. There are those that defend the X terminology, but the fact is, you just have to get used to it.

The ACCC has a site license for Hummingbird Communication's eXceed line of X servers (for DOS, MS Windows, and OS/2) and MacX for Apple Macintoshes. For more information, see Connecting with X Windows.

Motif (mwm) and open look (olwm) are common windows managers, and there are other ones like twm (the "t" is for its author, Thomas LaStrange), and fvwm (the "v" is for virtual; the "f" did mean something at one time, but whatever it was is now lost in the mists of time). When you use eXceed for MS Windows, you can even use MS Windows as your X window manager. This has a distinct advantage -- it allows you to cut-and-paste between an X program in running in one window and a Windows program in another.

One would think that window management, being rather fundamental to a windowing system, would come built-in. (As is true with microcomputer windowing software like MacOS, MS Windows, and IBM OS/2.) But X provides process, not policy. In other words, X provides the means for clients and servers to communicate, but lets each window manager and each application make its own decisions about what a button does, how to move or resize a window, how to determine which window grabs the keyboard input, and so forth.

The result is that no one is locked out of making improvements to X by proprietary software. The major vendors, as well as contributors to the X Consortium, have made improvements to window managers as well as application clients.

Although I use xterm the most, there are lots of other useful X clients, many available on the 'Net for free. There are terminal emulators, clocks, calendars, rolodex and mail programs, editors and word processors, statistical packages (like SAS), drawing and paint programs, and network utilities. Not to mention games and decorations. Obviously, many other operating systems and windowing programs offer these types of programs. But if you do have a compelling reason to use X, you may as well make use of the other benefits.  

X provides two security mechanisms. One, the xhost mechanism, is easy to use and, unfortunately, easier to abuse. The other is the magic cookie mechanism. It's a bit harder to use than xhost, but provides much better security when you run your X clients on a multi-user system. Neither, however, provides any real defense against network sniffing.

xhost security:

The xhost mechanism grants access to your X server to everyone on a given set of machines. If, for example, you want to run SAS on tigger, you could use your X server's xhost command to make tigger a trusted host machine; this would give everyone using tigger the ability to read the windows managed by your X server. Yes, the people who use tigger happen to be a nice, friendly bunch, but you can see that this could pose a problem. Please don't do this.

magic cookie security:

The magic cookie mechanism is much more sensible. It grants access to your X server only to certain accounts on the remote machine, not to everyone. It does so by forcing the remote client to provide your X server with a secret code called a "magic cookie". The hard part is figuring out a way for the X server and the X client to both know the shared magic cookie before the client is actually run.

I don't mean to scare you, but it is important to know the security implications when you use X. The "normal" X defaults can depend on many variables and are often not what you'd want. That said, we have set up eXceed in the ACCC labs so that when you make a connection to tigger or icarus, the magic cookie security is turned on by default. So you should be safe. But there are no guarantees if you mess with the configuration yourself.

You'll need a UNIX account to use eXceed in the labs. If you haven't opened your ACCC UNIX account yet, you can do it online; visit the ACCC's Computer Account Creation Web page and answer a few questions. Be sure you have your UIC i-card picture ID with you; you'll need it to open your account.

For more information on using X Windows at UIC, see Connecting with X Windows.

• In the ACCC public labs, eXceed is configured to start sessions automatically, without having to fiddle with the setup. But if you do fiddle, or if you use X from some other system, you need to set the display variable (so your clients will know where to put their windows) and to establish your X Authority mechanism (so your server knows which clients to allow).
  
  
• When starting a remote client, it is important that the client know where to display the output. This can be done either by setting the display environment variable, or usually by the option on the X clients command line. Often, this variable is set for you when you log on. (To check, enter: echo $display

It will return the name of the machine where your X server is running, with a :0 at the end.)

If you do need to set the display variable yourself and you're using K shell, enter something like this: export display=tigger.uic.edu:0

Without the :0 at the end, the X client might think your local device has many monitors, and wont know which one to use. Also if you are using magic cookie security, be sure that the case of the display variable matches the case of the result from the xauthlist command.



• If you get messages that the server refused service, either the magic cookie or xhost mechanism is not functioning properly. You can check the magic cookie authorizations with the xauthlist command. This will tell you what authorizations the remote UNIX system thinks it has. Be sure that the remote system's name in the list of authorizations matches exactly the name in the display variable, including case. You can also turn on the xhost authorization temporarily for testing, since it is sometimes easier than the magic cookie protocol. But be very careful when you do this, and be very sure not to type any passwords at all in this state.

• How to use X once you get it running, including how to resize windows, scroll, start clients, and so forth. Much of the details of these subjects depend on what window manager you use and, to some extent, the client application program you're running. If you are already comfortable with microcomputer windowing software like MacOS, MS Windows, or OS/2, with a little experimentation you should be able to discover a lot of what you need to know to use most X Windows window managers, but it won't teach you everything.
  
  
• Configuration and customization, and customizing your startup scripts. The ACCC supports eXceed and MacX, X Windows servers for PCs and Macs, respectively. There are configuration options that allow you to select fonts and colors, to choose a windows manager, and to set up your security scheme. And there are other "X resources" to play with. For example, you can customize X menus; because I login to tigger so often, I've put a new menu item in my root menu to do that for me.
  
  
• Common Desktop Environment. CDE is a fairly new industry-wide standard that, for the first time, prescribes a standard look and feel for X. We have it on tigger now, but not on icarus. CDE lets you have multiple virtual screens with multiple windows on each screen, drag-and-drop icons, and provides you with a session manager and lots of other good stuff. Of course, it has its own idiosyncrasies in customization.

The references in the Related Links section of Connecting with X Windows can help you learn about these.

Give X a Test Run

When eXceed starts up, it will display a menu that allows you to log onto tigger, icarus, or a few other machines. Pick one on which you have an account, login, and give it a whirl. (Be patient if you decide to login to tigger; tigger's login process uses CDE and it takes a while to start up.)

We have eXceed set in the public labs to use the remote window manager (on icarus or tigger) by default, so your X Windows session will take over your entire screen. But you can change this default using the eXceed configuration menu on the PC. We also have eXceed set up in the labs to use magic cookie security by default. Both tigger and icarus respond properly to this protocol, and will set up the necessary environment automatically.

Comments are appreciated; send them to
Bob Goldstein, bobg@uic.edu