Jim Mohr's SCO Companion


Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.

Be sure to visit Jim's great Linux Tutorial web site at https://www.linux-tutorial.info/

3 X-Windows

Despite the extent it has spread in the UNIX world, the X Windows System is not a UNIX product. The X Window System, affectionately called X, was developed by the Massachusetts Institute of Technology and runs on a wide range of computers. There are even MS-Windows based versions.

The first version was developed at MIT in 1984. Several versions have been developed since, with the most current version, X version 11 (X11), being first released in 1987. X11 has been adopted as the industry standard windowing system, with the support of a consortium of major computer industry companies such as DEC, HP, SUN and IBM.

The Basics of X

An X session is usually composed of several windows, each running a separate program, or client. Like a program on any other system, programs running under X vary in functionality. Some interact completely with the user like the xterm terminal emulator. Others simply display output on the screen like the xload system monitor.

The background window is referred to as the root window. Application windows, or clients, are displayed on top of the root window. Like UNIX processes, these windows are grouped together, or related, in a family hierarchy. Like init is the great-grandmother of all processes, the root window is the great-grandmother of all windows. Clients displayed on the root window are children of the root window and the root window is their parent. This hierarchy actually extends to different parts of a window. For example, menus are often considered children of the parent window as they inherit characteristics, but also can be configured and react independently of the parent window.

X consists of two sides: a server side and a client side. The basic functionality is similar to the way all client-server models work in that the X server has certain resources that it provides to the client. It is a common misconception that the server and clients are on the same machine. because X is integrated with the TCP/IP stacks, requests can come from any client and can be requested of any server. In addition, because X is not a program but more a protocol, machines can communicate with completely different architectures. For example, a Digital OSF/1 server can provide services to both a SCO and an AIX client, as well as either of the others providing services to the OSF/1 machine. Just like other network applications, a single machine can be both client and server.

The server acts as the interface between the client programs and the physical hardware. When you input data, either through the keyboard or pointer, the server accepts that input and is responsible for passing it along to the client. This information is passed to the client as events. Pressing a key or moving the pointer cause an event, to which the client may react. Often that reaction is in the form of changing the display on the screen. For example, a client receives the event that a particular menu was click on. It responds by requesting the server to display the pull-down menu. The server then passes the information on to the hardware, which shows the pull-down menu. As a screen, it gives it to the server, which then passes to the hardware. As a result of this separation of functionality, one client could display information on more than one server.

In order to start anything, an X server needs to be running somewhere. Despite that fact that you can access servers anywhere on the network, the most common configuration is where the server is running on the same machine as the client The two most common ways on both ODT and OpenServer are to either have scologin enabled or to use the startx shell script.

The scologin program is conceptually very similar to the way a normal login works. Although the interface is graphical, you are prompted to input your name and password. Incorrect values generate an error message, and a correct one gets you logged into the system, just like a normal login. Also like a normal login, an environment is set-up for you. If enabled, scologin will be available for you every time the system boots.

The next common way is through the startx shell script. This reads the .startxrc file in your home directory and treats it in the same way as your shell would treat the .cshrc and .kshrc files. Here is where your initial clients are started, such as terminal emulator and the window manager If you don't have a .startxrc file in your home directory, then startx will read the system default file /usr/lib/X11/sys.startxrc. In reality, the X server is started by the xinit program. However, both scologin and startx start xinit for you.

Contrary to popular belief, it is neither the X server nor the clients that are responsible for the appearance of the windows on the screen as we understand them. Instead, this falls to a window "manager." SCO provides two window managers: OSF/Motif Window Manager (mwm) and the Panning Motif Windows Manager (pmwm). Pmwm is actually an enhanced version of mwm, which provides virtual windows. This means that you can have what appears to be multiple screens and move easily between them. Both mwm and pmwm are actually clients themselves and provide the window appearance such as their locations on the screen, borders, menus and the appropriate actions when the mouse is used or keys are pressed.

What you can do to each part of a window is important in understanding the basic concepts of X. A click is used to activate a button. The is done by quickly pressing down and releasing one of the mouse buttons. Since there is only one mouse button on many systems, the mouse button used to click is usually button number one. On right handed mice, this is the left button. A double-click is when the button is clicked twice in succession. The maximum time allowed between clicks in order to be recognized as a double-click can be configured using the scomouse utility. To drag an object you select that object by placing the pointer somewhere on that object and pressing down and holding the first mouse button. In many cases, such as xterm or scoterm, you must click on the title bar. You then see the outline of that window, which you can move to its new location. You can also select the window by clicking on Move in the Window Menu. You drop an object onto another by dragging that object over another and then releasing the mouse button. This only works in appropriate circumstances. For example, dropping a document on the printer icon to print it.

If you have multiple clients on the screen, they exists in a kind of stack. Although they may be positioned so that no part of any window overlaps another window, they are still considered to be in a stack. That is, there is one window that is considered to be on top (usually the active one) and the others are at different levels underneath. You can bring any window to the top of the stack simply by clicking on it. If, however, the windows overlap so that one or more windows are obscured, you can cycle through the windows in either direction.

Let's assume we have three clients running. They are, in order from top to bottom: A, B and C. By pressing ALT-TAB we cycle down the stack. That is, B is now on top, followed by C, with A now on the bottom. Pressing ALT-TAB again, we have C on top, then A and B is now on the bottom. If we press ALT-TAB third time, A is once again on top, followed by B, then C. This effectively takes the top of the stack and moves it to the bottom or we are selecting the next client. If we press SHIFT-ALT-TAB, the process is reversed. The bottom of the stack is brought up to the top or we are selecting the previous client.

Figure 0-1 Description of the various parts of a window

It can also be said that you, the user, manage the windows. You determine the size and location of the window, as well as determine which is the active window. Changing the size of the window is done in several different ways. By moving the pointer, you can grab any corner of the window by pressing and holding down the left mouse button. You can then move that corner in any directory, thus changing both the horizontal and vertical sizes of the window. You can also grab an edge and change either the horizontal or vertical edge, depending on what edge you grab. In addition, you can choose the Size option from the window menu and then move the pointer to the edge or corner you want to use to resize with. This time you do not hold down the left mouse button.

There are also two buttons in the upper right hand corner of the window. The outer one is the maximize button. When you click on it, the window will fill the screen (it maximizes). When you click on it again, it returns to its previous size. Not the default, but the size it was when you clicked the maximize button. The other is the iconify button. This turns the window into a miniature version of its former self. This is a "representation" of that window. These little images are referred to as icons. Double-clicking on the icon returns it to the size it was. Here again, not the default size.

When you choose which window is active you set the focus. There are two types of focus policies used: explicit and pointer. If set to explicit focus, you must click explicitly somewhere within the window to set the focus. If set to pointer focus, the focus is set when the pointer enters a window. The default is explicit focus, and I suggest you leave it until you are very familiar with moving around windows or have a compelling reason to change it. The problem with pointer focus is that you could be typing away in one window, accidentally push the mouse so the pointer is in another window. Now, all of a sudden, the new window is accepting input. On slower machines, the opposite effect might happen. You intentionally move the pointer to a new window and start typing. However, it takes a moment for the focus to "catch up" with you and therefore the input is sent to the previous window.

Common to every windowing system (at least every one I have ever seen) is the concept of a menu. Like a menu in a restaurant, a menu in X presents you a list of choices. Windows in X come in two types: pull-down and pop-up. Pull-down menus are almost universally associated with a particular location on the window. When you click on that location, a menu appears to drop down from that location. In a sense, you are pulling down that menu. By default, each window has Window Menu located in the upper left corner. This is a small square, with a horizontal bar running through it. Some people describe it as looking like a filing cabinet drawer with a handle. When you click on the Window Menu, you are give options that are related to the window itself. These include moving the window, resizing it, or changing its position in the windows "stack" (raising or lowering it).

Pop-up menus are usually not associated with any particular location on the window. These menus "pop-up" from the current cursor position. An example of a pop-up menu is the Root Menu that pops up anytime you click on an exposed area of the root window.

Earlier I mentioned that it was the window manager that determined the "look and feel" of an application. However, this is not entirely true. Although what we see presented is a function of the window manager, the underlying routines used to represent a button or a scrollbar can be different. Most of the SCO provided clients use a set of routines called the X Toolkit (Xt). This is actually two libraries that are used to create the interface components (buttons, menus, and so on). These are referred to as "widgets." The two libraries are the X Toolkit Intrinsics and the Athena Widget set (Xaw).

Keep in mind that X does not provide a graphical user interface (GUI). X is simply the windowing mechanism, but some other component provides the GUI. In order to produce such a GUI, the Open Software Foundation (OSF) developed the Motif Toolkit, which is based on the X Toolkit Intrinsics and a set of widgets developed by DEC and HP. This was originally designed to emulate the look-and-feel of the IBM/Microsoft Presentation Manager used in OS/2.

On ODT and OpenServer you will find both Motif and standard X applications. Motif applications are those that use the Motif Toolkit. These all have a common look-and-feel. One standard X application is the clipboard. If you run it along with some other application such as SCOEdit, you will notice some distinct difference. The most dramatic is the overall appearance. Motif based applications appear three dimensional, whereas standard X applications look "flat."

Displaying Clients

When the clients connect to the server, one of the key pieces of information it needs is the display name. The display is of the form:


The hostname identifies the name of the machine that the display is physically connected to. The most common form of hostname is simply the node name, as more than likely the server is in the same network. However, it is possible to use a fully qualified domain or even an IP address for the hostname.

Unless you have some special hardware, you probably have only one physical display per server. However, each display is given a number starting at 0. If you only have one, then you are always accessing hostname:0. The screen number is only used in cases where a single keyboard and mouse are associated with multiple monitors. Like displays, screens are counted starting at 0. Since multiple screens are far less common than multiple displays, you can leave of the screen number when specifying the display. Generally, the default display is stored in the DISPLAY variable, which is then used by default. However, many X clients have a -display option, with which you can specify the display.

The important next issue is the concept of geometry. One of the advantages of a system like X is the ability to not only move windows around the screen, but to change their size and shape as well. Rather than using the window manager to change the shape of the window, we can specify the shape and size when the application is started. This is done by specifying the client's geometry.

The geometry is represented by four characteristics: width, height, distance from left or right and the distance from the top or bottom. These are referenced by width, height, xoff and yoff, respectively. Depending on the application, the height and width are measured in either pixels or characters, whereas the xoff and yoff values are measured only in pixels. Both xoff and yoff are measured in relationship to the screen. The general for of the geometry specification is:

application -geometry widthxheight+xoff+yoff

Here the + sign, in front of the xoff and yoff, indicate a distance from the left and top edges of the screen, respectively. By changing the + to a -, we change the offset to be from the right and bottom instead of left and top. For example, if you wanted to start the analog clock 30 pixels to the right of the upper left hand corner, the command would look like this:

oclock -geometry 90x90+30+0 &

(It's a good idea to run all clients in the background, otherwise you don't get your prompt back until the client terminates.) Now, if we wanted to start the clock 30 pixels to the left of the upper right hand corner, the command would look like this:

oclock -geometry 90x90-30+0 &

Now, if we wanted to start the clock 30 pixels to the left of the lower right hand corner, the command would look like this:

oclock -geometry 90x90-30-0 &

The four corners are thus mapped like this:

+0+0 -0+0

+0-0 -0-0

You can also specify negative offsets that would then start the client outside of the respective edge of the screen. For example, if we change the above command to look like this:

oclock -geometry 90x90--30+0 &

It will start the client so that right edge of the clock is 30 pixels outside of the right edge of the screen. (Be careful not to have spaces in there.) This does not mean that the entire clock is outside of the right edge of the screen. This is a misconception that many people have (including myself at first). On many systems, there is something magical about the upper left hand corner of the client. Offsets from the edge of the screen are in relationship to this magical corner. This is not so with X.

A +xoff value is the distance of the left edge of the client from the left edge of the screen. A -xoff value is the distance of the right edge of the client from the right edge of the screen. This also means that a +yoff value is the distance of the top of the client to the top of the screen and -yoff is the distance from the bottom of the client to the bottom screen.

Note that the geometry is specified in pairs. So, if you specify the height, you must also specify the width. Also, if you specify the x-offset, you must also specify the y-offset. However, you don't have to specify the offsets if you only want to specify the size. Therefore we could start the clock like this:

oclock -geometry 90x90 &

This gives me a 90x90 clock at the default location. If we only want the offset and to take the default size, it might look like this:

oclock -geometry +100+42 &

The thing that bothers me about this clock is that it is pretty boring. The colors are drab and it really doesn't have any life to it. The nice thing is that we can change the colors. With the analog clock, there are several different things we can change. If we wanted the background color to be cornflower blue, we would enter the command:

oclock -bg cornflowerblue &

This creates an analog clock with the default size at the default location with a background of cornflowerblue. However, it still looks boring. I want a foreground of red. So, let's run the command like this:

oclock -bg cornflowerblue -fg red &

Now it's beginning to have a little life to it. However, having both hands red is still not good enough. I want the hour hand red, but the minute hand white, and I want the jewel at the top of the clock to be yellow. The command would then look like this:

oclock -bg cornflowerblue -hour red -minute white -jewel yellow &

That's not all. There are a couple of more options that we can use. However, these are listed in the oclock(X) man-page so you can take a look there if you want. Other clients have different options, since some of them don't make sense with an analog clock. For example, the digital clock (dclock) has an option to specify the font (-fn). Since there are no characters on the analog clock, an option to change the font wouldn't make sense.


If we wanted we could have also included the geometry along with the colors. This ends up giving us a command that is almost too long for the screen. Even now, it is a long command, that takes a long time to type in and so you can easily make mistakes. One solution would be to write up everything in a shell script and start that script instead of typing everything on the command line.

But the nice thing is we don't have to. X provides a mechanism to change the appearance and sometimes the behavior of a client to fit our personal preferences. This is the concept of a resource. Up to now, we have specified the resource from the command line, such as foreground color and geometry. However, there are resource files that we can edit to change the default characteristics of a given client.

Resource files for most applications are found in /usr/lib/X11/app-defaults, The general form of the resource specification is:

appname*subname*subsubname...: value

The application is usually the name of the program you are starting with the first letter capitalized. Note the word "usually." I don't know how many times I've tried to change a resource and not have it work, only to find out that this one application's name is written small. In the case of the files in /usr/lib/X11/app-defaults, there is no appname necessary as there is one file for each client and X knows what client is meant when it reads these files. If set, X will search the path specified by the XFILESEARCHPATH variable for the resource information.

Unless you want to change the system defaults, I suggest leaving these files alone. Instead you can create a user or machine specific resource file. Normally, this is $HOME/.Xdefaults-hostname, where "hostname" is the name of the host these resource specifications apply to. If this .Xdefaults file is to apply to the local host, you can leave off the hostname. If you want to specify an alternative file, you can use the XENVIRONMENT variable.

These resources are organized into classes. This allows you to set groups of individual resources all at once. Individual resources are referred to as an instance. By convention the class name begins with an upper case letter and the instance begins with a lower case. We can generally say that a resource (both class and instance) is named for the aspect of appearance that it controls. For example, there is a class called Foreground, which sets the foreground color. An instance of the Foreground class would be specified with a lowercase F: foreground. Keep in mind that different parts of the clients are affected by the class Foreground, such as the text color, cursor color, and pointer color.

Basically all applications have the following resources. In each case the class name has an initial capital. Examples of this are:



window background color



width in pixels of the window border



window border color



window foreground color

The distinction between classes and instances is very useful if we want to set several resources at once. For example, if we define the foreground color for all aspects of the scoterm, the resource definition would look like this:

ScoTerm*Foreground: blue

This would be equivalent to:

ScoTerm*foreground: blue

ScoTerm*cursorColor: blue

ScoTerm*pointerColor: blue

This means that the foreground color of text, cursor and pointer are all blue. If we then defined the pointerColor instance to be something else, only it changes. For example, if we made the following definition:

ScoTerm*pointerColor: red

color is now red, although all the others remain blue.

Although the asterisk is perhaps the most commonly used delimiters, it's not the only one. The asterisk delimiter is used to indicate a loose binding. This is where there can be several layers in the object hierarchy. It's easy to think of the asterisk as having the same function as on the command line, that is, as a wild card. Here, the asterisk represents 0 or more intermediate layers between the root object and the resource we are defining.

If there are no intermediate layers between the objects, this is referred to as a tight binding. If we wanted is we could specify the binding with the asterisk, since it means 0 or more intermediate levels. However, the symbol used to explicitly specify a tight binding is a dot (.). Since I know that the level just above the pointerColor in the hierarchy is 'ansi,' I can make the specification like this:

ScoTerm*.ansi.pointerColor: red

However, since the loose binding specifier(*) can be used any place, but the tight binding specifier (.) only when appropriate, it is easier to always use the loose binding specifier.

Both the resource specifications and binding can bring up some conflicts. In the example above, we said to use blue for every foreground color related to the client "ScoTerm." We also said to use red for the foreground color of pointer. Now this seems like a conflict, which it is; however in this case the instance of the pointerColor took precedence over the class of Foreground.

Consider these lines from an .Xdefaults file:

ScoTerm*Foreground: blue

ScoTerm*pointerColor: red

ScoTerm*ansi.pointerColor: green

We first define the Foreground class to be blue. Next, we define the instance of the pointerColor to be red. Both of these are done with loose bindings. We then define the instance of the pointerColor for an ansi terminal to be green. Since tight bindings have precedence over loose bindings, the pointer is green.

Taking this one set further, we change the class specification so it contains a tight binding. However, we leave the instance specification a loose binding. So, we end up with these two lines:

ScoTerm*ansi.Foreground: blue

ScoTerm*pointerColor: red

In this case, there is a tightly bound class specification that is followed by a loosely bound instance specification. When we start the scoterm, the pointer is blue, not red. In general, we can say that the more specific a specification is, the greater the precedence.

There are a limited number of options that we can use from the command line, although there are many more resources that we might want to change. In order to accommodate a large number of resources without increasing the number of options, there is the -xrm option. For example, if we wanted to change the tty modes of scoterm (what the characters are for erase, delete, quit, and so on), we could do this using the -xrm option and specifying and instance of the TtyModes class. For example, to change the interrupt key from the default of DEL to CTRL-C, the command would look like this:

scoterm -xrm 'ScoTerm*ttyModes: intr ^C ' &

Keep in mind that this resource specification is only valid for this one scoterm that we are starting here. If we wanted it to be valid for all scoterms, we would either change the default in /usr/lib/X11/app-defaults or define the resource in the .Xdefaults file.


Although you may be satisfied with the default colors that X gives you, I am sure that eventually you will want you make some changes. In previous sections I talked about how you can change the color of X clients either from the command line or changing the appropriate resource. The only problem with that is you might not like the colors that SCO offers.

You might be asking, "Why doesn't SCO just give me a list with every possible color?" Well, you would need to have that list in a file somewhere. If you did, you would have a list that was millions of bytes! The reason that would happen is because of the way SCO stores colors.

How Colors Are Represented

Each color is represented by one byte for each of the three colors: red, green, and blue. This scheme is referred to as RGB for these three colors. Each byte can have one of 256 values that represent the intensity of each color. In other words, the value represents how much of each color is to be included. If all three colors have the value 255, this is pure white. If each color has the value 0, you have black.

The /usr/lib/X11/rgb.txt file contains names of colors and often times variations in that name. This is usually the case when the name of the color actually consists of two words. For example: Antique White. In such a case, you would also find the color antiquewhite. Each entry contains the RGB values and the name of the color. For example, the antique white entry would look like this:

250 235 215 antiquewhite

This means that the intensity of red in this color is 250/255 of full intensity. The intensity of green is 235/255 and the intensity of blue is 215/255. What this really means is how much energy is sent to each phosphor. For details on what phosphors are and what part they play in displaying an image see the section on monitors in Chapter 12.

If you are specifying the color as a resource (either from the command line or a resource file), you specify the color as a hexadecimal value. The key thing to note is that you must specify the value for each color, even if it is 0. Because the hexadecimal values range from 0000-FFFF, you have many more possible combinations of colors. When you do specify colors in this way, the hex string you use must be preceded by a pound-sign (#).

If you don't want to specify all four hexidecimal digits, you do not have to. However, all three colors need to be represented with the same number of digits. This is because the system would not be able to tell what value goes with what settings. If we look at an example, this will be clearer.

Let's assume we want to set the intensity of red to F, the intensity of green to 4, and the intensity of blue to 2. We might then have a resource specification that looked like this:

*background: #F42

What if we wanted the intensity of green to be 45, instead of 4. The resource specification might look like this:

*background: #F452

So what is it? Do we have red at F4, green at 5 and blue at 2? Or do we have red at F, green at 4 and blue at 52? The only way to keep things straight is if there are the same number of digits for each color. Since we have two digits for green, we also need two digits for the red and blue. Therefore, the above example would look like this:

*background: #0F4502

Remember that not all video systems are created equal. You may not get the same color on your system as someone else, even if you use the exact same hex values.

So where does the 20Mb come from? Well, if we represented every color, we would need over 16 million lines because there are 256 possibilities for red, 256 possibilities green and 256 for blue. Since 256x256x256 is already over 16 million, you can see how quickly the size grows.

Color Palettes

A key concept when dealing with colors and X is the idea of a color palette. A palette is a set of 8 colors that defines the primary portions of your windows. The characteristics are described in Table 0.1.

Each X client you start displays the colors it finds in the current palette. The colors used are configured by palette resource variables. When displaying the X client, the X server replaces the variable with the actual colors defined in the current palette. Color variables are assigned the names described in Table 0.1.


SCO Color




Background color of all windows.



Background color of all windows. This usually includes text, menus, buttons, icons, and so on.

Top shadow


Top shadow color. This helps to give the window a 3D appearance.

Active background


Background color of the active window.

Active foreground


Foreground color of the active window.

Active top shadow


Color of the top shadow on the frame of the active window.

Alternate background


Color of the Desktop background, scrollbar and sliderbar troughs and icon box background, if used.



Color of a button when it is pressed.

Table 0.1 Color Characteristics

The system default palettes are located in /usr/lib/X11/sco/ScoColor/palettes. There are over a dozen palettes available ranging from Chocolate (lots of browns) to Moonscape (lots of grays). You can add palettes to these defaults by using scocolor, but scocolor will do it's best to keep you from changing the default palettes. If you select any one of the palettes from in /usr/lib/X11/sco/ScoColor/palettes, then the "Delete Palette" button is disabled. Additionally, if you double click any of the buttons indicating you want to change the current color, you are prompted to input the name of a new palette.

If you really want to, you can edit the /usr/lib/X11/sco/ScoColor/palettes file, but I would recommend adding more palettes. If you use scocolor, then the palettes are added to the file $HOME/.odtprefs/ascii/palettes. If you are the system administrator and want to add a palette to the system defaults, you create a palette that ends up in $HOME/.odtprefs/ascii/palettes. You then add this to the end of the system palettes file. Afterwards, this palette cannot be changed or deleted.


The primary tool for changing colors the X-client scocolor. The file that is used to list the names of the files along with the intensity is /usr/lib/X11/rgb.txt. This is an ASCII file that you can easily edit if you know what changes you want to make.

If you add a palette or want to change one that you previously added you can do this in scocolor. By clicking one of the current colors, you can change the value of color. You have a choice of either a color name or specifying the intensity using slide bars. If you want to chose a color name and move the slide bar to give a slightly different flavor to the color you can. The values that are stored in the palettes file will be the RGB values and not the color names.

In addition to using the RGB color model, scocolor can also use the Hue/Saturation/Value (HSV) model. I find the RGB much each to work with as it is clearer to me what is being represented. The SCO doc maintains that the HSV system is more intuitive, but I disagree. In addition, the colors are stored using the RGB values anyway.

If you want to change the names of colors or add new ones, this is done through the /usr/lib/X11/rgb.txt. However, just changing the colors is not enough. Accessing a text file is not the most efficient means of loading colors. Therefore, the system uses a color database, which is "compiled" using the rgb command. To compile the existing rgb.txt file, change directories to /usr/lib/X11 and run:

rgb < rgb.txt

If you want to examine the existing color database, this can be done with the command /usr/bin/X11/showrgb. Since it is fairly long, you might want to consider piping it through more or pg. Note that the rgb.txt file also contains the SCO default colors (scoBackground, scoHighlight, and so on). Therefore, if you want to change these, then change the rgb.txt file as well.


Although not applicable to every client, fonts play a major role in many applications. Defined as a set of characters for displaying text and symbols, fonts share a common appearance in terms of size, boldness, and other physical characteristics. Fonts themselves can be grouped together into font families. Additionally, font families are grouped by resolutions (dots-per-inchÑ DPI) into directories. So named, because they were initially stored together in the same directory in the filesystem. Each directory contains a database that the server uses to translate font names into data that the server uses to display the characters on the screen.

If the X client has a font menu like MS-Windows or Macintosh, life would be easy when it came to fonts. Instead, we need to choose the font as we are starting the application. If we were tired of the boring font use by default on scoterms, we could choose something a little fancier. Perhaps one that look like cursive. For example, we could start sco term like this:

scoterm -fn -bitstream-charter-bold-i-normal--12-120-75-75-p-74-iso8859-1

At first, this appears rather intimidating. There are over 700 fonts on an OpenServer system and learning them all is a pain. More than that, it is a waste of time. There are two utilities that make like easier for you: xlsfont and xfontsel. The xlsfont utility simply lists all the available fonts, with their complete name as we see above. The xfontsel is a real X client that allows us to pick and choose a font to be based on different criteria. Knowing what those criteria are is helpful in understanding more about fonts.

Figure 0-2 Characteristics of the font name

The foundry is the font's developer. Here we have bitstream, which as one would guess is from the company Bitstream, the same people who develop so many fonts for MS-Windows. The font family (here Charter) is a convenient way of organizing the fonts by certain appearance characteristics.

The weight of a font can be thought of as its thickness. Common weights are medium and bold. The slant, as you might guess, is the change in orientation of the character from the vertical. A roman slant is upright, italic is tilted, but the characters are given a slightly different shape to make them more esthetically pleasing, and oblique characters are just tilted with no changes to their shape. In the font shown in Figure 0-1 we have an italic slant.

The set width is a general description of the average width. Common set widths are normal, condensed and double-width (expanded). The size of the font on the screen is determined by several aspects of the font name. These characteristics are the pixels, points and both vertical and horizontal DPI. Because the appearance on your screen is dependent on your monitor as well as what fonts you choose, it's safe to gauge the font size by the points. This is an old printer's measurement that represents 1/72 on an inch. Here we have 120 tenths of a pitch, therefore the size of each character is 1/6 of an inch.

One important characteristic is the font spacing. This determines whether the font is proportional or monospaced. A proportional font is one where the width of each character is different. Although this looks good on paper or in a word processor, it is not really suited for applications like terminal emulators. Better for such applications is the monospaced font, where every character takes up the same space.

The character set is basically another way of saying what letters are represented. In this example and most others in ODT and OpenServer, this field will be iso8859-1. This represents the ISO Latin 1 character set, which is a superset of the standard ASCII character set. In addition to American English characters, iso8859-1 contains the special characters used in most European languages.

So now that we know what goes into font name, we can easily come up with the right font. Well, maybe. Fortunately, we don't have to. We can use wildcard for the parts of the font that we either don't think are important or want to guess at. Any one of the specifications can be wildcarded and the system will do its best to find a match. By "do its best" I mean that there can and will be cases where multiple fonts match the specification. A rather simple example would be:

scoterm -fn '-bitstream-charter*'

On OpenServer, there are 60 matches. So, which one does the system choose? Easy enough: the first one it finds. Unless you are more specific, or know that the first one found is the one you want, you might not get the font you want. Fonts are sorted in alphabetical order, and since bold comes before medium, we get the bold version of this font instead on the medium.

Pop quiz:

Why did we enclose the font name here inside of single-quotes, although we didn't in the first example? Remember that the shell expands everything into tokens before it passes things off to the command. If we didn't use the single-quotes, the shell would try to expand it and we get a message indicating the system cannot find that font.

Life is even simpler than that. We don't need remember any long, drawn out font names, or try 20 different combinations to find the one we want. We can take advantage of the fact that the system understands font aliases. These are stored in the fonts directories in the file fonts.alias. These are ASCII files with the alias in the first column and the font name in the second column.

There are two things to keep mind. First, although you can edit these files and make changes, the system will not recognize the new alias unless you reset the font path with the xset command. This is simply done as:

xset fp

Next, unless you are absolutely positive about what fonts each user is using and how they are being referenced, it is not a good idea to remove aliases. If you remove an alias that some client is expecting, the results are unpredictable.

If you always want to use a particular font with a particular application, we don't need to always specify the -fn option when starting the client Since the font is just another resource, we can instead make the change to our resource definition file. An example in our .Xdefaults file might look like this:

ScoTerm*font: ibm10x20

If you looked though the directory files, you won't find a font simply named ibm10x20. This is actually an alias. However, If we wanted to specify the full name of the font, we could have done so like this:

ScoTerm*font: -sco-terminal-medium-r-normal--20-140-100-100-m-100-ibm437-1

Also, just like specifying the front from the command line, we can use wild cards to specify the "we-don't-cares."

The directories where the fonts are found by the server is by means of the font path. This is the XFONTS variable, which defaults to /usr/lib/X11/fonts, but can be changed using the xset command. Because it is the server that is displaying the information on the screen, the font path is on the server, not on the client machine. Therefore it is important to ensure that the server is able to display a particular font before changing it for any given client. There are five sub-directories under /usr/lib/X11/fonts varying in size and appearance.

The font database in contained in the fonts.dir file in each directory. This is used when you select a font, the system knows what file to read to be able to show the proper characters on the screen. The font.dir files are ASCII files with the name of the font file in the first column and the font name in the second column. When the system is installed, the mkfontdir reads the font files found in the font path and creates the fonts.dir files. You can use mkfontdir yourself, but the details of fonts creation and management goes beyond the scope of this book.

Rather than requiring every machine on the network to have a full compliment of fonts, there is something called a font server. Like a file server providing files across the network, a font server provides fonts across the network. Just like files, if the font you want is not available by the server, but is locally, there is no problem. You can access it as well.

The font server is not started by default, but can be started in one of several different ways. The first is from the command line, simply as:

/etc/fontserv start

Although this might be good for testing purposes, it is more efficient to have the fort server start up every time the system goes into multi-user mode. As are many different aspects of the system, this is accomplished through a script in the /etc/rc2.d directory. However, there is no script there by default. Obviously, you could write the script yourself, but you ought to let the system do it for you. This is done with:

/etc/fontserv enable

Interestingly enough, this makes a link to itself in both /etc/rc2.d and /etc/rc0.d. When the scripts in /etc/rc2.d are started they are given start as an argument, which (since the script is linked) is the same as starting it from the command line as above. It's just that the system does that automatically for us.

Starting the font server from the command line is not recommended for everyday use. In order to be able to use the fonts provided by the font server you need to tell your X session about it. The best place to do this is inside of your $HOME/.startxrc file. Although the system administrator (you?) can change the /usr/lib/X11/sys.startxrc file, so everyone using the default gets to use it, you need to remember those people that have already their own .startxrc file. Before any clients are started, you use the xset command to specify where the font server is. The general syntax is:

xset fp=tcp/server:port

The server is the name of the machine on which the font server is running, and port is the TCP broadcast port, which is 7000 by default. For example, to access the font server on the machine siemau, the command would be:

xset fp=tcp/siemau:7000

Or, if you want to use local fonts as well, the line might look like this:

xset fp=tcp/boston:7000,/usr/X11/fonts/100dpi

The font server's configuration file is /usr/lib/X11/fs/config. Here you can limit what fonts will be made available through the font server. This is done by changing the catalogue entry and specifying the fullpaths to the directories with the appropriate fonts. For example, if you only wanted to have access to the 100 dpi fonts, the line might look like this:

catalogue = /usr/lib/X11/fonts/100dpi

To make the changes take effect, either stop and restart the font server or use the /etc/fontserv command to re-read the configuration file and then flush the cached entries:

fontserv re-read

fontserv flush

Like nameservers in TCP/IP getting name information from other nameservers, you can have font server get fonts from other font servers. This is also done with the catalogue entry. For example, if I wanted to make the local 100dpi fonts available as well as those from the remote host scoburg, the entry might look like this:

catalogue = /usr/lib/X11/fonts/100dpi,tcp/scoburg:7000

Assuming that scoburg has their font server configured to use port 7000, changing the port is also accomplished by changing the /usr/lib/X11/fs/config file. On a line by itself, add a line specifying the appropriate port. For example, if we wanted to change it to 7042, the entry would look like this:


Once the change has made, the font server needs to be stopped and restarted. If any other machines were using this server, they need to be told that it is now set for port 7042.

You can use the -cf option when starting the fontserver to specify an alternate configuration file. Reconfigure any X servers that use the font server. NOTE: Exercise care when referencing other font servers. Font server connections place a heavy demand on network resources and bandwidth. Also, be careful not to let the number of references to other font servers become so large that your system font server becomes unmanageable.

The Window Manager

Because the window manager is an important aspect of X, we need to cover it in some more details. As I mentioned earlier, OpenServer provides two window managers, mwm and pmwm. The panner version is available as a separate product for ODT. Because the underlying concepts are the same, we're going to talk about them first. Later, there will be a separate section dealing with the issues related to the panner. To make things easier, I will refer to the window manager simply as mwm.

As I mentioned before, mwm is just another client. As such, it has a default file: /usr/lib/X11/app-default/Mwm (Pmwm for the panning version).The following sections describe the basic default behavior of windows, icons, the icon box, input focus, and window stacking. The appearance and behavior of the window manager can be altered by changing the configuration of specific resources.

By default there are several accelerator keys that perform various functions. These functions can also be reached through the window menu. Any windows managed by mwm with have these keys. These are explicitly defined and can be changed by modifying the appropriate resource (which we'll get to in a minute). These keys are:


Moves the window to bottom of the stack


Terminates the client


Restores the window to its previous size


Allows the window to be moved with keys or the mouse


Allows the window to be resized


Iconifies the window


Maximizes the window

The window manager is also responsible for managing icons. As I mentioned earlier, icons are small graphic representations of clients. Iconifying (turning into an icon) a client is a good way of reducing the space take up by clients that are currently not being used. Although the panner allows you to move clients from one virtual screen to another, icons are a good way of being able to instantly access a particular client. The icon box is enabled using the *useIconBox resource. This is Boolean value, so enabling it through the .Xdefaults file might look like this:

Mwm*useIconBox: TRUE

A nice thing about the icon box is that it represents all running clients and not just the ones that have been iconified. This makes finding the client you want easy, since you double-click on its icon in the icon box, and it is immediately made the active window and brought to the front.

If you click on the icon once, the icon menu pops up. This is actually the same menu as the window menu. However, certain functions are disabled (grayed out). For example, since the window is already at its minimized size, the minimize option is disabled. However, you can still move the icon. In this case, restoring returns the window to it's previous size. It is often said that the window is "opened." By double-clicking on the icon, it is restored to its previous size.

If you have a lot of icons, using the icon box is a good way of managing them. The icon box is simply another client,which manages the icon images. It can be moved and resized, even iconified. If there are more icons in the icon box than can be shown in the box, scroll bars will appear. An icon within the icon box can be restored just like an icon when it's not in the icon box.

The icon box has a different window menu than the other clients. Although it does have entries to move, resize and restore the icon box itself, there are other entries that sort the icons.

One of the strong points of both window managers is the ability to configure it to our tastes. Up to now we have basically been talking about the appearance of mwm. What is really fun is to modify its behavior. One way to accomplish this is through the resource description file. It contains descriptions of resources that are easily defined in the resource files. This includes such things as the behavior when buttons are pressed and the individual entries in each menu.

The default resource description file is /usr/lib/X11/system.mwmrc or /usr/lib/X11/system.pmwmrc. Here again, unless you want to institute system wide changes, I recommend copying the appropriate file into the user's home directory. It then has the name $HOME/.mwmrc or $HOME/.pmwmrc. Here is where your default menus and default bindings are defined. When you click on the root window, the root menu pops up. This is defined in the .mwmrc or .pmwmrc file, and is very easy to modify to your personal tastes and preferences.

There are three types of resources that can be described here: buttons, keys and menus. It is said that window manager functions are bound to button or key press events. The relationship between the button or key press is called a binding.

Since the resource description file is an ASCII text file, we can easily edit it to make the changes we want. The format of each type of resource is slightly different, but in each case, the fields are separated by white spaces. Any text from an unquoted pound-sign (#) to the end of the line is considered a comment. Therefore, if any description needs to contain the pound-sign it must be quoted. Single characters can be "quoted" by escaping them (using the back-slash). Any line containing an exclamation mark as the first character is also treated as a comment.

When an event occurs (button or key pressed, or menu item selected), a particular window manager function is called. In general, we can say that the functions have the following syntax:

function function_arguments

There are dozens of functions that you can call, relating to everything from resizing the particular window or icon, to shuffle the order, moving, and all the other things we talked about. All of these are detailed in the mwm(XC) man-page, so I don't feel a need to cover them all. However, I will discuss some of the more common one as I describe the syntax of the resource descriptions.

The syntax for the f.exec definition is:

label [mnemonic] [accelerator_key] f.exec <arguments>{P}

an example would be:

UNIXWindow _U Ctrl<KEY>u f.exec "/usr/bin/X11/scoterm -e /bin/ksh"

The label in each line is the symbol that will appear in the menu pane for that entry; in this instance, SCOTerm. Labels containing spaces or tabs need to be enclosed within double-quotes. For example, "UNIX Window." Symbol can be a text string or it can be bitmap. This allows you to assign icons to the menu entries instead of textBitmap file names that are preceded by an at-sign (@). The entry then might look like this:

@terminal _U Ctrl<KEY>u f.exec "/usr/bin/X11/scoterm -e /bin/ksh"

When you specify a bitmap, mwm defaults to reading /usr/include/X11/bitmaps. If the bitmap you want is not there, you must specify the full path. If mwm cannot find the file, it displays the entry as if it were text. If in the above example, the file was actually called terminal.xbm, I would not see the terminal bitmap, but rather the text string "@terminal," at-sign included.

A mnemonic is a single character that is used to activate the menu option when the menu pane is visible. Contrast this to accelerator keys that are active whenever that particular window has the focus. When a mnemonic is defined it is preceded by an underline. Then, the first character in the menu label that matches the character specified will also be underlined. When the menu pane is displayed, you can activate that window function simply by pressing the key specified. Here we have _U. When displayed, the U in UNIX will be underlined.

If the function called is the no-operation function (f.nop), the function is invalid or doesn't apply in the given context, then the label is grayed out (disabled). If a function is specified that isn't one of the supported functions, then it is interpreted by mwm as f.nop.

The accelerator key syntax is:


Where [modifiers] can be things like Ctrl for the control key, Alt for the alt key and Shift for the shift key, here we have said the accelerator key combination is CTRL-U. So, when I want to have a new UNIX window I just press CTRL-U.

au: why is word ÒmodifierÓ above in square brackets? remove?

The entire [modifier] on the line above will be replaced in the file. Threfore leave it as is.

Note that in contrast to button presses, key bindings to window manager functions are just for the key presses. Key releases have no meaning in this context. Also, the modifiers are exclusive. That means that no other modifier key can be pressed. Since I specified just CTRL-U and not SHIFT-CTRL-U, pressing SHIFT-CTRL-U would have no effect (unless I had defined it to something already).

Choosing this combination taught me two things. First, any accelerator that is defined for the root menu is valid no matter what other window is active. Since I had included this definition within the RootMenu section of my resource file, anytime I wanted a new UNIX window I just pressed CTRL-U. Much of this text was typed using 'vi' from within a scoterm window. I realized that this was not a good accelerator key when I tried to move up a couple of screens in 'vi'. Remember from the section on 'vi', CTRL-U is used to move up screens. Since it is the X server that gets the keystrokes and passes them to them to the client, 'vi' never saw them. Instead I had five new scoterms. Needless to say, I changed that accelerator key rather quickly.

The next type of resource that I want to talk about is also commonly modified. These are menu resources. The two functions related to menu are f.post_wmenu, which causes the windows menu to drop down, and f.menu, which creates a pull-out or cascading menu. It is said that it creates a new window pane. This is similar to a pull-down menu, except that the menu starts to the right of the item that called it. For example, if one menu item calls the f.menu function, a new menu will appear to the right of that menu. If bound to a button press, the menu will appear to the right of the current pointer position.

When the f.menu function is called, mwm searches for the menu label within the resource file. The menu definition has the follow syntax:

Menu menu_name


label [mnemonic] [accelerator_key] function

label [mnemonic] [accelerator_key] function

. . .

label [mnemonic] [accelerator_key] function


An example might look like this:

"Admin Menu" _A f.menu AdminMenu

When you click on the Menu entry labeled "Admin Menu", a pull-out menu appears with the content that appear between the curly brackets. Each entry within the sub-menu is just like any other entry containing f.exec, f.menu or any other functions. If you want, you can have several layers of sub-menus, but I have never found the need to have more than three. Even that was getting a little unsightly.

Each button binding has the following syntax:

button context function

The button field describes the state that the button enters for the event to take place . For example, an entry that said <Btn1Click> would mean that button 1 was clicked. Or <Btn2Down> means that button 2 must be down.

The context is where the button must be for the button action to have an effect. The contexts are defined as follows:

Contents can be OR'ed together to enable that behavior at different times. For example:

<Btn2Down> frame|icon f.post_wmenu

This says that anytime the pointer is over a window frame or an icon and button 2 is pressed, the window menu should be posted.

The button bindings are grouped together similar to the way menu is. In general, it looks like this:

Buttons group_name


button context function

button context function

. . .

button context function


In order for these button bindings to take effect, you have to set the buttonBindings resource value to the group_name. For example, If I had a button bindings group called JimButtonBindings, the definition would look like this:

Mwm*buttonBindings: JimButtonBindings

Because there are no default button bindings, per se, you must include all the bindings you want within the bindings sections. This is done within the .Xdefaults file. Examples of other button states are:

Btn1Down Press Button 1

Btn1Click Press and Release Button 1

Btn2Up Release Button 2

Btn3Click2 Double-Click Button 3

Aside from limiting where on the window a particular function is applicable, there are also limitations as to what kind of windows the function applies to. For example, if the window has been iconified, minimizing does nothing as the window is already minimized. If the window is already its normal size, the restore function has no effect. Basically what happens is that if the function invoked has no meaning in the particular context, it is treated as a f.nop. See the mwm(XC) for a list of what functions apply in what contexts.

The Panner

First introduced as an extension product to ODT 3.0, the SCO panner is perhaps one of the most significant improvements to X since its inception. Basically, the Panner is an enhanced version of the OSF/Motif Window Manager (mwm), which is the standard window manager on ODT. It is rather trite to say that all it does is provide virtual screens fro you to work in. Although this is true, it is comparable to saying X only gives you windowing capabilities.

One of the problems I, as well as many other users face is that we often do not have the luxury of large monitors. To have more than a handful of clients running, we usually end up with them being either overlapped or sometimes completely hidden. Often to avoid clutter, we will iconify the less frequently used clients to make room for others. However, this cures the symptom and not the illness. The obvious solution is to get a bigger monitor, but even that doesn't solve everything since you can't have a monitor that's infinitely large. Or can you?

This is where SCO Panner comes in. It established a virtual monitor that can be dozens of times the size of your "real" monitor. With the push of a button or click of a mouse, you move around this virtual workspace with an amount of freedom comparable to having a larger monitor. Just like virtual memory does have drawbacks over "real" memory, virtual screens have a drawback over a larger monitor. However, even if you do have a 21" monitor, the panner can provide you with even more work space.

Functionally, the panner behaves like a viewport or viewfinder into the larger virtual screen. You can move around and place your windows anywhere within the workspace. Movement can be in increments equal to the size of your "real" screen or you can move around in smaller steps, allowing finer control over what your viewfinder is currently looking at.

In order to change which window manager you use, you need to change the .startxrc or sys.startxrc file. By default the line looks like this:

exec mwm 2> /dev/null

This starts the standard Motif Window Manager. All you need to do is change the mwm to pmwm, like this:

exec pmwm 2> /dev/null

Now, start (or restart) your session and you will now have the panning Motif Window manager. When it starts you will see the panner "viewer" in the lower left hand corner (by default). It is divided into four workspaces (again, by default). These are numbered 1-4. Workspace 1 is referred to as HOME and you will see this as the label, instead of a number. Between each workspace is a thin line. This is the "grid." This simply shows you the boundaries of the predefined workspaces.

Each workspace is the size of your screen and there are several ways that you can move around:

The first way of moving, clicking on one of the workspaces, will move you completely into a workspace. That is, if you click on one of the work spaces, you are brought to that workspace and the viewfinder is completely within that workspace. Even if the viewfinder is over portions of multiple workareas (entirely possible), clicking on a workspace brings you there and will move the viewfinder.

If you use the ALT key and an arrow key, you are moved in that direction one "viewfinder-width". That is, if you are completely within workarea 3 and press ALT-LEFT_ARROW, you end up completely within workarea 2. However, if you are halfway over workarea 3 and workarea 4, pressing ALT-LEFT_ARROW moves you to a place halfway over workarea 2 and workarea 3. There are also options in the root menu that perform panning.

The viewfinder is represented in the panner window by a gray box, the size of a work area. By pressing the left pointer button, you can drag the viewfinder to any workspace. When you release the button, you are brought to that workspace. Using this method, you can move the viewfinder to a location between workspaces. I have found that the more the viewfinder resides in one workspace, the more likely it will actually move completely into that workspace. For example, if you move the viewfinder so it is 10% over workspace 2 and 90% over workspace 3, releasing the pointer button brings you completely into workspace 3. The granularity of movement is defined by the *snapDistanceX and *snapDistanceY resources.

Autopanning allows you to move between workspaces by simply pressing a button and moving the pointer in the appropriate direction. Autopanning is controlled by a couple of resources. The first, autoPanStep, is also used to enable and disable autopanning. This resource determines the percentage of the screen size the viewfinder moves when autopanning. Setting it to 0 means autopanning is disabled.

Whichever key is used to activate panning with mouse movements is defined by the *autoPanModifier resource. By default, this is set to the Meta (Alt) key. If this is not set, then any time the mouse bumps against the edge of the viewfinder, it will pan. I suggest leaving the default or selecting some other key, but do not remove this resource. If it is not set, then any time you accidentally bump against the viewfinder, your view is thrown out of whack. How long the panner must wait after autopanning before the next pan is allow is defined by the autoPanRepeatSensitivity.

If autopanning is enabled (that is, AutoPanStep > 0 ), the *autoPanStartOn determines whether autopanning must be first turned on (or not) before you can use it. The default is True, so that whenever pmwm starts and AutoPanStep is greater than 0, autopanning is activated. Otherwise you must enable it from the root menu or by pressing ALT+SHIFT+minus. The panning can also be turned off from the root menu or by pressing ALT+minus.

One concept new to the panner is the idea of nailed windows. Nailed windows stay put. That is, if you change your work area, they follow you. Hmmm. If they stay put, they follow you. Now, that's a contradiction if I ever heard one. Believe me, that's the way I felt, too. However, think of it not as the windows being nailed to the panner as a whole, but rather the viewfinder. If they are nailed to the viewfinder and you move the viewfinder, they stay within your view.

Aside from allowing you to move from workspace to workspace, the panner allows you to move clients between different workspace. When the panner has the focus, you can use pointer button 2 to drag a window to a new workspace. The nice thing is that regardless of how they are stacked, all windows will appear with the workspace view in the panner. Therefore, you can grab any window and move it. I have run into situations where two windows were the exact same size and were in the same position. In this case, it was impossible to figure out which window would be grabbed.

If you don't like the numbers given to the workspaces, you can change them with the *workAreaNames resource. This is what is used to name workspace 1 to home. Arranging your workspaces by function this is a good way of keeping track of what is where.

The panner window is just like any other window. There are resources to name it, change its color and define its geometry. Like other windows, you can change the size of the panner window. One side-effect of changing the size of the panner window is that you change the number of workspaces. By default, there is a single row of four workspaces. You can make the panner window longer, thereby increasing the number of workspaces, or you can make it taller, also increasing the number of workspaces. If you make it taller, then the windows are numbered left to right across the top row and continue in the second and subsequent rows. If you don't like the horizontal appearance of the panner, you can make it vertical, by simply changing the shape of the window. You cannot resize the panner window so that the workspaces with windows in them are removed. You can change the defaults for the panner in /usr/lib/X11/app-defaults/Pmwm.

For example, assume we have a workarea that is 3 rows of four workspaces each. If we place a window in workspace 12 (the lower right corner) we can no longer decrease the size in either direction. If we move the window to workspace 8 (right most window in middle row) we can decrease the number of rows, but not the number of columns. However, you can disable this by setting the *pannerResizeNoHide resource to FALSE.

By default the panner map has a scale of 1:10. That is, the height of each workspace in the panner is 1/10th that of a real workspace. This is defined by the *pannerScaleFactor resource. Unless you have a lot of clients in each workspace, then I feel that a 1:10 scale is too large. I use 1:15 ratio because it allows me to identify all the clients in each workspace, but still doesn't take up too much room. Anything higher and the individual windows in each workspace will run together.

If you prefer a feeling of having a single, larger workspace than a lot of little workspaces tacked together, you can turn off the grid by setting the *pannerShowGrid resource to FALSE.


The scologin program is actually a "display manager” since is displays the graphical login on more than just the system console. If you are running on X terminals, it is scologin that allows you to login. In principle, it serves the same functions as both getty and login.

Normally, scologin is started from /etc/rc2.d/P86scologin and runs on the second multiscreen, /dev/tty02. During the installation of OpenServer, you are given the option of enabling or disabling it by default. I prefer to start X on my own, therefore I always have it disabled. However, it is not a good idea to have X terminals relying on scologin. Instead, you can edit the file /usr/lib/X11/scologin/Xservers. There is a line:

:0 local /usr/bin/X11/X :0 -crt /dev/tty02

As you start-up, scologin uses several scripts to determine what to do and when to do it, all of which reside in /usr/lib/X11/scosession. The first, Xstartup defines what scologin should do before beginning the user's session. Next comes Xsession-<shell>, where <shell> is the user's login shell. This defines the basic characteristics of the user's X session. Xreset defines the actions when the users ends a session.

One thing to keep in mind is that the Xstartup script is run as root. As such, anything you put in there is run as root. This has the potential of becoming a security hole. Note that by default, you don't have to worry too much, as Xstartup is empty, just waiting for the eager system administrator to fill it up. One thing the Xstartup file is useful for is on X-terminals. Since they have no disk of their own, it is probably necessary to mount the filesystem containing the user's home directory.

It is only after that scologin has run through the Xsession files that it starts the X server. This is done with by running startx script with the -t. The Xsession-<shell> script that is run, behaves like a user's .profile or .login file, in that it sets up variables and other aspects of the user's environment.

In the SCO documentation you "are strongly urged to use scosession to control the clients." Their point is that if you start them out of either $HOME/.startxrc or /usr/lib/X11/sys.startxrc, you may miss certain aspects of that (or other clients), which may result in the loss of some functionality. Quite true. However, I have gotten around this.

First, I copied /usr/lib/X11/sys.startxrc to $HOME/.startxrc, which is a good idea anyway. I next comment out the lines that tested for the existence of /usr/bin/X11/scosession and if it was there, ran it. Instead, I just run the two lines that start a scoterm and the window manager:

exec scoterm 2> /dev/null &

exec pmwm 2> /dev/null

This way I still start all the clients the way SCO "wants”, but I don't have scosession. So, just what does scosession do? First, it's name implies it is responsible for the startup and shutdown of the X server. The configuration files for scosession are in $HOME/.odtpref/ScoSession with the standard X resource information in /usr/lib/X11/ScoSession. One nice thing about scosession is that it remembers what you were doing the last time. When you start up the next time, you are prompted to resume the saved session or start a new one. The file $HOME/.odtpref/ScoSession/dynamic contains the information that was saved from the previous session. That is, what is needed to configure your session when you decide to resume that last session. The static file contains the resource settings that define your default session. If this file doesn't exist, the resource information is taken from /usr/lib/X11/sco/ScoSession.

Using X terminals

As their name implies, X terminals are terminals the run X. In principle, they function the same way as normal terminals. The X terminal is responsible for communicating with other devices as well as displaying the incoming information on the screen. The major difference (I hope you already guessed) is that the interface is all graphical. The appearance is no different (well, not much) from what you would get running on the system console. X-Terminals can be as large as consoles as well as provide color.

You can configure your X-Terminal so that scologin automatically presents you withll a login prompt every time you turn on the terminal. Like "normal” terminals, you are connected to a host machine where the programs (in this case X clients) are running. To aid in the communication between host machine and X-Terminal, SCO can use the X Display Manager Control Protocol (XDMCP), provided the X-Terminal can use it. One advantage this has is that the connection is immediately re-established to the host when the terminal is turned back on, and you see the login prompt waiting for you.

If the X-Terminal does not understand XDMCP, you must include an entry for that terminal in the /usr/lib/X11/scologin/Xservers file. Otherwise you don't have to configure the host at all. Instead, the XDMCP communicates with the SCO machine and hooks you up. In addition, the terminal must be left powered on at all times to maintain the connection to the host machine. If you turn it off, you must manually reconnect it to the host.

On the X-Terminal side of things, there are two ways of configuring things. Well, actually three. The first is using XDMCP. If the X-Terminal uses it, there may be no configuration needed. However, if there is, you have to determine how the X-Terminal is to contact the host, as some broadcast a request for a host. When there is an answer, they will display a list of available hosts from which you can choose. Others broadcast a request and just accept the first available host.

Once you login, the behavior is the same as if you were on the system console. If there is an .Xdefaults file in your home directory that matches the name of the host that you connect to, these will be the defaults used.

The /usr/lib/X11/scologin/Xservers file is used to configure scologin on those X-Terminals that do support XDMCP (or ones where you don't want to reconfigure it). The format of the Xservers files is the same forof X-Terminals as it is for scologin. (Makes sense when one considersed that you get a scologin on the X-Terminal.)

Security and Authorizations

Because of its very nature, X is not very secure. It sits on a network, which means that potentially everyone on your network has access to your machine. This applies to X or any other network application. The problem is compounded further by X's design. It was intended to be accessible by others. If you know the name of the machine, theoretically you could display any client on someone else's machine. In fact, you could essentially take over control of that machine including taking over the mouse and even killing the other person's clients. Fortunately, there aren't any such bad willed people that perform such senseless acts of aggression. Yeah, right.

Although we haven't yet figured out how to make X completely secure (other than disconnecting it from the network), there are several mechanisms that we can use to limit the access to our machine. The first is based on which host is trying to contact you and is specified through the files /etc/X?.hosts, where ? is the display number. Since you more than likely have only one display, we are only going to talk about X0.hosts. However, what we talk about will be applicable to any display.

By default, the server only accesses clients that are running on the local machine. If we want to add a machine, we either add the machine's name to X0.hosts or we use the xhost program. The X0.hosts file is a simple text file containing a list of the hosts that are authorized to connect. For example, the X0.hosts file on scoburg might look like this:




Normally, this is sufficient, but in some cases you might need to include the domain name as well. If any other host tries to start a client on scoburg's display, they're will end up getting something like this:

Xlib: connection to "siemau" refused by server

Xlib: Client is not authorized to connect to Server

X Toolkit Error: Can't open display: siemau:0

The other mechanism is to use the xhost program to allow or deny access as needed. Since the X0.hosts file is usually one writable by root, xhost allows users to decided what machines can connect during their current session. To add a machine the syntax would be:

xhost +hostname

and to remove it:

xhost -hostname

Note that you cannot add hosts to a remote machine. For example, you cannot telnet to a machine and run xhost. If you try, you end up getting a message like this:

scoburg being added to access control list

xhost: must be on local machine to add or remove hosts.

You can also allow access by all hosts with:

xhosts +

However, this is counterproductive, as the whole idea here is to limit access to your machine.

Another access control method is the well-named MIT-MAGIC-COOKIE-1. Why is it well named? Come on! It's a great name! Despite any "logic" behind the name, I think it's fantastic.

When you are logging in X using scologin, a machine-readable code is placed in $HOME/.Xauthority. This code is called a magic cookie and is 128 bits long. The magic cookies can be thought of as a password that is only known to the server and the user logging in with scologin. Unlike regular passwords, users don't actually type in the password, but rather users run programs to manipulate it. Once established, a client has to present this password (code) in order to access the server. The code is obtained by reading .Xauthority, but since it is (by default) only readable by the owner, only the user can access it.

With a shared home directory (such as one using NFS) the .Xauthority file is available to you. If you are on another machine, you need to use the xauth program to raid the cookie jar on the other machine to extract the information and merge it with your own. However, If you don't have access to the remote .Xauthority file this won't work. One solution is user equivalence that we talked about in the section on networking. The other is .rhosts. Both allow you to define which users (and from which machines) can access the .Xauthority file. However, this also opens other things up.

If you are on the local machine and want to update the .Xauthority file somewhere else, you would run xauth like this:

xauth extract - $DISPLAY | rsh <remote_host> xauth merge -

The basic syntax for xauth is:

xauth <flags> <function> <options>

If we use the add, merge, or extract functions, then we need to specify the server. In the first half we are extracting the authority information from whatever machine we have defined with the DISPLAY variable, which is normally the local host. The dash (-) here says we want to write the output to stdout. If we wanted we could extract the information from another host by using that name, provided the information was in the .Xauthority file. Because we did not use the -f option to specify what file to read, the system uses the file in the XAUTHORITY variable, which usually defaults to $HOME/.Xauthority.

In the second half, we are running rsh on the remote host and merging the authorization information. Here the dash means we are reading from stdin. We can also extract the authorization information for a remote machine and merge it with the .Xauthority file on a different machine. The syntax would be:

xauth extract - vesta:0 | rsh scoburg auth merge -

We can now take this one step further and extract the authority information from a remote machine and merge it with the information locally. Again, assuming we are on siemau and want to extract the authority information on scoburg, the command would be:

rsh scoburg xauth extract - scoburg:0 | xauth merge -

The SCO Desktop

If you come from a MS-Windows or Mac world, then you will be familiar with the desktop metaphor presented by the SCO desktop (as shown in Figure 0-3). As you would expect, there are both menus and icons to help you access the programs and functions of your desk top. You will find a filing cabinet to help you find your file, an envelope for mail and even a life preserver if you need help. Like these other desktops, you can also configure you desktop to suit your needs.

Figure 0-3 The SCO Desktop

As you begin to work with the desktop, you will see that it is loaded with features. Unfortunately, there are too many features to cover them all here. Instead, as with many other aspects, we are going to just cover some of the more commonly-used features.

One of the key differences is that the SCO desktop is not the all powerful interface to the system like the Windows Desktop. In fact, the SCO desktop is an application like anything else, such as a terminal window. The only difference is that this application is a lot more complex than others. Another difference is that the SCO desktop can be turned off. That is, if you are running X Windows, you do not need to have the desktop running at all. If you do have it running, it does not have to fill up the entire screen. You can configure it to behave just like other Windows that you can make smaller to get out of the way (called iconifying them).

What's on the Desktop

You may have noticed two different kinds of icons. One set of icons has a file folder, in addition to some other kind of picture. This indicates that this icon doesn't do much on it's own, but is a folder containing more icons (or even more folders). The other set of icons are essentially programs that run when you click on them. I used the word "essentially" because it is better to say that the icons are "objects." Clicking on them, or even dropping other objects onto them will trigger certain actions. What actions occur is something that you can program.

The icons that you see on your desktop are referred to as objects, which have properties and behavior, very similar to those you find under the newer versions of Windows. Instead of just defining the program to start a working directory as you would in MS-Windows, you define how it behaves. For example, what should the behavior be when you double click the icon (activate) or what happens when you drop other object on top of it (drop)? In addition, change different object for when the object has been activated (large and small)

Let's take a quick look at the printer object to see how this can work. If you were to drop a file onto this icon, that file will be printed. On the other hand, if you were to open it (by double-clicking it or selecting Open from the File menu) the Print Job Manager would open. This shows you that the two ways of opening an object can initiate two different actions.

Another object that behaves differently is the Object Builder. This is the program that you use to create new objects and to edit existing objects. This you will find in the controls folder on the desktop. If you open the Object Builder, it will open up a blank object. However, if you drop another object onto it, the Object Builder will start, having loaded this object.

The default behavior of the FreeSCO is that the desktop is configured to run automatically when you start up X windows. Also, the default behavior is to start up taking up the whole screen. This is referred to as the root window. Learning how to change this is what we'll get to next.

Configuring the Desktop

Changing the behavior of the desktop: the est way to change the behavior is through the Preferences Editor, which is found in the Controls folder. You can also start it from the Options menu by clicking the "Preferences Editor" entry. There are normally over 20 different things that you can configure (see Figure 0-4). Some of these will only configure one specific aspect of the system. The Bell icon, for example, controls characteristics of the bell such as the frequency and duration. Other icons allow you to configure a wide range if aspects. For example, the Tools icon is used to configure (among others) the specific programs to start for different desktop functions. For example, the Text editor entry defines which editor is started when "something" needs to be edited. (This happens in various places.) The default here is ScoEdit (a graphical editor). I change this to vi.

Figure 0-4 Preferences Editor

Many others just configure the appearance of something such as the "Desktop Appearance" icon or "Popup Menus". Here you can define which font to use and sometimes other things such as a background pattern to display in a specific window. One thing I always change is in Main Desktop Behavior. The first entry is "Desktop as root window". This defines whether the desktop takes up the whole screen. I prefer that it doesn't so I set this to "No". In addition, the desktop is not "nailed" to the background. Since it is just another window, when changing your workspace with the panner, the window containing the desktop stays put. (However, you can changing this from within the Window menu with "Toggle Nail.")

When using the desktop, I prefer to use the desktop like this, rather than as my root window. This way I can work as I want without the icons and the rest of the desktop getting in my way. However, I still have the desktop open as a window. I then change the shape so it is a thin strip across the top of my workspace which gives me a simple little toolbar.

The default desktop displays mode: specifies icons or text. The desktop opening display method: allows you to specify with the View menu method if icons are displayed as text or images. If set to always inherit, new icons are displayed in the same way. Never means they are set according to value set in "Default desktop display mode".

Another aspect here that I change is the "Desktop traversal mode". This defines whether or not a new window is open when you open up a new desktop top. I rarely have a need to have multiple desktops open, so I set this to "Always reuse window". Therefore, when I open a new desktop, the contents of the first window are basically overwritten with the contents of the new window. However, you can set it to "Open new window" which will (as it implies) open a new window.

The Desktop display mode defines whether the names are displayed as icons or as text. At least, this is what the SCO documentation says. And this is true, for the most part. However, when you specify the names to be displayed as text, they normally have a much smaller icon with them. Note also that when you display the name, you get the name of the object in most cases and nothing very descriptive. When you display the icons, the text that appears is the title of the object and not its name. The title is something that you can define using the Object Builder (which we will get into shortly).

The "Desktop opening display method" defines the way icons are displayed for subsequent desktops. Setting it to "Always inherit" means that new desktops will display the icons in the same way as the desktop from which the new one was started. Setting it to "Never inherit" means that the appearance will be the same as defined in "Default desktop display mode".

One thing to watch is when you have configured your system to reuse the same window for the desktops. Normally, desktops are created with nothing in them. The exception is the Personal desktop, but that is created by the system the first time you start the main desktop. The personal desktop contains an icon label "Main desktop." This will get you back to the main desktop. However, subsequent desktops will not have this icon. If you have created several layers of desktops, you cannot traverse back up the tree automatically. Instead, you need to select the entry "Open main desktop" from the File menu.

Keep in mind that you can have multiple copies of objects wherever you need them. Therefore, each desktop *could* contain an icon for all the other desktops. Therefore, no matter where you were, you could get to the desktop you wanted.

When you start the desktop for the first time (normally the fist time that you start up X), several files are created. One is your personal "Desktop". This is all of the icons that you have placed on the desktop and is stored in the file Personal.dt in your home directory. You can access this desktop by clicking the desktop looking icon labeled "Personal Desktop." (Makes sense, huh?) The default is nothing other than another desktop looking icon labeled "Main Desktop". Clicking this brings you back to your start-up desktop.

What this allows you to do is configure as many different desktops as you need. Sometimes, I find that the functionality of just the folders is not enough. Instead, I create a desktop that has all of the icons that I needed. I then open up that desktop when I need those tools. I rarely have more than a couple of desktops in addition to the main one. The others are simply additional icons within icons. I rarely find it necessary to layer them. That is, having desktops within desktops within desktops. Instead, the few I need are placed on the main desktop. However, you can if you wish to.

Desktops are created using the "New Desktop" entry under the File menu. When you select this, you are given a input window so you can input the name of the desktop. If you leave out the default extension '.dt' the system will add it for you.

Keep in mind that the desktops are only connected logically. They are not like directories where one desktop is inside of the other. At least not the default. The default puts all of the desktops into your home directory. So when the input window appears, you simply give it another directory path. However, the default will always be your home directory. For example, assume I create a sub-directory in my home directory called Desktops and create the new desktop called Admin.dt. If I then create a desktop on top of Admin.dt, the system will default to putting it in my home directory and not in Desktops. However, it is just a simple matter of adding the appropriate directory name.

Also in your home directory is the main desktop, stored in the Main.dt file. This contains all of the default objects. The main desktop is called from the personal desktop, so there is no real reason to change it. Instead, you should make any changes to your personal desktop. Keep in mind, however, that the system will update the Personal.dt for you. (You are prompted to save when you exit the desktop.) Therefore, you shouldn't need to make any changes in the Personal.dt file yourself. At least, not yet. Checkout the xdt3(XC) man-page for details on configuring these files.

One thing that I find very useful is that many of the functions and folders are available from different places. For example, the basic configuration location is the Preferences Editor. However, there are other places on the desktop you might want to configure: something like the bell or the keyboards. Depending on the window you have open, you will have an Options menu at the top. Here you can define characteristics that are specific to that window or general characteristics such as the bell.

Note that not all windows will have the same characteristics. For example, opening up your home directory gives you the option to change many different characteristics. However, if you have a scoterm window open, you can only change those options applicable to the scoterm. (For example, the size of the font or whether or not there are scroll bars.)

In the Accessories folders are a handful of "gadgets". These range from a calculator to a paint program to a reminder program. There is also a calendar program, which you can use to keep track of appointments, schedule meetings, and so on. One very nice thing about this is that you can access other people's calendars as well. By default, all events created in your calendar can be viewed by others. However, you can make any event private, if you wish.

Each desktop window (as well as several other windows) will have a menu item labeled Tools. The Toolsheds entry opens up a window containing several folders. Some, like the Accessories folder, are also on the main desktop. In these folders are a wide range of tools. It is not easy to group them into a single category as they do some many different things. For example, the System Commands folder gives you a graphical interface into many of the commands on your system. The Demonstration folder contains a handful of animated icons.

The Applications entry will open up a folder containing icons for various applications. Surprisingly, you will find icons for SCO Merge and Wabi. This does not mean that these are installed on your system. It just means that if you do install them, the icons are already there. What gets placed in this folder depends on the application. If the application does not know about the desktop structure, you will have too install an icon by hand. (See the section on creating objects.)

The Personal Icons entry will show you the icons that you have stored in the .xdt_dir/bitmaps directory in your home directory. There are two sub-directories here: one for small and one for large icons. Note that there are no bitmaps/icons in here by default.

You may have noticed two small folder-like icons in the bottom left-hand corner of many of the windows. One of these has an up-arrow in it. This brings up one directory. Remember that objects are nothing more than a set of files in a single directory. If you have a particular folder open, you are basically showing the contents of a particular directory. This system knows that if this is an object, it should be displayed in a special way. When you click the icon with the arrow, you are moved up one directory. Note that folders are nothing more than directories. By convention, they have an ending ts. However, you can call them whatever you like. The other icon (without the arrow) will refresh the current window.

Creating Objects

Objects are created using the Object Building which you will find within the Control folder. This is described in chapter 20 of Graphical Environment Guide, ÒCreating Objects for the DesktopÓ.

Fortunately, changing an existing icon is as simple as one would hope. As I mentioned previously, Objects react to two types of actions or triggers. These triggers are "open” and "drop.” Either you open up the object and trigger the open action or drop another object onto it an trigger the drop action.

Since the Object Builder icon on the desktop is on object itself, it too reacts when something is dropped on it. That something is to start and load the object that was dropped. You can then save these objects as a different name and edit it to your heart's content.

Creating new objects is a fairly straightforward process. However, creating objects as complicated as many of those provided for you is not all that easy. Rather than making this a book on creating desktop objects, I will refer you to Chapter 20 of the Graphical Environment Guide, "Creating Objects for the DesktopÓ.

New objects can be created either by copying existing objects or creating them new. The easy way to copy an existing object is to drop the object onto the Object Builder. When you do this you are given the choice to load both the icons (picture) and the actions (what is done when the icon is clicked or another object is dropped onto it). Which you load will depend on whether it is just the icons you want to copy or the actions of the icons.

Figure 0-5 The Object Builder

As an example, let's take the UNIX icon from the desktop. When it opens up we see something similar to Figure 0-5. I recommend that very first thing that you do is save the object under a new name. This keeps you from overwriting the existing object. If you are logged in as a user other than root, copying system objects won't be a problem as you cannot overwrite them. However, if you are root and overwrite something that the other users need, you can make yourself very unpopular.

To associate a program with a particular action (opening or dropping) you "install" it using the Executable entry under the Install menu. This brings up a dialog window which allows you to search for the specific application you want to start. This creates very basic actions that you can modify as you need to. You are also asked whether this is a graphical application or not. If not, then you are asked whether the system should wait for a key to be pressed before continuing. This is useful for programs that will simply display some output before returning to your prompt. An example of this would be the df program to display the disk free space. Normally, you enter this command and are brought back to the prompt. If you create an object that runs df and do not wait, it will run the command, but the window it is displayed in will disappear as soon as the command finishes.

au: words missing below??? please advise

it. In the upper part, the trigger action is "activate" which simply means the program started when you double click on the object. Below is the trigger action when an object is dropped on it. The actions created by default are fairly simple. For example, the activate actions for a graphical program look like this:


cd $HOME

/usr/bin/xv $*


The actions are defined within the begin-finish block. In this case, all that is done is to change directories to the current userÕs home directory, run the program /usr/bin/xv and pass any arguments to command. You can pass arguments to the object by selecting the object and clicking the right mouse button. A pop-up menu will appear labeled "Activate with arguments". If you select this entry, a window will appear in which you can input arguments that should be passed to the program.

If you said that this was a non-graphical application, the default script looks like this:


cd $HOME

shell -n '' '/bin/df $* ; xdtwait'


Basically it is the same, with the exception of the line that actually starts the application. First, the object changes into the users home directory before the program is started. In this case, a shell is started. The shell command is a built-in directive, which says to run the user's default shell. We see the program that will be started (/bin/df), which will then be passed all the arguments.

In all honesty, I have never done anything much more than that. On occasion, I have installed a shell script this way and explicitly passed arguments, However, I personally have not used any of the advanced programming features that are available. Writing commands are fairly straight forward, as much of it is the same syntax as shell programs. Unfortunately, this is one area that I will have to put off. See Chapter 25 of Graphical Environment Guide, ÒWriting Desktop CommandsÓ, for more detailed information.

What Now?

The principles by X may appear overwhelming at first. By understanding that the different aspects of X-Windows can be thought of as different layers building on each other, it's easier to understand their interactions. My suggestion now is to play around with your X system and make some changes and see how the changes effect the behavior and appearance of your windows and the entire work area. Don't worry too much. The worst that can happen is that you will need to reinstall. However, if you keep backups of all the files that you modify, you shouldn't need to worry about needing to reinstall.

Next: Building an Internet Server


Copyright 1996-1998 by James Mohr. All rights reserved. Used by permission of the author.

Be sure to visit Jim's great Linux Tutorial web site at https://www.linux-tutorial.info/