JPH0667902A - Method and apparatus for automatically generating computer program - Google Patents

Abstract

PURPOSE: To provide the method that generates a computer program to simulate a communication protocol between protocols. CONSTITUTION: This program is generated automatically as a result of supervision of protocol message exchange. When all packets are stored in a memory, they are interpreted by a device 80. This point in the Xprog 90 differs from the Xscope. The Xscope interprets each packet by printing out dumped codes of each content. The Xprog checks each packet 80 and writes a source code with respect to the function to an output file 82 so as to try generating an Xlib function call by which the packet were generated. This inverse translation technology edits a source code as the result and when it is executed in place of a code of the original request party, the packet of the same sequence is produced on a link.

Description

Detailed Description of the Invention

[0001]

FIELD OF THE INVENTION This invention relates to inter-process computer communication, and more particularly to the generation of monitoring and communication between host and client processes within a multi-process computer environment.

[0002]

BACKGROUND OF THE INVENTION The cost of introducing a new computer architecture has risen significantly over the last three decades. Early computer systems (e.g., IBM7094) were designed, manufactured, and sold with little or no software assistance. But over time,
Hardware alone is no longer enough. Assemblers and loaders are now required to sell new machines to customers. Soon it was necessary to supply the operating system and then the compiler was required. In addition, users have come to expect that the software that was available on the previous system will also be available on the new system.

Today, any system is an advanced operating system, such as the UNIX operating system developed by Bell Laboratories, some of the most popular software programming languages,
For example, it would be unthinkable to sell seriously unless a compiler for C or Pascal, standard utilities, networking support, and a graphic user interface were available at the same time. Customers are increasingly looking for a complete working system, rather than a faster CPU or improved hardware architecture.

As a result of the need to sell complete systems, various hardware and software projects have been developed simultaneously with dependencies between the various parts. As an example, an application program written in the C programming language for the X11 window system on the UNIX operating system is being developed while its C compiler, X11 window system, and UNIX operating system are still under development. , Developed in parallel.
The window system allows the display screen to be divided into multiple areas (windows). Programs can use windows to interact with users, display results, and request input. The user controls the size of the window and its position on the screen. Window system technology is currently under development, and thus new, competing Unido systems may emerge.

The X11 window system is the newest of the series of window systems developed at MIT University under the guidance of the Athena project. The X Window System originates from the W Window from Stanford University, but has been redesigned many times, most recently the X10.
Has been changed from X11 to X11. The X11 window system is a window server. The window server runs as a separate process and controls the allocation and access to display screens. The application program, called the client, uses interprocess communication, possibly acting as a process to communicate with the window server through the network. The resulting architecture is shown in FIG.

Communication between the X11 window server and the X11 client is defined by the X11 protocol. The X11 protocol defines the format and content of a request made by a client to an X11 server, and the X11 protocol.
It defines the responses, errors and events that the server returns to the client. The protocol specifies the type and sequence of values in requests, responses, errors and events.

The X11 protocol is a byte level protocol. Effective programming is more commonly accomplished by using a higher level functional library or toolkit that issues lower level X11 requests for sequences. For example, an application program interacts with its user in the form of text, buttons, scroll bars, and menus. These higher level objects are supported by separately programmed toolkits.

In some cases, there are multiple layers of libraries and toolkits such that one toolkit is built on top of another toolkit that uses the library to issue the actual X11 request. As a result of this, the application program has a significant distance from the X11 requests sent to the server, and if subtle errors were present in the toolkit supporting this application program, they would be very difficult to detect. .

Even more difficult than detecting the actual error in the toolkit is a less than optimal translation of the higher level interface to the X11 protocol interface. For example, Gnu Emacs
Early versions of the editor (Stallman, RM;
(Stallman, RM) "GNU Emacs Manual," version 18, Free Software Foundation, Boston, MA, 1988), appears to work well until the X10 is slowed down for debugging. It was In this case, it became clear that the Emacs editor was redrawing the display a few more times than needed. At the higher speeds of higher X10 servers, the redisplay is present but invisible to the human eye.

For the window system described above, see Robert, W .; Schaefler (Robert W.Scheifl
er) and Jim Gettys, "X Window System", Transactions on Graphics, Vol. 63, 198
6 years; Robert W. Scheffler, "X Window System Protocol Release 2: X Version 11," Computer Science Laboratory, Massachusetts Institute of Technology, 1988; and Frank G.L. Harasuzu (Fr
ank G. Halasz), Robert S. Peten Gill (Robert
S. Pettengill), James L. Peterson (Ja
mes L. Peterson), Tom J. Smith (Tom J. Smit
h) and "Window by ZviWeiss"
Server Independent Interface ”, Technical Report STP-348-87, Software Technology Program, MCC, October 1987 issue, all of which are hereby incorporated by reference for background information. It has been incorporated.
If the performance of the system under development is poor, you need to know where to focus your efforts to improve performance.
In the above example of developing an application program in parallel with the environment in which it will be executed, it is necessary to separate the computation of the application program from the computation of the window system.

[0011]

SUMMARY OF THE INVENTION The present invention is a tool for automatically generating an X11 program that runs the above problems at the same speed that an X11 client will run for any user session. A certain Xpro
Solved by developing g. This allows the impact of client computation to be separated from the X11 server computation. By separating these calculations into two parts,
It makes it easy to detect performance problems within any part of the system as a whole. The client part is X11
An automatically generated X11 that mimics the data stream that would be generated by the client without internal computation
By substituting programmatically, the client can run in the system as fast as possible, which eliminates the unknown variable of client processing time in the calculation of overall system throughput.

The solution achieved by Xprog is described by James L. et al. By James L. Peterson, "Xscope: Debugging and Performance Tools for X11," Information Processing 89, Elsvia Science Press, 19
Xsco, 1989, pp. 49-54
It is an extension of the approach using pe. Xprog is located between the X11 client and the X11 server.
Client has Xprog in Xprog as if Xprog
11 Connect as if it were a server. Xprog is
Meanwhile, it connects to the actual X11 server. All bytes from the client to the Xprog immediately return the actual X.
11 server is passed while all bytes from the X11 server are passed to the actual X11 client.
Thus, except for a slight increase in communication costs, Xpr
og is completely invisible to the X11 client and X11 server.

That is, the communication between the client and the server is as if Xprog does not exist at all.

Xprog is an X11 client and an X11
It does not affect the communication with the server, but this communication can be monitored. From the analysis of X11 communication, Xpro
g produces a new program as its output. X
The output of prog is a C program, which when compiled and executed produces the exact same interaction with the X11 server as the original client had in its monitored session. Therefore, the program thus newly generated reproduces the same display as the original client. However, since this new program does not perform other calculations, X11
Issue commands to the server as fast as possible. There is no delay due to the calculation of the application program, and thus it is possible to accurately determine how fast the X11 server is actually.

For example, reading a set of line segments outlining a political map of Europe, creating a window, scaling the line segments with respect to the window, small for overlapping line segments or screen resolution. Assume an X11 application program that checks for line segments that pass and draws the result in the center of the window. The Xprog's thus generated program output for this line drawing program is primarily a long list of Xlib calls for displaying a list of line segments given by absolute pixel coordinates. It displays the exact same set of line segments as the original application program, but all line segments are stored as parameters to the Xlib line drawing procedure within this program. Therefore, no time is required to read, scale, or translate points. The Xprog output drives the X11 server to display the same European map as quickly as possible.

It should be noted that the output of Xprog is a program that produces the same display as the original program, but it always produces the exact same display. It has no input and cannot display other maps. It also does not scale or translate the data when the window size changes. The Xprog output simply reproduces the exact same display as the original program produced. This appears to be a limiting factor, but in fact it is exactly the same behavior that is required in many cases, such as when the server timing requires predictable, repeatable input.

This type of program is also useful for demonstration purposes. It is often useful to create displays that are freely distributed or safely displayed and open to potential customers. The output of Xprog is an exact replica of the previous display, but contains no information about the algorithm or data that produced it, and
It does not contain untested code that indicates failure at critical times or as a result of inexperienced user behavior. The output of Xprog can be freely distributed in source or edited form without any risk of ownership.

Accordingly, one object of the present invention is to provide an improved development environment for computer systems.

Yet another object of the present invention is to provide an improved development environment that assists in parallel development of application programs and operating systems upon which application programs execute. is there.

Yet another object of the present invention is to provide an improved method for analyzing system performance within a computing environment.

Yet another object of the present invention is to provide an improved method for analyzing system performance within a windowed computing environment.

Yet another object of the present invention is to provide a tool for monitoring communication protocols.

Yet another object of the present invention is to provide a tool for generating a computer program.

Yet another object of the invention is to mimic the response of an action to one side of a communication dialogue.

Yet another object of the present invention is to provide an improved method for distributing computer software for demonstration purposes.

The above and other objects, features and advantages of the present invention will become more apparent by reading the following embodiments of the present invention with reference to the accompanying drawings.

[0027]

EXAMPLES The implementation of Xprog is based on Xscope described above. For this reason, Xscope will be described in such a way that its operation can be understood.

Referring to FIG. 2, Xscope12 is X
11 is a tool for enabling an interaction to be analyzed between the client 10 and the X11 server 14. Xsc
The ope is located between the client 10 and the server 14 and listens to all communications between them. Xscope prints a trace of this communication and programmers can use their X1
It was designed so that the correctness and efficiency of using 1 could be seen. This is of particular value to programmers writing toolkits, such as AndrewToolkit, which is described by James H. et al. James H. Morris, Mahadev Satyanayanan, Michael H. Morris. Connor (Mi
chael H. Conner), John H. Howard (Jhon H. How
ard), David S. H. Rosentail (David SHRo
senthel), and F. Donelson Smith (F.Donelson
Smith) "Andrew: Distributed Personal Computing Environment", ACM Communications, Vol. 29, No.
3, March 1986, pp. 184-201.

3 and 4 show an X11 client and an X.
11 shows a part of the trace with the 11 server. Time 0.0
At 0, the client sends 12 bytes of data 20 to the server. After 0.04 seconds, the server responds with 8 bytes of data 22, 0.06 seconds later (time 0.1
It responds with an additional 136 bytes 24 (at 0). Bytes continue to flow between the client and server. The buffered information is printed in hexadecimal with its size, the time it was sent, and whether it was sent by the client or the server.

Xscope also translates these bytes to indicate what they mean under the X11 protocol. 5 and 6 show traces between an X11 client and an X11 server translated by Xscope. For Xscope, the first 12 bytes 30 sent from the client to the X11 server are X1
Looks like a setup message 32 for 1. The 8-byte and 136-byte messages sent from the X11 server to the client are combined to form the setup response 34, which gives information about the particular server configuration. Following this setup exchange, the client creates a graphic context 36 and sends a GetProperty request 38 to the resource manager. The server responds, for example, that there is no resource manager (40).

Since the underlying TCP / IP socket connections used by X11 and X11 are network connections, each process runs either on a separate machine that communicates over the network or on the same machine ( TCP / IP is a well-known industry standard packet switched communication method). Suppose the client runs on machine A and the X11 server runs on machine B. Xscope can run on machine A, machine B, or another machine C. When Xscope is started, command line parameters indicate the name of the machine along with the X11 server (and possibly the display). When the client program is started, it is given the name of the Xscope machine.

The client program is Xscope
, And Xscope immediately connects to the Xscope server. X11 client is Xscope X11
I think that it is a server, and Xscope is X
I think I have 11 clients. All bytes from the actual X11 client to Xscope are the actual X1
Sent to 1 server, Xscop from the actual X11 server
All responses to e are sent to the actual X11 client. Xscope is just in the middle and gives a trace of what the real server and client are doing.

As shown in FIG. 7, Xscope64
Main loop 42 waits for input from client 50, server 52, or a new client connection. Xs when connection 44 is made from a new client
The copy creates a new connection to the X11 server for that client and updates its table 46. As soon as input 54 arrives from the client, this is 5
X11 server 52 for this client in 8
As soon as the input 56 arrives from the X11 server, it is written to the client 50 at 60. Thus, Xscope is transparent to both the server and the client, and its performance impact is small. In both cases, once the data has been written, it passes the procedure for further processing and printing at 62.

This processing code breaks the input data into one meaningful packet for each request, response, error, or event and calls another routine to translate and print this packet. . Since the printing procedure can only handle one complete packet, it requires buffering incomplete packets until enough bytes arrive to give a complete packet.

The X11 protocol is far superior to the X10 protocol in that Xscope determines the packet length. Each X11 request has a field (bytes 2 and 3) giving the length of the request in words (1 word is 4 bytes).
including. However, bytes 0 and 1 may contain valid data, so the first 4 bytes need to be set aside before determining the length of the request. If the request length is the beginning of the request, the request length can be determined without requiring storage of bytes.

Packets from the server are more complex.
If the packet is a response to a previous request, bytes 4-7 contain the response length. On the other hand, errors and events have no explicit length and are always 32 bytes long. For this reason,
Requests, responses, events and errors must be handled separately even if they are all substantially the same for tracking purposes.

Another difficulty is the identification of the specific format of individual packets. The request is identified by the request opcode in these first bytes. Similarly, errors and events are identified by the code in their first or second byte. On the other hand, the response is not directly identified using any method. It should be noted that not all requests generate a response, as shown between request 36 and request 38 in FIG. Of the 120 different X11 requests, only 40 generate responses. The communication between the client and the server is asynchronous so that the client can make requests to generate several responses without waiting for a response.

To identify the server response packet (or the cause of the server error packet), the client must record the serial number of each request (request 1 is the first request after the initial setup communication). Is). Each response (or error) contains the serial number of the request that caused it. To identify the type of response, the client (and Xscope) keeps a table of pending request serial numbers and matches the serial numbers to identify the request type and from there the response type.

Once the request, response, event, or error code has been identified, the contents of the packet are ready to be printed according to the type of packet and its code. Here, there are several possibilities. A violent approach is to write a procedure to manually print the packet contents for each type of packet. However, 120 different requests, each with an average of 6 columns, 4
With 0 responses, 34 events, and 17 errors, this is a fair amount of monotonic code.

For X10, this rough encoding is
Avoided by using table derivation code. Each request, response, event, and error is described by an entry in the table. The items in this table are
It mainly consists of a list of columns. Each column indicates its starting byte, length, type and name. One routine is
A routine that picks up a packet and its description and then prints the individual columns within the packet. X11
If you take a similar approach to, some problems occur.

The first issue is of type. In the case of X10, there are only 4 or 5 different types of objects, namely integers, identifiers, strings, etc. However, in the case of X11, 11
There are two different types of objects. The main reason is that the X11 protocol defines types much finer than the X10 case. In X10, types that are simply treated as shorts are also listed in X11 (all legal values are named) or enumerated types (or each legal bit is named). Can be type.

However, not all types for X11 are explicitly defined. Some types are
They are implicitly defined in the records in which they are used. These types are anonymous types. This is also the case when the same type is used in multiple different packets. For example, if the same COLORMASK item is StoreNamed
COLORI used in Color and StoreColors requests
May be defined as both as a TEM type sub-element. This definition cannot be represented by name, so this definition is repeated for both uses.

In fact, the use of anonymous types seems to hide the possibility of reusing the same type in multiple places. For example, the response to the GetKeyboardControl request has columns defined as 0 for OFF and 1 for ON anonymously. ChangeKeyboardControl has another anonymous type with the same definition and another different anonymous type with the definitions 0 for off, 1 for on and 2 for default. In addition to this, other types (most of which have no name) have the same 0/1 value as false / true, no / yes, none / all, off / on, installed / installed Not defined, not allowed / not allowed, reset / start, insert / delete, top / bottom, and sync / async.

Further several types are created by different translations of specific values of resource identification. For example, a window identifier is translated with its zero value as "none" (for SetInputFocus request) and "PointerWindow" (for SendEvent request). The seven basic resource identifiers have specific translations with several different values.

On the other hand, the names "MSBfirst" and "LS"
Bfirst "is defined as 0x42 and 0x6C (client to server setup message) or 1 and 0 (server to client setup response) in two different contexts.

However, given a list of types, the generated large set of procedures will print the type given the type. It is obvious what to print for most types, but there are some problems. For example, I
NT8 is defined as a signed 8-bit integer, C
ARD8 is an unsigned integer. Similar types have BYTE defined simply as an 8-bit value. B
No significant difference between YTE and CARD8 or INT8 is ever given by this protocol definition.

Given the list of X11 types, the procedure for printing these, and the definitions of the various packets, the table-guided printing function is written. Based on the X10 program, it is expected that this name, starting byte, length and type of individual fields within the packet will be known. However, I soon encounter a big problem.

The main difficulty of table-guided decoding of the X11 protocol is the inclusion of variable length items in requests and responses. The difficulty with variable length items is that the length cannot simply be known in advance and cannot be put into the decoding table.

Another difficulty with table guided decoding is that each packet may have more than one variable length list. For example, AllocColorCells
The response to the request has two lists, a pixel and a mask. The length of the pixel list is given in bytes 8 and 9, and the length of the mask list is given in bytes 10 and 11.

Unfortunately, the X11 protocol does not necessarily define the length of its variable length list. In particular, QueryC
Let's consider the length of the list in the olors request. The length of this list is not given in this request and must be calculated from the length of the request. Specifically, if the length of this list is n, then the length of this request is 2 + n (as previously mentioned, the request length is the number of 4-byte words in the request, 2 + n). Note that the request length is 8 bytes + n x 4 bytes list entry for the fixed part of the request). Other packets, such as FreeColors requests and requests for GetImage, also require the length of the data item to be calculated from the requested length. Perhaps the most complex is the ChangeProperty request. These requirements are
Holds a list of variable length strings. The number of strings is never given and must simply be determined when running out of the string header where the requested length is possible.

Due to the complexity of the X11 protocol, it does not seem possible to print with the table-guided procedure. However, in an attempt to build a table for the X11 protocol, I noticed the following: To build the table, request, response, error, event, and type descriptions from the troff source of protocol material are extracted. These textual descriptions are then translated into a set of procedure calls to build the table entries. For example, the trough sources for the BOOL type are: This is converted using the Gnu Emacs editor as follows:

P = DefineTYPE (BOOL, E
NUMERATED, "BOOL" PrintENUM
ERATED); DefineEValue (P, OL, “Fals
e "); DefineEValue (P, 1L," Tru
e ″); Instead of having a set procedure and a routine for translating these tables to build a table of sets, each packet definition has been translated into a routine for printing that packet directly. Produces about 217 packet printing procedures, which is nothing more than a table-directed packet printing routine plus code to initialize this table. Allows manual encoding to compensate for the complexity of the X11 protocol without requiring the design, construction and translation of very complex tables.

In this approach, various packet descriptions are made and then converted into routines that each print that packet using the GnuEmacs text editor. Once the general transformations are designed, all requests, responses, events, and errors can be automatically transformed from their description in the X11 protocol definition material into a routine for printing them.

The Xscope code described above is used to establish a communication socket to Xprog. Figure 8
Xprog 90 is located between client 0 and server 52 and produces output 92, as shown in FIG. The output 92 thus produced is a computer program that, when edited and executed, produces a data stream produced by the client (application program) used to communicate with the server using the X11 program. To imitate.

Referring to FIG. 7, the client is Xpr.
When connected to og, it will immediately connect to the X11 server 52 and then proceed to wait for selection loop 70. This program waits for input to one of its input file descriptors (fd) 72 from either client 50 or server 52. With input, this is read at 74,
It is immediately written to the corresponding output fd76 for the client or server.

In addition to this, the input buffer is passed to one routine for packetization at 78.
The main function of this routine is to decompose the input buffer stream into an X11 packet stream, where each packet contains one request, response, event, or error, as shown at 20, 22, and 24 in FIG. To do. The format for each of these packet types is shown in FIG. Events and errors from the server are always 32 bytes and the request from the client contains one opcode (byte 0) and one early field (bytes 2-3) containing the request length. The response also contains one opcode (byte 0), a length field (bytes 4-7) defining their length, and one serial number field (bytes 2-3). A detailed definition for each possible X11 packet is given in the references attached at the end of the detailed description of the invention.

Returning to FIG. 9, individual packets are translated at 80 once they are all assembled in memory.
This is where Xprog90 differs from Xscope. Xscope translates individual packets by printing a dump of their contents. Xprog examines each packet 80 and attempts to generate the Xlib function call it would have generated by writing the source code for that function to output file 82. This reverse translation technique causes the same sequence of packets to appear on this communication link if the resulting source code is edited and executed on behalf of the original requester's code. Back translation simply means translating the data stream from the execution requester program into a series of Xlib function calls.

For example, a packet containing a MapWindow command causes Xprog to generate an XMapWindow function call.
This MapWindow request consists of a length (8 bytes), an opcode ("08" x), and a 32-bit window identifier that specifies which window to map.
The XMapWindow function requires two parameters: (i) the display to be used, and (ii) the window to map. Therefore, the main problem to be solved in this back translation is how to generate those parameters needed for the XMapWindow from those values contained in the MapWindow packet.

Display parameters to XMapWindow and other Xlib commands specify the connection to the window server. There is typically only one connection to the server, which creates a global variable'dpy 'in the Xprog output, which is used as the display parameter for all Xlib functions. This'dpy 'variable is the main () of Xprog output
The result of the XOpenDisplay function in is initialized as follows. main () {dpy = XOpenDisplay (getenv (“DISPLAY”)); ... XMapWindow (dpy, ...?); ... The window identifier (ID) is a typical client /
It is one of a large number of object identifiers involved in server interactions. X11 uses 32-bit identifiers to point to windows, fonts, graphic contexts, and many other X11. These identifiers are selected by the Xlib support code within the client from the range specified by the server when the connection is established. These identifiers are hidden from the Xlib header file by the C language typedef. For this reason, the client program calls the window a type window variable. X
In prog, a numeric identifier is passed to the IWINDOW () function to generate the name for this window variable, which is the string (ch
ar *) is returned.

For Xprog, the low order bits of the numeric X11 identifier are used to specify a hexadecimal number, to which the alphabet type identifier is added.
Thus, the name of the variable for window 1 is called W1 and the graphic context with identifier 2 is G
The font called C2 and having the identifier 10 is called Fa. Each identifier type in X11 has its own function of converting an ID of that type into a name.

These names are used in two ways. These are used each time a request corresponds to an Xlib function that requires a parameter specified by an identifier. So the code for the MapWindow request would be:

MapWindow (buf) unsigned char ^* buf; {/ ^* Request MapMapwindow is opcode 8 ^* / char * window = IWINDOW (& buf [4]); ,, DISPLAY, window);} This translates the MapWindow request back into C code as follows:

XMapWindow (dpy, W8);
This code creates a window with a reference to the specified X11 object, in this case its ID starting at byte 4 of the request. In order for this output to be valid C code, a declaration for this variable name (W8) must be made. Xpr when the identifier is first used
og registers the identifier by type in the Xprog symbol table, and in the C code output file (of the correct type)
Generate a declaration. Thus, all variable names are declared when they are first used. For example, the XMap above
The window in the Window call is declared as follows.

Windows W8; C language, of course, does not allow mixed declarations and commands, where
The output of Xprog is generated in two files. The first file is used for all declarations and the second file is used for executable commands. Xpr
When og finishes, it produces its output by first copying all the declarations from these two files and then copying all the commands. This process produces one output file with all declarations and all commands in the correct order.

Some requests, such as CreateWindow or CreatePixmap, are used to define a new identifier to the X11 server. This identifier is defined by the Xlib support code and returned to the application program by the corresponding Xlib function. Thus, the Xprog code corresponding to these requests is one allocation as seen below.

PX30 = XCreatePixmap
(Dpy, W12,13,13,1); this is generated by the following Xprog code:

Fprintf (Codeout, "\ t
% S = XCreatePixmap (% s,% s,%
d,% d); \ n ", pixmapId, DISPLA
Y, drawable, width, height, d
epth); Similar techniques can be used for other parameter types. These parameter types for X11 requests are generally as follows: (a) The identifier is used to generate a name from that identifier and its type.

(B) The numbers are simply printed in decimal.

(C) The string is printed as a standard C string delimited by double quotes, paying attention to characters that should be internally escaped or quoted.

(D) Symbolic constants are used for the many enumerated types specified for X11.
h is given in the heading file.

(E) The structure and array of values are constructed in a row in the generated program.

The use of structures and arrays as parameters from the X11 client to the X11 server requires the most complex code generation. For example, the CreatePixmapCursor request is used to create a cursor from a pixel map. This request specifies the source and mask pixel map (identifier) as well as the position (number) of the source origin and the foreground and background colors for that cursor. These colors are defined as an array or structure of four values, three of which specify the red, green, and blue components of the color (RGB). Xpr for such requests
The output from og is: Static XColor fore = {O, OxOOOO, OxOOOO, OxOOOO}; static XColor back = {O, Oxffff, Oxffff, Oxffff}; The parentheses are used to generate the local naming context, which allows two color variables to be generated, the foreground and the background. Foreground and background define foreground and background colors. The values for these definitions are taken directly from the CreatePixmapCursor request, 1
It is represented by a hexadecimal number. This allows Xprog to create structures or arrays as needed to pass the correct values to the Xlib function.

Another problem with back translation occurs when there is no Xlib function that directly corresponds to a given X11 request. This is due to the extra semantics placed within the Xlib interface that are not a direct reflection of the underlying X11 interface. That is,
Xlib is not without a sham. For example,
There is no Xlib function corresponding to the X11 OpenFont request. The closest match is the Xlib XloadFont feature, which produces both OpenFont and QueryFont requests. This means that back-translation must know the order of the requests in order to produce its output completely correctly. For example, flag bits must be used to remember whether or not subsequent requests should be ignored, or simply accept less than perfect back translation.

Some requests to X11 produce a response from X11. Typically, these requirements are for certain properties of certain objects. For example, Quer
The yFont request produces a response containing the characteristics of the queried font. The request is back-translated from the X11 request into an Xlib function call. The response from the server to the client is simply ignored by Xprog and discarded. The effect of this response on the session is that future X11
Reflected in the arguments passed in the request. The program that Xprog creates simply tries to create the same command sequence as the session that created it, so
The value returned from a QueryFont request has no meaning to it.

For example, if the client program is X1
Suppose a server is asked to use a QueryFont request to determine the size of characters in a font and this information is used to determine the character spacing across the screen. Quer
The information in this response to the yFont request is that this information is X
Used to calculate the position of the text that should be displayed by the client program to be passed to the client through the prog. Xprog saves and uses the resulting client-calculated position given in the text display request,
We do not know how these values are calculated from the information in this response message. Therefore, the returned function value in the output produced by Xprog is simply ignored. The QueryFont request produces:

(Void) XQueryFont (dp
y, F9); we could just completely drop the QueryFont request when generating the Xprog output program, but doing so would change the timing characteristics of this application in the context of the X11 network protocol. Therefore, it will be placed in the generated output file without being discarded.

Other Xlib functions have some values to be returned and use call-by-reference parameters to return these values. For example, the XGetGeometry function returns seven values in its parameter and one more function value. All of these values are discarded by the code generation below.

Unwindowed a; int b; int c; unsigned int d; unsigned int e; unsigned int f; unsigned int g; &G);} This code makes a request and receives its response value in a temporary variable on the stack, which is then discarded. The impact of these values on the future behavior of the client program is included in the parameters used in future client requests.

Errors are referred to as comments in Xprog output, but require considerable care in the output program. The correct approach to handling errors is to determine the request that caused the error and remove them from the output program. This requires the output program to be buffered until it is certain that it will not generate an error. Another approach that is more faithful to the original session is to define error handlers in the output program that allow errors to occur but ignore them.

Some programs generate and handle errors. For example, AndrewToolkit attempts to open a named font. If the font does not exist, an error is generated by the X11 server. This error was caught and handled by the Andrew Toolkit and as a result it picks up the font instead of the one that does not exist. There are two aspects to this behavior. The first point is that the font used is the last font opened (the one that does not cause an error), so that the request generating the error can be removed from the output program for the correct behavior. The second aspect is that considering the timing issue, all requests and their subsequent errors should be included. That is, if a large number of error messages are generated, removing them will affect the timing characteristics of the output program. The current code has no provision for handling errors.

Events are the most difficult parts to generate in the output program of an interaction. If the Xprog output program is run without paying attention to the event, then typically no valid display operation is obtained. The output program starts, establishes a connection to the X11 server, creates windows, outputs to these windows, then X11
Exit by breaking the connection to the server, at which time the X11 server normally removes all references to this newly created window before it displays the window on the screen. At best, the user is Xpro
Only to see a momentary flicker on the screen while the g-output program is starting, running, and exiting almost immediately. This first use of the Xprog output program without event processing indicates that the event should be processed.

The event acts to pace the X11 program. For example, Expo as a result of a MapWindow event
The se event has the ability to synchronize client requests with the server's ability to do something with these requests. The time required for the user to move and click the mouse on the menu also gives the time required for the user to read the menu, and the "user interaction" time is the point of natural stop (or at least pause) for this program. give. A typical X11 client creates an initial display and then waits for user input (keyboard or mouse). The user input changes the display and waits for the next user input again. Thus, the X11 client alternates between the two phases. That is, alternating between waiting for user input and changing the display to respond to that input.
(This model ignores the fact that time is also another factor that often changes the display. This happens, for example, in a clock program that displays a clock on the display).

As a result of these considerations, it is conceivable to split the X11 event into two types: significant and minor events. Non-critical events include mouse movements, enter and exit notifications, and focus events. Insignificant events are simply discarded by Xprog. Key events include keyboard and mouse button input (user pacing events), and Expose
Events (X11 server pacing events) are included. X
Prog generates code that waits for significant events. Xpr
og generates a call to the WaitForEvent procedure for each significant event discovered during its communication session.

The WaitForEvent procedure has two parameters:
That is, it has two types: (i) event type to wait for, and (ii) prompt message. Prompt messages are written to inform the user console (stderr) of the type of message required by the user (when the event requires user input, such as pressing a mouse or keyboard button). Then,
Events are received until an event of the required type arrives. There is no pause when the requested event is already in the event queue. If the requested event is not in the event queue, then all other events are discarded until the event queue is empty, then the procedure waits. Sync events, such as Expose events from NapWindow requests, typically reside in the event queue and require no user action. User pacing events, such as mouse and keyboard input, are prompted with a message waiting for the requested user input.

Pseudo-events are used at the end of the program to prevent the display from disappearing before the user clearly indicates the end. This pseudo-event has a "Exit" prompt message and waits for a Button Press on the input device.

Finally, Xprog needs the same environment as the original client program had in order to execute. To the extent that client programs can use environmental characteristics that do not exist in other different environments, Xprog output is generally unable to handle altered display devices, or different sets of fonts. In addition to this, the order of input events is
Must match the order that occurred in the original client program.

While one preferred embodiment of the present invention has been described herein, the present invention is not limited to the exact same structures disclosed herein, but rather is set forth in the following claims. All changes and modifications that come within the scope of the invention are also claimed. The detailed definition for the X11 packet is shown below.

Protocol Encoding [Syntactic Conventions] All numbers are decimal unless a prefix of #x is given, and with this prefix is hexadecimal (base 16). is there. The general syntax used to describe requests, responses, errors, events and complex types is as follows: NameofThing Encoding Form (encode-form) ... Encoding Form (encode-form) Each Encoding Form Describes a single element. The elements are described in the protocol as follows: Name: TYPE The encoding format is as follows: N TYPE Name N is the number of bytes occupied in the data stream, TYPE
E is a translation of these bytes. For example: Depth: CARD8 becomes: 1 CARD8 Depth For elements with static numeric values, this encoding format is: N value name value always has N-byte sign. Translated as no integer. For example, the first two bytes of a window error are always 0 (indicating a general error) and 3 (indicating a window error specifically): 1 0 error 1 3 Within the protocol for code elements Is described as follows: Name {Name1 _... , NameI} This encoding format is as follows: The value is always translated as an N-byte unsigned integer. Note that the size of N is often larger than the exact size required to encode these values. For example, the class {InputOutput, InputOnly, CopyFromParent} is as follows: 2 Class 0 CopyFromParent 1 InputOutput 2 InputOnly elements are described in the protocol as follows: NAME: TYPEatAlternateAlternateAlternate. The format is as follows: N TYPE NAME value 1 Alternative 1 ... Value I Alternate I TYPE An alternative value is guaranteed so as not to conflict with the encoding of the TYPE. For example: Destination: WINDOW or PointerWindow
Or InputFocus is as follows. 4 WINDOW Destination 0 PointerWindow 1 InputFocus The elements are described in the protocol as follows: Value Mask: BITMASK The encoding format is as follows: N BITMASK Value Mask mask1 mask-name1 ... mask-maskI maskI. The individual bits in the mask are designated and named, and N is 2 or 4. The most significant bit in BITMASK is reserved for use in defining a chained (multi-word) bitmask as an extended augmented existing core request. The exact translation of this bit is not yet defined here. However, a possible mechanism is to indicate that 1-bit is followed by another N-byte bit mask, and the bits in the mask as a whole are translated from the least significant to the most significant in N-byte units. N byte units are translated in stream order, and the mask as a whole contains byte bytes within each N byte unit.
Swapped. For LISTofVALUE encoding, the request is followed by a section of the form:
List one coding format for ALUE: VALUES coding format ... Coding format NAME in each coding format corresponds to BITMA.
The key to the SK bit. VALUE is always 4
Occupies bytes, but the number of bytes specified in the encoded form indicates how many least significant bytes are actually used; the remaining bytes are unused and their value does not matter. In various cases, the number of bytes occupied by one element is specified by a single lowercase variable name, rather than by a particular number, and often other elements are represented by simple numeric expressions containing these variables. It has a specified value. Elements specified with such expressions are always translated as unsigned integers. The ranges for these variables are usually simply enclosure requests, responses, errors, events,
Alternatively, it is a composite byte. For example: 2 3 + n Request Length 4n LISTofPOINT Points For unused bytes (the value of this byte is undefined and does not matter), the encoding format is typically: N unused bytes When the number of is variable, the encoding format is typically as follows. p unused, p = pad (E) where E is some expression and pad (E) is E
Is the number of bytes required to round to a multiple of 4. pad (E) = (4- (Emod4)) mod4 [Common Types] LISTofFOO In this document, the notation LIST is strictly F.
Means a certain number of iterations of OO encoding; the actual length of the list is encoded elsewhere. SETofFOO One set is always represented by a bitmask, 1
-The bit indicates presence in the set. BITMASK: CARD32 WINDOW: CARD32 PIXMAP: CARD32 CURSOR: CARD32 FONT: CARD32 GCONTEXT: CARD32 COLORMAP: CARD32 bit 16: VAR8: CARD32 CODE: 8 bits: CARD32 CODE: 8 bits: CARD32 CODE: 8 bits: CARD32 CODE: 8 bits: CARD32 CODE: 8 bits: 8 bits: CARD 32 Integer 32: 32-bit signed integer CARD8: 8-bit unsigned integer CARD16: 16-bit unsigned integer CARD32: 32-bit unsigned integer TIMESTAMP: CARD32 BITGRAVITY 0 Forget 1 Northwest 2 North 3 NorthEast 5 Center 6 East 7 SouthWest 8 South 9 SouthEast 10 Static WINGRAVITY 0 Unmap 1 NorthWest 2 North 3 NorthEast 4 Wast 5 Center 6 East 7 SouthWest 8 South 9 SouthEast 10 Static BOOL 0 False 1 True SETofEVENT # x00000001 KeyPress # x00000002 KeyRelease # x00000004 ButtonPress # x00000008 Button Release # x00000010 EnterWindow # x00000020 LeaveWindow # x00000040 PointerMotion # x000 0080 PointerMotion
Hint # x00000100 Button1Motion # x00000200 Button2Motion # x00000400 Button3Motion # x00008000 Button5b000x000b000x000V000x0000p000x000E0000p000E000S000th000Motion # x0000000
nge # x00020,000 StructureNoti
fy # x00040000 ResizeRedirec
t # x00080000 SubstructureN
notify # x0010000 SubstructureR
direct # x00200000 FocusChange # x00400000 PropertyChange
e # x00800000 ColormapChange
e # x01000000 OwnerGrabButt
on # xfe000000 Not used but must be 0 The SETofPOINTEREVENT encoding is the same as SETofEVENT except: # xffff8003 Not used but must be 0 SETofDEVICEENT encoding is the same as SETofEVENT except in is: # xffffc0b0's not in use must be a 0 KEYSYM: CARA32 KEYCODE: CARD8 BUTTON: CARA8 SETofKEYBUTMASK # x0001 Shift # x0002 Lock # x0004 Control # x0008 Mod1 # x0010 Mod2 # x0020 Mod3 # x0040 Mod4 # x0080 Mod5 # x0100 Button1 # X02 0 Button2 # x0400 Button3 # x0800 Button4 # x1000 Button5 # xc000 but not used but must be 0 SETofKEYMASK coding, except for the following, SETofKEYBUTMA
Identical to SK: # xff00 Not used but must be 0 STRING8: LISTOfCARD8 STR16 LISTofCHAR2B CHAR2B 1 CARD8 BYTE1 1 CARD8 BY2 CONT2x16C2 ORD2 INT16T2AR2 16T2 2 1616 2R16T2 ORD16D2INT16G2 CONT16x2R1616D2INT16G2C16D2IN16D2INT16INT2INT16G2CT16L2 1616 2 2 16 16 2 2 16 16 2 2 16 ARC 2 INT16 x 2 INT16 y 2 CARD16 Width 2 CARD16 Height 2 INT16 Angle 1 2 INT16 Angle 2 HOST 1 Family 0 Internet 1 DECnet 2 Chaos 1 Not used 2 n Address length n LISTp by address Not used. (N) STR 1 Name in n bytes Length n STRING8 Name [ (Errors) Request 1 0 Error 1 1 code 2 CARD16 sequence number 4 not used 2 CARD16 small opcode 1 CARD8 large opcode 21 not used Value 1 0 Error 1 2 code 2 CARD16 sequence number 4 <32-bits> bad value CARD16 small opcode 1 CARD8 large opcode 21 not used Windows 10 0 Error 1 3 code 2 CARD16 number of sequences 4 CARD32 bad resource id 2 CARD16 small opcode 1 CARD8 large opcode 21 not used Pixmap 1 0 C16 UR2 C4D code 4 CORD 2 CARD Bad resource id 2 CARD16 Small opcode 1 CARD8 Large opcode 21 Not used Atom 10 Erro r 1 5 code 2 CARD16 sequence number 4 CARD32 bad atom id 2 CARD16 small opcode 1 CARD8 large opcode 21 not used Curser 1 0 Error 1 6 code 2 CARD16 sequence number 4 CARD32 bad resource id 2 CARD16 small opcode 1 large code 8 CARD Used Font 1 0 Error 1 7 Code 2 CARD16 Sequence number 4 CARD32 Bad resource id 2 CARD16 Small opcode 1 CARD8 Large opcode 21 Not used Match 1 0 Error 1 8 code 2 CARD16 Sequence number 4 Not used 2 CARD 16 large opcode Small CORD16 small opcode 21 Not Used Drawable 1 0 Error 1 9 Code 2 CARD16 Sike Number 4 CARD32 bad resource id 2 CARD16 small opcode 1 CARD8 large opcode 21 not used Access 1 0 Error 1 10 code 2 CARD16 sequence number 4 not used 2 CARD16 small opcode 1 CARD8 large opcode 21 not used Alloc 1 1 or 11 Er code 2 CARD16 Number of sequences 4 Not used 2 CARD16 Small opcode 1 CARD8 Large opcode 21 Not used Colormap 1 0 Error 1 12 code 2 CARD16 Number of sequences 4 CARD32 Bad resource id 2 CARD16 Small opcode 1 CARD8 Large opcode 21 r1 ortGcontex 13 code 2 CARD16 number of sequences 4 CARD32 bad resource id 2 CAR D16 Small opcode 1 CARD8 Large opcode 21 Not used IDChoice 1 0 Error 1 14 code 2 CARD16 Number of sequences 4 CARD32 Bad resource id 2 CARD16 Small opcode 1 CARD8 Large opcode 21 Not used Name 1 0 Error 4 COR 16 D 2 CARD 16 Code 2 Used 2 CARD16 Small opcode 1 CARD8 Large opcode 21 Not used Length 1 0 Error 1 16 code 2 CARD16 Number of sequences 4 Not used 2 CARD16 Small opcode 1 CARD8 Large opcode 21 Not used Implementation 1 0 Error 4 COR 1 16 Code 2 17 Code 2 Use 2 CARD16 Small opcode 1 CARD8 Large opcode 21 Use [Keyboard] KEYCODE value is always greater than 7 (less than 256). Bit # x10000000
KEYSYM with a set is reserved as a vendor designation. See Appendix F for the name and encoding of standard KEYSYM values.
Contained within. [Pointer] BUTTON is a string having a number of 1. [Predefined atom] (Predefined Atoms) PRIMARY 1 SECONDARY 2 ARC 3 ATOM 4 BITMAP 5 CARDINAL 6 COLORMAP 7 CURSOR 8 CUT - BUFFER0 9 CUT - BUFFER1 10 CUT - BUFFER2 11 CUT - BUFFER3 12 CUT - BUFFER4 13 CUT - BUFFER5 14 CUT _{- BUFFER6 15 CUT - BUFFER7 16 DRAWABLE} 17 FONT 18 INTEGER 19 PIXMAP 20 POINT 21 RECTANGLE 22 RESOURCE - MANAGER 23 RGB - COLOR - MAP 24 RGB - BEST - MAP 25 RGB - BLUE - MAP 26 RGB - DEFAULT - MA _{P 27 RGB - GRAY - MAP 28} RGB - GREEN - MAP 29 RGB - RED - MAP 30 STRING 31 VISUALID 32 WINDOW 33 WM - COMMAND 34 WM - HINTS 35 WM - CLIENT - MACHINE 36 WM - ICON - NAME 37 WM - ICON - _{SIZE 38 WM - NAME 39 WM -} NORMAL - HINTS 40 WM - SIZE - HINTS 41 WM - ZOOM - HINTS 42 MIN - SPACE 43 NORM - SPACE 44 MAX - SPACE 45 END - SPACE 46 SUPERSCRIPT - X 47 SUPERSCRIPT - Y 48 SUBSCRIPT - X 49 SUBSCRIPT _- Y 50 U _{NDERLINE - POSITION 51 UNBDERLINE - THICKNESS 52} STRIKEOUT - ASCENT 53 STRIKEOUT - DESCENT 54 ITALIC - ANGLE 55 X - HEIGHT 56 QUAD - WIDTH 57 WEIGHT 58 POINT - SIZE 59 RESOLUTION 60 COPYRIGHT 61 NOTICE 62 FONT - NAME 63 FAMILY - NAME 64 FULL - NAME 65 CAP _- HEIGHT 66 WM _- CLASS 67 WM _- TRANSENT-FOR 68 [Connection Setup] In a TCP connection, the display on any host is a numbered string beginning with 0 and the display N. To The corresponding server listens for and accepts connections on port 6000 + N. In a DEC Net connection, the display on any host is a string numbered from 0 and the server for display N is the object name obtained by chaining "XSX" with the decimal representation of N. , For example XSX0 and X
Listen for and accept the connection on SX1. The information sent by the client in setting up the connection is as follows. 1 byte order # x42 MSB first # x6C LSB first 1 Not used 2 CARD16 protocol large version 2 CARD16 protocol small version 2 n Allowed protocol name length 2 d Allowed protocol data length 2 Not used n STRING8 Allowed protocol name p not used, p = pad (n) d STRING8 admission protocol data q not used, q = pad (d) All 16-bit and 32-bit quantities sent by the client are specified unless explicitly indicated in the protocol. All 16-bits and 32-
The bit amount is transmitted in this byte order. The information received by the client when it is not authorized is as follows: 1 0 failure 1 length of reason in n bytes 2 CARD16 protocol large version 2 CARD16 protocol small version 2 (n + p) / 4 of additional data Length in units of 4 bytes n STRING8 Reason p Not used, p = pad (n) The information received by the client when permission is granted is as follows. 1 1 Success 1 Not used 2 CARD16 protocol large version 2 CARD16 protocol small version 2 8 + 2n + (v + p + m) / 4 Length of 4 bytes in additional data 4 CARD32 number of releases 4 CARD32 resource id base 4 CARD32 resource id mask 4 CARD32 motion Buffer size 2 v Vendor length 2 CARD16 Maximum required length 1 CARD8 Number of SCREEN in route 1 n Number of F FORMAT in pixel map format 1 Image byte order 0 LSB first 1 MSB first 1 Bitmap format view Order 0 LeastSignificant 1 MostSignificant 1 CARD8 Bitmap format Scan line unit 1 CARD8 Bitmap format Alignment pad 1 KEYCODE Minimum keyboard 1 KEYCODE Maximum keyboard 4 Not used v STRING8 Vendor p not used, p = pad (v) 8n LISTofFORMAT Pixel map format m LISTofSCREEN root (m is always a multiple of 4) CORD8DARMAT Bits Per Pixel 1 CARD8 Scan Line Pad 5 Not Used SCREEN 4 WINDOW Root 4 COLORMAP Default Color Map 4 CARD32 White Pixels 4 CARD32 Black Pixels 4 SETofEVENT Current Input Mask 2 CARD16 Pixel Width 2 CARD16 Pixel Height 2 CARD 2 CARD Millimeter unit width 2 CARD16 Millimeter unit height 2 CARD16 Minimum introduction map 2 CARD16 maximum introduction map VISUALID Visual Root 1 Support Memory 0 Never 1 WhenMapped 2 Always 1 BOOT Save-Lower 1 CARD8 Root Depth 1 CARD8 Number of Depths in Medium Depth n LISTofDEPTH 1 Depth of depth 8 (n is 4) Not used 2 n Number of VISUAL TYPE in visual 4 Not used 24 n LISTof VISUAL TYPE PE Visual VISUAL TYPE 4 Visual id 1 Class 0 Static Gray 1 Cray rg sr Cor 2 C ur s s s s s s s s s s s s s s s s s 2 s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s 4 s s s s s s s s t s s s s s s s s s s s s s s s s s s s s s s s sssssssss | 4 CARD32 green mask 4 CARD32 blue mask 4 not used

[Requests] CreateWindow 1 1 Opcode 1 CARD8 Depth 2 8 + n Required Length 4 WINDOW wid 4 WINDOW Parent 2 INT16 x 2 INT16 y 2 CARD16 Width 2 CARD16 Height 2 CARD16 O2CARD16 O2CARD16 O2CARD16 Height 2 CARD16 O2CARD16 Height 2 CARD16 O2CARD16 O2 4 VISUALID Visual 0 CopyFromParent 4 BITMASK Visual Mask (with n bits set to 1) # x00000001 Background-Pixel Map # x00000002 Background-Pixel # x0000004 Boundary-Pixel Map # x00000008 Boundary-Pixel # x00000010 Bit-Gravity 20 Gravity -Gravity # x0 0000040 Supporting memory # x00000080 Supporting plane # x0000100 Supporting pixel # x00000200 Override-redirection # x00000400 Save-Down # x00000080 Event-Mask # x00001000 Non-propagable mask # x00002000 Color map # x00002000 Pixel background 4x LISTofPIVALEM value background 4 List of values 0 None 1 ParentRelative 4 CARD 32 Background-Pixel 4 PIXMAP Boundary-Pixel Map 0 CopyFromParent 4 CARD 32 Boundary-Pixel 1 BITGRAVITY Bit Gravity 1 WINGRAVITY 2 winGravity 1 No Memory 1 Support Memory Always 4 CARD32 Support-Plane 4 CARD32 Support-Pixel 1 BOOL Override-Redirect 1 BOOL Save Under 4 SETofEVENT 2 Op + Even 2COR not Cour Pour 0 COR POINT 0 COR 32 COLOR MAP COR COLOR MAP 4 COLORMAP COR MAP FOR 0 COR MAP COLOR MAP 0 COUNT Request Length 4 WINDOW Window 4 BITMASK Value Mask (with n bits set to 1) The encoding is the same as for CreateWindow.  4n LISTofVALUE Value List Encoding is the same as for CreateWindow.  GetWindowAttributes 1 3 Opcode 1 Not Used 2 2 Requested Length 4 WINDOW Window => 1 1 Reply 1 Assisted Memory 0 NotUseful 1 What Map IT 2 Inp 1 O 2 Inp 2 A 1 Ins 2 O 4 Ins 2 CARD 16 2 Inp 1 O 2 Ins 2 CARD 16 Ins 2 U 4 ID 3 V ID 4 Ins 2 CARD 16 Ins 2 C ID 16 4 U 3 ID 4 4 U ID 4 4 U ID 4 Sequence 4 U ID 4 4 U ID 4 Sequences Gravity 1 WINGRAVITY win Gravity 4 CARD32 Support Plane 4 CARD32 Support Pixel 1 BOOT Save under 1 OOL Map is built in 1 Map state 0 Unmapped 1 COO NE Mapo Unoable 2 Unviewable 4 Unviewable 4 Uncharted 0 NT All Event Mask 4 SETofEVENT Your Event Mask 2 SETofDEVICEEVENT Non Propagable Mask 2 Not Used DestroyWindow 1 4 Opcode 1 Not Used 2 2 Requested Length 4 WINDOW Window 1 d s Wed 2 S 1 Wed 2 W 1 Wed 5 S 2 Ops Coded 6 Opcode 1 Mode 0 Insert 1 Delete 2 2 Request Length 4 WINDOW Window ReparentWindow 1 7 Opcode 1 Not Used 2 4 Request Length 4 WINDOW Window 4 WINDOW Parent 2 INT16 x 2 INT16 y 2 No Request 1 Map8 Length 4 WINDOW Window Map ubwindows 1 9 opcode 1 not used 2 2 requested length 4 WINDOW window Unmapwindow 1 10 opcode 1 not used 2 2 requested length 4 WINDOW window UnmapSubwindow ig 1 won 2 WDO 2 WIN Wd 2 CW window required Not used 2 3 + n Request length 4 WINDOW window 2 BITMASK value mask (with n bits set to 1) # x0001 x # x0002 y # x0004 width # x0008 height # x0010 border width # x0020 sibling # x0040 stack mode 2 Not used 4n LISTofVALUE value list VALUEs 2 INT16 x 2 INT16 y 2 CARD 6 Width 2 CARD16 Height 2 CARD16 Boundary Width 4 WINDOW 1 Brother Mode 1 Stack Mode 0 Above 1 Bellow 2 Toplf 3 Bottomlf 4 Opposite Draw 1 Gour 2 Width 1 W 4 Width 1 W 2 Width 1 Width 2 Width 1 Width 1 Width 2 Width 1 Width 2 Width 1 Width 2 Width 1 Width 1 Width 2 Width 1 Width 2 Width 1 Width 2 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 1 Width 2 Use 2 2 Requested length 4 DRAWABLE Drawable => 1 1 Reply 1 CARD8 Depth 2 CARD16 Number of sequences 4 0 Response length 4 WINDOW Route 2 INT16 x 2 INT16 y 2 CARD16 Width 2 CARD16 Height 2 Width 10 CARD16 Used QueryTree 1 15 Opcode 1 Not used 2 2 Request Length 4 WINDOW Window => 1 1 Reply 1 Not used 2 CARD16 Number of sequences 4 n Response length 4 WINDOW Root 4 WINDOW Parent 0 None 2 n Number of fWINDOWs in child 14 Not used 4n LISTof WIndOl WINDOWO code 16 n Not used only-if-exists 2 2+ (n + p) / 4 Required length 2 n Name length 2 Not used n STRING8 Name p Not used, p = pad (n) => 1 1 Reply 1 Not used 2 CARD16 Number of sequences 4 0 Response length 4 ATOM atom 0 None 20 Not used GetAtomName 1 17 Opcode 1 Not used 2 2 Requested length 4 ATOM atom => 1 1 Reply 1 Not used 2 CARD16 Number of sequences 4 (n + p) / 4 Response length 2 n Name length 22 Not used n STRING8 Name p Not used, p = pad (n) ChangeProperty 1 18 Opcode 1 Mode 0 Replace 1 Prepend 2 Append 2 6+ (n + p) / 4 Request length 4 WINDOW window 4 ATOM characteristic 4 ATOM type 1 C32 format C 3D AR D format 3 AR 3 Length (n for format = 8) (n / 2 for format = 16) (n / 4 for format = 32) n LISTofBYTE data (n is a multiple of 2 for format = 16) (n is format = 32 Is a multiple of 4) p Not used, p = pad (n) DeleteProperty 1 19 Opcode 1 Not used 2 3 Request length 4 WINDOW window 4 ATOM characteristic GetProperty 1 20 Opcode 1 BOOL Delete 2 6 Request length 4 WINDOW window 4 4 ATO characteristic 4 WINDOW window 4 4ATO characteristic 4 WINDOW window 4 ATO characteristic 4 WINDOW window 4 ATO characteristic Offset 4 CARD32 long length => 1 1 Reply 1 CARD8 format 2 CARD16 number of sequences 4 (n + p) / 4 response length 4 ATOM type 0 None 4 CARD32 after byte 4 length value in CARD32 format unit (format = 0 to (= 0) (for format = 8 = n) (for format = 16 = n / 2) (for format = 32) n / 4) 12 n to nonuse n LISTofBYTE value (format = 0 0) (multiples of n to format = 16 2) (multiples of relative format = 32 n is 4) p unused, p-pad (n) ListProperties 1 21 Opcode 1 Not used 2 2 Required length 4 WINDOW window => 1 1 Reply 1 Not used 2 CARD16 Number of sequences 4 n Response length 2 n Number of ATOM in atom 22 Not used 4n LISTofATOM atom SetSelectionOwner 1 22 Opcode 1 Not used 2 4 Requested length 4 WINDOW Owner 0 None 4 ATOM selected 4 TIMESTAMP time 0 CurrentTime Get 1p 1 1 2 Not used 1 2 Not used 1 opted 1 2 Not requested. 2 CARD16 Number of sequences 4 0 Response length 4 WINDOW Owner 0 None 20 Not used ConvertSel ction 1 24 Opcode 1 Not used 2 6 Request length 4 WINDOW Requester 4 ATOM selection 4 ATOM Target 4 ATOM Characteristics 0 None 4 TIMESTAMP Time 0 CurrentTime in Wo W in W 0 W 0 W 1 W 0 W ID W 2 W 11 W 0 W 1 W 11 W 0 W 1 W 11 W 11 W 11 InputFocus 4 SETofEVENT Event Mask 32 Event Standard Event Format (see Events section) GrabPointer 1 26 Opcode 1 BOOT Owner Event 2 6 Request Length 4 WINDOW Won claw window 2 SET of POINTEREVEN ch n oS Point of Mask 0 event 0 0 hronous 1 Asynchronous 4 WINDOW limit 0 None 4 CURSOR cursor 0 None 4 TIMESTAMP Time 0 CurrentTime => 1 1 Reply 1 Status 0 Success 1 AlreadyGrabbed 2 InvalidTime 3 NotViewable 4 Frozen 2 CARD16 sequence number 4 0 response length 24 nonuse UngrabPointer 1 27 Opcode 1 Not Used 2 2 Request Length 4 TIMESTAMP Time 0 CurrentTime GrabButton 1 28 Opcode 1 OOL Owner Event 2 6 Request Length 4 WINDOW Understanding Window 2 SETofPOINTEREVENT Event Mask 1 Pointer Mode 0 Synch nous 1 Asynchronous 1 keyboard mode 0 Synchronous 1 Asynchronous 4 WINDOW limit 0 None 4 CURSOR cursor 0 None 1 BUTTON button 0 AnyButton 1 Not used 2 SETofKEYMASK qualifier # x8000 AnyModifier UngrabButton 1 29 opcode 1 BUTTON button 0 AnyButton 2 3 request length 4 WINDOW grasp window 2 SETofKEYMASK qualifier # x8000 AnyModifier 2 not used ChangeActivePointerGrab 1 30 opcode 1 not used 2 4 request length 4 cursor cursor 0 none 4 time cursor time ntTime 2 SETofPOINTEREVENT event mask 2 unused GrabKeyboard 1 31 opcode 1 BOOL owner events 2 4 required length 4 WINDOW grasp window 4 TIMESTAMP time 0 CurrentTime 1 pointer mode 0 Synchronous 1 Asynchronous 1 keyboard mode 0 Synchronous 1 Asynchronous 2 Not used => 1 1 Reply 1 Status 0 Success 1 AlreadyGrabbed 2 InvalidTime 3 NotViewable 4 Frozen 2 CARD16 Number of Sequences 4 0 Response Length 24 Not Used UngrabKeyboard 2 S 1 Request 2 Not Used 1 32 Not Required TAMP time 0 CurrentTime GrabKey 1 33 opcode 1 BOOL owner events 2 4 request length 4 WINDOW grasp window 2 SETofKEYMASK qualifier # x8000 AnyModifier 1 KEYCODE key 0 AnyKey 1 pointer mode 0 Synchronous 1 Asynchronous 1 keyboard mode 0 Synchronous 1 Asynchronous 3 non-use UngrabKey 1 34 opcode 1 KEYCODE key 0 AnyKey 2 3 required length 4 WINDOW grasp window 2 SETofKEYMASK modifier # x8000 AnyModifier 1 mode 0 opcodes 1 35 opcode 1 35 opcode 1 ter 1 SynchPointer 2 ReplayPointer 3 AsyncKeyboard 4 SyncKeyboard 5 ReplayKeyboard 6 AsyncBoth 7 SyncBoth 2 2 required length 4 TIMESATMP time 0 CurrentTime GrabServer 1 36 opcode 1 Not used 2 1 request length UngrabServer 1 37 opcode 1 Not used 2 1 request length QueryPointer 1 38 Opcode 1 Not Used 2 2 Request Length 4 WINDOW Window => 1 1 Reply 1 BOOT Same Screen 2 CARD16 Sequence Number 4 0 Response Length 4 WINDOW Route 4 WINDOW Child 0 None 2 INT16 Route x 2 INT16 Route T16 winx 2 INT16 winy 2 SETofKEYBUTMASK mask 6 nonuse GetMotionEvents 1 39 opcode 1 Not used 2 4 required length 4 WINDOW window 4 TIMESTAMP Start 0 CurrentTime 4 TIMESTAMP stop 0 CurrentTime => 1 1 Reply 1 Not used 2 CARD16 sequence number 4 2n Response length 4 n Number of TIMECOOR Ds in event 20 Not used 8n LISTofTIMECOORD Event TIMECOORD 4 TIMESTAMP Time 2 CARD16 x 2 CARD16 y TranslateCoordinates 1 40 opcode 4 W 4 c W DO W1 W2 IN W2 W2 W2 DOW dst window 2 INT16 src-x 2 INT16 src-y => 1 1 Reply 1 OOL same screen 2 CARD16 sequence number 4 0 response length 4 WINDOW child 0 None 2 INT16 dst-x2 wyp16 not used 1 41 Opcode 1 Not used 2 6 Requested length 4 WINDOW src window 0 None 4 WINDOW dst window 0 None 2 INT16 src-x 2 INT16 src-y 2 CARD16 src 16d 2st 16t 2d 16-dst 16 2d -Y SetlnputFocus 1 42 Opcode 1 Inversion 0 None 1 PointerRoot 2 Parent 2 3 Requested length 4 WINDOW Focus 0 None 1 PointerRoot 4 TIMESTAMP Time 0 CurrentTime GetlnputFocus 1 43 Opcode 1 Not Used 2 1 Requested Length => 1 1 1 Wn OW 0 Won 4 Wo 1 Point 4o Point 2o Ron 4 Point 0 Reply 1 PointerRoot 20 Not used QueryKeymap 1 44 Opcode 1 Not used 2 1 Required length => 1 1 Reply 1 Not used 2 CARD16 Number of sequences 4 2 Response length 32 LISTofCARD8 Key 2+ Opn + 1 45 Not used 1 45 Not used 4 Required length 4 FONT fid 2 n Name length 2 Not used n ST ING8 name p non-use, p = pad (n) CloseFont 1 46 Opcode 1 Not used 2 2 Requested length 4 FONT font QueryFont 1 47 Opcode 1 Not used 2 2 Requested length 4 FONTABLE font => 1 1 Reply 1 Not used 2 CARD 16 + 2 n Response length 12 CHARINFO Minimum boundary 4 Not used 12 CHARINFO Maximum boundary 4 Not used 2 CARD16 Minimum character or byte 2 2 CARD16 Maximum character or byte 2 2 CARD16 Character omission 2 n Number of FONTPROP in the characteristic 1 Drawing direction 0 LeftToRightRight1 1 CARD8 Minimum byte 1 1 CARD8 Maximum byte 1 1 OOL All characters present 2 INT16 font up 2 INT16 font down m char number of charinfo in infos 8n LISTofFONTPROP characteristics 12m LISTofCHARINFO char-infos FONTPROP 4 ATOM name 4 <32-bits> value charinfo 2 INT16 left bearings 2 INT16 right bearing 2 INT16 character width 2 INT16 rise 2 INT16 falling 2 CARD16 attribute QueryTaxExtents 1 48 Opcode 1 OOL Odd length, True if P = 2 2 2+ (2n + p) / 4 Required length 4 FONTABLE font 2n STRING16 string p Not used, p = pad (2n) => 1 1 Reply 1 drawing direction 0 LeftToRight 1 RightToLeleft 2 CARD16 number of sequences 4 0 response length 2 INT16 font increase 2 INT16 font increase 2 INT16 overall increase 2 INT4 IN 32 overall INT 4 INT 32 IN16 Left 4 INT32 Entire right 4 Not used ListFonts 1 49 Opcode 1 Not used 2 2+ (n + p) / 4 Required length 2 CARD16 Maximum name 2 n Pattern length n SSTRING8 Pattern p Not used, p = pad (n) => 1 1 Reply 1 not used 2 CARD16 number of sequences 4 (n + p) / 4 response length 2 number of STRs in CARD16 name 22 not used n LISTofSTR name p not used, p = pad (n) ListFontsWithlnfo 1 50 Opcode 1 Not used 2 2+ (n + p) / 4 Required length 2 CARD16 Maximum name 2 n Pattern length n STRING8 Pattern p Not used, p = pad (n) => (excluding the latest in the series) 1 1 Reply 1 n Name in bytes Length 2 CARD16 Number of sequences 4 7 + 2m + (n + p) / 4 Response length 12 CHARINFO Minimum boundary 4 Not used 12 CHARINFO Maximum boundary 4 Not used 2 CARD16 Minimum character or byte 2 2 CARD16 Maximum character or byte 2 2 CARD16 Character omission 2 m Number of FONTPROP in the characteristic 1 Drawing direction 0 LeftToRight 1 RightToLeft 1 CARD8 Minimum byte 1 Maximum byte 1 CARD8 Boolean All characters present 2 INT16 font up 2 INT16 font down 4 CARD32 Response hint 8m LISTofFONTPROP Characteristic n STRING8 Name p Not used, p = pad (n) FONTPROP encoding is the same as in QueryFont CHARINFO encoding is the same as in QueryFont => (latest in series) 1 1 Reply 1 0 Latest response indicator 2 CARD16 Sequence number 4 7 Response length 52 Not used SetFontPath 1 51 Opcode 1 Not used 2 2+ (n + p) / 4 Requested length 2 CARD16 Number of STRs in path 2 Not used n LISTofSTR Path p Not used, p = pad (n) GetFontPath 1 52 Opcode 1 Not used 2 1 Request list => 1 1 Reply 1 Not used 2 CARD16 Number of sequences 4 (n + p) / 4 Response length 2 CARD16 Number of STRs in path 22 Not used n LISTofSTR path p not used, p = pad (n) CreatePixmap 1 53 opcode 1 CARD8 depth 2 4 required length 4 PIXMAP page identifier 4 DRAWABLE drawable 2 CARD16 width 2 CARD16 height FreePixmap 1 pixel opcode length X 2 AP 2 no request 2 CreateGC 1 55 Opcode 1 Not Used 2 4 + n Required Length 4 GCONTEXT cid 4 DRAWABLE Drawable 4 BITMASK Value Mask (with n bits set to 1) # x0000001 Function # x0000001 Function # x0000001 Plain Foreground # x000000004 Foreground # x00004 Width # x00000020 Line style # x00000040 cap style # x000 0080 join style # x00000100 fill style # x00000200 fill rule # x00000400 Title # x00004000 Stipple # x00001000 Tile-stipple-x origin # x00002000 Tile-stipple-y origin # x00004000 Font # x00008000 Sub window mode # x00000000 Origin of graphics # x00000000 Graphic presentation # X00040000 y Clip origin point # x00080000 Clip mask # x0010000 Dash offset # x00200000 Dash # x00400000 arc mode 4n LISTofVALUE value list VALUEs 1 Function 0 Clear 1 And 2 AndReverse 3 Cop y 4 AndInverted 5 NoOp 6 Xor 7 Or 8 Nor 9 Equiv 10 Invert 11 OrReverse 12 CopyInverted 13 OrInverted 14 Nand 15 Set 4 CARD32 planemasks 4 CARD32 foreground 4 CARD32 background 2 CARD16 line width 1 line styles 0 Solid 1 OnOffDash 2 DoubleDash 1 cap Style 0 NotLast 1 Butt 2 Round 3 Projecting 1 join Style 0 Miter 1 Round 2 Bevel 1 fill Style 0 Solid 1 Tiled 2 Striped Extended 3 OpaqueStippled 0 1 Ittle 4 PIXMAP Stippling 2 INT16 Title-Stipple-x Origin 2 INT16 Title-Stipple-y Origin 4 FONT Font 1 Sub-window Mode 0 ClipByChildren 1 IncludeInferiors 1 BOOL Graphic Presentation 2 INT16 xAP Clip 4 Origin Clip Clip 2 INT16 Origin Clip Clip 2 INT 16 0 None 2 CARD16 Dash offset 1 CARD8 Dash 1 arc mode 0 Chord 1 PieSlice ChangeGC 1 56 Opcode 1 Not used 2 3 + n Requested length 4 GCONTEXT gc 4 BITMASK Value mask is set to C bit value C (recoded) C is set to bitCnC bit. 4n LISTofVALUE encoding same as Same as in CreateGC CopyGC 1 57 Opcode 1 Not used 2 4 Requested length 4 GCONTEXT src-gc 4 GCONTEXT dst-gc 4 BITMASK value mask Coding is same as in CreateGC 1st option Not used 58 SetDash 2 3+ (n + p) / 4 request length 4 GCONTEXT gc 2 CARD16 dash offset 2 n dash length n LISTofCARDS dash p not used, p = pad (n) SetClipRectangles 1 59 Opcode 1 Sequence 0 UnSorted 1 YSorted 2 YXSorted 3 YXBanded 2 3 + 2n Requested length 4 G CONTEXT Gc 2 INT fL IN 16 L 8 IN 16 L 2 IN 16 IN 2 IN 16 L 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN 2 IN 16 IN IN 2 IN 16 IN G IN 2 IN 16 L IN 16 L IN 16 IN 2 IN 16 L IN 16 L IN CH IN CONTINUE GLIN GLIN. 2 2 Request Length 4 GCONTEXT gc ClearArea 1 61 Opcode 1 Boolean Presentation 2 4 Request Length 4 WINDOW Window 2 INT16 x 2 INT16 y 2 CARD16 Width 2 CARD16 Height 2A DRA 7 A Request Code 7 Area 2 W DRA 7 A Request Code 4 A src drawable 4 DRAWABLE dst drawable 4 GCONTEXT gc 2 INT16 src-x 2 INT16 src-y 2 INT16 dst-x 2 INT16 dst-y 2 CARD16 Width 2 CARD16 Height CopyPlane 1 63 Opcode 1 Not used 2 8 Required length 4 WDR AWR 4 A DR 4 A DRA WA Possible 4 GCONTEXT gc2 INT16 src-x2 INT16 src-y2 INT16 dst-x2 INT16 dst-y2 CARD16 width 2 CARD16 height 4 CARD32 bitplane PolyPoint 1 64 in op 1 Ori code 0 coordinate 1 Ori code O coordinates 1 4 Drawable 4 GCONTEXT gc 4n LISTofPOINT Point PolyL ine 1 65 opcode 1 coordinate mode 0 Origin 1 Previous 2 3 + n required length 4 Drawable drawable 4 GCONTEXT gc 4n LISTofPOINT point PolySegment 1 66 opcode 1 Not used 2 3 + 2n request length 4 Drawable drawable 4 GCONTEXT gc 8n LISTofSEGMENT segments SEGMENT 2 INT16 x1 2 INT16 y1 2 INT16 x2 2 INT16 y2 PolyRectangle 1 67 Opcode 1 Not used 2 3 + 2n Requested length 4 DRAWABLE Drawable 4 GCON CONT 3 G4 8G L CONT ACT not used Gc 8n LISTyc R2G1 8n LISTofc LE drawable 4 GCONTEXT gc 12n LISTofARC arcs FillPoly 1 69 opcode 1 Not used 2 4 + n required length 4 Drawable drawable 4 GContext gc 1 Form 0 Complex 1 Nonconvex 2 Convex 1 coordinate mode 0 Origin 1 Previous 2 unused 4n LISTofPOINT point PolyFillRectangle 1 70 Opcode 1 Not Used 2 3 + 2n Required Length 4 DRABLE Drawable 4 GCONTEXT gc 8n LISTofRECTANGLE Rectangle PolyFillArc 1 71 s Opcode 1 Not Used 2 3 + 3n Required Length 4G 4Cn L 4G 4N CONT 4G RAW 4G Drawable utlmap 1 72 opcode 1 format 0 Bitmap 1 XYPixmap 2 ZPixmap 2 6+ (n + p) / 4 requested length 4 DRAWABLE drawable 4 GCONXT pad 2 C1D 16 16 d 2 CARD 16 width 2 CORD 16 d 2 CARD 16 high 2 CORD 16 d 2 CIND 16 high 2 CORD 16 high 2 CORD 16 high 1 CARD8 depth 2 not used n LISTofBYTE data p not used, p = pad (n) Getlimage 1 73 opcode 1 format 1 XYPixmap 2 ZPixmap 2 5 request length 4 DRAWABLE drawable 2 INT16 x 2 INT16 y 2 CARD16 width 2 CARD16 Re 8 plane 1 CORD16 height 4 CARD 16 width 2 CARD 16 height 1 CARD 16 height 4 CARD 16 2 CARD16 Number of sequences 4 (n + p) / 4 Response length 4 VISUALID Visual 0 None 20 Not used n LISTofBYTE data p Not used, p = pad (n) PolyText8 1 74 Opcode 1 Not used 2 4+ (n + p) / 4 Required length 4 DRAWABLE drawable 4 GCONTEXT gc 2 INT16 x 2 INT16 y n LISTofTEXTITEM 8 Item not used p = pad (n) (p is always 0 or 1) TEXTITEM8 1 n string length (cannot be 255) 1 INT8 delta n STRING8 string or 1 255 font shift indicator 1 font byte 3 (most significant) 1 Font byte 2 1 Font byte 1 1 Font byte 0 (lowest) PolyText16 1 75 Opcode 1 Not used 2 4+ (n + p) / 4 Requested length 4 DRAWABLE Drawable 4 GCONTEXT gc 2 INT16 x 2 INT16 EMn LIST LISTo Not used, p = pad (n) (p is always 0 or 1) TEXTITEM 16 1 n number of CHAR2Bs in the string (cannot be 255) 1 INT8 delta n STRING16 string or 1 255 font indicator 1 font byte 3 (most significant) ) 1 font byte 2 1 font byte 1 1 font byte 0 (least significant) ImageText8 1 76 opcode 1 n string length 2 4+ (n + p) / 4 required length 4 DRAWABLE drawable 4 GCONTEXT gc 2 INT16 x 2 INT16 STRING8 string p not used, p = pad (n) ImageText16 1 77 opcode 1 n number of CHAR2Bs in string 2 4+ (2n + p) / 4 required length 4 DRAWABLE drawable 4 GCONTEXT gc 2 INT16 x 2 INT16 IN 16 G 2 not used p = pad (2n) CreateColormap 1 78 opcode 1 alloc 0 None 1 All 2 4 request length 4 COLORMAP mid 4 WINDOW window 4 VISUALID visual 80 cm pOR cop 1 CO 2 APor COp 1 CO 2 mapp 1 CO 2 CORMAP 1 CO 2 AP 1 CO 2 COP 1 CO 2 COP 1 CO 2 COP 1 CO 2 AP 1 CO 2 COP 1 CO 2 COP 1 CO 2 COP 1 CO 2 COP 1 CO 2 COP COLORMAP 1 CO 2 COP 1 CO 2 COP 1 CO 2 COP 1 CO 2 COP COLORMAP 1 CO 2 COP 1 CO 2 MAP Not used 2 3 Requested length 4 COLORMAP mid 4 COLORMAP src-cmap InstallColormap 1 81 Opcode 1 Not used 2 2 Requested length 4 COLORMAP cmap Unstall COMPorm COL 2 COL map LOR 2 Not required 1 Opcode 1 Not used aps 1 83 Opcode 1 Not used 2 2 Request length 4 WINDOW window => 1 1 1 Reply 1 Not used 2 CARD16 Number of sequences 4 n Response length 2 n Number of COLORMAPs in n cmap 22 Not used 4n LISTofCOLORMAPclC cma cm 1 not used 2 4 requested length 4 COLORMAP cmap 2 CARD16 red 2 CARD16 green 2 CARD16 blue 2 not used => 1 1 Reply 1 not used 2 CARD16 number of sequences 4 0 response length 2 CARD16 red 2 CARD16 green 2 CARD16 blue 2 Not used 4 CARD 32 pixels 12 Not used AllocNamedColor 1 85 Opcode 1 Not used 2 3+ (n + p) / 4 Required length 4 COLORMA cmap 2 n name length 2 nonuse n String8 name p nonuse, p = pad (n) => 1 1 Reply 1 not used 2 CARD16 number of sequences 4 0 response length 4 CARD32 pixels 2 CARD16 accurate red 2 CARD16 accurate green 2 CARD16 accurate blue 2 CARD16 visual red 2 CARD16 visual Top green 2 CARD16 Visual blue 8 Not used AllocColorCells 1 86 Opcode 1 OOL Contact 2 3 Required length 4 COLORMAP cmap 2 CARD 16 colors 2 CARD16 plane => 1 1 Reply 1 Not used 2 C4 m + sequence 4 CARD16 Number of CARD32 in 2 n pixels 2 m Number of CARD32 in mask 20 Not used 4n LISTofCARD32 pixel 4 m LISTofCARD32 mask AllocColorPlane 1 87 opcode 1 BOOL contact 2 4 required length 4 COLORMAP cmap 2 CARD16 color 2 CARD16 red 2 CARD16 green 2 CARD16 blue => 1 1 Reply 1 not used 2 CARD16 number of sequences 4 n response length 2 nD of 32 n pixels Number 2 Not used 4 CARD32 Red mask 4 CARD32 Green mask 4 CARD32 Blue mask 8 Not used 4n LISTofCARD32 Pixel FreeColors 1 88 Opcode 1 Not used 2 3 + n Required length 4 4 Pixels Corp CORp CORD CORD 32L CORP 32 CORD 4 CARD 32 Cor 4 CARD 32 Cord 32 Corp CORD 3 Cn 4 CORD 32 Use 2 2 + 3n Required length 4 COLORMAP cmap 12n LISTofCOLORIT M item COLORITEM 4 CARD32 pixels 2 CARD16 red 2 CARD16 Green 2 CARD16 blue 1 do- red, do-green, do-blue # x01 do-red (1 is true, 0 is false # x02 do-green (1 is true, 0 is false # x04 do-blue (1 is true, 0 is false) # xf8 Not used 1 Not used StoreNamedColor 1 90 Opcode 1 do-red, do-green, do-blue # x01 do-red (1 is true, 0 is false # x02 do-green (1 is true, 0 is false # x04 do-blue (1 is true, 0 is false) # xf8 Not used 2 4+ (n + p) / 4 Required length 4 COLORMAP cmap 4 CARD32 Pixel 2 n Name length 2 Not used n STRING8 Name p Not used, p = pad (n) QueryColors 1 91 Opcode 1 Not used 2 2 + n Required length 4 COLORMAP cmap 4n LISTofCARD32 pixels => 1 1 Reply 1 Not used 2 CARD 16 Number of sequences 4 2n 22 colors of color 2 2n Not used 8n LISTofRGB Color RGB 2 CARD16 Red 2 CARD16 Green 2 CARD16 Blue 2 Not used LookupColor 1 92 Opcode 1 Not used 2 3+ (n + p) / 4 Required length 4 COLORMAP cmap 2 n Name Length 2 Not used RIN Nn Not used, p = pad (n) => 1 1 Reply 1 not used 2 CARD16 number of sequences 4 0 response length 2 CARD16 exact red 2 CARD16 exact green 2 CARD16 exact blue 2 CARD16 visual red 2 CARD16 visual green 2 CARD16 Visual blue 12 Not used CreateCursor 1 93 Opcode 1 Not used 2 8 Response length 4 CURSOR cid 4 PIXMAP source 4 PIXMAP Mask 0 None 2 CARD16 Before-Red 2 CARD16 Before-Green 2 CARD16 Before-Blue 2 CARD -Red 2 CARD16 rear-Green 2 CARD16 rear-blue 2 CARD16 x 2 CARD16 y CreateGlyphCursor 1 94 CreateGlyph-Cursor 1 Not used 2 8 Required length 4 CURSOR cid 4 FONT source font 4 FONT mask font 0 None 2 CARD16 source character 2 CARD16 mask character 2 CARD16 front-red 2 CARD16 front-green 2 CARD16 front-blue 2 CARD16 rear-red 2 CARD16 rear-green 2 CARD16 rear-blue Freecursor 1 95 Opcode 1 Not used 2 2 Requested length 4 CURSOR cursor RecolorCursor 1 96 Opcode 1 not used 2 5 Requested length 4 CURSOR cursor 2 CARD 16 Before-red 2 CARD 16 Before-green 2 CARD 16 Before-blue 2 CARD 16 2 CARD16 Rear-Green 2 CARD16 Rear-Blue QueryBestSize 1 97 Opcode 1 Class 0 Curser 1 Tile 2 Sti ple 2 3 Required length 4 DRAWABLE Drawable 2 CARD16 Width 2 CARD16 Height => 1 1 Reply 1 Not used 2 CARD16 Number of sequences 4 0 Response length 2 CARD16 Width 2 CARD16 Height 20 Not used QueryExtension 1 Not used Query1 Used 2 2+ (n + p) / 4 Required length 2 n Name length 2 Not used n STRING8 Name p Not used => 1 1 Reply 1 Not used 2 CARD16 Sequence number 4 0 Response length 1 BOOL Present 1 CARD8 Large opcode 1 CARD8 First Event 1 CARD8 First Error 20 Not Used ListExtensions 1 99 Opcode 1 Not Used 2 1 Required Length => 1 1 Reply 1 CARD8 Number of STRs in Name 2 CARD16 Number of sequences 4 (n + p) / 4 Response length 24 Not used n LISTofSTR Name p Not used ChangeKeyboardMapping 1 100 Opcode 1 n Key code count 2 2 + nm Required length 1 KEYCODE 1 m 2 m Key code 1 m 2y per key code Used 4nm LISTofKEYSYMY keysyms GetKeyboardMapping 1 101 Opcode 1 Not used 2 2 Requested length 1 KEYCODE 1st key code 1 CARD8 Count 2 Not used => 1 1 Reply 1 Cry 4 Cy 1 keyy C key code 1D Reply 1 CRY8 key 2 Keys keyed m = count field from request) 24 not used 4nm LISTofKEYSYM keysyms ChangeK yboardControl 1 102 Opcode 1 Not used 2 2 + n Request Length 4 BITMASK Value Mask (with n bits set to 1) # x0001 Key Click Percentage # x0002 Bell Percentage # x0004 Bell Pitch # x0008 Bell Duration # x0010 led # x0020 led mode # X0040 Key # x0080 Auto Repeat Mode 4n LISTofVALUE Value List VALUEs 1 INT8 Key Click Percentage 1 INT8 Bell Percentage 2 INT16 Bell Pitch 2 INT16 Bell Period 1 CARD8 led 1 led Mode 0 Off 1 On 1 KEY Off Code 1 2 Default GetKeyboardControl 1 103 Opcode 1 Not used 2 1 Required length => 1 1 1 Reply 1 Global auto repeat 0 Off 1 On 2 CARD16 Number of sequences 4 5 Response length 4 CARD32 led mask 1 CARD8 key click percentage 1 CARD8 bell percentage 2 CARD16 bell pitch 2 CARD16 bell Period 2 Not used 32 LISTofCARD8 Auto-repeat Bell 1 104 Opcode 1 INT8 Percent 2 1 Request length ChangePointerControl 1 105 Opcode 1 Not used 2 3 Request length 2 INT16 Acceleration-IN 0T 1 O 16 Denominator 2 IN 16 O 1-Degree 2 O Boolean do Threshold GetPointerControl 1 106 Opcode 1 Not used 2 1 Required length => 1 1 Reply 1 not used 2 CARD16 number of sequences 4 0 response length 2 CARD16 acceleration-numerator 2 CARD16 acceleration-denominator 2 CARD16 threshold 18 not used SetScreenSaver 1 107 opcode 1 not used 2 3 required length 2 INT16 interval 2 INT 2 timeout 2 INT 2 Priority blanking 0 No 1 Yes 2 Default 1 Presentation permission 0 No 1 Yes 2 Default 2 Not used GetScreenSaver 1 108 Opcode 1 Not used 2 1 Requested length => 1 1 Reply 1 Not used 2 Responses 4 CARD 16 2 CARD16 Timeout 2 CARD16 Interval 1 Priority blanking 0 No 1 Yes 1 Presentation permission 0 No 1 Yes 18 Not used ChangeHosts 1 09 Opcode 1 Mode 0 Insert 1 Delete 2 2+ (n + p) / 4 Requested Length 1 Family 0 Internet 1 DECnet 2 Chaos 1 Not Used 2 CARD16 Address Length n LISTofCARDS Address p Not Used 1st110 Not Used 1List 2 Hosts Request Length => 1 1 Reply 1 Mode 0 Disabled 1 Enabled 2 CARD16 Number of Sequences 4 n / 4 Response Length 2 CARD16 Number of HOSTs on Host 22 Not Used n LISofHOST Host (n is always a multiple of 4) Cont1 Secscet111 Opcode 1 Mode 0 Disable 1 Enable 2 1 Request length SetCloseDownMode 1 112 Opcode Mode 0 Destroy 1 RetainPermanent 2 RetainTemporary 2 1 Request length KillClient 1 113 Opcode 1 Not used 2 2 Request length 4 CARD32 Resources 0 AllTemporary RotateProperties 1 Wn 2 Wn 2 + 1 Wn 2 Request 2 Not required 1 INT16 Delta 4n LISTofATOM Characteristics ForceScreenSaver 1 115 Opcode 1 Mode 0 Reset 1 Activate 2 1 Request Length SetPointerMapping 1 116 Opcode 1 n Map Length 2 f1L4o + np 4 Ip + Ip + Ip + Request 1n + (n +) + 1+ (n +) + 1+ (n +) + 1+ (n +) + 1n + Maps 2n + 1+ (n +). Reply 1 Status 0 Success 1 Busy 2 CARD16 Number of sequences 4 0 Response length 24 Not used GetPointerMapping 1 117 Opcode 1 Not used 2 1 Requested length => 1 1 Reply 1 n Map length 2 CARD16 + Number of sequences 4 (4) Response length 24 Not used n LISTofCARD8 map p Not used SetModifierMapping 1 118 Opcode 1 n Key code per qualifier 2 1 + 2n Requested length 8n LISTofKEY KEYCODE Codes ＞＞ 1 1 REPLY Cue UC 1 4 0 Response length 24 Not used GetModifierMapping 1 119 Opcode 1 Not used 2 Request length => 1 1 Reply 1 n keycode per Qualifier 2 CARD16 sequence number 4 2n response length 24 nonuse 8n LISTofKEYCODE keycode NoOperation 1 127 opcode 1 Not used 2 1 request length

[Events] (Events) KeyPress 1 2 Code 1 KEYCODE Details 2 CARD16 Number of sequences 4 TIMESTAMP Time 4 WINDOW Root 4 WINDOW Event 4 WINDOW Child 0 None 2 INT16 Root x 2 INT16 Root 2x 2y UT 16S 2y UT 2S UT 16y 2U SYN 2U 16S event 1 BOOL same screen 1 not used KeyRelease 1 3 code 1 KEYCODE details 2 CARD16 sequence number 4 TIMESTAMP time 4 WINDOW route 4 WINDOW event 4 WINDOW terminal 0 None 2 INT16 route x 2 INT16 root y 2 INT16 event x 2 INT16 event y 2 SETofKEYBUTMASK State 1 BO OL Same screen 1 Not used ButtonPress 1 4 Code 1 BUTTON Detailed 2 CARD16 Number of sequences 4 TIMESTAMP Time 4 WINDOW Root 4 WINDOW Event 4 WINDOW Child 0 None 2 INT16 Root 16 2x16 INT 2 Root 16 2x16 INT 2 Root 16 2x 16 INT 2 Root 16 2x 16 INT 2 Root 16 2x 16 INT 2 Root 16 2x 16 INT 2 Root 16 2x 16 INT 2 root 1 BOOL Same screen 1 Not used Button Release 1 5 Code 1 BUTTON Detail 2 CARD16 Sequence number 4 TIMESTAMP time 4 WINDOW Root 4 WINDOW event 4 WINDOW Y WIN 2 UT16T 2 SY16 event x 2 INT16 route x 2 INT16 route x 2 INT16 route x 2 INT16 route x 2 INT16 route x 2 INT16 route State 1 Boolean Same screen 1 Not used MotionNotify 1 6 Code 1 Details 0 Normal 1 Hint 2 CARD 16 Sequence number 4 TIMESTAMP Time 4 WINDOW Root 4 WINDOW Event 4 WINDOW 2 IN 16 IN 2 root 16 IN 2 Root 2 IN 16 Root 2 IN 2 Root 16 IN 2 2 IN 16 root 2 IN 2 IN 16 root 2 IN 16 Event y 2 SETofKEYBUTMASK State 1 OOL Same Screen 1 Not Used EnterNotify 1 7 Code 1 Details 0 Ancestor 1 Virtual 2 INTER WORD IN WORW 4 WNW 4 NONLINEAR 4 Nonliner 4 Nonliner 4 Nonliner 4 Nonlinear 4 4 one 2 INT16 route x 2 INT16 route y 2 INT16 event x 2 INT16 event y 2 SETofKEYBUTMASK state 1 mode 0 Normal 1 Grab 2 Ungrab 1 same screen, focus # x01 focus (1 is true, 0 is false # # is false) 1 is true, 0 is false) #xfc Not used LeaveNotify 1 8 Code 1 Details 0 Ancestor 1 Virtual 2 Inferior 3 Nonlinear 4 Nonlinear WIN W 2 IN 4 W 0 IN W 2 W IN W 2 W IN 4 W 4 WIN W IN 4 WIN 4 WIN 4 WIN W IN 4 WIN 4 WIN 4 WIN 4 WIN 4 WIN 4 WIM 4 IN 4 WIN WIN 4 WIN 4 WIM 4 IN 4 WIN WIN 4 WIN WIN 4 WIN 4 WIN WIN 4 WIN 4 WIN 4 WIN 4 WORD 4 WIM IN IN Root 4 WIN 4 WIN 4 WIN of 4 of 4 WIN of WORD 4 of WORD IN of WORD 4 of WORD 4 WIN 4 2 INT16 route y 2 INT16 event x 2 INT16 event 2 SETofKEYBUTMASK State 1 Mode 0 Normal 1 Grab 2 Ungrab 1 Same screen, focus # x01 Focus (1 is true, 0 is false) # x02 Same screen (1 is true, 0 is false) #xfc Not used Focus1 1 9 Code details 0 Ancestor 1 Virtual 2 Inferior 3 Nonlinear 4 NonlinearVirtual 5 Pointer 6 PointerRoot 7 None 2 CARD16 sequence number 4 WINDOW events 1 mode 0 Normal 1 Grab 2 ungrab 3 WhileGrabbed 23 not used FocusOut 1 10 codes 1 details 0 Ancestor 1 Virtual 2 Inferior 3 Nonlinea 4 NonlinearVirtual 5 Pointer 6 PointerRoot 7 None 2 CARD16 Number of sequences 4 WINDOW Event 1 Mode 0 Normal 1 Grab 2 Ungrab 7y 0r 3 Keys 1 3c 8 Whip Grabed 23 a key Keys are not used. 12 Code 1 Not Used 2 CARD16 Sequence Number 4 WINDOW Window 2 CARD16 x 2 CARD16 y 2 CARD16 Width 2 CARD16 Height 2 CARD16 Count 14 Not Used GraphicsExposure 1 13 Code 1 Not Used 2 CARD16 Sequence Number 2 CARD16 WORD 4 D x 2 CARD16 y 2 CARD16 Width 2 CARD16 Height 2 CARD16 Small Opcode 2 CARD16 Count 1 CARD8 Large Opcode 11 Not Used NoExposure 1 14 Code 1 Not Used 2 CARD16 Sequence Number 4 DRAWABLE Drawable 2 CARD16 Small Opcode use VisibilityNotify 1 15 codes 1 not used 2 CARD16 sequence number 4 wINDOW window 1 state 0 Unobscured 1 PartiallyObscured 2 FullyObscured 23 unused CreateNotify 1 16 codes 1 not used 2 CARD16 sequence number 4 wINDOW parent 4 wINDOW window 2 INT16 2 INT16 y 2 CARD16 Width 2 CARD16 Height 2 CARD16 Border width 1 BOOT Override re-instruction 9 Not used DestroyNotify 1 17 Code 1 Not used 2 CARD16 Sequence number 4 WINDOW Event 20 Not used 2 p Not used 18 a Not used CARD16 Number of sequences 4 WINDOW event 4 WINDOW window 1 BOOT from configuration 19 Not used MapNotify 1 19 Code 1 Not used 2 CARD16 Number of sequences 4 WINDOW event 4 WINDOW q 1 COOL u 20 Red code not used Re-instruction not used 19 Sequence number 4 WINDOW Parent 4 W NDOW Window 20 Not Used RepeatNotify 1 21 Code 1 Not Used 2 CARD16 Number of Sequences 4 WINDOW Event 4 WINDOW Window 4 WINDOW Parent 2 INT16 x 2 INT16 y 1 BOOL Override Reindication 11 Not Used Config No 1 Config No Config2 Code2 4 WINDOW Event 4 WINDOW Window 4 WINDOW The same country as above 0 None 2 INT16 x 2 INT16 y 2 CARD16 Width 2 CARD16 Height 2 CARD16 Border Width 1 BOOL VOLE VO2 Stack Override Recode 0 Toplf 3 Botto lf 4 Opposite 2 CARD16 Sequence number 4 WINDOW Parent 4 WINDOW Window 4 WINDOW Brothers 0 None 2 INT16 x 2 INT16 y 2 CARD16 Width 2 CARD16 height 2 CARD16 Height 2 CARDx # BITx # 0002x 0002x # 0002x 0001x 0002x # 0002x 0001x 0002x # 0002x 0001x 0002x 0001x 0002x # 0002x # 0002x 0001x 0002x 0001x 0002x 0001x 0002x 0001x 0002x # # mask. Height # x0010 Border width # x0020 Brotherhood # x0040 Stack mode 4 Not used GravityNotify 1 24 Code 1 Not used 2 CARD16 Number of sequences 4 WINDOW Event 4 WINDOW Window 2 INT16 x 2 INT16 y 16 Not used Resize1 Resque code not used CARD16 Number of sequences 4 WINDOW window 2 CARD 6 Width 2 CARD16 Height 20 Not Used CirculateNotify 1 26 Code 1 Not Used 2 CARD16 Number of Sequences 4 WINDOW Event 4 WINDOW Window 4 WINDOW Not Used 1 Place 0 Top 1 Bottom 15 Not Used 2 CIRC1 Recirculate 4 wINDOW parent 4 wINDOW window 4 not used 1 location 0 Top 1 Bottom 15 unused PropertyNotify 1 28 codes 1 not used 2 CARD16 sequence number 4 wINDOW window 4 aTOM aTOM 4 TIMESTAMP time 1 state 0 NewValue 1 Deleted 15 not used SelectionClear 1 29 Code 1 Misuse 2 CARD16 Number of Sequences 4 TIMESTAMP Time 4 WINDOW Owner 4 ATOM Selection 16 Not Used Selection Request 1 30 Code 1 Not Used 2 CARD16 Number of Sequences 4 TIMESTAMP Time 0 Current Time TO M TO 4 M TOA 4 TOW ID 4 A Requirement 4 WINDOW Owner 4 A 4 Not Used SelectionNotify 1 31 Code 1 Not Used 2 CARD16 Number of Sequences 4 TIMESTAMP Time 0 CurrentTime 4 WINDOW Requester 4 ATOM Selection 4 ATOM Purpose 4 ATOM Characteristic 0 None 8 Not Used Color1Worth Code2 WORD1 Not Used 2 CORD 16 NDOW window 4 COLORMAP color map 0 None 1 Boolean new 1 state 0 Uninstalled 1 Installed 18 not used ClientMessage 1 33 code 1 CARD8 format 2 CARD 16 number 2 CARD16 number of sequences 4 WINDOW window of 4 data type 2 CARD16 number of codes 4 WINDOW window of data type 4 C code 16 CORD 16 No. 1 Request 0 Modifier 1 Keyboard 2 Pointer 1 KEYCODE First Key Code 1 CARD8 Count 25 Not Used

[Brief description of drawings]

FIG. 1 is a diagram illustrating an example of an X11 client / server model.

FIG. 2 is a diagram showing how Xscope connects to an X11 system.

FIG. 3 is a diagram illustrating an example of a client / server protocol exchange.

FIG. 4 is a diagram showing an example of a client / server protocol exchange.

5 shows the protocol exchange of FIG. 3 after packet decoding.

6 shows the protocol exchange of FIG. 4 after packet decoding.

FIG. 7 is a flow chart showing the flow of Xscope program logic.

FIG. 8 is a diagram showing how Xprog connects to X11.

FIG. 9 is a flowchart showing the flow of Xprog program logic.

FIG. 10 is a diagram showing a general structure of an X11 packet.

[Explanation of symbols]

 50 client 52 server 90 XPROG 92 output

Claims (20)

[Claims] 1. A computer comprising the steps of: monitoring a data stream having a known syntax by a computer process; and generating a series of computer instructions that mimics the data stream by the computer process. Automatic program generation method. 2. A method for simulating processes in a computer system having a client process and a server process and exchanging messages between them, the method comprising: the client in the computer system. Monitoring a protocol exchange between a process and the server process, as a result of the monitoring, generating a series of computer instructions that, when executed on the computer system, replicate the client process; And executing the resulting computer instructions in connection with the server process on behalf of the client process. 3. The method of claim 2, wherein the protocol exchange uses the X11 protocol. 4. The method of claim 2, wherein the client process is an X11 client. 5. The method of claim 2, wherein the server process is an X11 server. 6. A method for producing a distributed copy of computer software, the method monitoring the exchange of information between the computer software and a computer operating system having a system call. , And generating a distribution computer program as a result of the monitoring, the distribution computer program generating the same sequence of system calls as the computer software did. 7. The method of claim 6, further comprising the step of converting the distribution computer program into a machine executable program. 8. A method for producing a distribution copy of claimable computer software including claimable information therein, the method comprising a computer having the computer software and a system call. The same as the distribution computer program did, including the steps of monitoring the exchange of information with the operating system, and generating a distribution computer program as a result of the monitoring. A method of generating a system call of a sequence of. 9. The method of claim 8 further comprising the step of converting the distribution computer program into a machine executable program. 10. A monitoring means for monitoring a data stream having a known syntax by a computer, and a generating means for generating a series of computer instructions by the computer to mimic the data stream. A device for generating a computer program that executes. 11. An apparatus for simulating processes in a computer system having a client process and a server process and exchanging messages between them, the apparatus comprising: the client in the computer system. Monitoring means for monitoring protocol exchanges between a process and the server process, generating a series of computer instructions that, when executed on the computer system as a result of the monitoring, replicate the client process Generation means for
And an executing means for executing the resulting computer instructions in the computer system on behalf of the client process in connection with the server process. 12. The apparatus of claim 11, wherein the protocol exchange uses the X11 protocol. 13. The apparatus of claim 11, wherein the client process is an X11 client. 14. The apparatus of claim 11, wherein the server process is an X11 server. 15. A device for producing a distributed copy of computer software for monitoring the exchange of information between said computer software and a computer operating system having a system call. Monitoring means, and generating means for generating a distribution computer program as a result of the monitoring means, the distribution computer program generating the same series of system calls as the computer software did. A device characterized by the above. 16. The apparatus of claim 15, further comprising conversion means for converting the distribution computer program into a machine executable program. 17. An apparatus for producing a distribution copy of claimable computer software, including claimable information therein, the apparatus comprising: claimable computer software. Computer operating system with system call
Monitoring means for monitoring the exchange of information with the system, and as a result of said monitoring means a distribution computer
An apparatus comprising generating means for generating a program, wherein the distribution computer program generates the same series of system calls as the computer software did. 18. The apparatus of claim 17, further comprising conversion means for converting the distributed computer program into a machine executable program. 19. A computer program product for machine generating a computer program fixed on a tangible computer medium, the tangible computer medium for monitoring by a computer a stream of data having a known syntax. A computer program product comprising monitoring means and generating means for generating a series of computer instructions by the computer that mimics the data stream. 20. A computer program product for producing a distribution copy of computer software fixed on a tangible computer medium, wherein the tangible computer medium carries said computer software and a system call. A monitoring means for monitoring the exchange of information with the operating system, and a generating means for generating a distribution computer program as a result of the monitoring means, the distribution computer program being the computer software; A computer program product characterized by producing the same series of system calls as the ware did.