http://www.fok.hu/~dirk
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.
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.
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:
The book is divided into three Parts:
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
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.(If technical details aren't so relevant to you, you can skip over this module.)
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.
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.
X in a Nutshell
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).
A Brief Overview of the X System
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.
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:
The separation of client from server is fundamental in X, and it is what gives X most of its unique benefits.
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.)
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.
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:
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).
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:
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.
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.)
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.
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.
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).
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:
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 '.
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).
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.
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.
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).
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.
It differs from X in two important ways:
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.
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.
However, NeWS is proprietary to Sun, and is used by almost
nobody else.
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:
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:
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.
The Benefits X Gives You
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.
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.)
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.
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').
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.
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.
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.
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:
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:
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:on remote machine XYZ run SPREADSHEET, 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.run SPREADSHEET here, also displaying to here
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:
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).
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.
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.
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.
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.
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
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
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.
Making the user interfaces consistent in all the programs you use has many benefits:
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:
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.
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.
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!
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:
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.)
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.
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.
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.)
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.
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.
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:
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.
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.
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.
(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.)
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.
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.
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.