MULTICS TECHNICAL BULLETIN
To:
To:
To: MTB Distribution
From:
From:
From: Jon Rochlis
Date:
Date:
Date: 22 June 1985
Subject:
Subject:
Subject: A Remote Window System Procotol for Multics
Abstract
Abstract
Abstract
Most currently existing window systems are built for computers with
special purpose hardware which they directly control. Yet many larger
computers which are used for conventional timesharing or as special application
servers, have neither the hardware required to implement a sophisticated window
system, nor have the software developed to support such hardware were it
available. This thesis proposes a solution for such systems: a remote window
system protocol. It allows an existing computer with a window system (the
workstation) to act as a server for applications running on the host machine.
There are numerous advantages to implementing a window system in this manner:
no new hardware need be developed for the host; minimal software development is
required (certainly less than development of a window system from scratch); the
host need not know any specifics of the workstation; and the host application
can be used without software changes from any type of workstation which
MTB-714 Page 2 22 June 1985
implements this protocol. The protocol is built as an extension to a standard
virtual terminal protocol, and is itself quite extensible. Modifications to the
Multics Video System needed to implement this protocol are presented.
This MTB is derived from the author's MIT S.B. thesis.
Comments should be entered in the System-M forum meeting
>udd>Multics>meetings>Multics_Workstations (mworks)
or via electronic mail to
Rochlis <Jon Rochlis> on System-M, MIT or CISL.
A Remote Window System Protocol Rochlis
MTB-714 Page 3 22 June 1985
Table of Contents
Table of Contents
Table of Contents
Table of Contents 3
1. Introduction 5
1.1 The History of Display Management 7
1.1.1 Remote Processing 7
1.1.2 Local Processing 8
1.1.2.1 Smarter Terminals 8
1.1.2.2 The needs of remote network access 9
1.2 Current Trends 11
1.2.1 Local Window Systems 11
1.2.2 Remote Window Systems 13
2. Protocol 15
2.1 Goals 15
2.1.1 Relieving the host of display management burden 16
2.1.2 Lower development cost 16
2.1.3 Portability 17
2.1.4 Compatibility with current virtual terminal protocols 18
2.1.5 Use of the workstation's user interface 18
2.1.6 Extensibility 19
2.2 Commands 20
2.2.1 Acknowledgments 20
2.2.2 Negotiation 21
2.2.3 Desk Management 22
2.2.4 Scrolling 25
2.2.5 Menus 27
2.2.6 More processing 28
2.2.7 Error codes 30
2.2.8 Options 30
3. Other Systems 32
3.1 Unix based networked window systems 32
3.1.1 X 32
3.1.2 CMU Network Window-Manager 33
3.2 Multics echo negotiation 34
A Remote Window System Protocol Rochlis
MTB-714 Page 4 22 June 1985
4. Extensions 36
4.1 Local echo negotiation 36
4.2 Local editing 36
4.3 Translation tables 37
4.4 Choice facilities 38
5. Conclusions 39
Appendix A. Protocol Specification 40
A.1 Negotiation 42
A.2 Desk management 43
A.3 Scrolling 44
A.4 Menus 44
A.5 More processing 45
Appendix B. Multics Video System Modifications for MWP 46
B.1 Modifications to window_io_ 46
B.1.1 window_ 47
B.1.2 window_call 59
B.1.3 window_io_ control orders 59
B.2 Modifications to tc_io_ 59
B.3 Future Modifications 62
References 63
A Remote Window System Protocol Rochlis
MTB-714 Page 5 22 June 1985
Chapter 1
Chapter 1
Chapter 1
Introduction
Introduction
Introduction
A terminal is the first user visible part of any general-purpose computer
system. It has some sort of a display (such as a CRT screen) which the
computer system can use to show information to the user, and some form of input
device (most likely a typewriter keyboard) through which the user can transfer
information to the computer system. Virtually all of the user's interaction
with the computer will be through the terminal; when working interactively
everything he wishes to tell the computer will pass through it, as well as all
of the information destined for him from the computer. It seems quite
reasonable to devote a substantial effort to improving this device, the
terminal, so that it helps the user to become more productive, rather than
acting as an obstacle between the information stored in the computer and its
human user.
The first generation of terminals were large, slow, printers which were
directly connected to large timesharing systems. A major improvement was the
dumb CRT terminal, which not only avoided having to keep a paper record of a
computer session, but which also allowed higher bandwidth connections to the
mainframe. As micro-processor technology progressed more and more
A Remote Window System Protocol Rochlis
MTB-714 Page 6 22 June 1985
"intelligence" was moved into the terminal. Terminals which could perform such
functions as positioning to arbitrary points on the screen, inserting
characters in the middle of a line of text, and clearing arbitrary regions
became commonplace. Software such as the Emacs text editor was written to take
advantage of these new capabilities.
As computer technology itself has progressed the cost and size of
computers has fallen to such a degree that it is now feasible to replace a
terminal with a desktop computer that has the capacity of a mainframe of
yesteryear. However, economic constraints (as well as issues of sharing) often
compel the use of a remote machine. The local terminal, now more properly
___________
called a workstation, can perform as much of the information processing job as
possible, offloading more complicated tasks to a remote computer. For example,
the local workstation could formulate selection queries for a database and
query a database server which would do the actual search, quite likely
providing access control and sharing at the same time.
Determining what should be done on the local workstation and what should
be done on the usually more powerful remote host is an important problem. One
task which comes to mind as eminently suitable for the workstation is that of
"display management." which includes how displays appear to the user, where on
the screen they are put, how the user manipulates them, and how the user makes
choices between different options. To understand this, we must look at what
display management involves, what has been done in the past to distribute it
A Remote Window System Protocol Rochlis
MTB-714 Page 7 22 June 1985
between local and remote hosts, and how this can be extended given the
increased power of today's workstations.
1.1 The History of Display Management
1.1.1 Remote Processing
Early terminals were directly connected to their host computers; nothing
but a wire stood between them. The terminals were capable of doing little more
than printing characters on whatever output device they possessed (usually a
screen or printer), and sending characters typed by the user to the remote
computer system. This meant that the remote system did all of the work, such
as deciding how a control character should be displayed, and providing some
form of "more processing," which usually amounted to stopping at the bottom of
a screen (for screen-oriented devices), and waiting for the user to acknowledge
the current screenfull of information, before proceeding to display the next
screen, as well as providing any form of editing, such as using the backspace
or delete key to correct typing mistakes.
A Remote Window System Protocol Rochlis
MTB-714 Page 8 22 June 1985
[-------------------] [-------------------]
[ ] [ ]
[ terminal ]------------------[ computer system ]
[ ] (wire) [ ]
[-------------------] [-------------------]
Figure 1-1:
Figure 1-1:
Figure 1-1: early display management
1.1.2 Local Processing
1.1.2.1 Smarter Terminals
Terminals got smarter. They began to support cursor positioning, editing
features such as insert/delete characters and lines, and selective echoing.
This created new opportunities which had not existed before, and immediately
shifted responsibility for these functions away from the remote host and to the
terminal. The host could tell the terminal what do, but the terminal did all
the work.
One important function of system software running on the remote computer
system was to isolate the application program from the subtle differences in
terminals. It seemed that no two terminal manufacturers could ever agree on
the control sequences used to invoke the terminal's advanced features, nor
could they agree on what set of features to implement. Also some terminals
performed some operations faster than others, which can be important if the
A Remote Window System Protocol Rochlis
MTB-714 Page 9 22 June 1985
terminal will ignore any commands sent to it while it is busy doing the
previous command. The system software would have some kind of database
describing the different types of terminals, for example, the TTF (terminal
1
type file) of Multics [Multics 83a] or the termcap database on Unix [Unix 83].
This creates three layers of processing: the application asking the system to
perform some display function, such as clearing the bottom half of the screen;
the system software figuring out what the proper way to accomplish the
function, given the kind of terminal; and the terminal itself, doing the lowest
level work.
1.1.2.2 The needs of remote network access
As people wished to use computer systems which were geographically
distant, or wanted to use a number of local machines, the use of networks
increased. Remote network access caused display management to become even more
distributed. In the simplest case, the local computer merely controlled the
network connection, so that the wire connecting the target computer system with
the terminal had actually become a local computer system and a network. Such
local systems are often called terminal concentrators.
The lessons of this arrangement should not be overlooked. The local
_______________
1
Unix is a trademark of Bell Laboratories.
A Remote Window System Protocol Rochlis
MTB-714 Page 10 22 June 1985
[----------] [-----------------] [-----------------]
[ ] [ local ] [ foreign ]
[ terminal ]--------[ computer system ]-----------[ computer system ]
[ ] (wire) [ ] (network) [ ]
[----------] [-----------------] [-----------------]
Figure 1-2:
Figure 1-2:
Figure 1-2: network access changes display management
computer system can relieve the foreign system of some of the display
management burden. This is especially useful when the foreign system is a
large, overloaded time-sharing system, and the the local system is a small
computer, such as PDP-11, whose only duty is to manage the network and display
management requirements for a small number of terminals.
At this stage protocols were developed for use between the local and
foreign systems. TELNET [Postel 80] was was developed for the ARPA network to
standardize issues of echoing, synchronization, and negotiation of the
capabilities of the local terminal. TELNET merely acted as a wire, however,
when larger issues of display management are considered. More complicated
protocols which took advantage of the terminals more sophisticated features
_______ ________ _________
were devised [Stallman 82a]. These virtual terminal protocols, allowed the
terminal type database and the computational work associated with it, to move
off the foreign system and on to the local system. It did what the the
terminal manufacturers could not do: create a standard terminal type. Thus one
A Remote Window System Protocol Rochlis
MTB-714 Page 11 22 June 1985
could look at the local computer/terminal combination as presenting a standard
interface to the application running on the foreign computer. More recent
standards [ISO 83], have been adopted by many manufacturers, yet there is still
a large disparity in speed and a lack of negotiation schemes to inform
applications which functions are implemented by a particular terminal.
Some local computers' implementations provide other display management
functions, such as more processing or local editing (which performs much better
than editing on the foreign system because network delays due to large numbers
of small packets are avoided, and the processing is done on the usually less
heavily loaded machine). These are extensions which go beyond simply managing
the terminal's raw capabilities. The local computer is actually adding new
functionality to the system.
1.2 Current Trends
1.2.1 Local Window Systems
Terminals really got smarter. Bitmapped displays started to appear,
having sophisticated graphics and large screen sizes. Now there was much more
_________
room on a screen to display information and the concept of windowing became
popular. Windows are regions of the screen. Applications can be associated
with a particular window, and more than one window can be visible at any one
time. The user can freely switch between windows, treating windows much as he
A Remote Window System Protocol Rochlis
MTB-714 Page 12 22 June 1985
would treat pieces of paper on a desktop, bringing new windows to the top of
the pile, perhaps partially obscuring existing windows. Thus manipulating
_____ __ _____ __________ ____ __________
windows is often called piece of paper management or desk management.
Alternative input devices are often associated with window systems, most
_____
notably the pointing device known as a mouse. A mouse allows the user to move
a cursor on the screen by rolling a small mechanical device (the mouse) on his
desktop. Mice have one or more buttons, so the user not only can move the
mouse cursor to a specific point on the screen, but can also indicate that some
action should occur. For example, clicking a mouse button when the mouse
cursor is positioned in a buried window could cause that window to be brought
to the front of the "desktop."
Many different window systems have been developed for systems which
directly control their display devices. These include expensive systems such
as Lisp Machines [LISPM 83], less expensive systems such as Suns, Apollos, and
2
Micro-vaxes, and inexpensive systems such as Apple's Macintosh [Macintosh 84].
_______________
2
Macintosh is a trademark of McIntosh Laboratories, Inc.
A Remote Window System Protocol Rochlis
MTB-714 Page 13 22 June 1985
1.2.2 Remote Window Systems
The next logical step will be the development of remote window systems, in
which a remote host will cooperate with a workstation's window system to
provide the advantages of the local window system to the remote host. Among the
reasons why distributing window systems makes good sense are:
- The remote network access virtual terminal paradigm can be
meaningfully extended to include windowing functions. For example, a
Lisp Machine user might want might want to run a window-based
application on a foreign server Lisp Machine. Furthermore the server
machine need not be a Lisp Machine, but on some other system such as
a Multics or a Vax.
- Some window systems are hampered by the lack of reasonable hardware.
If the only output device available is a 24x80 CRT, and the only
input device is a typewriter keyboard without many special purpose
keys, the window system supported can only be so sophisticated.
Examples of this can be found in Unix's Curses Library [Unix 83] and
the Multics Video System [Multics 83b].
- A window-based application can run on any of a number of
workstations, as long as the workstation implements the remote window
protocol. Much as Emacs works on VT100's as well as HEATH19's, a
mail reading subsystem making use of a remote window system protocol
could run on a Macintosh as well as a Lisp Machine. Furthermore, the
user interface to display processing can be adapted to the particular
workstation, without the knowledge of the application program. For
example, pull-down menus could be used on a Macintosh, while pop-up
menus could be used on a Lisp Machine.
This thesis proposes such a workstation independent remote-windowing
protocol. It leaves room for the addition of features related to display
management, such as local editing or choice facilities. In addition, it is
A Remote Window System Protocol Rochlis
MTB-714 Page 14 22 June 1985
built on top of today's existing virtual terminal protocols, and fits in well
as an extension to them.
I will first present the goals and details of my protocol, then I will
examine several existing systems seeing how far they have taken the goals of
distributing window system functions and how they have dealt with the issues
that arise. This will be followed by a discussion of areas for future
enhancement. An appendix detailing an ISO 6249 compatible implementation of
the protocol will be presented, as well as an appendix describing the changes
to Multics required to implement this protocol as part of the Multics Video
System.
A Remote Window System Protocol Rochlis
MTB-714 Page 15 22 June 1985
Chapter 2
Chapter 2
Chapter 2
Protocol
Protocol
Protocol
_______ ___________ ________
This chapter describes the goals of the Multics Workstation Protocol (MWP)
3
as well as the specific commands which can be given either by the remote
computer or the local workstation. In the rest of this discussion, the remote
computer will be referred to as the "host", and the local computer will be
referred to as the "workstation."
2.1 Goals
_______________
3
Note: Just because the name "Multics" is in the title of the protocol, does
not imply that it is Multics specific. Indeed one of the goals is to make the
protocol as widely applicable as possible. The name arose simply because the
Multics Video System provided the first impetus for its development.
A Remote Window System Protocol Rochlis
MTB-714 Page 16 22 June 1985
2.1.1 Relieving the host of display management burden
By moving as much of the computational load required to support desk
management as possible away from the host and onto the workstation, the host
can perform other tasks. This will result in better utilization of the host,
as well as the workstation. The end user will see a faster system, since the
host need not be involved in the common operations, such as echoing characters,
burying and restoring windows. These will all happen locally (as much as
possible), and the host will be informed of what has happened where
appropriate. Thus the network delays and process scheduling delays of the
performing these functions on the host will usually be avoided.
2.1.2 Lower development cost
Some computer systems, such as Multics, lack the necessary hardware upon
which a sophisticated window system is built. Even if such hardware were
obtained and interfaced with existing devices, a large body of software would
need to be written, for window systems are large, complicated projects. By
using workstations which have an existing window system implementation much of
the window system software development cost can be bypassed.
A Remote Window System Protocol Rochlis
MTB-714 Page 17 22 June 1985
2.1.3 Portability
Rather than writing programs on the host computer which have a detailed
knowledge of the target workstation, the details are hidden from the host by
the workstation implementation of the protocol. Any number of different MWP
implementations could be done for various workstations, but only one
controlling program need be written on the host. This allows the use of the
window system on a variety of workstations. In addition, more than one host
implementation could exist, allowing the use of a single workstation with
several host computers, each taking full advantage of the workstations
windowing ability.
Along these lines, all communication is done over one full-duplex
connection. Other systems have one connection/process per-window or similar
schemes. MWP, however is aimed at environments which may not have
sophisticated network capabilities (e.g. the Macintosh), or true multi-tasking
at the application level (e.g. Multics). This should not present much of a
performance problem, since most of the operations found in window systems are
not inherently parallel, and multiple connections would simply multiplex the
network connection and the workstation's CPU in any case. It also does not
preclude having more than one host connection to a given workstation, each one
using MWP at the same time. The ability to do this would depend upon the
available hardware and the workstation implementation.
A Remote Window System Protocol Rochlis
MTB-714 Page 18 22 June 1985
2.1.4 Compatibility with current virtual terminal protocols
Much good work has been done in defining virtual terminal protocols over
the last few years. It would be foolish to discard and either devise a new
protocol for lower level functions, such as cursor positioning, or to lose
device independence by requiring the host to have detailed knowledge of how to
accomplish such tasks on each particular workstation. Therefore MWP will be
built on top of ISO 6249, by using sequences specified as application
4
"private". This will provide a rich variety of fundamental operations within
windows, and will show that such a virtual terminal protocol can be extended to
include windowing as well.
2.1.5 Use of the workstation's user interface
One danger inherent in hiding workstation details from the host is that
the only functions which will be used are the ones which all workstations have
in common. Specific features implemented by workstation A may not be
implemented by workstation B, or they simply may be too difficult to describe
in a generic fashion. MWP attempts to deal with this by leaving as much
_______________
4
SUPDUP would also do, but was not chosen since it has not gained wide-spread
support outside of the academic community. ISO 6249 has a much richer command
set, including, for example, font selection and various character attributes,
such as color and intensity.
A Remote Window System Protocol Rochlis
MTB-714 Page 19 22 June 1985
discretion to the workstation as possible, since the workstation can best
choose the optimal method to perform its tasks. Hopefully this will allow the
unique flavor of each workstation to come through. For example, one could
change the location of a window by dragging its title bar on a Macintosh or by
5
holding the left mouse button on a Vax running X, but the host application
won't know or care which is used, it will just be interested in the end effect.
This will also increase the effective bandwidth of the communications link,
since less information must be sent went communicating via these higher level
transactions.
2.1.6 Extensibility
It is hoped that MWP allows enough flexibility so that more features can
be built on top of it, to handle yet unthought of applications or specific
features of workstations. For example, the problem of drawing icons could be
addressed as a layer on top of the window system. The host could use a
standard graphics format, such as SUPDUP or GKS, and the workstation could map
that into its own format for icons. Furthermore, information about what
actions to take when icons were selected or moved could also be specified.
Other possibilities, such as local editing, are described in chapter 4.
_______________
5
Vax is a trademark of Digital Equipment Corporation.
A Remote Window System Protocol Rochlis
MTB-714 Page 20 22 June 1985
2.2 Commands
There are several major sets of commands. These include acknowledgment
commands, negotiation commands, desk management commands, and several others.
The other sets of commands, are presented as typical extensions to the basic
protocol, some of which may or may not be present in any given implementation
of MWP.
2.2.1 Acknowledgments
The following commands are used as generic positive and negative
acknowledgments. Not all commands require acknowledgments, and some require
______ _______
specialized actions to be taken. Window-handles are described in section 2.2.3.
ack
ack ______ ______ _______ ____ ____ ____
ack window-handle command-name [more-info]
a positive acknowledgment. The requested operation on the
____ ____
specified window was successfully performed. More-info may be
present depending upon the command being acknowledged (e.g. the
create
create
create command, defined in section 2.2.3, returning a
______ ______
window-handle).
nack
nack ______ ______ _______ ____ _____ ____ ____ ____
nack window-handle command-name error-code [more-info]
a negative acknowledgment. The requested command on the
_____ ____
specified window was not performed. If error-code is present
it provides an indication of why the action could not be
performed. See section 2.2.7 for a list of suggested error
____ ____
codes. More-info can be used to specify which argument caused
the error or to provide an english text description or
explanation, if desired, but is optional.
A Remote Window System Protocol Rochlis
MTB-714 Page 21 22 June 1985
2.2.2 Negotiation
Most of the common windowing operations must be present in all workstation
implementations, but some of the less essential commands such as scrolling or
future additions to MWP, such as those described in chapter 4, may not be
implemented on all workstations, or at least may not be present in initial
implementations. Thus some mechanism is needed for the host to decide which
functions are available for use during the current session. Rather than
maintain a static database on the host machine, with all of the maintenance
problems involved, MWP instead will use a negotiation scheme quite similar to
that used by the TELNET protocol [Postel 80].
In normal operation one party will request that a particular option be
performed, or perhaps that it stop being performed, and the second party will
either agree or refuse to perform the option. The option commands are designed
to be symmetrical so that if both parties issue a request at the same time that
the same option be performed, each will see the other party's request as an
acknowledgment of its own request. Because of the symmetry care should be
taken to avoid infinite acknowledgment loops. For example, if a request to
perform an option already in effect is received, it should not be acknowledged.
The following four commands will be used:
do
do ______ ______
do option request that the receiver perform option, or confirmation that
______
sender expects the receiver to perform option.
A Remote Window System Protocol Rochlis
MTB-714 Page 22 22 June 1985
will
will ______ ______
will option indicates the sender wishes to perform option, or confirms that
______
the sender is performing option.
don't
don't ______ ______
don't option requests that the receiver stop performing option or confirms
______
that the sender no longer expects option to be in effect.
won't
won't ______ ______
won't option indicates that the sender will not perform option.
If more negotiation is required for a given option, it can be undertaken
once both parties agree to perform the option.
See section 2.2.8 for the defined options.
2.2.3 Desk Management
These commands are the basic window management commands. They may be sent
from the host to the workstation or from the workstation to the host. Usually
the host will be asking the workstation to take some action to accomplish the
given command, while the workstation issuing one of these commands is usually
informing the host of action it has already taken. The workstation need not
inform the host of every action it takes, but rather only those performed as a
result of a direct command from the host, or those which require host
interaction (e.g. creating a window and executing a command on the host in
______ ______
that window). All windows are identified by a unique window-handle.
create
create ______ ______ _______ ____ ______ __________
create window-handle command-line window-attributes
create a window on the workstation. The arguments may be
______ ______
specified or may not be present. If window-handle is absent
the receiver must create one (which should be unique in its
list of known windows) and return it in the acknowledgment. If
A Remote Window System Protocol Rochlis
MTB-714 Page 23 22 June 1985
______ __________
window-attributes is absent the receiver may make any
assumptions regarding the window which it desires, including
querying the user for size and location. (See the
set_window_options
set_window_options
set_window_options command for a description of the available
window attributes, and how to change them.) If present
_______ ____
command-line specifies a command to be invoked on the host (if
the workstation is initiating this operation), and whose I/O
should be directed to the newly created window. If a
_______ ____
command-line is not specified the host should invoke a generic
command processor.
delete
delete ______ ______
delete window-handle
delete specified window from the desktop. No other operations
may be performed on deleted window once the this command has
been acknowledged.
selection
selection ______ ______ _____ ______ ____
selection window-handle [input-output-flag]
_____ ______ ____
the specified window has been selected. Input-output-flag may
have three values: INPUT (future input will come from this
window's input buffer), OUTPUT (future output will be sent to
this window), or BOTH (both future input and output will be
_____ ______ ____
come from/go to the specified window). If input-output-flag is
not present, BOTH is assumed.
surface
surface ______ ______
surface window-handle
the specified window should be brought to the front of the
desktop, obscuring other windows as need be. This does not
imply that the window is selected ala the Macintosh window
system. If the workstation cannot separate the selection and
selection
selection
surface functions, it should send a selection command to the
surface
surface
host, after receiving a surface command. The host should be
prepared for this.
bury
bury ______ ______
bury window-handle
the specified window should be put behind all existing windows
on the desktop, causing previously obscured windows to be
brought to the front of the desktop.
move
move ______ ______ ________
move window-handle [location]
move specified window to the given location on the screen. If
________
the host does not specify location the workstation should query
the user in some appropriate fashion, and return the location
in the acknowledgment.
A Remote Window System Protocol Rochlis
MTB-714 Page 24 22 June 1985
resize
resize ______ ______ ___ ____
resize window-handle [new-size]
___ ____
changes the size of the specified window to new-size. If the
___ ____
host does not specify new-size the workstation should query the
user in some appropriate fashion.
set_window_info
set_window_info ______ ______ ______ __________
set_window_info window-handle window-attributes
sets all or some of the attributes for the specified window.
Any absent attributes are left unchanged. Version One window
attributes are listed below:
name
name
name specifies the name of the window. The
workstation should use this name when
displaying window information to the user.
location
location
location the location of the window on the workstation's
screen. Windows are assumed to be rectangular,
and the location is specified by the X,Y
coordinates of the upper-left corner of the
window.
size
size
size the size of the window. Again this is an X,Y
pair, giving the number of columns and rows,
respectively.
scrolling
scrolling
scrolling indicates whether the window has the ability to
scroll to view more data then can fit in the
window. The workstation will display the
appropriate control to allow the user to scroll
though the extended "contents" of the window,
and will generate scroll events (see section
2.2.4) when such controls are used. The
scrolling
scrolling
scrolling parameter may take three values:
HORIZONTAL, VERTICAL, or BOTH. If absent, the
window is not capable of scrolling.
workstation_info
workstation_info ______ ____ ____ _____
workstation_info screen-size font-width
the workstation should send this after initial agreement to
______ ____
perform desk management functions. Screen-size specifies size
____ _____
(in pixels) of the workstation's screen (X,Y). Font-width
specifies the width of the default fonts. This is enough
information for the host figure out how many rows and columns
of text will fit in a window.
A Remote Window System Protocol Rochlis
MTB-714 Page 25 22 June 1985
The receiver should acknowledge the above requests with the acknowledgment
commands described in section 2.2.1.
2.2.4 Scrolling
One common operation on windows is to view a portion of data which is not
currently displayed. In essence the window provides a view on the data and the
user can "scroll" or move this view forwards or backwards. The scrolling
protocol allows the workstation and host to cooperate in achieving this goal.
The workstation can chose the most natural way to query the user for the
scrolling commands, most likely by some form of "scroll" bars attached to the
window border (ala the Macintosh), or by "pushing" against the window border
(ala the Lisp Machine).
In order for the scrolling commands to be valid, the window must have the
scrolling attribute (see section 2.2.3), and the host and workstation must have
scrolling_vertical_version_1
scrolling_vertical_version_1
negotiated the scrolling_vertical_version_1 or the
scrolling_horizontal_version_1
scrolling_horizontal_version_1
scrolling_horizontal_version_1 options depending upon which type of scrolling
is desired (see section 2.2.2). These are the scrolling commands:
disable_scrolling
disable_scrolling ______ ______ ________ __________
disable_scrolling window-handle vertical horizontal
disable scrolling commands for the specified window. If no
______ ______
window-handle is supplied, all windows with the "scrolling"
attribute are effected. This may be used to inform the
workstation that it is no longer appropriate for this window to
________ __________
be scrolled. Vertical and horizontal are boolean flags
specifying weather vertical or horizontal scrolling, or both,
are effected.
A Remote Window System Protocol Rochlis
MTB-714 Page 26 22 June 1985
enable_scrolling
enable_scrolling ______ ______ ________ __________
enable_scrolling window-handle vertical horizontal
enable scrolling commands for the specified window. If no
______ ______
window-handle is supplied, all window's with the "scrolling"
________ __________
attribute are effected. Vertical and horizontal are boolean
flags specifying weather vertical or horizontal scrolling, or
both, are effected.
request_scroll_position
request_scroll_position ______ ______
request_scroll_position window-handle
used by the workstation to request that the host inform it of
the current position of the specified window. The host should
______ ________
respond with a scroll_position command; The workstation may
supply the information to be display to the user.
scroll_position
scroll_position ______ ______ ___ ____ ______ _____ _____ ________ ______
scroll_position window-handle [top-line-number] [total-lines] [leftmost-column]
_____ _______
[total-columns]
_______ ______ ________
The host's reply to a request_scroll_position command, or the
host's way of indicating that the scroll position of the
___ ____ ______
specified window has changed. Top-line-number is the number of
the line currently display in the specified window.
_____ _____
Total-lines is the total number of lines that can be positioned
________ ______
to. Leftmost-column is the column currently displayed at the
_____ _______
left of the window. Total-columns is the total number of
columns that may be displayed.
scroll
scroll ______ ______ ___________ ____ ________ _________
scroll window-handle positioning-mode position direction
used by the workstation to tell the host to scroll the window
___________ ____
contents. Positioning-mode can either be RELATIVE or ABSOLUTE.
________
It is the workstations responsibility to assure that position
___________ ____
is consistent with the positioning-mode and the last received
scroll_position
scroll_position
scroll_position command. However, the host should respond with
nack scroll
nack ______ ______ scroll
a "nack window-handle scroll INVALID_ARGUMENT" if the request
_________
is invalid. Direction is either VERTICAL or HORIZONTAL,
indicating in which direction scrolling should occur.
disable_scrolling enable_scrolling
disable_scrolling enable_scrolling
The disable_scrolling and enable_scrolling commands should be acknowledged
request_scroll_position
request_scroll_position
via the standard ack/nack commands. The request_scroll_position command should
scroll_position scroll
scroll_position scroll
be acknowledged via the scroll_position command, and the scroll command need
nack
nack
not be acknowledged, although a nack is allowed.
A Remote Window System Protocol Rochlis
MTB-714 Page 27 22 June 1985
2.2.5 Menus
Another appropriate task for the workstation is querying the user in an
"user-friendly" manner. Menus are a fine example of such a choice facility
which can be easily specified. Not only will distributing the management of
menus allow the workstation's features to used, but it can save communications
time by caching frequently used menus.
The host may download to the workstation one or more menus. At any time
the host may request that a choice be obtained from a given menu and the
workstation will query the user and return his choice. Alternatively, the host
______
may designate a set of menus as active and the user may invoke any one of them
at any given time causing the workstation to send the host an indication of
what choice was made from which menu. This later mode could be used to take
advantage of a menu bar type facility as found in the Macintosh.
define_menu
define_menu ____ ______ ____ _____ ______ _ ______ _ ______ _
define_menu menu-handle menu-title choice-1 choice-2 ... choice-N
____ _____
defines a menu. Menu-title should be a string suitable for
______ _
display to the user as the title of the menu. Choice-N is the
string which should be displayed to the user for the Nth choice
in the menu.
get_choice
get_choice ____ ______
get_choice menu-handle
display the specified menu and get a choice from the user. The
user may elect not to answer the query, and the host should be
prepared for this.
clear_active_menus
clear_active_menus
clear_active_menus
clears all menus from the active state.
add_active_menu
add_active_menu ____ ______ _ ____ ______ _ ____ ______ _
add_active_menu menu-handle-1 menu-handle-2 ... menu-handle-N
adds the specified menu(s) to the active state.
A Remote Window System Protocol Rochlis
MTB-714 Page 28 22 June 1985
remove_active_menu
remove_active_menu ____ ______ _ ____ ______ _ ____ ______ _
remove_active_menu menu-handle-1 menu-handle-2 ... menu-handle-N
removes the specified menu(s) from the active state.
choice
choice ____ ______ ______ ______
choice menu-handle choice-number
indicates that the user has made the indicated choice from the
specified menu.
All menu commands should be explicitly acknowledged using the standard MWP
get_choice choice
get_choice choice
acknowledgment commands, except get_choice, since the choice command can also
function as an acknowledgment.
2.2.6 More processing
Another application, albeit a minor one, that can be moved to the
workstation is more processing. The workstation is receiving output and should
be able to determine when a full screen has been displayed, at which point it
should usually wait for the user to acknowledge the current screenfull before
displaying the new data. It should also allow the user to elect not to see the
rest of the output of the request. The following are commands from the host to
the workstation to control more processing:
enable_more_processing
enable_more_processing ______ ______
enable_more_processing window-handle
enables local more processing for the specified window.
disable_more_processing
disable_more_processing ______ ______
disable_more_processing window-handle
disables local more processing for the specified window.
set_more_mode
set_more_mode ______ ______ ____ ____
set_more_mode window-handle more_mode
sets the action to be taken after a more break for the
____ ____
specified window. More_mode may be one of the following:
A Remote Window System Protocol Rochlis
MTB-714 Page 29 22 June 1985
scroll
scroll
scroll old lines scroll off the top of the window, new
lines are displayed in the spaced freed. This
should be the default.
wrap
wrap
wrap new lines are displayed starting at the top of
the window, erasing old lines as they go along.
clear
clear
clear the window is cleared and new text appears at
the top of the window.
more_break
more_break ______ ______
more_break window-handle
indicates to the host that a more break has occurred in the
specified window. To prevent overflowing the workstation's
buffers the host should stop sending output until receiving a
continue_output discard_output
continue_output discard_output
continue_output or discard_output command.
continue_output
continue_output ______ ______
continue_output window-handle
tells the host to continue sending output to the workstation
after a pause for a more break.
discard_output
discard_output ______ ______
discard_output window-handle
tells the host that the user has elected not to see the
remaining output. The host is free to interpret what
"remaining output" means. For example when printing a group of
files discarding output in the middle of the second file may
cause output to begin with the third file, or it may flush the
entire print command.
Only negative acknowledgments need be sent by the workstation, since the
only error conditions are invalid window-handles and invalid parameters to
set_more_mode
set_more_mode
set_more_mode. The host should be smart enough to avoid such error conditions.
more_break continue_output discard_output
more_break continue_output discard_output
The more_break, continue_output, and discard_output commands should
acknowledged by the host. This is necessary so the workstation can know where
"new" output begins when the user discards output and the host has already sent
more output.
A Remote Window System Protocol Rochlis
MTB-714 Page 30 22 June 1985
2.2.7 Error codes
The following is a list of recommended error codes. Other error codes may
be used, and english descriptions can be provided, but these should suffice for
most error conditions and should be recognized by all MWP implementations.
required_argument_missing
required_argument_missing
required_argument_missing
a necessary argument was not supplied.
invalid_argument
invalid_argument
invalid_argument
a supplied argument has an invalid value. More specific error
message are preferable.
invalid_command
invalid_command
invalid_command a command was given which is not valid. For example a
discard_output more_break
discard_output more_break
discard_output command without a preceding more_break comman
window_not_known
window_not_known
window_not_known
______ ______
a window-handle was supplied which does not correspond to a
existing window.
window_too_large
window_too_large
window_too_large
the size parameter is too large to fit on the screen.
position_not_on_screen
position_not_on_screen
position_not_on_screen
the location parameter is not on the screen.
unknown_menu
unknown_menu ____ ______
unknown_menu the supplied menu-handle does not correspond to a known menu.
2.2.8 Options
These are the currently defined options which may be negotiated as
described in section 2.2.2.
desk_management_version_1
desk_management_version_1
desk_management_version_1
the version of the desk management as described in section
2.2.3.
A Remote Window System Protocol Rochlis
MTB-714 Page 31 22 June 1985
scrolling_vertical_version_1
scrolling_vertical_version_1
scrolling_vertical_version_1
the version of the scrolling protocol defined in section 2.2.4,
with vertical scrolling.
scrolling_horizontal_version_1
scrolling_horizontal_version_1
scrolling_horizontal_version_1
the version of the scrolling protocol defined in section 2.2.4,
with horizontal scrolling.
menu_protocol_version_1
menu_protocol_version_1
menu_protocol_version_1
the version of the menu protocol described in section 2.2.5.
more_processing_version_1
more_processing_version_1
more_processing_version_1
the version of the more processing protocol described in
section 2.2.6.
A Remote Window System Protocol Rochlis
MTB-714 Page 32 22 June 1985
Chapter 3
Chapter 3
Chapter 3
Other Systems
Other Systems
Other Systems
3.1 Unix based networked window systems
A number of window systems have recently been built on top of Unix. They
frequently run on 6800 based workstations, and some make extensive use of local
area networks to allow applications to run on separate machines.
3.1.1 X
The window system "X" developed by Bob Scheifler and used by MIT's Project
Athena, represents an interesting approach to the remote window system problem.
The workstations, DEC Vaxstations (VS100's), provide some very sophisticated
windowing facilities, but are not user-programmable. Thus the window system
runs on a host machine, usually a VAX-750. There is one server per
workstation, running on the VAX to which the VS100 is connected. In order to
open windows and do I/O to the VS100, an application opens a TCP connection to
the X Server and speaks the X protocol. Most of the standard desk management
functions are provided, and a window manager program can be run in the
background to manage the windows on a particular VS100. Advantages of the X
A Remote Window System Protocol Rochlis
MTB-714 Page 33 22 June 1985
approach include being able to have several host machines use a particular
VS100 (all they have to do is open a network connection), and a protocol which
attempts to minimize the overhead in making requests. However, X itself does
not address the conventional virtual terminal functions, leaving that instead
for applications.
3.1.2 CMU Network Window-Manager
The Information Technology Center (ITC) of Carnegie-Mellon University has
developed a window system very similar to MWP, but with several important
differences [CMU 84]. The ITC window system, like X, has one server per
display and clients communicate with it via TCP/IP streams. Remote procedure
calls (RPC) are used by the client to request that display functions be
performed by the server. This saves two levels of dispatch (one on each side)
over byte stream virtual terminal protocols, but does not support existing
applications that are not prepared to use the RPC mechanism without an
additional layer to translate the standard terminal protocol to RPC. The
requests made by a client are considered "hints" and the workstation has the
ability to do the best it can in satisfying the request in a similar manner to
MWP. The ITC window system includes functionality not yet specified by MWP such
as fonts and graphics operations, but it does not have a generalized facility
for deciding what features are present on a given workstation.
A Remote Window System Protocol Rochlis
MTB-714 Page 34 22 June 1985
3.2 Multics echo negotiation
____ ___________
Though not directly a desk management issue, echo negotiation, a form of
local editing, is one of the applications best suited for implementation in the
workstation. All possible input characters are divided into two classes:
those normal printing characters which can be echoed by the workstation, and
_____
those break characters, which require more sophisticated action on the part of
the host. The host informs the workstation of the break table (i.e. which
characters are breaks and which are not), and tells the workstation to perform
a read function. The workstation reads characters and echoes any non-break
characters. The host is sent all the echoed characters in one burst when one of
the following conditions occurs:
1. A break character is typed. The last character returned is the
break character.
2. The cursor would be positioned beyond the last column on the screen.
This is done so the host application can decide how to wrap lines.
3. Asynchronous output is attempted. Before any output can be done,
the host must be informed of what characters have been echoed,
otherwise its screen image will be out of date.
In the current Multics implementation of echo negotiation, the workstation
is the Multics Front-End Processor (FNP). The FNP is a minicomputer which
controls a number of "channels". All communications to and from terminals
passes through the FNP, thus it is the obvious choice to put the intelligence
A Remote Window System Protocol Rochlis
MTB-714 Page 35 22 June 1985
6
of echo negotiation. The Multics user-community has found echo negotiation to
be invaluable performance enhancement, since it has made the most common
editing operation, echoing characters, independent of the load on the
mainframe.
_______________
6
It is really only the right place because there was no real alternative when
Multics echo negotiation was implemented, since there were no widely available
intelligent terminals. Because the FNP implementation only works for
non-multiplexed channels, networks do not gain from echo negotiation. An
end-to-end protocol between Multics and a workstation would be a better way to
implement echo negotiation.
A Remote Window System Protocol Rochlis
MTB-714 Page 36 22 June 1985
Chapter 4
Chapter 4
Chapter 4
Extensions
Extensions
Extensions
MWP has been designed with several extensions in mind. They should fit on
top of MWP in the same way the MWP fits on top of a standard virtual terminal
protocol.
4.1 Local echo negotiation
Echo negotiation, the process of negotiating which input characters can be
echoed by the workstation and which characters need the attention of the host,
would be an excellent extension to MWP. The design of such a local echo
negotiation protocol, patterned after the existing Multics implementation
described in section 3.2, has already been done at Honeywell and would fit in
to MWP with few changes [Margolin 85].
4.2 Local editing
Richard Stallman has shown that local echo negotiation can be extended
even further [Stallman 82b]. A local editing protocol (LEP) could be
implemented which allowed the host to download not simply which characters
should be echoed or not echoed, but which specified what some of the break
A Remote Window System Protocol Rochlis
MTB-714 Page 37 22 June 1985
characters should do. For example, there is no reason why the host should have
to process a request such as move-backward-one-character. The workstation
should have all the necessary information to do this and the host should not be
bothered.
The scrolling protocol described in section 2.2.4 could be extended so
that the workstation has some knowledge of the contents of a window, beyond
what is visible. When the user requested that the window be scrolled, or an
local editor request which contains an implicit scrolling request is performed,
the workstation could try to update its display without involving the host. If
the workstation did not possess enough information (perhaps because of limited
memory it may only cache a few screenfulls of data), it may query the host for
the missing data. This would optimize many requests, while adding little
overhead which would not have already been present. [Stallman 82b]
4.3 Translation tables
Many systems choose different representations for non-printing characters
when they are really sent as output. By default Multics prints a control-a as
its octal equivalent (001) while many other systems use a "^" to indicate a
control character, and display a control-a as ^A. Multics lets users define
their own conversions if they desire. This functionality could easily be moved
from the host to the workstation.
A Remote Window System Protocol Rochlis
MTB-714 Page 38 22 June 1985
4.4 Choice facilities
The menu system described in section 2.2.5 is a good start, but it is only
a start. More sophisticated choice facilities could be designed patterned
after such existing systems as the dialog manager for the Apple Macintosh
[Macintosh 84] or more sophisticated approaches such as Apollo's ADM [Apollo
84].
A Remote Window System Protocol Rochlis
MTB-714 Page 39 22 June 1985
Chapter 5
Chapter 5
Chapter 5
Conclusions
Conclusions
Conclusions
Unfortunately a prototype implementation of MWP has not yet been finished,
so it is difficult to draw firm conclusions. However, specifying the protocol
to this degree has shown that it is feasible as a first step towards effective
use of workstations for systems such as Multics.
One very important principle embodied in MWP is that of allowing the
workstation to do as much as possible. The host avoids specifying details,
leaving the method of implementation to the workstation. Dealing at this higher
level allows the host to take advantage of detailed features of the workstation
which the host has no knowledge of, and thus hopefully solves the problem of
only using a set of "common denominator" functions which are implemented by all
workstations and which can be conveniently expressed in a generic fashion.
Future software designers should be aware of this.
There is much more work to be done. The extensions described as MWP
options are merely examples, others should be pursued. The harder questions of
moving more than just display management to the workstation should also be
addressed.
A Remote Window System Protocol Rochlis
MTB-714 Page 40 22 June 1985
Appendix A
Appendix A
Appendix A
Protocol Specification
Protocol Specification
Protocol Specification
The chapter provides the detailed escape sequences used to invoke the
various the commands described previously. They have been chosen to be
compatible with the ISO 6429 virtual terminal standard. Commands from the host
______ _______ _______
to the workstation are encoded as Device Control Strings, and commands from
___________ _______ ________
workstation to the host are represented by Application Program Commands. ISO
6429 allows the host or the application total freedom to interpret the byte
stream between either of these control sequences and the terminating character
(ST) which is also defined by ISO 6429. The normal ISO 6429 commands will only
________
effect the selected window, as specified by the last MWP selection command.
___ ___ _____ ____ ____ __
The structure of a command will be DCS MWP-token ; arg1 ; arg2;... ST or
___ ___ _____ ____ ____ __
APC MWP-token; arg1; arg2; ... ST. The arguments may or may not be present
depending upon the MWP command in question. Numeric arguments will be
specified as described in section 5.4 of ISO 6429. String parameters are not
specified by the standard and MWP will enclose strings inside of double quote
characters (pos. 2/2) if the parameter separator (";", 3/11) is included in
the string. The ISO parameter indicator will be "=" (3/13), indicating a
private parameter. The terminator character (ST) may not be present in a
A Remote Window System Protocol Rochlis
MTB-714 Page 41 22 June 1985
string parameter. It may only be used to specify the end of the APC or DCS
string, because programs having no knowledge of MWP must be able to determine
when the application or device command is over.
___ _____
The MWP-token will usually consist of two parameters, the first specifying
the general type of command, and the second specifying the actual command. The
first parameter must be one of the following:
1. NEGOTIATION
2. DESK_MANAGEMENT
3. SCROLLING
4. MENU
5. MORE_PROCESSING
_______
6. ACK - command indicates which command is being acknowledged and
____ ____
permissible values are specified below. More-info provides a way to
send information to the host while acknowledging a command, for
______ ______
example returning a window-handle.
_______
7. NACK - command indicates which command is being acknowledged and
_____ ____
permissible values are specified below. error-code is a numeric
____ ____
argument as defined above, more-info provides more information about
the error. If it is a number that should be the number of the
offending argument, if it is a text string it should be suitable for
display to the end user.
If the first parameter is either ACK or NACK, the second parameter is to
be interpreted as the command area, followed by the another parameter which
specifies the actual command being acknowledged. Otherwise the second
parameter will indicate the actual command. For example:
A Remote Window System Protocol Rochlis
MTB-714 Page 42 22 June 1985
- NEGOTIATION DO MORE_PROCESSING_VERSION_1 (1;1;5) requests that the
other party perform the more processing protocol.
- ACK DESK_MANAGEMENT CREATE 5 (6;2;1;5) acknowledges the creation of a
______ ______
window with a window-handle of 5.
Most parameters will be encoded as numbers since they are well specified
by the international standard, and they will be easy for the host to generate
and the workstation to parse and dispatch from, since the facilities required
do this must already be present in any ISO 6429 implementation.
Each section below specifies the numeric equivalents for the given MWP
commands and also describes the format and order of the arguments. Optional
arguments not present are coded as blank parameters (;;) as specified in the
international standard, and can be omitted in total if no other arguments
______ ______ ____ ______
follow. Window-handles and menu-handles are standard numeric parameters and are
not explicitly mentioned below.
Boolean values will be represented as numbers, "1" (3/1) meaning true and
0 (3/0) meaning false.
A.1 Negotiation
The negotiation commands defined in Section 2.2.2 will be specified as
follows:
______
1. DO - option
______
2. WILL - option
A Remote Window System Protocol Rochlis
MTB-714 Page 43 22 June 1985
______
3. DON'T - option
______
4. WON'T - option
The options, as defined in section 2.2.8 will be defined as follows:
1. DESK_MANAGEMENT_VERSION_1
2. SCROLLING_VERTICAL_VERSION_1
3. SCROLLING_HORIZONTAL_VERSION_1
4. MENU_PROTOCOL_VERSION_1
5. MORE_PROCESSING_VERSION_1
A.2 Desk management
_______ ____ ______ __________
1. CREATE - command-line is a string parameter and window-attributes if
present is specified in below in the SET_WINDOW_INFO command.
2. DELETE
3. SELECTION
4. SURFACE
5. BURY
________
6. MOVE - location will be specified by two numeric parameters
7
indicating the X and Y position, respectively.
____
7. RESIZE - size will be specified by two numeric parameters specifying
the number of rows and columns, respectively.
_______________
7
In units of pixels.
A Remote Window System Protocol Rochlis
MTB-714 Page 44 22 June 1985
____ ________ ____
8. SET_WINDOW_INFO - name is simply a string, location and size are the
move resize
move resize
same as specified by the move and resize commands, scrolling is a
boolean value (coded as a "1" (3/1) if true and a "0" (3/0) if
false).
______ ____ ____ _____
9. WORKSTATION_INFO - screen-size and font-width are numeric
parameters; both must be present.
A.3 Scrolling
________ __________
1. DISABLE_SCROLLING - vertical and horizontal are boolean values, both
must be present.
________ __________
2. ENABLE_SCROLLING - vertical and horizontal are boolean values, both
must be present.
3. REQUEST_SCROLL_POSITION
___ ____ ______ _____ _____ ________ ______
4. SCROLL_POSITION - top-line-number, total-lines, leftmost-column, and
_____ _______
total-columns are numeric parameters. Either set may may blank if
the appropriate form of scrolling is not enabled.
___________ ____
5. SCROLL - positioning-mode is either RELATIVE (coded as "1" (3/1)) or
________
ABSOLUTE (coded as "2" (3/2)), position is a numerical parameter,
_________
and direction is either VERTICAL (coded as "1") or HORIZONTAL (coded
as "2"). All must be present.
A.4 Menus
____ _____
1. DEFINE_MENU - menu-title and each choice are string parameters.
2. GET_CHOICE
3. CLEAR_ACTIVE_MENUS
4. ADD_ACTIVE_MENU
5. REMOVE_ACTIVE_MENU
A Remote Window System Protocol Rochlis
MTB-714 Page 45 22 June 1985
______ ______
6. CHOICE - choice-number is a numeric parameter and must be present.
A.5 More processing
1. ENABLE_MORE_PROCESSING
2. DISABLE_MORE_PROCESSING
____ ____
3. SET_MORE_MODE - more-mode must be one of the following:
1. SCROLL
2. WRAP
3. CLEAR
4. MORE_BREAK
5. CONTINUE_OUTPUT
6. DISCARD_OUTPUT
A Remote Window System Protocol Rochlis
MTB-714 Page 46 22 June 1985
Appendix B
Appendix B
Appendix B
Multics Video System Modifications for MWP
Multics Video System Modifications for MWP
Multics Video System Modifications for MWP
The Multics Video System supports basic windowing on standard CRT type
devices. It does not support anything but the most primitive form of desk
management. There are two major parts are of the video system, each of which
is implemented as a Multics "I/O module". An I/O module is simple a piece of
code which conforms to the standard Multics I/O calling conventions (i.e. can
be dispatched to by the iox_ subroutine). The two video system I/O modules are
window_io_, which is responsible for operations on windows, and terminal
control (tc_io_) which is responsible for mapping window operations into
operations on a given terminal.
B.1 Modifications to window_io_
The application interface to those window_io_ functions not covered by the
standard iox_ I/O functions, is the window_ subroutine. The window_$create
entrypoint will be enhanced and several new entrypoints will be added.
Window_call, the command language interface to window_ will be upgraded as
well. One window_io_ control order will be enhanced.
A Remote Window System Protocol Rochlis
MTB-714 Page 47 22 June 1985
B.1.1 window_
Window_$create: The window_position_info parameter will be enhanced to
include the MWP window attributes. It may point to the following structure,
which will be defined in the include file window_control_info.incl.pl1. (Note,
the old will structure will still be accepted for compatibility):
A Remote Window System Protocol Rochlis
MTB-714 Page 48 22 June 1985
dcl 1 window_attributes_info aligned
based (window_attributes_info_ptr),
2 version char(8),
2 name char(256) varying,
2 position_info aligned like window_position_info,
2 flags,
3 vertical_scrolling unaligned bit(1),
3 horizontal_scrolling unaligned bit(1),
3 mbz unaligned bit(34);
dcl window_attributes_info_ptr ptr;
dcl window_attributes_info_version_1 char(8) init
static options (constant) init ("wati0001");
where:
1. version (Input)
is the version of the structure. The current version is
window_attributes_info_version_1.
2. name (Input)
is the name of the window.
3. position_info (Input)
is a window_position_info structure (defined in
window_control_info.incl.pl1) which describes the location and
size of the window.
4. vertical_scrolling (Input)
is true if the application creating the window is prepared to
deal with vertical scrolling events.
5. horizontal_scrolling (Input)
is true if the application creating the window is prepared to
deal with horizontal scrolling events.
A Remote Window System Protocol Rochlis
MTB-714 Page 49 22 June 1985
The following entrypoints will be added to window_:
---------------------------------------------------------------------
______
Entry: window_$start_mwp
This initializes MWP.
_____
Usage
dcl window_$start_mwp (fixed bin(35));
call window_$start_mwp (code)
where:
1. code (Output)
is a standard system error code.
---------------------------------------------------------------------
A Remote Window System Protocol Rochlis
MTB-714 Page 50 22 June 1985
______
Entry: window_$select
This is used to select a window as defined in MWP.
_____
Usage
dcl window_$select (ptr, fixed bin(35));
call window_$select (window_iocb_ptr, code);
where:
1. window_iocb_ptr (Input)
is a pointer to an IOCB attached via window_io_.
2. code (Output)
is a standard system error code.
---------------------------------------------------------------------
A Remote Window System Protocol Rochlis
MTB-714 Page 51 22 June 1985
______
Entry: window_$surface
This is used to bring the specified window to the top of the
desktop.
_____
Usage
dcl window_$surface (ptr, fixed bin(35));
call window_$surface (window_iocb_ptr, code);
where:
1. window_iocb_ptr (Input)
is a pointer to an IOCB attached via window_io_.
2. code (Output)
is a standard system error code.
---------------------------------------------------------------------
A Remote Window System Protocol Rochlis
MTB-714 Page 52 22 June 1985
______
Entry: window_$bury
This is used to bury the specified window beneath existing windows
on the desktop.
_____
Usage
dcl window_$bury (ptr, fixed bin(35));
call window_$bury (window_iocb_ptr, code);
where:
1. window_iocb_ptr (Input)
is a pointer to an IOCB attach via window_io_.
2. code (Output)
is a standard system error code.
---------------------------------------------------------------------
A Remote Window System Protocol Rochlis
MTB-714 Page 53 22 June 1985
______
Entry: window_$move
This is used to move the window to a new location on the screen.
_____
Usage
dcl window_$move (ptr, ptr, fixed bin(35);
call window_$move (window_iocb_ptr, window_position_info_ptr,
code);
where:
1. window_iocb_ptr (Input)
is a pointer to an IOCB attached via window_io_.
2. window_position_info_ptr (Input)
is a pointer to a window_position_info structure. The new
location is given by window_position_info.origin. If column and
line are both zero, they are not specified and the workstation
will query the user (Multics window coordinates are one-based).
The value of window_position_info.extent is not used.
3. code (Output)
is a standard system error code.
---------------------------------------------------------------------
A Remote Window System Protocol Rochlis
MTB-714 Page 54 22 June 1985
______
Entry: window_$resize
This entry is used to resize a window.
_____
Usage
dcl window_$resize entry (ptr, ptr, fixed bin(35);
call window_$resize (window_iocb_ptr, window_position_info_ptr,
code);
where:
1. window_iocb_ptr (Input)
is a pointer to an IOCB attached via window_io_.
2. window_position_info_ptr (Input)
is a pointer to a window_position_info structure (defined in
window_control_info.incl.pl1). The new window size is taken
from window_position_info.extent. If width and height are both
zero, they are not specified and the workstation will query the
user. The value of window_position_info.origin is not used.
3. code (Output)
is a standard system error code.
A Remote Window System Protocol Rochlis
MTB-714 Page 55 22 June 1985
The following entries will be added to window_ to support the scrolling
protocol:
---------------------------------------------------------------------
______
Entry: window_$disable_scrolling
This entry is used to disable scrolling for the specified window.
_____
Usage
dcl window_$disable_scrolling entry (ptr, bit(1) aligned, bit(1)
aligned, fixed bin(35))
call window_$disable_scrolling (window_iocb_ptr, horizontal,
vertical, code);
where:
1. window_iocb_ptr (Input)
is a pointer to an IOCB attached via window_io_.
2. horizontal (Input)
if true horizontal scrolling is to be disabled.
3. vertical (Input)
if true vertical scrolling is to be disabled.
4. code (Output)
is a standard system error code.
A Remote Window System Protocol Rochlis
MTB-714 Page 56 22 June 1985
---------------------------------------------------------------------
______
Entry: window_$enable_scrolling
This entry is used to enable scrolling for the specified window.
_____
Usage
dcl window_$enable_scrolling entry (ptr, bit(1) aligned, bit(1)
aligned, entry (ptr, fixed bin(35)), fixed bin(35))
call window_$enable_scrolling (window_iocb_ptr, horizontal,
vertical, scroll_event_handler, code);
where:
1. window_iocb_ptr (Input)
is a pointer to an IOCB attached via window_io_.
2. horizontal (Input)
if true horizontal scrolling is enabled.
3. vertical (Input)
if true vertical scrolling is enabled.
4. scroll_event_handler (Input)
is an entry which should be called when a SCROLL command is sent
by the workstation. It should take two arguments, a pointer to
a scroll_event_info structure (described below and defined in
window_control_info.incl.pl1) and a code variable.
5. code (Output)
is a standard system error code. If the specified window does
not have the proper scrolling attribute or the workstation does
not implement the proper scrolling option the error code
video_et_$capability_lacking will be returned.
A Remote Window System Protocol Rochlis
MTB-714 Page 57 22 June 1985
The scroll_event_info structure:
dcl 1 scroll_event_info aligned based (scroll_event_info_ptr),
2 version char(8),
2 direction fixed bin,
2 flags,
3 absolute unaligned bit(1),
3 mbz unaligned bit(35),
2 distance fixed bin (21);
where:
1. version
the version of the scroll_event_info being passed to the event
handler, currently scroll_event_info_version_1.
2. direction
is one of the following constants defined in
window_control_info.incl.pl1: SCROLL_VERTICAL or
SCROLL_HORIZONTAL.
3. absolute
is true if position is to be interpreted as an absolute
position, otherwise position will be a relative position.
4. position
is the number of line (or column depending on the value of
direction) which the workstation wants to be displayed in the
top line (or leftmost column) of the window.
---------------------------------------------------------------------
A Remote Window System Protocol Rochlis
MTB-714 Page 58 22 June 1985
______
Entry: window_$set_scroll_position
Informs tc_io_ (and hence the workstation) of the current position
of the window. The workstation will probably display this information
to the user.
_____
Usage
dcl window_$set_scroll_position entry (ptr, fixed bin(21), fixed
bin(21), fixed bin(21), fixed bin(21), fixed bin(35));
call window_$set_scroll_position (window_iocb_ptr, top_line,
total_lines, left_column, total_columns, code)
where:
1. window_iocb_ptr (Input)
is a pointer to an IOCB attached via window_io_.
2. top_line (Input)
is the top line currently displayed in the window.
3. total_lines (Input)
is the last line number which may be displayed in the window.
4. leftmost_column (Input)
is the left most column which is displayed in the window.
5. total_columns (Input)
is the last column which can be displayed in the window.
6. code (Output)
is a standard system error code. If the specified window does
not have either the vertical or horizontal scrolling attribute
the error code video_et_$capability_lacking will be returned.
A Remote Window System Protocol Rochlis
MTB-714 Page 59 22 June 1985
B.1.2 window_call
Window_Call keywords and new control arguments will be added to support
the window_ entries.
B.1.3 window_io_ control orders
___ ______ ____ ___ ______ ____
The set_window_info control order and its companion get_window_info will
also be modified to handle window_attributes_info structures, as well as the
current window_position_info structures.
B.2 Modifications to tc_io_
Window_io_ will inform terminal control of the MWP requests via the
following additions to tc_operations_.incl.pl1. These will supplement existing
mechanisms (i.e. the "check_(in out)_window" control orders), rather than
replacing them. The new tc operations will be the only method to generate the
MWP sequences sent to the workstation.
dcl OP_CREATE_WINDOW fixed bin initial (17) internal static options
(constant);
dcl 1 request_create aligned based (request_ptr),
2 header aligned like request_header,
2 window_attributes_info_ptr ptr;
A Remote Window System Protocol Rochlis
MTB-714 Page 60 22 June 1985
dcl OP_DELETE_WINDOW fixed bin initial (18) internal static options
(constant);
dcl 1 request_delete aligned based (request_ptr),
2 header aligned like request_header;
dcl OP_SELECT_WINDOW fixed bin initial(19) internal static options
(constant);
dcl OP_SURFACE_WINDOW fixed bin initial(20) internal static options
(constant);
dcl OP_BURY_WINDOW fixed bin initial(21) internal static options
(constant);
dcl OP_MOVE_WINDOW fixed bin initial(22) internal static options
(constant);
dcl OP_RESIZE_WINDOW fixed bin initial(23) internal static options
(constant);
dcl OP_SET_WINDOW_INFO fixed bin initial (24) internal static options
(constant);
dcl 1 request_set_window_info aligned like request_create
based (request_ptr);
dcl OP_DISABLE_SCROLLING fixed bin initial (25) internal static options
(constant);
dcl OP_ENABLE_SCROLLING fixed bin initial (26) internal static options
(constant);
dcl OP_SET_SCROLL_POSITION fixed bin initial (27) internal static
options (constant);
Terminal control (tc_input.pl1) will look for APC strings when reading and
take the correct action. It will respond directly to the workstation as much
A Remote Window System Protocol Rochlis
MTB-714 Page 61 22 June 1985
as possible, for example when the workstation requests the current scroll
position. When window creation is requested, terminal control will create the
iocb, and start a control point (i.e. a task) with standard iocbs mapped to the
newly created iocb. Terminal control will isolate the user from having to
perform selection commands by wrapping the correct selection commands around an
I/O request done to an inactive window.
How will terminal control map MWP Operations into the correct DCS strings?
One possibility is to extend the TTF [Multics 83a] to include entries for each
new operation. This is deficient because it would require major changes to add
new types of arguments to TTF sequences, and since MWP only needs to describe
one set of sequences, the generic terminal type definition interface and its
supporting programs need not be modified. Instead, include file definitions of
the sequences will be used and much knowledge of the individual requests will
reside in the code itself. In the long run a more flexible replacement for the
TTF should be developed.
_____ ___
Initial dialog will be started via a new control order start_mwp, which
will cause terminal control will do any necessary initialization, negotiate for
the implemented options, and inform the workstation of existing windows on
Multics.
A Remote Window System Protocol Rochlis
MTB-714 Page 62 22 June 1985
B.3 Future Modifications
The next obvious candidate for modification is menu_. This would allow
existing menu based applications to take advantage of the workstations choice
facilities. However, there is a problem. The existing Multics menu facility
assumes that the is forced to make a choice, but many workstation allow the
user to abort any menu at any time. This will have to be resolved. It would
also be nice to enhance menu_ to take advantage of the new features found in
the MWP menu protocol, such as the active menu list. After this more
processing could be moved out of window_io_iox_.pl1 and into the workstation by
implementing the option described in section 2.2.6. Further MWP extensions, as
described in chapter 4, would also fit in well with existing Multics software.
Extensions such as translation tables or local echo negotiation would require
few changes on Multics, but could represent a large increase in performance and
functionality.
A Remote Window System Protocol Rochlis
MTB-714 Page 63 22 June 1985
References
References
References
[Apollo 84] Schulert, Andrew J., George T. Rogers, James A. Hamilton.
___ _ ______ _______
ADM - A Dialog Manager.
Technical Report, Apollo Computer, Inc., 1984.
[CMU 84] Gosling, James A., Rosenthal, David S. H.
_ _______ ______ _______
A Network Window-Manager.
Technical Report, Information Technology Center, Carnegie-Mellon
University, 1984.
[ISO 83]
Additional Control Functions for Character-imaging Devices.
International Organization for Standardization.
ISO-standard number 6429.
[LISPM 83] Stallman, Richard M., Moon, David, Daniel Weinreb.
____ _______ ______ ______ ______
Lisp Machine Window System Manual
MIT A.I. Lab, 1983.
______ _________
[Macintosh 84] Inside Macintosh
Apple Computer Company, 1984.
A Remote Window System Protocol Rochlis
MTB-714 Page 64 22 June 1985
[Margolin 85] Margolin, Barry.
_____ ____ ___________
Local Echo Negotiation.
MTB 708, Honeywell Information Systems, March, 1985.
_______ __________ _ _________ ______
[Multics 83a] Multics Programmer's Reference Manual
AG93-03 edition, Honeywell Information Systems, 1983.
_______ ____ ________ __________ ______
[Multics 83b] Multics Menu Creation Facilities Manual
CP51-01C edition, Honeywell Information Systems, 1983.
[Postel 80] Postel, J. B.
______ ________ _____________
TELNET Protocol Specification.
RFC 764, ARPA Network Information Center, June, 1980.
[Stallman 82a] Stallman, Richard M.
______
SUPDUP.
AIMEMO 644, MIT A.I. Lab, March, 1982.
[Stallman 82b] Stallman, Richard M.
_ _____ _____ ___ ___ ______ _______
A Local Front End for Remote Editing.
AIMEMO 643, MIT A.I. Lab, Febuary, 1982.
____ __________ _ ______
[Unix 83] Unix Programmer's Manual
University of California, Berkeley, 1983.
A Remote Window System Protocol Rochlis