CS4CC3 / CS6CC3
Advanced Operating Systems
Laboratory 1 (v3)
X-Windows(Client/Server)
LAB to be done individually
File:4cc04lb1.doc Date:27sep04/wfsp Revision Level:3.0
2004/2005 CS 4CC3/6CC3 -- Laboratory 1 page 1-2
INTRODUCTION
This laboratory will introduce you to the X WINDOW SYSTEM. You will explore the features and capabilities of the X Window System by examining the components offered. The main goal of this laboratory will be to allow you to become familiar with the X Window System and see the way in which programming is handled in a windowing environment. Some of the later labs in this course require the operation and an understanding of the X-window system.
Using the X Window System is simply learning how to manipulate windows, icons, and applications will be the main emphasis. In addition to becoming familiar with the windowing system you will be asked to interpret differences in execution time between a host machine and a remote machine using particular benchmark tests. The appendix illustrates the development side of the X Window System. You will be able to inspect some working applications and determine how they work. The difference between raw Xprogramming in C and that done with the X toolkit is quite striking and provided for your information only.
SYSTEM OVERVIEW
The X Window System is described as a "software environment for engineering workstations."1 Project Athena and the Laboratory for Computer Science, two organizations at the Massachusetts Institute of Technology responsible for developing and using large quantities of workstation application programs, realized that the reprogramming of applications for different types of workstations was wasting large amounts of time and resources. In order to alter this inconvenience, they introduced a common workstation interface. This system was developed at the Massachusetts Institute of Technology (M.I.T.) in the hopes that goals could be reached in the areas of network- transparency, vendor-independence, and portability.
Network-transparency allows an application running on a remote CPU to be connected to a workstation and use that workstation for input and output purposes. X applications are portable which means that as long as the application can create a connection to a workstation it can use all of the capabilities of that workstation regardless of the model or vendor provided that the X network protocol is supported. This standard environment for applications, called the X Window System, has grown to be quite popular and there are many components to the system, which need to be understood before programming can be attempted.
The X Window Setting
The environment of the X Window System is made up of several important entities. The entire system is built upon the Base Window System, which uses the X Network Protocol. This Protocol is the only way through which applications can interface with the Base Window System. To hide some of the complexities of the X Network Protocol an X Toolkit is often used. Figure 1 shows the different
1 Jones, Oliver, Introduction to the X Window System, Prentice-Hall, Englewood Cliffs, NJ, 1989, pp. 2.
2004/2005 CS 4CC3/6CC3 -- Laboratory 1 page 1-3 layers, which constitute the make up of the X Window System. The Base Window System is the lowest layer upon which all other components are added. Applications do not typically access the Base Window System directly. Instead, they use the Xlib; a basic C language routine library. The remaining piece of the puzzle, the window manager, can be seen on the left side of the diagram. It is treated as an application by the X Window system and it's purpose is to monitor window activities.
Figure 1: Software components of the X-system.
Client-Server Relationship and the X Network Protocol
The X Window System is based on the client-server model. The server is the program which is resident in each particular workstation; while applications make up the client portion of this relationship. Messages, which flow between these two entities, are the basic means of communication in this type of model. The X Network Protocol determines the make-up and interpretation of the messages being transferred.
In order for this model to take place, a connection must first be made between the client and the server. The application is responsible for making this connection to the server. Once a connection has been established, the transfer of messages can begin using the X Network Protocol.
2004/2005 CS 4CC3/6CC3 -- Laboratory 1 page 1-4
PART I Introduction
The purpose of this part of the laboratory is to introduce you to the X Window System as a beginner. You will login to X Windows on one of the Suns and explore how some of the system features work. You will be introduced to windows, X Window applications, menus, and pointer use within windows. Throughout this laboratory it is important to remember that the X Window System is, from a user point of view, relatively easy to use but has a much more complex inner-working which is hidden from view.
After reading the preceding System Overview section and the accompanying appendix answer the following questions about the X Window System and include your answers as part of the lab report submitted seven days after the lab completion.
1. What are the four types of packets or messages used in the client-server relationship and give an example of each? 2. Define the following: window, window manager, X Toolkit, Xlib, pointer, X Network Protocol. 3. Explain briefly the diagram presented in the System Overview section.
Figure 2: The famous X-Window screen. Note: your screen may differ slightly depending on which window manager has been selcted as the default for the display server in use. 2004/2005 CS 4CC3/6CC3 -- Laboratory 1 page 1-5
Logging In
You should sit down in front of a Sun workstation console in ITC-235 or ITC-236*•. A login prompt should appear when you hit the ENTER key. It should look similar to the following although there are several names, which could precede login (i.e. wolf
Common Desktop Environment Server login :
Use your usual login account name and password as noted above, as in
wolf2 login : xxxxxxx and respond to the password prompt by typing
Password : yyyyyy
This should result in a successful login. If this is not the case, ask Mr. Robert Li (RL) or Mr. Derek Lipiec (DL) of the Departmental technical staff (ITC-242) for assistance.
Once logged in you may wish to change the default password using the passwd command.
You will know that you have entered X Windows when you see some or all of the following: a clock, one or two windows, and an X that you can move using the pointer. See figure 2-2.
If you do not reach this stage within a few minutes ask either RL or DL for assistance.
Enter your name and password, and figure out which environment you are using. Older machines often default to twm or olwm. Linux based machines, more common at home, will often supply KDE or Gnome. Sun machines often use CDE. The important thing to realize is that no matter which environment you are using, you are still running X.
Mouse Movement
One of the most important aspects of any windowing system is the pointer device. The pointer is controlled by the mouse normally attached to the right-hand side of your keyboard. Place this on top of the square pad and move it around, watching the screen as you do. You should find that an X is moving within the screen. NOTE: depending on which display server is executing and its selected window manager, some of these mouse movement questions are not applicable. Do your best to see how the behaviour and mouse movements are correlated.
• For users already familiar with X-windows, you may perform these operations from home using either a Linux workstation or a MS Windows/Apple OS appropriately equipped with an X-Windows display server software system which converts the PC into a X display server station. Usually a standard login is done from home to the CAS machine designated as the client application system using secure shell (remote login system – do not use “telnet”, “rlogin” or other unsecure method for CAS machine access) which has been previously set up to handle X-tunnelling. The recent VPN (virtual private network) interconnection system from CAS made to access on-campus machines can also be utilized. 2004/2005 CS 4CC3/6CC3 -- Laboratory 1 page 1-6
What happens when you move the pointer into one of the windows on the screen?
To enter commands in a particular window the pointer must be in the window. This will cause the cursor at the prompt to become highlighted.
Now, move the pointer into the action bar of the same window. The action bar is the top bar of the window which has the name of the window on the right hand side and a small box with two arrows pointing up and down on the right.
What happens when you move the pointer here? Are you still able to enter commands with the pointer in this location?
Look at the mouse and you should notice that there are three buttons present. Try pressing down one of the mouse buttons while the pointer is in the action bar and holding it down to see what each does.
When you press and hold the left mouse button while in the action bar and move your mouse at the same time what happens? Are there any restrictions to what you can do?
Explain what the other two mouse buttons do in this instance.
Now that you know something about how to move windows partially or totally obscure one window by placing the other on top of it. Once you have done this click the left mouse button in the blue (or solid) part of the action bar. What happens?
When using the right mouse button in the action bar to resize the window what appears in the upper left corner? What is the maximum size of a window on the display?
Overlap the two windows again and this time position the pointer in the small box with two arrows on the right side of the action bar. Click one of the mouse buttons and comment on what happens.
Pressing the middle mouse button down while in the action bar of a window brings up a menu of options for that window. Describe what each option does and when you might need to use it. Now move the pointer outside of the windows and into the blue area or background portion of the screen. The pointer should look like an X.
Press each of the mouse buttons down in turn and describe what happens. How do you know if a menu item has a sub-menu attached to it?
Press the left mouse button down and find the (De)Iconify menu item and move the pointer until it is highlighted. Let go of the mouse button and move the pointer to one of the windows and press the button again. What happens?
Try clicking on the clock. Does anything happen? If not, how do you move the clock? Move it to the lower left hand corner.
Bring up the utilities menu and try each of the menu items listed there and describe what each does.
2004/2005 CS 4CC3/6CC3 -- Laboratory 1 page 1-7
PART Ib
The second portion of this part of the lab and its purpose is to run a few benchmark tests to determine the differences, if any, in the amount of time it takes to execute certain activities. The command, which you will be using to test the machines, is called x11perf. This command allows you as a user to run a series of events within X Windows to measure performance times.
The options you will be running using x11perf are:
resize - resize window uresize - resize unmapped window create - create and map subwindows ucreate - create unmapped windows map - map window via parent unmap - unmap window via parent
Run these options, that is the X-client applications on the departmental cluster machine called penguin. After logging in to penguin with the usual CAS login and password by secure shell, say, use the x11perf command. The UNIX help command ("man x11perf") may be helpful for you here. Do this from penguin.
For example
penguin10[105] x11perf -resize
A new window should appear on the screen and results should begin appearing in the original window from which you entered the x11perf command. If this does not happen check the current directory to make sure it matches the one specified earlier. If you have any trouble ask the TA for assistance. The two resize options take the longest to execute so be patient, others are very fast. Because there is a fair amount of data taking, you may wish to capture the ASCII results into a file using the unix command called “script” Use the man command to check out how to use the facility.
Now move to another X-display server, i.e. if you are on a fox move to a wolf or visa versa and repeat the X11 performance command from the new server. Record all results and note which machine served as the display server. Compare the results you obtained and give possible reasons for any differences encountered. Below are the hardware comparison of the performance for the wolfs or foxs.
Table 1-1 – Hardware Specifics for ITC-236 “terminals”.
The Foxs -- Sun Ultra 5s The Wolfs – Sun Ultra 10s 270 Mhz SPARC Stations 330 Mhz SPARC Stations 320 Mb external cache 256 Mb external cache 8 Gigabyte of Memory 2 Gb of Memory 24-bit colour frame buffers 24-bit colour frame buffers 100 Mbps TCP/IP Ethernet NIC 100 Mbps TCP/IP Ethernet NIC
2004/2005 CS 4CC3/6CC3 -- Laboratory 1 page 1-8
Once you are finished find the EXIT X Windows options and highlight the yes option. This should remove you from the X Window environment and if you are logged on to a host machine back to the prompt you were at previously. Type exit to logout of this session.
Note that when using different clients from the same X-display server, it may be necessary (i.e. not already done in your login script) to allow the client machine, to use the machine in front of which you are sitting as a X-display server by typing on the console window:
xhost
Also, the client must be told on which machine, the display server must be run. This is done by typing on the window to the client machine the following:
setenv DISPLAY
As done in the earlier parts, record results and compare to the other two runs. Explain any similarities or differences note from comparisons. (HINT: do not forget this is a SYSTEMS course.)
Hand in answers to all questions asked within the lab along with any comments on aspects of the X Window System which you may have found worth noting.
PART II – FYI Only
Introduction
The purpose of this part of the laboratory is to introduce you to a basic X Window application. As well, you will examine the differences between the program which you will help write and a much shorter program which does almost the same thing. The difference in the program lengths is due to the fact that one uses the X Toolkit and the other makes direct calls to the Xlib. From this part of the lab the main objective is for you to experience the requirements of programming in a windowing environment.
Answer the following questions about the "helloworld" program for the X Window System and hand them in as part of your submitted laboratory report.
1. What does the X Window "helloworld" program need to be concerned with? (ie window creation...)
Helloworld.c
/* X include pre-defined header files */ /* X Library - defines X data structures */ #include <
/* String to be placed in window where mouse clicks occur */ char hi[] = {"HI"}; main(argc,argv) int argc; char **argv; { /* declarations */ /* pointer to an X data structure controlling */ /* connection to the workstation */ Display *mydisplay; /* X Resource identifier for the window */ Window mywindow; /* X Resource identifier for the graphics context */ GC mygc; /* data structure which X places input information */ /* on events into */ XEvent myevent; /* individual key presses are held here */ KeySym mykey; /* data structure used to inform other applications */ /* about its window */ XSizeHints myhint; XWMHints mywmhint; /* set data types for foreground, background, */ /* and other required data types for the main loop */ int myscreen; unsigned long myforeground, mybackground; int i; char text[10]; int done; /* initialization */ /* X Window System request which initiates a display */ /* connection from this application to the */ /* workstation and fills in a Display structure */ /* returning a pointer to this structure */ mydisplay = XOpenDisplay(""); /* these lines contain info on filling in foreground */ /* and background areas */ myscreen = DefaultScreen(mydisplay); mybackground = WhitePixel(mydisplay,myscreen); myforeground = BlackPixel(mydisplay,myscreen); /* default program-specified window position and size*/ /* the windows upper left corner will be at (200,300)*/ myhint.x = 200; myhint.y = 300; myhint.width = 350; myhint.height = 250; myhint.flags = PPosition | PSize; mywmhint.flags = InputHint; mywmhint.input = True; /* call to request that the workstations creates */ /* a simple window. It returns the window's */ /* resource identifier to mywindow. The variables */ /* passed describe the characteristics of the window */ mywindow = XCreateSimpleWindow(mydisplay, DefaultRootWindow(mydisplay), myhint.x,myhint.y,myhint.width,myhint.height, 5,myforeground,mybackground); /* another X Window System request which describes */ /* the characteristics of this application's window */ /* to other applications on the workstation */ 2004/2005 CS 4CC3/6CC3 -- Laboratory 1 page 1-10
/* including the window manager application */ XSetStandardProperties(mydisplay,mywindow,hello,hello, None,argv,argc,&myhint); XSetWMHints(mydisplay,mywindow,&mywmhint); /* these lines create a graphics context and puts */ /* the foreground and background colours into it */ mygc = XCreateGC(mydisplay,mywindow,0,0); XSetBackground(mydisplay,mygc,mybackground); XSetForeground(mydisplay,mygc,myforeground); /* from this point on the application needs to know */ /* when a mouse button is pressed or a keyboard */ /* action occurs in mywindow. ExposureMask */ /* receives expose events and allows the application */ /* to determine when a redraw becomes neccesary.*/ XSelectInput(mydisplay,mywindow, ButtonPressMask | KeyPressMask | ExposureMask); /* this window mapping request asks that the window */ /* be placed on top of any existing windows on the */ /* screen */ XMapRaised(mydisplay,mywindow); /* main event-reading loop controlling statement*/ done = 0; while(done == 0) { /* read next event from workstation and fill */ /* in the myevent structure*/ XNextEvent(mydisplay,&myevent); /* transfer each event to the case statements */ switch(myevent.type) { /* repaint window on exposure events */ case Expose: if (myevent.xexpose.count == 0) XDrawImageString( myevent.xexpose.display,myevent.xexpose.window,mygc, 50,50, hello,strlen(hello) ); break; /* process keyboard mapping changes - used if */ /* the configuration of the keyboard changes */ case MappingNotify: XRefreshKeyboardMapping(&myevent); break; /* process mouse-button presses by placing */ /* hi string in the window at mouse click */ /* position xbuuton.x, xbutton.y */ case ButtonPress: XDrawImageString( myevent.xbutton.display,myevent.xbutton.window,mygc, myevent.xbutton.x,myevent.xbutton.y, hi,strlen(hi)); break; /* process keyboard input - XLookupString */ /* translates the information in XEvent into */ /* a character string. If the result is a 'q' */ /* the loop is done */ case KeyPress: i = XLookupString(&myevent,text,10,&mykey,0); if(i == 1 && text[0] == 'q') done = 1; break; 2004/2005 CS 4CC3/6CC3 -- Laboratory 1 page 1-11
} /* switch (myevent.type) */ } /* while done == 0 */ /* Termination - destroys the graphics context, */ /* destroys the window, closes the display, and */ /* exits the application */ XFreeGC(mydisplay,mygc); XDestroyWindow(mydisplay,mywindow); XCloseDisplay(mydisplay); exit(0); }
The next step is to take the program and compile it using the following command: cc helloworld.c -lX11 -o helloworld
If no errors result you will have a file called helloworld. Type helloworld to run the application.
Helloworld.c using the X Toolkit
#include <
}
This program has already been compiled for you. The command to do so is of the form:
cc helloworld.c -lXaw -lXt -lX11 -o hwtoolkit
Type hwtoolkit to execute the application.
2. Describe how the X Toolkit can reduce the amount of code by so much. In other words, what capabilities are present in the toolkit to allow such a decreased amount of code?
Hand in your writeup including the answers to any questions within the lab as part of the submitted laboratory report.
LABORATORY 1
APPENDIX
The X Window System is defined in terms of a network protocol. The network protocol specifies the format and meaning of messages passed over a display connection between application and workstation. Although applications may use any means to generate X protocol messages, C programs gain access to X workstations by calling the Xlib procedural interface (subroutine package). Xlib is the subject of this book.
The X protocol provides four kinds of messages for communications between application and workstation. The most common message type is the one-way request. Almost everything an applicaiton does (for example, drawing) on a workstation generates a one-way request. Xlib assembles consecutive one-way requests into buffers and transmits them in batches to improve performance. Applications send one-way requests, then forget about them and go on to other work. The workstation carries out one-way requests in order as it receives them.
Round-trip requests are used by applications for informational queries, such as finding our the size of a window. Applications originate round-trip requests. The workstation carries them out immediately and generates a reply. Round-trip requests can degrade performance, because Xlib cannot assemble them into buffered batches. Whereas applications originate requests, workstations originate events and error events, to inform applications of user actions and errors in requests.
2004/2005 CS 4CC3/6CC3 -- Laboratory 1 page 1-13
All X applications begin execution by using Xlib's XOpenDisplay call to establish a display connection. By specifying the appropriate display name, an application can establish a display connection, to a workstation on the same cpu, or to a workstation on a remote cpu. This capability of remote display connections provides X's network transparency. By using the appropriate form of display name, an application can specify the workstations' cpu, the type of communication network (Unix-Domain sockets, TCP/IP, or DECnet) to use, and the display and screen to use.
Once a display connection is established, applications interact with workstations by manipulating resources, including windows, graphic contexts, fonts, color maps, pixmaps, and cursors. These resources are resident in the workstation. They give a way for the application to load useful state information, such as window positions and drawing colors, into the workstation. The correct use of resources is central to the functioning of an X application. All resources are referred to by means of resource identifiers: 32-bit integers containing unique identifying values.
Resources can be shared among applications running on a workstation. Ordinarily, resources continue to exist as long as their creating application keeps its display connection open. It is possible for applications to arrange for their resources to outlive them. Resources are ephemeral, however: in no event do they continue to exist after the end of a user's logged-in session on the workstation.
All workstations contain some pre-existing resources, such as root windows. Applications can use informational macros to find out the resource identifiers for the pre-existing resources. Informational macros are also useful for finding out other workstation-dependent display configuration parameters, such as the appropriate pixel values to use for drawing in black and white. If applications are to be portable, they must make proper use of this display configuration information.
X workstations let the application know about user-induced actions such as key presses and mouse motion by means of events. Events are also used to report application-induced changes to the workstation's display. Events report all kinds of actions, ranging from mouse button presses to changes in window visibility to changes in color maps.
One of the most important types of events, the Expose event type, informs an application that it must redraw the contents of a window. A well-written X application processes events in a modeless way, in any order. Typically, a user users many different application programs simultaneously. Expose events allow application programs to find out when their windows have been damaged (covered, then uncovered) by other windows. X applications must respond to Expose events by redrawing windows.
Events come from windows. With a very few exceptions, applications only receive event types if they solicit them beforehand, using the XSelectInput call or the equivalent. The workstation delivers evetns to applications in the order they occur.
2004/2005 CS 4CC3/6CC3 -- Laboratory 1 page 1-14
Events wait in an application event queue between the time the workstation delivers them and thet time the application accepts them. Xlib provides several ways of accepting events and removig them from the event queue. the most useful call for accepting events is XNextEvent. Often, applications contain a main loop with XNextEvent at the top of the loop. Applications can use XEventsQueued to determine how many events, if any, remain unprocessed in the event queue.
As described previously, Xlib saves one-way X requests in a buffer for transmission in batches. Applications using a main loop topped by XNextEvent do not have to do anything explicit to control Xlib's request buffer, because XNextEvent automatically sends the buffer's contests when necessary. However, any application can explicitly flush its request buffer (send its contents to the workstation) by calling Xflush.
Applications can use Xsync to synchronize the application and workstation: to flush the request buffer and wait for the workstation to complete all requests.
Xsync synchronizes just once each time it is called. Applications can also use Xsynchronize to put Xlib into synchronous mode, in which Xlib automatically waits for the completion of every request. (On Unix and compatible systems, setting the variable "_Xdebug" to a nonzero value has the same effect.) Synchronous mode severaly degrades performance, but it makes debugging much simpler.
Because X allows applications to send requests to the workstation in batches, most Xlib calls do not return a success or failure status immediately. Instead, the workstation carries out the requests when it receives them. If the workstation detects an error in a request, it sends an error event message back tothe application, which generated the offending request. Xlib provides a default error event handler, which prints the particulars of an error and stops the application. Xlib provides a way for application programs to define and use custom error event handlers. Custom error event handlers allow applications to recover from errors. Xlib also provides a way for application programs to define their own system (I/O) error handlers.
file: 4cc04lb1.doc date: 10sep04 / wfsp revision level: 3 date: 30sep04/wfsp