To: MTB Distribution

             From: Jon Rochlis

             Date: 22 June 1985

             Subject: A Remote Window System Procotol for Multics


                  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
               Smarter Terminals                                          8
               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


                  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

    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
             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.

    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


                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
             Micro-vaxes, and inexpensive systems such as Apple's Macintosh  [Macintosh 84].


                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


             A Remote Window System Protocol                                         Rochlis

             MTB-714                             Page 15                        22 June 1985

                                                Chapter 2
                                                Chapter 2
                                                Chapter 2


                                                          _______ ___________ ________
                  This chapter describes the goals of the Multics Workstation Protocol (MWP)
                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


                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
             "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


                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
             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


             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.


                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 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   command,   defined   in  section  2.2.3,  returning  a
                             ______ ______

             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 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 option     indicates the sender wishes to perform option, or confirms that
                             the sender is performing option.

             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 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 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 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 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 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 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
                             surface  functions,  it  should send a selection command to the
                             host, after receiving a surface command.  The  host  should  be
                             prepared for this.

             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 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 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 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            specifies  the  name  of  the  window.      The
                                             workstation   should   use   this   name   when
                                             displaying window information to the user.

                             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

                             size            the size of the window.  Again this is  an  X,Y
                                             pair,  giving  the  number of columns and rows,

                             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  parameter  may  take  three  values:
                                             HORIZONTAL, VERTICAL, or BOTH.  If absent,  the
                                             window is not capable of scrolling.

             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

             negotiated        the        scrolling_vertical_version_1        or         the

             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 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 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 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 window-handle [top-line-number] [total-lines] [leftmost-column]
                              _____ _______
                                                   _______ ______ ________
                             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 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 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

             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

             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 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 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.

                             clears all menus from the active state.

             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 menu-handle-1 menu-handle-2 ... menu-handle-N
                             removes the specified menu(s) from the active state.

             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 window-handle
                             enables local more processing for the specified window.

             disable_more_processing ______ ______
             disable_more_processing window-handle
                             disables local more processing for the specified window.

             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          old lines scroll off the top of the window, new
                                             lines  are displayed in the spaced freed.  This
                                             should be the default.

                             wrap            new lines are displayed starting at the top  of
                                             the window, erasing old lines as they go along.

                             clear           the  window  is cleared and new text appears at
                                             the top of the window.

             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 window-handle
                             tells  the  host  to continue sending output to the workstation
                             after a pause for a more break.

             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.  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.

                             a necessary argument was not supplied.

                             a  supplied argument has an invalid value.  More specific error
                             message are preferable.

             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

                                ______ ______
                             a  window-handle  was  supplied  which does not correspond to a
                             existing window.

                             the size parameter is too large to fit on the screen.

                             the location parameter is not on the screen.

             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.

                             the  version  of  the  desk  management as described in section

             A Remote Window System Protocol                                         Rochlis

             MTB-714                             Page 31                        22 June 1985

                             the version of the scrolling protocol defined in section 2.2.4,
                             with vertical scrolling.

                             the version of the scrolling protocol defined in section 2.2.4,
                             with horizontal scrolling.

                             the version of the menu protocol described in section 2.2.5.

                             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

             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



                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


                  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


             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


                  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


             A Remote Window System Protocol                                         Rochlis

             MTB-714                             Page 39                        22 June 1985

                                                Chapter 5
                                                Chapter 5
                                                Chapter 5


                  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


             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


                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



                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
                   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.

                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

                                          ______ ____         ____ _____
                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");


                         1. version (Input)
                       is  the  version  of  the  structure.    The  current version is

                        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.


                      dcl window_$start_mwp (fixed bin(35));
                      call window_$start_mwp (code)


                        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.


                      dcl window_$select (ptr, fixed bin(35));
                      call window_$select (window_iocb_ptr, code);


                        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


                      dcl window_$surface (ptr, fixed bin(35));
                      call window_$surface (window_iocb_ptr, code);


                        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.


                      dcl window_$bury (ptr, fixed bin(35));
                      call window_$bury (window_iocb_ptr, code);


                        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.


                      dcl window_$move (ptr, ptr, fixed bin(35);
                      call   window_$move   (window_iocb_ptr,  window_position_info_ptr,


                        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.


                      dcl window_$resize entry (ptr, ptr, fixed bin(35);
                      call  window_$resize  (window_iocb_ptr,  window_position_info_ptr,


                        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



                 Entry: window_$disable_scrolling

                      This entry is used to disable scrolling for the specified window.


                      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);


                        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.


                      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);


                        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);


                        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

                        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.


                      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)


                        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

                 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

                 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

                 dcl OP_SURFACE_WINDOW fixed bin initial(20) internal static options

                 dcl OP_BURY_WINDOW fixed bin initial(21) internal static options

                 dcl OP_MOVE_WINDOW fixed bin initial(22) internal static options

                 dcl OP_RESIZE_WINDOW fixed bin initial(23) internal static options

                 dcl OP_SET_WINDOW_INFO fixed bin initial (24) internal static options

                 dcl 1 request_set_window_info aligned like request_create
                           based (request_ptr);

                 dcl OP_DISABLE_SCROLLING fixed bin initial (25) internal static options

                 dcl OP_ENABLE_SCROLLING fixed bin initial (26) internal static options

                 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


             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


             A Remote Window System Protocol                                         Rochlis

             MTB-714                             Page 63                        22 June 1985


             [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.


                            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