The Joy of X

An overview of the X Window System

Another great release from Werner 'Dirk Gently' Zsolt.

http://www.fok.hu/~dirk


Preface

The X Window System (X) has, over the last few years, become increasingly important, and it is now accepted as the windowing system for workstations, minicomputers, mainframes and supercomputers. It has become the standard means of providing graphical facilities on these classes of computers, and is even available on PCs, running instead of, or in conjunction with, Microsoft Windows. And just as Microsoft Windows has revolutionized the PC, X is doing the same for its users, for two reasons. First and most visibly, X allows standard graphical user interfaces to be provided on all the computers used by an organization, no matter which underlying hardware or operating system is used. Second, X allows applications running on one computer to be used by people working on other eomputers elsewhere on the network; the applications are `network transparent', and all applications can be made available to all the users, independent of what type of computing platform they have. This is true Open Systems in action - it gives users and system managers the freedom to chouse the best software and the best hardware for their needs, with the confidence that it will integrate simply and reliably into their overall computing environment.

X began in 1984 at the Massachusetts Institute of Technology (MIT) as a joint project between the Lahoratory for Computer Science and Project Athena, with much of the early work sponsored by DEC and IBM. By 1986 X was becoming significant in commercial computing; and the system as we know it, X Version 11 (X11), was released in 1987. Since then X has been considerably enhanced, largely under the management of the MIT X Consortium, which defines the standards for the system and has ensured that current X 11 implementations remain compatible with earlier releases.

About This Book

A lot of information about X is available, but much of it is unpublished or difficult to find. We wanted to pull together material from different sources, and provide a book which gives a complete view of the system so that you can understand the important features and issues, and see how the various aspects of the system fit into the overall picture. We hope this book will aet as a springboard, and give you what you need to develop your particular interest in X, whether as programmer, user or system manager. ‚Our aim was to write a small book about X, to make it more accessible, and to counter the view that some X books are sold by weight rather than the volume! As a result, we have sometimes had to omit some low-level detail, in the interest of making the book more readable. Even so, where it is essential for an understanding of the system, we include some fairly complex material.

Who Should Read This Book

You don't need any special knowledge to read this book - it is suitable for anyone who is interested in X and has some experience of computers. You will find the book particularly useful if:

  • You have heard about X and want to find out more about it - for instance, what is special about it, and how it compares with other window systems.
  • You are a system manager, and need to understand the architectune of X and the techniques and tools you will need to use when you are running an X system.
  • You are an IT director or manager, deciding whether your organization should `go the X route'; and you need to know what the implications of such a strategy are, and what developments are likely in the future.
  • You are confused by the `GUI' wars between OPEN LOOK and Motif, and want to see what these things really are, and the issues involved in choosing between them.
  • Your are involved in technical support, and need a good understanding of how X works, and what your customers are likely to be doing with X and why.
  • You are a programmer, and want to get an overview of the system before exploring X programming in depth.
  • Your are involved in sales or marketing, and need to understand how X can help your customers, where it can be applied, and how some implementations have competitive advantages over others.

    Structure of the Book, and How to Use It

    The book is divided into three Parts:

    1. X in a Nutshell. This is a quick `management overview' of the system, its architecture, and how using it can benefit your organization.
    2. How X Works, in Detail, and How the User Sees It explains the operation of the system, and describes the X server, client application programs and how they are built, `look and feel' issues, toolkits and window managers. ‚There may be more detail here than you need; if so, just dip into the sections you need once you have read Part 1.
    3. Using the System, System Administration, Performance, and Programming covers what you need to start using an X system, how it is administered, managed and customized, what the performance considerations are, and how you write X programs. (For more details about hands-on use of the system, see the companion volume, The X Window System: A User s Guide, Addison-Wesley 1991, ISBN 0-201-51341-2.)

    The book consists of `Modules', each of which consists of two pages. The lefthand page of the two starts with a summary of what the module is about, followed by the main text of the module. The right-hand page usually contains diagrams, tables or screen-shots. To make it easier for you to skip straight to the sections that interest you, we have tried as far as possible to make each module a unit in itself. Because of this, there is some duplication in plaees, though you will often find that different perspectives are offered in different sections. For example, in Chapter 3 we describe how the server uses fonts to draw text, whereas in Chapter 11 we cover fonts from the system management point of view. Some modules are marked

    (If technical details aren't so relevant to you, you can skip over this module.)

    You can bypass these on your first reading of the book, or skip them completely if you are not partieularly interested in complex technical issues.

    Software Used

    The book deals with the standard MIT software (which is broadly representative of many vendors' offerings) and other widely available eommercial software such as OPEN LOOK (we used Sun's OpenWindows, Version 2) and Motif (we used Version 1.1). We also used the Motif version of the FrameMaker document preparation system, and the Motif version of IST's XDesigner user-interface management system. In some sections we have described software which is not yet widely used, but which illustrates some particular point, or which is an indication of what may be become commonly available in the future.

    We prepared and wrote the book on a Sun SPARCstation running SunOS 4.1.2, and the standard MIT Release 5 of X Version 11. The text was edited with GNU emacs from the Free Software Foundation, and typeset with LaTeX using style-files prepared by Paul Davis at the University of Washington. The index was processed using the LaTeX Makeindex system, and the screen-shots were processed with the pbmplus Extended Portable Bitmap Toolkit. We used make and imake for configuration management and SCCS for source-code control of the text.

    Acknowledgements

    Many people have been very helpful. Paul Davis kindly spent much of his spare time developing the LaTeX style-files required for the book's special format, and also helped with some LaTeX problems. Steve Jamieson of NCD supplied information about server configuration files. Tony Moms of AWM Computer Consultants, and the White Company, Cambridge, provided facilities for scanning images. From the European X User Group, Bob McGonigle and Peter Whitehead helped with the printing of early drafts, and Bevis King and John Harvey provided much useful documentation. Selwyn Castleden of TOP-LOG and Frame Technology very generously helped with the production of illustrations. The (anonymous) reviewers of early drafts of the manuscript made many helpful and constructive suggestions about content and presentation. We are also grateful to Sun Technology magazine, for permission to include the illustration in Module 7.1.

    Others have been just as helpful, although more indirectly. First we must include all those people on the xpert mailing-list who reply to queries for clarification and assistance, and the authors of the X software itself, such as David Rosenthal of Sun who published the `Hello, World' programs, included in Chapter 5, as one of the first tutorials on X. Then there are the authors of articles and books which over the years have given much background information and offered different perspectives on aspects of X, and the many people I have had discussions with, and whose tutorial sessions I attended. In particular I recall Jim Gettys' ideas on customization, Doug Young's approach to constructing X applications, and Lany Maki's characterization of benchmarks.

    Finally, I owe a great debt to Oliver Jones for his wonderfully generous encouragement and help when I thought this book would never be finished. This constructive and cooperative atmosphere is what makes working in the field of computer software so satisfying and rewarding, and indeed contributes to the joy of X.


    Contents

    Preface

    PART 1 X in a Nutshell


    1 A Brief Overview of the X System

    2 The Benefits X Gives You


  • 2.1 X gives you all the usual benefits of a window system.
  • 2.2 X integrates applications on different hardware and operating systems
  • 2.3 Benefits of a standard GUI throughout your organization.
  • 2.4 X allows distributed computing, or centralized, or both
  • 2.5 X fundamentally changes software and hardware decisions
  • 2.6 The financial benefits of using X
  • 2.7 How X can help different categories of people

    PART 2 How X Works, in Detail, and How the User Sees It




    3 The Server - the Display Control Software

    4 Communication between the Server and Clients

    5 Clients - the Application Programs

    6 'Look and Feel' Part 1- Toolkits for Application Programs
  • 6.1 `Look and feel' means how the user sees the system
  • 6.2 X allows many different look and feels
  • 6.3 Motif and OPEN LOOK - the standard look and feels
  • 6.4 How look and feel is implemented: toolkits

    7 The Standard X Toolkit - Intrinsics and Widgets

  • 8 'Look and Feel' Part 2 - Window Managers
    9 Using Many Applications Together - 'Inter-Client Communications'

    PART 3 - Using the System, System Administration, Performance, and Programming




    10 Using the X System
    11 System Administration

  • 11.1 Starting up the system
  • 11.2 Customizing server settings
  • 11.3 Administering fonts
  • 11.4 Security
  • 11.5 A summary of X system administration

  • 12 Customizing Applications


  • 13 Performance Factors

  • 14 Writing X Programs
  • 15 Epilogue
  • Index


    Part 1-

    X in a Nutshell

  • This first Part of the book gives you an overview of what the X Window System is, and how it works. This is deliberately not very detailed; it is only an introduction to get you started and to give you a feel for where you are going. There are pointers to other modules of the book where the various features are covered in more detail, so if you are really interested in some topic, you can go straight to it. However it is probably best to skim through at least Chapter 1 to begin with, before exploring further.

    This Part also contains a full description of the benefits X can give you, explaining how the system's technical features can help you solve real-life problems for your organization or in your particular job.

    When you have finished Part 1, if you are interested in the practical points of how you get to use X, you can jump straight to Part 3 (Using the System), but if you want to explore the deeper concepts of X and want to understand more of its internal operations, just continue on to Part 2 (How X Works, in Detail).


    Chapter 1-

    A Brief Overview of the X System

    Introduction

    This chapter gives you a very brief oulline of what X is, its component parts, and what is special about it. We have included in this chapter just enough information for you to understand the benetits X can give you (which we cover in the next chapter) and to give you a framework of understanding for you to build on, when we look at the system's operation in detail in Part 2 of the book.

    1.1 X is a client/server window system

    X lets you run many simultaneous applications on your display, each with one or more windows of its own. The display is controlled by software called the X `server'. Applications cannot interact with the display directly. Instead they send requests across a communications channel to the server to perform actions for them - they are X `clients'.

    Like other window systems, X lets you have many applications displaying on your screen simultaneously. Each application has iL, own window, and all the windows can be active simultaneously: you can be typing in one window while another application is outputting to a different window. That is how X is similar to other systems; now let's see where it differs from them.

    The X system consists of three main parts:

    1. The server - the software that controls the user's display, including the screen, keyboard and mouse.
    2. The clients - the application programs, which are completely separate from the server.
    3. A communications link, which connects the clients and the server. This link can take many forms, as we see below.

    The separation of client from server is fundamental in X, and it is what gives X most of its unique benefits.

    The server controls the display

    As shown in Figure A, the server controls the display hardware. It, or the underlying operating system, contains device drivers for the keyboard, mouse, and screen; the server contains the only hardware dependencies in the system. The server accepts requests which are sent across the communications link from client (application) programs to create windows on the screen, to change the size or location of windows, and to draw text or graphics in these windows. It also sends events back to clients, telling them about input from the keyboard or mouse, or indicating that certain changes in the status of windows have happened.

    A server can handle multiple simultaneous connections from clients, that is, you can have several applications each with its own window on the screen, all active at once. The terms display and server are often used interchangeably. (You can also think of the server as a seat, to use a common workstation term.)

    The client is the application program

    The client program contains the code to perform the function the user requires - send electronic mail, handle the payroll, maintain a database or whatever - as well as the code needed to support X and to provide a graphical user interface. Figure B compares the X server/client operation with the more familiar file-server/diskless client case, and you can see why the X terminology is correct. (It's confusing only because in so many other cases the `server' is the remote component; if you think about what is happening and what each element of the system is doing, the terminology becomes clear).

    A client can work with any display, as long as there is a suitable communications link between them. You don't have to recompile or relink the client when you want to use it with a new display, so clients you write now will work with the next generation of servers produced in the future. For example, new super-fast servers may be developed to take advantage of advances in semiconductor technology and networking.

    A client can connect to multiple displays, for example a teacher can run a single application which displays to servers on each of her students' desks.

    Figure A. The server controls the display and is separate from the clients.

    Figure B. Analogy of file server anc1 X server.

    1.1.1 X can work locally or across a network

    The client and server are completely separated and only require a communications link between them to function. This link can be a local area or wide area network, so applications can execute on one machine but display to another somewhere else on the network.

    As shown in Figure A, the communications link is the third major component of the system. (The first two components are the server and the client.) All communication between client and server goes across this link, and the only requirement for the system to work correctly is that this link exists. It follows that it doesn't much matter what type of link it is.

    There are two main situations of interest:

    1. Client and server are executing on the same CPU. (A typical example of this is where a workstation is being used to run X.) Here the communications link can be any available form of inter-process communication; for example, shared memory, streams, named pipes, UNIX sockets, etc. (Figure B).
    2. Client and server are on different CPUs. Here the link is across a network (Figure C). X can run over almost any type of network - it is network independent. On the physical level, Ethernet, token ring, X.25 and serial lines have been used. At the protocol level, X can run over TCP/IP, DECnet and OSI (see Module 4.4 for details).

      The two machines don't have to have the same architecture (same CPU type) or operating system, because the requests and events that are transmitted between server and client are device independent. They are expressed in terms of high-level `objects' rather than as device-dependent commands or sets of pixels to be drawn. (For example, a line is specified by its start and end points, and its width.)

    So, you can run your application on the same machine as your server (which you are sitting at), or you can run the application somewhere else on your network. In other words, you can run the client locally or remotely. This is true of any X application, and this feature of X is called network transparency - that is, the program can work across a network, and it sees no difference. When you use the application on your display you have the illusion that it is running on your machine - the network is transparent to the user as well as to the system (Figure D). Note that the program isn't just outputting to the screen on your display: it is taking its input from your keyboard and mouse, so you can detect no difference whatever in its operation.

    Later on we'll see how useful this can be, particularly where an application must run on a particular machine, but it isn't feasible to give everyone a machine of this type. For example, large company-wide database systems require big computers with a lot of disk storage and a lot of CPU power. By using X, all users can execute the database application on the large machine, but interact with it and display the output on their own workstations on their desks (Figure E).

    Figure A. The communications link is the third component of the system

    Figure B. Client and server executing on the same machine

    Figure C. Client and server executing on different machines.

    Figure D. Remote execution is transparent to the user.

    Figure E. Remote execution lets users share a special machine.

    1.2 The user interface is not built into the base X system

    Scrollbars, menus, push-buttons and all the other elements of the graphical user interface of an X application are part of that application and not of the server. Because these components are not in the server, X's whole user interface is alterable, so X can support many different interfaces.

    Unlike almost every other window system, X does not provide a standard user interface. The user interface components that we take for granted in most systems - the scrollbars, pull-down and pop-up menus, buttons, etc. - are not provided by the base X system at all. In other words, they are not part of the server; therefore they must be provided by the client. X and other window systems are compared schematically in Figures A and B.

    This design may seem strange, but it was a deliberate decision made by the X developers. Their aim was to produce a system that would be as widely useful as possible without restricting how people would use it: they wanted X to provide `mechanism, not policy'. So, they provided everything needed to build whatever style of user interface anybody wanted, but they left it to others to use these tools to design and build the actual interfaces. There were many reasons for this feature of X:

  • The user interface is what people use to interact with the computer. To design it correctly you have to study the people as well as the computer. The X developers modestly realized that good user interface design is the job of psychologists and human factors specialists, not of computer scientists.
  • When X began, user interface technology hadn't matured enough. There was no interface that was obviously the best. (And many people say there still isn't.)
  • User interfaces ane an emotional and controversial area. If X had chosen one particular interface, many companies and people who favoured other styles would have refused to suppon and use X. So it was `politically' expedient not to define a standard.
  • Interface design is a major area for research and development. By not defining a standard interface, X can be used for exploring new interfaces and styles of interaction.
  • One of the design principles for X was that anything that didn't absolutely have to be in the server was left to the clients. Omitting the user interface details from the server made it smaller, simpler and more robust, as well as making it easier to change or fix the user interface code during development. (It also reduced the time needed to develop the server!)

    In the next three modules we see how a standard interfaee can be made available across all machines and operating systems, and how the interface is actually provided.

    Figure A. The user interface code is in the X client.

    Figure B. The user interface is an integral part of other window systems.

    1.2.1 Standard graphical user interfaces

    The user interface components - buttons, scrollbars, etc. - are programmed into the application. Originally each application programmer designed and coded their own user interface and the components in it. Then, subroutine libraries were developed to simplify writing the user interface part of programs. Finally, toolkits of standard, consistent, interface components were produced and widely distributed, and some have become de facto standards.

    In the early days of X, each programmer, or each group of programmers working on a project, developed their own user interfaces. They eaeh developed their own pushbuttons and scrollbars and wrote their own systems for handling menus. Apart from being time consuming, this meant that if you were using several X programs from different suppliers, each of them had its own style of interface, and they all worked differently.

    Initially the user interface part of each program was written using just the low-level features provided by the basic X system, in the Xlib library of standard X functions or subroutines. For example, if you wanted a menu, you had to create a window for the menu background, then windows for each menu pane, write code to display the appropriate text in the panes, and detect when the user clicked on a menu item, and process it. Thus the structure of an X program was as shown in Figure A.

    As the system matured, people developed toolkits - subroutine libraries or sets of predefined functions which the application programmer can use - to provide welldefined consistent interfaces. These subroutine libraries or toollcits are built into the application when it is compiled (Figure B). The toolkit lets the applications programmer build up the user interface of the program being written from ready-made modules. Many of the X toolkits are object-oriented, and the ready-made modules are user interface objects, which you can think of as building blocks. The applications programmer takes these prefabricated building blocks and assembles them into the structure she wants, giving a program with the standard look and feel of the toolkit used, without having to worry about the internals of each object.

    More recently, MIT itself and companies like AT&T, Digital, Hewlett-Packard, and Sun have developed toolkits, and considerable resources have been invested in marketing some of them. These interfaces have been very widely adopted, so that now they are de facto standards and and available across a wide range of platforms. Application programmers no longer have to worry about writing their own user interface systems. The style of the user interface is decided by the designer of the toolkit, and all interfaces built with the same toolkit will have the same graphical user interface (GUI) or look and feel: what the interface looks like (the `look') and how you operate it (the `feel') are similar in all applications.

    The dominant user interface look and feels are currently Motif and OPEN LOOK, which are illustrated in the next module. (There are lots of other look and feels too, but they haven't caught on.)

    Providing the same user interface on different platforms

    Making the same toolkit available on different machine types is easily done, by writing it in a portable and widely available language such as `C' (which is what X itself has been implemented in on most systems). Remember that the user interface has nothing to do with the server - it's all within the application. So, to port a toolkit to different machines you have to ensure that the toolkit running on, say, a VMS VAX sends the same set of requests to the server as the toolkit running on a Cray supercomputer, for example, or a Hewlett-Packard mini. A request is just a group of bytes ordered in the specific format required by X so, at a practical level, all that an implementation of the toollcit has to do is package the request appropriately and pass it to the particular network software underlying X on that machine. After that, the toolkit can forget about it, because the lower layers of the system software look after transporting the request to the server. (For more detail see Chapter 6, especially Module 6.4.)

    Figure A and B. Structure of early X programs; Application programs have user interface subroutine libraries (toolkits) built-in.

    1.2.2 The Motif and OPEN LOOK graphical user interfaces

    Two commercial GUIs are predominant. These are Motif from the Open Software Foundation, and OPEN LOOK from UNIX System Laboratories. They both provide broadly similar facilities but differ in appearance and how they operate.

    The Motif GUI was developed by the Open Software Foundation (OSF) which is a nonprofit consortium of manufacturers including DEC, Hewlett-Packard, IBM, and others. The look and feel of Motif is similar to that of Presentation Manager and Microsoft Windows. An example Motif screen is shown in Figure A.

    The OPEN LOOK GUI was developed primarily by Sun Microsystems and AT&T, and is now owned by UNIX System Laboratories (USL). OPEN LOOK's look and feel is based on the pioneering user interface work carned out by Xerox in the early 1980s. A sample OPEN LOOK screen (using Sun's OpenWindows) is shown in Figure B.

    We cover these standard interfaces in depth in Module 6.3.

    Figure A. The Motif look and feel.

    Figure B. The OPEN LOOK look and feel.

    1.2.3 The user interface has two separate parts

    The overall interface presented to the user consists of the look and feel built into each application, plus the controls necessary to manage the application windows themselves - position them on the screen, resize them, and so on. This second aspect of the user interface is not built into the application or the server, but is provided by a separate client program called a `window manager'. There are two separate components of the overall system which control the user interface as seen by the user:
    1. The subroutine libraries or toolkit mentioned in the previous modules, which determine the interface within a particular program built with those libraries. In general this part of the interface cannot be altered without altering the source code of the program and recompiling; so effectively, when you buy software (without source code) from a vendor, its user interface is fixed.

      This part of the interface is called the application interface.

      Because the user interface is compiled into the particular program and doesn't affect any other applications, it follows that different applications can have different user interfaces even though they are running on the same display (that is, on the same server). In other words, each application can have its own distinct application interface.

    2. A separate client program called a window manager, which controls how you manage your screen desktop - how you move windows, make them bigger or smaller, stack them, get rid of them, etc. Because this is a separate program and not built into the server (Figure A), you can change it and therefore the user interface provided by it. In general, any window manager should work with any set of applications, so you can easily switch from one window manager to another without having to change any other part of your system. You don't need to recompile or alter your application programs; in fact, you cab even switch window managers in mid-session while other applications are still running.

      This part of the user interface is called the management interface.

      Because the window manager controls all the application windows on your display, the management interface for all applications is the same. You can use a different window manager and so get a different management interface ; therefore while you can ehoose your management interface, at any one time all the applieations on your display share that single management interface.

    This separation of the user interface into two parts, and the fact that none of the interface is built into the server, are major differences between X and other window systems. The management interface is probably the most visible aspect of any window system and the part most utilized by users. In fact, one of the main attractions of Motif is that its window manager interface is very like Presentation Manager and Microsoft Windows, so a Windows user can use a Motif system with little or no retraining. Figure B shows a screen containing only those elements that are provided by a Motif window manager, and from this you can see that many of a screen's recognizable features are due to the window manager. Thus, being able to change the management interface just by starting a diffenent window manager is a very important feature of X.

    We discuss all these interface issues in much greater detail in Chapter 6 (Look and Feel - Toolkits) and Chapter 8 (Look and Feel - Window Managers).

    Figure A. Window management is handled by a separate client program.

    Figure B. The elements of an application's window and the screen provided by a Motif window manager

    1.3 The unique features that make X so useful

    The combination of X's ability to work locally or across a network (`network transparency'), its device independence, and flexibility of user interface enable X to solve many problems in delivering computing into organizations, and have made X very popular. Widespread adoption of X has been easy because X was initially implemented with the emphasis on portability, and the source code is freely available.

    When the X developers at MIT began their work they defined a set of requirements for the system so it would meet the needs of its target users. Even at that time, MIT had a very mixed (`heterogeneous') computing environment, with many different types of machines from various manufacturers. The design goals of X, and the architecture that was produeed to meet them and the benefits that result, stem largely from the constraints such a heterogeneous environment imposed on the system. Some of the resulting features are:

    1. Network transparency. Applications running on one machine can use the display on another. In practice this allows you to use programs running on other machines, but have them display on your screen and take input from your keyboard and mouse just as though they were running on your machine (see Figure A). In turn this lets you distribute applications around your network, as we'll see in Module 2.2.1.

      You don't have to be a network expert to write an X application program: network transparency is easy to use - the system makes it available `for free '.

    2. X is network independent. It doesn't depend on features specific to one network protocol, so it can work over many different types of networks (see Module 4.4).
    3. Device independence of applications. You don't need to recompile or even relink your application for it to work with a new display, in the same way that if you buy a new serial-line character-based terminal you don't expect to have to change your application. For example, if you replace an existing Digital VT100 terminal with a VT220, your program should continue to run unaltered. For more detail, see Module 3.4.
    4. Minimal device dependence of server. The server was developed as portably as possible, so that X could be implemented on as wide a variety of hardware displays as possible. For example, X runs nn small PCs with limited memory, small workstations with simple frame-buffers, and highperformance workstations with complex graphics co-processors and lots of real and virtual memory. In addition, when it is run on workstations the X server is usually not embedded in the operating system, but is just another user-level program. This makes it easier to debug (if the server crashes, you don't have to wait for the whole machine to re-boot) and therefore to implement.
    5. Extensions to the system are possible. For any system to be useful for a long time, it must be able to develop organically. But this is dangerous if it is not controlled: non-standard features will creep in, and the goals of device independence and perhaps network transparency will be violated.

      At the outset, the X developers realized that new demands would be put on the system (for example, X handled only two-dimensional graphics, but it was obvious that 3-D graphics would soon be required). So, an extensions mechanism was built into X, to allow new functionality to be added cleanly, and without affecting the continued correct operation of existing systems (see Module 3.8).

    6. X is 'policy-free'. As we discussed in the previous modules, the user interface is not pre-defined, so the system can handle many different interfaces. This is especially useful if you want X to imitate (or emulate) the interface available on some other system.
    7. X is non-proprietary. Many vendors got involved early on. Sample implementations of server and applications have always been available from MIT, free, and with virtually no commercial restrictions on their re-use. This let hardware and software developers get started on X very quickly. X went through a major re-design around 1987: this process was largely public, so a huge number of people from many different organizations were able to, and did, participate. This resulted first of all in a good design, and second, in widespread acceptability of X.

    In the next chapter we see how these features of X result in real-life benefits, letting you build flexible and powerful networks of interoperating machines (both new and old) with the minimum of restrictions.

    Figure A. Local and remote applications look just the same to the user

    1.4 How X compares with other systems

    Other network systems, such as telnet, allow character-based applications to execute remotely over the network. Other window systems, such as the Macintosh, provide a GUI and multiple windows, but don't support remote execution over the network. As the user interface is an integral part of these systems it cannot be altered: only X can offer its unique combination of flexibility and function.

    Each one of the features that makes X so powerful is available on some other system, but individually they do not give the fiexibility needed to provide all the computing facilities an organization needs. It is the combination of the features that gives what is required. Let's look at some of the other systems available, and see how they compare with X.

    Summary

    This chapter has given you an overview of X and what is special about it. You've seen that the system consists of three main components:

    1. The server, controlling the display hardware
    2. The client, which is the application program
    3. The communications link or network they communicate over.

    This architecture lets you run an application locally (on the same machine as your server) or remotely (on some other machine). The user interface is not part of the server but consists of two parts:

    1. The application interface which is built into each application when it is compiled, usually by means of a toolkit. Different applications can have different application interfaces. The application interface can usually be altered only by changing the program source code to use a different toolkit and then recompiling it.
    2. The management interface which is provided by the window manager program, and which can be changed just by running a different window manager.

    Thus X can support different interfaces. Finally, we compared X with other systems, and looked at its unique features. In the next chapter we consider the benefits these features can give you.


    Chapter 2-

    The Benefits X Gives You

    Introduction

    This chapter looks at how X's unique features can help your organization. The freedom to run applications remotely or locally lets you integrate all your computing facilities into a consistent whole, enhanced by a uniform graphical user interface. The result is a greater choice of both user and system management applications, better facilities for your users, and financial benefits overall.

    2.1 X gives you all the usual benefits of a window system

    Like most window systems, X allows you to write programs that present information graphically and which you interact with by directly manipulating graphical controls instead of typing commands from a keyboard. This `graphical user interface' to applications helps make people more productive, by making systems easier to learn and to use.

    X is primarily a window system. And like other window systems, many of its benefits come from being able to display information graphically - in the form of graphs or pictures, perhaps with colour, and different fonts - and being able to interact with the information directly using a mouse. (By contrast, character-based (ASCII or EBCDIC) terminals are usually limited to single-font displays, and you can only interact with them using a keyboard.)

    Of course the three approaches can be combined. People often want to use the central facilities (such as the accounts system, or the company database) provided by the organization; they also need to use the special tools specific to their own department (such as a CAD system, or simulation package); and finally they have their own personal tools (for example, a name and address database, and their favourite, that is, nonstandard, text editor, spreadsheet, etc.) As we mentioned before, if the system has been carefully set up, the users need not know which applications are running where - they may not realize that applications are running over the network, or even that there is a network at all!

    Figure A. Centralized computing: X terminals and central hosts.

    Figure B. Departmental computing: hosts within workgroups

    Figure C. Distributed computing: local applications on workstations.

    2.5 X fundamentally changes software and hardware decisions

    Because you can deliver any application to your users, no matter what type of machine it's running on, your choice of hardware isn't so important any more. So now you decide `which application is the best for our users', then you buy it (as well as the machine it runs best on, if you don't have one already!).

    Computing is about helping people do theirjob better or more easily; it's about delivering applications to users. (In this context `users' means anyone who needs a computer for their work - senior managers, secretaries, network managers, graphic artists, applications programmers, data-entry clerks, etc.) The more freedom you have in selecting applications, the more likely you are to give your users what they want and need. The emphasis should be on the applieation, and how good and how useful it is.

    But because of technical limitations, until recently most organizations had to limit themselves to applications which ran on their `official' choice of computer. There were many `VMS shops' or `IBM companies' using only software written for DEC's VMS, or for IBM's MVS operating systems, for their large applications. For desktop applications, many organizations standardized on either the PC or the Macintosh, and bought only PC or Macintosh applications. People made these decisions because there was no general method of providing all the necessary applications to their users on different platforms. And these decisions were sensible: there were major technological barners to truly integrated multi-vendor networks. But there was a price: these organizations were locking themselves out of all the excellent software that was available for other systems, so their end-users were missing out on good tools which could have helped them.

    X changes all this. Because any X application can display to any X station (Xterminal, PC X server, or workstation) you gain three major benefits when building your organization's system:

    1. The choice of what hardware to put on the user's desktop is no longer critical. As long as it runs X, the user can access every application you provide. Your decision now reduces to questions that are relatively easily answered: about price and performance, whether the user needs colour, or a large screen, etc.

      Thus you might provide cheap monochrome PC X servers for data-entry clerks, and high-performance colour workstations for CAD designers. Both will be able to access your X-based electronic mail system, and both can use your X-based `desktop' facilities such as diary-manager, calculator, etc. (Of course, if you are also using non-X applications this reduces your choice. For example, if users need access to a DOS word processor, giving them a PC with an X server is the easiest solution.)

    2. When you are choosing X applications it doesn't really matter what hardware or operating system platform they run on; it's the quality of the application that's important - how much it will benefit your organization and your users.

      The factors influencing your decision about what hardware to use have changed completely. For example, even if you have only IBM mainframes currently, and Macintoshs on the users' desks, there is no technical reason why you shouldn't provide X-based DTP facilities running on central UNIX systems, and a new database on a VAX. Once you have found the application you want, you choose from the platforms that support it, considering factors such as hardware price and performance, software price, reputation of supplier, and whether you want to support extra operating systems with the extra training and maintenance costs that involves.

    3. When developing a new application, you only have to write it once using X, for the platform of your choice. Then it's immediately available to everyone in your organization, unlike the old days when you had to port it to each of your platforms, and had to maintain these different versions for the lifetime of the application.

      Thus, X is giving you true open systems.

      A pleasant side-effect may be that your software licence costs are low. With a network of workstations, you usually have to license a separate copy of the application for each workstation. With X, you may be able to license a single copy for one central machine, and have several users running it simultaneously on that machine but displaying to their own X stations; some X software is licensed on this basis now. If the software is particularly expensive, it's often cost-effective to buy a single large machine dedicated to running that application for all the users on the network: the savings in multiple licence fees often more than offset the extra hardware cost.

      However, increasingly, applications are being controlled with a floating licence; it doesn't matter which machine you actually execute the application on, but you are limited to a particular number of simultaneous users on the network. Floating licences remove this pleasant side-effect.

      2.6 The financial benefits of using X

      X preserves your investment in hardware, by letting you continue to use old hardware while still allowing you to migrate to new, X-based, applications. Your increased freedom of choice lets you benefit from the better price/performance ratios of hardware. You also gain from increased user productivity due to better interfaces.

      Preserve investment

      X can help you preserve your investment in existing hardware and software. You can continue to use your existing software, for both character-based terminals and other window systems, using the methods described in Modules 2.2.3 and 2.2.4 (and in more detail in Modules 10.3 and I0.4).

      Elderly workstations, which may not have the power to run today's resourceintensive applications, can be used predominantly as X-terminals, but with some small applications running locally to minimise the load on central machines.

      Old PCs, which again don't have the power required for even the new DOS applications, can also be used as X-terminals for non-intensive applications by means of PC X servers. More powerful PCs can be converted to use X as well as other PC applications. For many organizations this is particularly important, as they have hundreds or even thousands of PCs. Converting them to X is a cheap way of extending their useful life: the incremental cost is small, and you still have them available to run their own DOS applications when necessary. For the support staff this route provides easy and cheap migration; you are not removing anything - just adding to what is already there. (For system managers this can be a very attractive route, because it's often politically expedient not to throw out equipment recommended in the past, even if it is obsolete now.)

      Take advantage of better price/performance

      CPU power is becoming very cheap (if you buy the right CPUs!). For example, RISC workstations and workgroup computers, and 386- and 486-based PCs are very costeffective ways of providing raw power. The challenge is to be able to make effective use of this cheap resource. X helps you do this, by letting you distribute your applications over the network on whatever CPUs you provide. You can choose between a huge central timesharing machine connected to X terminals, or have several central large RISC machines running different applications again connected to X-terminals, or cheap PCs as multitasking workstations on every desk running most of the individual user's computing load. With X you can take advantage of `cheap MIPS' anywhere you decide to plug them into your network.

      User productivity

      The uniform user interface that X lets you provide across your whole computing environment also brings financial advantages. Your users learn new applications more quickly, which saves in time and training costs. They are likely to be happier with applications, and therefore to use them better. In particular, non computer-specialists will be much more comfortable using your organization's systems, so that introducing new applications, new procedures and tools across your organization may be feasible in a way that wasn't possible before.

      At a high level in your organization, senior management may now be able to use the MIS systems directly rather than via an intermediary or by reading printed reports. This means that the senior people's expertise and knowledge can be applied more effectively to your organization's work. For example, if a manager uses printouts of a spreadsheet produced by someone else, the spreadsheet is only a static report, whereas if the manager uses the spreadsheet directly there is a two-way information flow. The spreadsheet becomes an interactive tool for examining the organization's business and dynamically exploring the information available, and the manager's knowledge and expertise is likely to be incorporated into the spreadsheet model where other people can make use of it too.

      Other benefits - scalability and licensing

      Because any X application running on a host computer can work with any X display, you take separate decisions about what hardware to run the applications on, and what to put on people's desktops. This lets you spend your hardware budget more effectively, because different users have different requirements in terms of performance and facilities, and you only buy what you really need to. We'll look at this in depth in the next module.

      In the previous module we saw also that X can save you money on licence costs in some situations, by reducing the number of separate machines running the licensed application.

      In the next module we look at how you benefit financially from being able to choose which hardware and software to provide in the various areas of your organization, and how X system upgrades can be very cost-efficient.

      2.6.1 Savings from freedom of choice

      The freedom of choice X gives you in buying applications and hardware can save you money by letting you apply funds where they are most needed. X gives more flexibility in upgrading your systems, too.

      Users. Different users have different requirements in terms of performance and facilities. For example, in a very large organization a cross-section of needs might include:

      • Data entry clerks: simple low pertormance monochrome screens.
      • Secretaries: medium resolution screen for word processing, higher resolution and perhaps colour for DTP work and presentation graphics.
      • Engineers: high-performance, high-resolution workstations for three-dimensional image processing and CAE or CAD design work.
      Applications. Different types of applications also have a wide range of resource requirements :
      • Large databases and other I/O bound applications: these need to run on central machines with large disks and fast I/O subsystems.
      • Compute- and memory-intensive applications: these need large, fast machines or supercomputers
      • Real-time systems: for example, process control, network management, real-time financial displays. These often need specialpurpose hardware, although their CPU-power requirements may not be great.
      • Accounts systems: these need a balance of I/O and CPU power, typically provided on a mid-range machine.
      • Office automation, electronic mail, and DTP: these often run on one or more small machines, serving specific groups of users.

      From this you can see that the requirements for the desktop and the computer room are unrelated: Figure A shows a scenario with all permutations of machine performance requirements. What this means to you is that you buy only the hardware you really need, and you spend your money where it gives you the best value. Money you save on desktop units can be applied to buying large workhorse CPUs for your critical applications.

      Improved upgradability

      With X you get flexibility in the upgradability of your system. If an application is used by only a few people, run it on a small machine; if its use spreads later, you can upgrade that machine, and only that one, leaving everything else unchanged. (Apart from cost, this also minimizes the disruption to users, and the load on your support staff.) When you need more CPU power on your network, you can add it in arbitrary-sized pieces, by plugging in new central machines as needed. Contrast this with upgrading a network of distributed workstations: to give more power to everybody you have to upgrade each workstation, and often this will mean a complete replacement, swapping a perfectly good monitor and keyboard as well as the processing unit of the workstation. With X you will more often `augment' rather than `upgrade', as hardware manufacturers of small to medium machines rarely offer good value for true upgrades.

      On the desktop too, you can upgrade incrementally. If one user's requirements grow, and they need faster graphics, etc., you need only upgrade that one machine, perhaps from a PC-based system to a workstation with special-purpose graphics hardware to provide the performance improvement needed.

      Figure A. Different performance requirements for desktop and central computers

      2.7 How X can help different categories of people

      X has been widely adopted because it solves real problems encountered every day in providing computer services. Almost everybody in your organization can benefit from it, from programmer to your director of IT.

      In this module we pull together all the advantages of X that we have mentioned earlier, and see how they apply to different people within your organization, and in other parts of the computer industry.

      • The system manager has increased flexibility in buying software and hardware. Software can now be chosen on the basis of the benefit to the user without worrying too much about the difficulty of integration into the overall system. Hardware from different vendors, and even non-standard machine architectures (for example, special-purpose database engines or file servers) can be introduced relatively easily as long as they have an X interface.
      • Support staff have a smaller training and user-error correction load, as the applications have a consistent interface and are easier to use. Support of remote sites - your own or your customers' - is easier. If there is a suitable network connection you don't have to visit the site: instead, execute the application causing the problem remotely on the distant machine, displaying back to your own X station in your own office, so you can actually see what the problems are rather than having to debug verbally over the phone. This does not pose great security problems for most customers, because they are giving you neither the application nor the data it is using; they remain securely on the customer's premises.

        (But we should also add that moving to highly distributed computing based on a network of X machines requires its own discipline, and will impose some extra load on technical support staff and the system manager, especially during the initial phases.)

      • Users have better-designed and easier-to-use interfaces, making their jobs less frustrating, and improving their productivity. Multiple applications on screen make many tasks possible now that were previously tedious or impossible.
      • Professional and management users can make more effective use of computers. Good applications are now more accessible, so instead of delegating tasks involving software tools to specialists, managers can do the work themselves, and they can interact with the systems and explore the information, which wasn't possible before.
      • IT director/CIO have the assurance that they have minimized their dependence on any one vendor, because of the freedom of choice for both central and desktop machines. The uniform user interface available across different vendors, and easier-to-use applications, make it possible to introduce new corporate systems and tools more quickly, more cheaply, and with less disruption of the staff.
      • Software developers, in-house and third-party, have a wider potential customer base. Commercial developers can now address much larger markets, instead of limiting themselves to sites that had standardized on their particular choice of platform. (For example, if your VAX VMS-based network management system is good enough, people in a traditionally HewlettPackard UNIX-based site can buy and use it if it is X-based). For small specialist developers, this larger market makes some projects economic which previously were not feasible.

        Internal developers need to write an application only once for it to be available to everyone in your organization. In the old days, you had to provide a separate version for each machine-type you had - for instance, one for PCs, another for Macintoshes, yet others for VMS, UNIX, etc.

        All developers benefit from lower development cost and time, as a lot of the programming and design work - for the GUI - has already been done. They can concentrate on the functionality of the system, rather than worrying about internal user interface details (in other words, what's inside the toolkit), and produce better applications.

        With the emerging dominance of X, developers of large packages (for statistics, data analysis, graphics, and so on) can reasonably restrict their device support, making X their only standard for screen-based input and output. By having only one output format (instead of dozens - for DEC terminals, Tektronix terminals, etc.) they reduce their development load. They can also optimize the X implementation since they no longer need generalized code to handle all possible different output devices.

      • Hardware developers see increased demands for large-CPU machines to run the X applications. We have already mentioned that it is now good economics to use a lot of CPU power to make applications easier for the user, and the extra work involved in providing a GUI like X does use more resources.

        Developers of new X-terminals and workstations supporting X have a large target market immediately. Before, they would have had to spend a lot of time and money developing a window system of their own design, and even more effort marketing it.

      • Sales and marketing have an attractive and powerful technology to sell, offering real benefits to the purchasers as well as the end users of the systems. Software and hardware products can be sold outside their traditional vendor-speeific markets, because they are now so easily integrated. And finally, beeause the new X applications are much easier to use than their predecessors, a user-led demand is being created for the products - people are asking to buy!


      Summary

      This chapter has described the benefits you can get from X. It lets you integrate your applications on all your different platforms into a single cohesive computing environment for your users. This close integration is possible because X can provide the same user interface on any platform. You can manage programs and data centrally, or distribute them amongst the functional units of your organization. All this flexibility and freedom of choice can give you considerable financial benefits. Finally, we summarized the advantages people in different positions in an organization can derive from X.

      This concludes the first Part of the book, `X in a Nutshell'. In the next Part we go back and look much more closely at how X works, examining each of its components in detail, and seeing how they interact with one another.