# 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

  - 1.1 X is a client/server window system
  - 1.2 The user interface is not built into the base X system
  - 1.3 The unique features that make X so useful
  - 1.4 How X compares with other systems

  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
- 3.1 The role of the server
- 3.2 Implementations of the X server
- 3.3 How the server handles output to the screen
- 3.4 The server contains the only display hardware dependence in the system
- 3.5 Handling text and fonts.
- 3.6 Handling colour.
- 3.7 Pictures and images - bitmaps,cursors and pixmaps.
- 3.9 Extras you may want or need: server extensions
  4 Communication between the Server and Clients
- 4.1 Clients send high-level `requests' to the server
- 4.2 The server uses `events' to communicate input and status changes to the client.
- 4.3 Intercepting input and requests for special handling
- 4.4 X can work over many different network types,as well as locally
- 4.5 What load does X impose on the network?
- 4.6 X Version and Release numbers, and compatibility issues
  5 Clients - the Application Programs
- 5.1 An overview of the client and its role
- 5.2 What X clients consist of, and how they are built
- 5.3 Internationalizing and localizing applications - Xil8n
- 5.4 Examples of X 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
- 7.1 The standard X Toolkit, `Xt'
- 7.2 Widgets and widget sets are building blocks
- 7.3 The `Intrinsics' lets you manipulate widgets
- 7.4 Event handling and `callbacks'
- 7.5 Some implementations of Motif and OPEN LOOK use Xt
- 7.6 Other X toolkits.
- 8 'Look and Feel' Part 2 - Window Managers
- 8.1 What you need a `window manager' for
- 8.2 Using the window manager.
- 8.3 The window manager's look and feel
- 8.4 How a window manager works.
  9 Using Many Applications Together - 'Inter-Client Communications'
- 9.1 Why applications need to communicate with each other
- 9.2 `Properties' - the basic mechanism for inter-client communications
- 9.3 Advanced communications mechanisms
- 9.4 The Selections Service - a high-level communications mechanism
- 9.5 ICCCM - the rulebook for inter-client communications
- 9.6 Desktop managers

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

  10 Using the X System
- 10.1 What you need to get started.
- 10.2 How you use the network facilities
- 10.3 Using character-based applications - terminal emulators
- 10.4 Integrating X with other systems.
- 10.5 Where to get the software.
  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
- 12.1 Customizing applications.
- 12.2 The Resources mechanism for customizing applications
- 12.3 How the Toolkit uses resources
- 12.4 Translation tables resources and keyboard mapping.
- 12.5 Tools for customizing resources
- 13 Performance Factors
- 13.1 Server performance
- 13.2 Network performance
- 13.3 Client performance
- 13.4 Benchmarks and tests
- 14 Writing X Programs
- 14.1 Programming the system, and development tools
- 14.2 User interface management systems and other development tools
- 14.3 Migrating old applications to X - enhanced terminal emulators
- 14.4 Porting from other window systems, and multiple-platform applications
- 14.5 User interface design, and programming
- 15 Epilogue
- 15.1 The MIT X Consortium
- 15.2 The X standards
- 15.3 Sources of further information and assistance
- 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.

  - telnet is part of the TCP/IP networking system, and is designed for characterbased terminals. It lets you log-in from your own machine on to another

    machine somewhere else on your network, and then run programs on that remote machine just as though your terminal were connected to that machine. (Similar facilities are the rlogin remote login program, and the VMS

    SET HOST command.)

    So, telnet does offer remote execution, but only one session at a time (it doesn't give you multiple simultaneous applications unless you run several copies, in some type of windowing system, for example) and it is limited to character applications (you can't run a graphics program on the remote machine and have telnet display the full graphical user interface of that program on your terminal).

  - SQL database client systems, often run on PCs, let you interact with a large database system running elsewhere on your network. They usually provide a good graphical interface, and download some of the work of presenting the database information to your PC.

    Again, you are getting some remote execution facility - the database is running elsewhere - and an improved GUI. These systems are not general purpose, but are highly restrictive: they only handle interaction with a database, and if you want to run any other programs you need some other system.

  - Microsoft Windows for DOS gives you a true windowing system on a PC, with a consistent GUI, and multiple applications which can be more or less active simultaneously. Like X, it is not part of the operating system, but is a separate and optional piece of software which you run on top of the operating system.

    It differs from X in two important ways:

    1. The user interface is fixed and built into the system, so you cannot change it. For example, if you wanted to emulate the Macintosh interface you just can't do it with MS-Windows.
    2. You can only run local applications, which means that you can only use applications written for DOS PCs. You cannot compile a program for VAX VMS, say, with the Windows GUI built into it, and run it on the VAX displaying to your PC.

    The network usability of Windows can be improved by using it in conjunction with a good PC TCP/IP system which will let you run multiple telnet sessions within Windows, but you still don't get network-transparent graphics programs.

  - The Apple Macintosh, like Microsoft Windows, gives you a consistent GUI, and with the latest releases allows multiple applications to be active simultaneously. Again, the GUI is completely determined: if you don't like the Macintosh interface, don't use a Macintosh.

    It differs from Microsoft Windows in that it is built into the kernel or heart of the operating system - you can't run a Macintosh without its window system.

  - Sun Workstations have offered three different window systems:
    1. SunView was Sun's own native window system, and its characteristics are just like the Macintosh's - it is built into the operating system, it allows only local applications, and you can't change the interface.
    2. NeWS (Network extensible Window System) is a client/server system like X, offering the same advantages. It is based on Adobe's PostScript language (developed for powerful laser printers and typesetters) and so offers very good facilities for DTP and text handling.

       However, NeWS is proprietary to Sun, and is used by almost

       nobody else.

    3. OpenWindows is Sun's latest system, and is a mixture of NeWS and X. Any standard X program should work with OpenWindows, but the reverse is not true: many OpenWindows programs use the Sun-specific PostScript facilities and therefore won't work with standard X servers.
  - Other workstations. Hewlett-Packard's and Digital's systems now offer X as the standard window system (Digital's DECwindows is 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.)

  - Quantitative information displayed graphically is often much easier to understand than a large set ofnumbers (`a picture is worth a thousand words').
  - Other information is often much more quickly assimilated when shown as a picture rather than in words, and can be understood by people of different nationalities without having to be translated.
  - The controls for the program can be shown explicitly, as visible `objects' such as scrollbars or push-buttons, whose function is obvious to the user. You interact with these controls by direct manipulation. You handle the data and invoke functions in the program by simulated physical actions (pressing knobs or buttons, or grabbing and moving sliders) rather than by abstract verbal reference (by typing in English words, or computer-language commands).

    In a well-designed application, these controls model real-world objects, so they provide an immediate hint about what function they perform, and each is suited to or specially designed for its particular task. Separate controls can be provided for each parameter or thing to be controlled, making it even easier to use the program. (Compare driving a car which has a separate cnntrol for each function, with figuring out how to adjust a digital watch which has only two buttons; the same two buttons have to be used to invoke all the different functions the watch provides.) Making a program easier to use makes it more popular with its users, so their productivity and job satisfaction are likely to be improved.

  - Programs that use such a Graphical User Interface (GUI) are usually easier to learn, because it is more obvious how to use them. Using the menus, scrollbars, and other components of a GUI reduc;es the amount of information you have to remember to be able to use the application - these components on the screen are visual reminders. But menus and dialogs (separate pop-up windows which let you enter all the information relating to a panicular aspect of the program, such as selecting and configuring the printer you want to use) also hide details while still making it obvious how to access them when necessary. Novices aren't confused, and the workspace isn't cluttered with unnecessary information. This principle of designing user interfaces is called progressive disclosure. (This is often applied in designing consumer equipment too; for example, the more complex controls on many televisions and video cassette recorders are often hidden behind an easily opened Hap which is clearly visible on the front of the appliance.)

    Using this approach can result in a program that you can use without any specific instruction, and which doesn't need a manual. The X clock (Figure A) needs nc instructions at all. A more complex example, a calculator program written for X, anc providing a GUI, is shown in Figure B. A child or a computer novice can use thi: program easily, because they can apply their knowledge of the real world to their task on the computer. By contrast, even experienced programmers have difficulty using the standard UNIX calculator dc (Figure C): it gives no clue about how to use it, it doesn' print a prompt, and worse, it uses `reverse Polish' arithmetic notation (so instead o typing `3 + 4 + 5 =' to add and print three numbers, you enter `3 4 5 + + p').

    ###### Figure A. The X clock is easy to use - its interface is natural.

    ###### Figure B. An X calculator with a GUI.

    ###### Figure C. The UNIX `desk calculator'

    ### 2.1.1 X allows multiple applications and overlapping windows

    X lets you run multiple applications simultaneously on the same screen, each with one or more windows of its own. Each application runs independently, but you can cut and paste information from one window to another.

    X lets you have multiple applications on your sereen, each with its own window or windows (Figure A). These windows can be arranged side by side, or overlapped and stacked, just like papers on your desk. You can group programs near each other on the screen to suit the task you are doing, move them around, and put them away when you don't need them. You are effectively simulating a physical desktop. In the early days, many people saw this as X's main benefit! [Footnote: To convince non-users, purehasing managers say, of how important this feature can be, suggest they try handling all their paperwork looking through a cut-out window in a pieee of cardboard, allowing a view of only 80 * 24 characters.]

    Your different applications can all be active simultaneously: you don't have to stop one to start another. [Footnote: We deliberately use the long-winded phrase,X allows multiple simultaneous active applications' instead of saying 'X is a multitasking environment'. Running the multiple tasks, locally or remotely, is not done by X - that is the job of the operating systems used, and it is the operating system that is multitasking or not. The X server is a single task which allows many windows to be active simultaneously, whether they belong to one application or to many. ] So, while you are watehing the output of some long task appear in one window, you can be editing a mail message in another window, and writing a report with a DTP system in a third. This alone greatly improves the productivity of the system. But being able to cut and paste information, that is, copy it from one window into another, makes multiple windows even more useful. For example, if you need information from your database for your report, you just go to another window, perform your database inquiry, and cut and paste the information back into your DTP window.

    In computer terms, window systems often use more resources (memory, CPU, disk space) than non-windowed systems. You are trading computer power against improving the effectiveness and productivity of the people using the computers. Computing costs are decreasing rapidly, and people costs are inereasing, so this trade-off is constantly becoming more economic.

    ###### Figure A. A sample X sereen with many applications.

    ### 2.2 X integrates applications on different hardware and operating systems

    X's network transparency lets users access applications running on different CPU types and different operating systems, just as though they were running on the user's own local machine. The user gets a rich and flexible environment, as all applications can be delivered to all users. This is the greatest single benefit of X.

    Most large or medium-sized computer installations, and even a lot of small ones, are heterogeneous - they include different types of hardware, and usually many different operating systems too. For example, engineering companies have UNIX workstations for CAD work, PCs and/or Macintoshes for office automation tasks such as wordprocessing and mail, VMS systems for the company-wide database, and perhaps an IBM mainframe for the financial systems. In an environment like this, if you have to provide a new application, how do you make it available to everyone who needs it? What hardware do you run it on? Or if, for example, a vendor develops a network management system that runs on one type of hardware but needs to be accessed from many other workstations, how can it best be delivered'?

    X gives you an easy solution. Once you have set up your network so that all your users can use X (that is, their workstation or PC runs an X server), then any X application on any machine on your network can be accessed by any user.

    As shown in Figure A, you are not restricted by the operating systems or type of machine the applications are running on, or the type of X server you have. Any application can be delivered to any user. (We'll deal with this in more detail in the next module.) Figure B lists some of the machines and operating systems for which X is available: you can see that the range is enormous, covering desktop PCs, through workstations, to supercomputers.

    Running applications over the network is helpful in real life because there are always some applications which are available only on particular platforms (such as large database systems or financial packages) and now you can share them across all your users. It is also feasible to make use of applications that employ specialist or very expensive architectures and share them among many users. For example, some applications have to execute on supercomputers, but you can interact with them from your X display.

    #### Integrating X with other widely used systems

    Most people can't move completely to X immediately, because they have a large investment in applications for other systems. They have to continue using existing programs, while using X for new applications, both those developed in-house as well as third-party ones.

    Special X servers are available for many machines (for example, DOS PCs with or without Microsoft Windows, Macintoshes, Sun and NeXT workstations) which let you use X in conjunction with the native window system (Module 2.2.4). Most X, systems also include a terminal emulator facility which lets you run ordinary characterbased applications in an X window just as though it were a normal character terminal. Coexisting with other systems is covered in Module 2.2.3, and in Chapter 10. We also look at special hardware for X in the form of X-terminals, and see what benefits they give, in Modules 2.2.5 and 3.2.1.

    In the next four modules we show how you can use X to integrate your organization's computing - at a single site, at multiple sites connected with a wide area networkand to merge in applications for X, for other window systems, and for character-based terminals.

    ###### Figure A. Sharing X applications on different hardware and operating systems.

    ###### Figure B. Partial list of platforms supporting X.

    ### 2.2.1 Integrating an organization's computing on a local network

    By using both local and remote applications on a LAN you can make applications available to all your users in a way that hides network details and simplifies the growth of your system.

    The key to integrating your applications is being able to run a program on a machine somewhere else on your network, but having it use the display you are sitting at, as shown in Figure A. (Module 10.2.1 describes the commands you use to do this, if you are interested.)

    You can have several remote applications connecting to your X display as shown in Figure B, and you can have both local and remote applications (Figure C.)

    The advantages of this are:

    - As a user you can access any of the X applications available on any of the machines on your network. For example, even if your X server is running on a DOS PC, you can run your database system on a VAX with the VMS operating system, and your accounts package on an IBM mainframe.
    - If the system is set up properly - so that applications can be started just by making a selection on a menu, say - then you need not be aware that the applications are running over the network, or that your machine is even connected to a network!

    X can completely hide the architecture of your network. When you have just started using a new application (an X spreadsheet, say), for reasons of licence costs you might make it available on only one machine on the network. Then, the command invoked by the menu item for the spreadsheet would be something like:

           on remote machine XYZ run SPREADSHEET, displaying to
           here

    Later on, when the spreadsheet gains acceptance in your organization and is heavily used, you might choose to make a copy available on every machine. Then, just by changing the command invoked by the menu to be:

           run SPREADSHEET here, also displaying to here

    users are switched to the new system. They see no difference - press the menu button, and up comes the spreadsheet - even though what's happening behind the scenes is very different.

    ###### Figure A. Application runs remotely but uses your display.

    ###### Figure B. Several remote applications using your display.

    ###### Figure C. Local and remote applications together.

    ### 2.2.2 Integrating head office, branches, and isolated sites

    With X, and by using different types of network for different tasks, it is now practicable for an organization to link all its branches together - even one- or two-person outstations - providing a consistent set of applications to all its users everywhere.

    Up to now our examples have all concerned local area networks (LANs) - those covering one building or a single site. But X can work over wide area networks (WANs) too, and this can be very useful for organizations with offices in several different locations.

    Figure A shows three branch offices connected to a head office. All applications for Branch A run on machines back at head office. Branch B also uses the head office applications remotely, but it has its own workgroup computers running applications specific to the branch. The advantages are:

    - Small branches (Branch A) need not have any technical staff to run their computers, since all the applications and all the data are back in head office (which presumably has DP and networking support staff). The only equipment in the branch is the machines running the stable and unchanging X servers, and the WAN communications link.
    - Larger branches (Branch B), where workgroup or departmental computers, applications and data can be adequately supported, have their own computing resources. They can still use head office resources too, but even when there are problems with the WAN link they can continue to work on their own, although perhaps at a degraded level.

    Branch C is a small, isolated site where just a single terminal is required. As with Branch A, the only computer needed is something to run the X server, plus a communications link to head office. This link can be provided over dial-up telephone lines or perhaps over ISDN if that is available, using SLIP (serial line Internet Protocol), or PPP (point-to-point protocol).

    In all these examples, suitably fast communications links are needed if performance is not to be a problem (see Modules 4.5 and 13.2).

    ###### Figure A. Remote branches using applications running at head office.

    ### 2.2.3 Using non-windowed applications with X

    You can run ordinary character-based applications in an X window using a special X client called a `terminal emulator'. Other special clients emulate popular nonwindowed systems, for example the IBM PC, so you can use their applications via your X system. Using these tools to run your old applications lets you migrate to X and to new applications with the minimum disruption to your organization.

    If you already have a large investment (of money, or training, or organizational procedures) in applications, it isn't sensible to abandon everything you've got and start from scratch again with X. You want to eontinue using your existing software, while using X for any new applications that you purchase or develop in-house - it is `your window onto the future'. We'll look at how you can use X in conjunction with applications for eharacter-based terminals in this module, and in the next module we see how you can use X with other window systems.

    ### Character-based applications

    Most programs for workstations, micros, and medium-to-large sized computers were not written for any window system; they just output and read characters to and from the terminal, typically as ASCII. For example, commands to list the contents of directories, to print files (Ipr on UNIX or PRINT on VMS), to compile programs (CC, f77, or FORTRAN), or edit text (vi, emacs, EDT, or TPU) all expect to be working with a character terminal such as a VT220, or a Wyse (or even a Teletype !).

    On their own these programs can't work with X displays: they don't know how to issue requests to the server to write text to the screen, or handle events to get input from the keyboard. To overcome this problem, most X implementations provide a terminal emulator. This is an X client program which `pretends' to the old application that it is a real terminal, but translates character output to X text-drawing requests, and translates X keyboard-input events into the equivalent input characters, as shown schematically in Figure A. The emulator doesn't have to run on the same computer as the `old' application - they can be connected via the network as shown in Figure B.

    We deal with terminal emulators (and software emulators for other systems) in more detail in Module 10.3. For now, it is enough to see that they let you use all your existing character-based applications without alteration on X systems, and you can run several simultaneously, each in its own X window.

    ### Emulators for IBM PCs

    There is a great deal of good software available for DOS PCs which people need to integrate with the rest of their organization's software environment. To avoid having a PC for some tasks and an X-based workstation for the rest, PC emulators have been developed which let you run a DOS application on your non-DOS, non-Intel platform, for example on your VAX or Sun workstation. The application uses your workstation's keyboard, and the PC `screen' is shown in an X window on your workstation display. These systems emulate the CPU and graphics controller of the PC and don't require any PC hardware at all.

    In the next module we look at systems that provide similar functionality but in a very different way - by running an X server within a DOS Windows environment on a hardware PC.

    ###### Figure A. Terminal emulator translates character I/O to X events/requests

    ###### Figure B. The terminal emulator program and the old application can run on separate computers

    ### 2.2.4 Using applications for other window systems with X

    You can use applications for other window systems by means of special-purpose X servers running on top of the other system. This lets you migrate gradually from the other window system to X, or to continue indefinitely using applications for both systems.

    If you are already running another window system, such as Microsoft Windows, Macintosh or SunView (or Atari or Amiga or NeXT), you can get special X servers that run on top of the original system, allowing you simultaneous access to both, as shown in Figure A. If you already have a (networked) PC, adding an X server to it can be a very cheap way to get X capability, especially if you need colour. (There are also PC X servers which run on native DOS and don't require Microsoft Windows, although for any of these systems your PC must of course have a network interface card and network software such as TCP/IP.)

    Typically these servers allow you to cut and paste graphics and text between the two window systems; this can provide an almost seamless environment where the user doesn't really know which application is X and which is using the other window system. Figure B shows a network with many different types of X servers, illustrating the possibilities.

    Very recently a different type of software has come on the market which allows you to run the other-window-system program on its native machine (for example, a Macintosh or a Microsoft Windows PC) but `hijack' its input and display functions, so that these are performed on a remote X station![Footnote: We use the term X station to mean any PC or workstation running an X server, or any special-purpose X display such as the X-terminals described in the next module.] Figure C shows schematically a Macintosh application being used from an X-terminal. Using such systems, all your users can access applications written for these systems via X, instead of each user having a PC or Macintosh of their own in addition to their normal display.

    Module 10.4 covers coexistence with applications from other systems in more detail.

    ###### Figure A. X server running `on top of' Microsoft windows

    ###### Figure B. Special X servers let you use X with many other window systems

    ###### Figure C. Macintosh application connected to your X display.

    ### 2.2.5 X-terminals: cheap substitutes for workstations?

    X-terminals consist of the display hardware, an X server, and networking hardware and software manufactured as an integral unit. They give the user an environment that is just like a workstation, often offering simplified system administration, and sometimes at a lower cost. However, they may not be ideal for all applications.

    Workstations are increasingly popular, for good reason: they give the user a better computing environment by allowing a windowed user interface and supporting multitasking - multiple simultaneous applications. But workstations have disadvantages. System administration is quite complex, as each workstation has its own configuration information and operating system that must be maintained. Workstations, especially when run diskless, can load the network heavily with both file traffic and program swapping or paging.

    X-terminals - special hardware built just to run X - are intended to overcome these disadvantages, while still giving the user most of the benefits of the workstation, and often at a lower cost. An X-terminal is based on a simple and fast computer with an X server built in. The hardware includes a mouse, keyboard, graphics screen, and network interface; usually the server is stored in read-only memory, so a disk isn't needed. Because the X server is so completely and so cleanly separated from the applieations, it is possible to isolate it in a package like this. Now all applications run remotely on other hosts, and what you've got is just a terminal! (But a terminal with a difference, because it runs X, and you can run lots of simultaneous applications from it.)

    The advantages are

    - X-terminals give you the same interface as a workstation: you have a full X system, so you can run the same applications as before, though remotely over the network.
    - System administration is simplified. X-terminals are very like ordinary terminals: they don't have any operating system to be maintained, so setting them up and moving them to another network is easy, and they are easier to restart after power failures as they don't have disks or filesystems to be recovered or rebuilt after failure.
    - The X-terminal's hardware and software is simpler - no other applications are running on it, there's no big operating system, no disks, etc. - so it should more reliable than complex workstations.
    - X-terminals can be cheaper than workstations, again because they are simpler and a lot of the complex hardware and software can be omitted. The entry price especially is lower, and is getting even less as X-terminals become commodities.
    - Upgrading your overall system to get more power is cheaper. Your display elements (X-terminals) aren't altered: you only have to upgrade the application-running CPUs. If your network consists entirely of workstations, upgrading to a bigger CPU on the desktops often involves changing the display and keyboard as well, involving you in needless expense.

    Performance of networks of X-terminals is satisfactory, and network loading isn't usually a problem (see Modules 4.5 and 13.2).

    But remember, X-terminals are only terminals, so you still need central computers for your applications to run on - we're almost back to time-sharing! The classical argument in favour of this is: instead of giving N users one unit of CPU power each in the form of a workstation, provide a single CPU centrally with N units of power. Most of the time the majority of users don' t use their full unit of power, so there is usually a lot of spare processing power available for anyone who has a transient requirement for more than a single unit. You can allocate CPU power in a precise way if you wish, by giving each workgroup its own host on which to run its applications.

    Of course, for people working on their own, it doesn't make sense to buy one CPU for applications plus a separate X-terminal: a workstation is obviously the simplest solution.

    For more about the implementation of X-terminals, see Module 3.2.1

    ### 2.3 Benefits of a standard GUI throughout your organization

    By using a consistent set of libraries (or `toolkit') you can construct or buy applications, for all your different computers, which provide the same graphical user interface. Previously each vendor's computer had its own interface which was inconsistent with the others, making life difficult for users. Motif and OPEN LOOK are examples of widely available standardized user interfaces.

    Before X was developed, one of the biggest problems for systems managers was getting computers from different manufacturers to interoperate with each other in a sensible, easy-to-use way. Initially there were networking problems; with the development of de facto practical standards like TCP/IP (and perhaps OSI in the future) these have been overcome.

    But there was still a problem for the users of window systems: each vendor had their own system with its own unique (and often proprietary) interface. You could not run, say, a VMS windowed application onto your Apollo workstation - and even if it were possible, using it would be difficult because its style of interface would be completely different to all the other applications you were using. For example, the Macintosh interface, Presentation Manager/Microsoft Windows, and Sun's SunView are all completely different and incompatible.

    X can now solve this problem by allowing the same interface to be provided on any and every X system.[Footnote: It's ironic that it is precisely because the X designers didn't provide a standard user interface that X is able to provide a universal user interface when desired!] (This is usually done by building a `user interface toolkit' (Module 1.2.1) for each system that applications are to be written for, providing the same style of user interface on each platform, although here we are not really concerned with how a particular interface is implemented.) What is important to the end-user is the program's look and feel: the visual appearance of the components in the interface and how you operate them. In fact the same look and feel can be provided in different ways in different programs, and this is often the case in practice. For example, there are many different toolkits, written in different languages and not based on the same code at all, which provide standard user interfaces (Figure A). In other words, the interface seen by the user, and the programming interface used by the application developer (the API or application programming interface) are distinct and should not be confused.

    ### Advantages of a single graphical user interface

    Making the user interfaces consistent in all the programs you use has many benefits:

    - New applications are easier to learn. Once you are familiar with a scrollbar in one program, you recognize it in all other programs as well, and can use it without further instruction (so your existing knowledge is leveraged).
    - Well-designed applications are easier tu use. Because menus, scrollbars, push-buttons, and so on, are always visible, instead of having to remember what actions or options the program provides, the user just has to look at the screen and see what the program is offering. (There is a similar contrast between adjusting the time on a mechanical alarm clock which has separate, obvious, and labelled controls for its various functions, and setting an electronic watch which provides many, many functions, all of which have to be invoked by pressing only two buttons in apparently magic sequences that give different effects depending on which `mode' the watch is in.) This greater ease of use is particularly noticeable with programs used only occasionally, in which you never really get a chanee to master all the commands and remember them fully.
    - Applications integrate seamlessly. You may have on your screen at one time a mix of applications running on different VAXes, IBMs, and UNIX machines throughout the network, but they are all consistent visually and in the way they are used. That is, the way you use the scrollbar in the IBM applications is exactly the same as in the Hewlett-Packard ones. This is why scenarios such as those outlined in Module 2.2.1 are possible.

    ###### Figure A. The same look and feel can be provided by many very different toolkits.

    ### 2.4 X allows distributed computing, or centralized, or both

    You can decide whether to make an application available for users to run locally on their own workstations, or to provide it only for remote running on machines that are administered centrally by the DP/IT department. Centralized applications can give more secure administration and better control of the organization's data.

    When running a network of distributed workstations you must ensure that data and applications on the workstations are backed up properly, and that applications and systems software are kept up-to-date and consistent across the whole network. By choosing the appropriate mixture of X-terminals (or PC X servers) connected to central hosts on the one hand, and workstations on the other, you can manage your software and data very precisely, giving them the appropriate level of control and security.

    You can consider three different levels of `ownership' for programs and data:

    1. Corporate. The information belongs to the whole organization, so it needs to be administered centrally.

       All applications and data should be kept on central machines (`in the computer room'), with X-terminals or PC-based servers on the users' desks for access to the applications (Figure A). In this way, proper data security can be maintained, and only approved applications can be run.

       As the figure illustrates, even the remote offices use only X-terminals. System administration is kept very simple: no data or applications are stored at the remote site, so no technical support or operations staff are needed at the branch. `Starting up' the system in the branch merely requires turning on the X-terminals.

    2. Departmental. The information is specific to a department or workgroup. Applications run on machines within the department, again with X-terminals or PC X servers on the users' desktops.

       The example in Figure B shows three workgroups. Two are in the organization's head office, and one in a remote branch office connected via a wide area link. Even if this link fails, the users in the branch can continue working, using their departmental applications on the computers within the branch.

    3. Personal. Individuals have their own programs and they look after t.heir own data, which are stored on their own machines.

       The best way to implement this is to provide each user with their own workstation (Figure C). Users can load programs and data onto their machines as they require; if the machines are networked (even `standalone' users occasionally need to swap information or electronic mail with other people), the users can continue to work even when the network fails, as all their resources are on their local machine.

  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.