From:         William M. York

Date:         March 4, 1983

To:           MTB Distribution

Subject:      Video System Plans for the Foreseeable Future


With the installation  of MR 10.1, the video  system has become a
useful  and  useable product  for  the entire  Multics community.
Gone are  the days when the  only users of the  video system were
those  who  considered  processes  cheap, and  who  preferred the
thrill of living on the video edge to the stability of the normal
printing terminal environment.

In spite of all of this progress, there is still a lot of work to
be done on the video  system.  There are many additional features
that  should be  added to bring  about a full  realization of the
managed video environment on Multics.  This paper is a discussion
of the  major defficiencies of  the current video  system and how
they should be addressed.

Some  of  the  work  described   herin  has  been  scheduled  for
implementation and installation in  MR 10.2.  The remaining items
will be scheduled and implemented as resources permit.

I may be  contacted via computer mail on  MIT's Multics system or
System M  as York.Multics.  Comments  may also be  entered in the
>udd>m>bim>forum>Video meetings on either system.

For those of you preferring more traditional media, my U.S.  Mail
address and phone number are:

          William M. York
          Cambridge Information Systems Laboratory
          Honeywell Information Systems, Inc.
          575 Tech Sq.
          Cambridge, MA  02139

          617-492-9314 (HVN 261-9314).


This is a Multics Project internal working document and is not to

Video Plans                                               MTB 619

                        Table of Contents

1      New Features  . . . . . . . . . . . . . . . . .  1
1.1    User Defined Editor Key Bindings  . . . . . . .  1
1.1.1  User-written Editor Requests  . . . . . . . . .  1
1.1.2  Changing Key Bindings . . . . . . . . . . . . .  3
1.1.3  The Editor Utility Routine Library  . . . . . .  5
1.2    TTF Enhancements  . . . . . . . . . . . . . . .  6
1.2.1  New Fields for Current TTF  . . . . . . . . . .  7
1.2.2  New TTF Mechanism . . . . . . . . . . . . . . .  7

2      Improvements to Existing Capabilities . . . . .  8
2.1    Co-Existence with tty_  . . . . . . . . . . . .  8
2.1.1  Saving and Restoring tty_ State . . . . . . . .  8
2.1.2  Output Conversions  . . . . . . . . . . . . . .  8
2.1.3  Input Canonicalization  . . . . . . . . . . . .  8
2.1.4  resetread and resetwrite  . . . . . . . . . . .  9
2.2    Video Reconnection  . . . . . . . . . . . . . . 10
2.3    window_call Extensions and io_call Support  . . 10
2.4    Vertically-divided Windows  . . . . . . . . . . 11
2.5    Performance Improvements  . . . . . . . . . . . 12
2.5.1  Tuning Output Buffering . . . . . . . . . . . . 12
2.5.2  Code Restructuring  . . . . . . . . . . . . . . 12
2.6    Asynchronous Event Handling . . . . . . . . . . 13
2.7    Hardcore Changes: hcs_$tty_write_whole_string . 14

3      Schedule  . . . . . . . . . . . . . . . . . . . 15
3.1    Time Estimates  . . . . . . . . . . . . . . . . 15
3.2    Recommendations . . . . . . . . . . . . . . . . 15

Video Plans                                               MTB 619

                         1  NEW FEATURES

The features provided by the  current video system are sufficient
to implement  a large set of  video applications.  However, there
are several  additional capabilities that  would greatly simplify
many video  applications.  This section  describes these proposed
extensions and how they would be used.


MR 10.1  video provides the  user with a full  input line editor,
including  the ability  to edit  in the  middle of  the line.  Of
course,  there are  many potential  editor functions  that people
would like to  use (see the Emacs Text  Editor User's Guide), and
not all of these are provided.  Rather than attempt to anticipate
every possible editor request, the  video system should provide a
simple  mechanism which  allows users  to write  their own editor
requests  and  associate  sequences   of  keystrokes  with  these

This key binding mechanism can can  be used for a wide variety of
applications.   Since   these  editor  requests   are  triggerred
immediately  by  single or  multiple keystroke  sequences, highly
interactive facilities  can be built into  the input line editor.
These  facilities include  such things as  command completion and
argument prompting at command level, interactive help facilities,
and  real-time  expansion  of  abbreviations  for  commonly typed

1.1.1 User-written Editor Requests

Editor  request  routines  are  simply PL/I  programs  which must
conform to a standard calling sequence.  The request procedure is
given complete control of the input  buffer and can add or delete
characters  or modify  the current  contents of  the buffer.  The
video system editor's redisplay  facility will manage all display
updates; the individual editor routines  need no knowledge of the
video enviroment or the screen contents.

A library of editor utility routines will be provided.  These can
be called by user-written editor routines to perform such actions
as insertion  and deletion of text  from the buffer, manipulation
of  the kill  ring, and  manipulation of  words within  the input
buffer.  The available line editor utility routines are described

MTB 619                                               Video Plans

A line editor routine is delcared as follows:

dcl twiddle_words entry (pointer, fixed bin(35));
call twiddle_words (line_editor_info_ptr, code);


     is  a   pointer  to  the   line_editor_info  data  structure
     (described below).

code  (output)
     is a standard  status code.  If the status  code returned by
     the editor routine is error_table_$action_not_performed, the
     editor  will  ring the  terminal bell  to indicate  that the
     editor  routine was  used improperly.  ring  the bell).  Any
     other code will  reported in a more drastic  manner, via the
     sub_err_ mechanism.

     The     line_editor_info      structure     (declared     in
     window_line_editor.incl.pl1) is declared as follows:

     dcl  1 line_editor_info       aligned based (line_editor_info_ptr),
            2 version              char(8),
            2 repetition_count     fixed bin,
            2 flags,
              3 return_from_editor bit(1) unaligned,
              3 merge_next_kill    bit(1) unaligned,
              3 old_merge_next_kill bit(1) unaligned,
              3 pad                bit(30) unaligned,
            2 cursor_index         fixed bin(21),
            2 line_length          fixed bin(21),
            2 input_buffer         character(1024) unaligned;

     dcl  line_editor_input_line   char(line_editor_info.line_length)
          based (addr (line_editor_info.input_buffer));

     dcl  line_editor_info_version_1
          char(8) static options (constant) init ("lei00001");


     version (input)
          is the version string  for this structure.  The current
          version  string,  "lei00001",  is   the  value  of  the
          variable  line_editor_info_version_1,  declared  in the
          same include file.

     repetition_count (input)
          is the  value of the numeric  argument specified by the
          user, with a default value  of 1 if no numeric argument
          was specified.

Video Plans                                               MTB 619

return_from_editor (output)
     is a flag  which is set by the editor  routine if the editor
     invocation is  to be terminated and  the input line returned
     to the caller.

merge_next_kill (input/output)
     is a flag which should be set when text is deleted and added
     to the kill ring if subsequent  deletions are to be added to
     the  same kill  ring element.  This  flag is  managed by the
     editor  utility routines.   If they  are used  for all input
     buffer modifications,  the user-written editor  routine need
     never set this flag.

old_merge_next_kill (not used)
     is an internal editor state flag and should not be modified.

cursor_index (input/output)
     is the index  of the character in the  input buffer on which
     the cursor is currently located.  This index must be updated
     if characters are added or deleted before the cursor, or the
     cursor  is moved  by the  editor routine.   The cursor index
     must   be   no   larger    than   one   greater   than   the
     input_line_length.  If the editor  utility routines are used
     for all input buffer manipulations, the cursor_index will be
     updated appropraitely.

line_length (input/output)
     is a count of the number  of characters in the current input
     line.  This  variable must be updated  if any characters are
     inserted or deleted from the input buffer.  The value of the
     line_length variable  must always be  non-negative, and must
     never be larger than the length of the input buffer.  If the
     line editor  utility routines are used  for all input buffer
     manipulations,  the  line_length  variable  will  be updated

input_buffer (input/output)
     is  a character  string containing  the current  input line.
     Any  manipulations may  be performed  on this  string by the
     editor routine.   It is recommended that  the editor utility
     routines be used for all  insertions and deletions to ensure
     that   the   various  state   variables  and   flags  remain
     consistent.  The line_editor_input_line variable can be used
     to address the valid part of the input buffer as a string.

1.1.2 Changing Key Bindings

A line  editor routine is  bound to a sequence  of keystrokes via
the  set_editor_key_bindings  control  order.   The  sequence  of
characters that triggers an editor  request may be of any length,
with  multiple-key  sequences  working   like  the  Emacs  prefix
characters.  This allows the use of terminal function keys (which

MTB 619                                               Video Plans

often  send  three or  more character  sequences) to  invoke line
editor  requests.   More  than  one binding  can  be  set  in one
invocation  of this  control order.   The info_ptr  points at the
following structure (declared in window_line_editor.incl.pl1):

dcl 1 line_editor_key_binding_info
                              aligned based (window_key_binding_info_ptr),
      2 version               char(8),
      2 binding_count         fixed bin,
      2 longest_sequence      fixed bin,
      2 bindings              (0 refer
        3 sequence            char(0 refer
                              (line_editor_key_binding.longest_sequence)) varying,
        3 type                fixed bin,
        3 editor_routine      entry (pointer, fixed bin(35));


version             (input)
     is the version string for the structure.  The current version
     string, "lekb0001", is the value of the variable
     line_editor_key_binding_info_version_1, declared in the same
     include file.

     is the number of editor requests described in the structure.

     is the length in characters of the longest keystroke sequence
     defined in the structure.

     is the character string representing the keystrokes that must be
     typed to the each editor request.  This string is interpreted
     literally, with no special conventions for representing
     non-printing ACSII characters.  To define an editor request that
     is to be invoked when  the user types control A, the string
     should contain the single ASCII character 001.

     determines whether the editor routine to be bound to the
     keystroke sequence is an external user-supplied routine, or one
     of the existing built-in editor requests.  The include file
     window_editor_values.incl.pl1 defines a set of named constants
     corresponding to the built-in requests.  If the type field is set
     to EXTERNAL_REQUEST (value 0), the procedure specified by the
     editor_routine entry variable in this structure will be called
     when the specified keystroke sequence is type.  If it is any of
     the other values defined in the include file, the corresponding
     built-in request will be bound to the specified sequence.  The
     variables corresponding to built-in requests are EXTERNAL_ROUTINE,

Video Plans                                               MTB 619


     if type = EXTERAL_ROUTINE, is the routine that is to be invoked
     when the specified keystroke sequence is typed.

1.1.3 The Editor Utility Routine Library

As was mentioned above, a library of editor utility routines will
be  provided  for the  benefit  of user-written  editor routines.
Some operations may be performed  simply by a user-written editor
routine.  For example,  to position the cursor to  the end of the
line, simply  set the cursor_index  variable to one  greater than
the value of the line_length variable.  However, most actions are
more  complex than  this and  it is  recommended that  the editor
utility  routines  be  used  to  perform  most  operations.   The
following  is  a description  of these  routines.  In  all cases,
line_editor_info_ptr is the pointer  to the editor data structure
that is supplied as an argument to user-written editor routines.

dcl window_editor_util_$insert_text entry (ptr, char(*), code);
call window_editor_util_$insert_text (line_editor_info_ptr, "foo", code);

This routine inserts the supplied character string into the input
buffer  at the  current cursor  location.  If  the string  is too
large   to  fit   in  the   remaining  buffer   space,  the  code
error_table_$action_not_performed  is   returned.   This  routine
updates the line_length field of the line_editor_info structure.

dcl window_editor_util_$delete_text entry (ptr, fixed bin, code);
call window_editor_util_$delete_text (line_editor_info_ptr, count, code);

This routine  deletes a specified number  of characters (supplied
by  the  variable count)  from  the input  buffer at  the current
cursor  location.  If  there are not  enough characters remaining
between    the    cursor    and    the   end    of    the   line,
error_table_$action_not_performed  is returned  and no characters
are    deleted.     The     line_length    component    of    the
line_editor_info_structure is updated.

dcl window_editor_util_$delete_text_save entry (ptr, fixed bin,
    bit(1), code);
call window_editor_util_$delete_text_save (line_editor_info_ptr, count,
     kill_direction, code);

MTB 619                                               Video Plans

This  entrypoint is  idenentical to delete_text,  but the deleted
text is added to the kill  ring.  The kill_direction flag is used
during  kill mergng  to decide  whether the  killed text  will be
concatenated onto the  beginning or end of the  current kill ring
element.   "1"b   is  used  to  specify   a  forward  kill  (e.g.
FORWARD_DELETE_WORD), "0" a backward kill.

dcl window_editor_util_$move_forward entry (ptr, fixed bin, code);
call window_editor_util_$move_forward (line_editor_info_ptr, count, code);

This entrypoint is used to advance the cursor forward a specified
number of  characters (supplied by  the variable "count")  in the
input  line.   If there  are  not enough  characters  between the
cursor and the end of the line, error_table_$action_not_performed
is returned.

dcl window_editor_util_$move_backward entry (ptr, fixed bin, code);
call window_editor_util_$move_backward (line_editor_info_ptr, count, code);

This entrypoint is  used to move the cursor  backward a specified
number of  characters (supplied by  the variable "count")  in the
input  line.   If there  are  not enough  characters  between the
cursor and the end of the line, error_table_$action_not_performed
is returned.

dcl window_editor_util_$move_forward_word entry (ptr, code);
call window_editor_util_$move_forward_word (line_editor_info_ptr, code);

This entrypoint updates the cursor_index  to a position after the
next word  (or token) in the  input line.  A word  is defined via
the   editor's   set   of   token   delimiters,   set   via   the
set_token_delimiters control order.

dcl window_editor_util_$move_backward_word entry (ptr, code);
call window_editor_util_$move_backward_word (line_editor_info_ptr, code);

This entrypoint updates the cursor_index to a position before the
preceeding word (or token) in the  input line.  A word is defined
via  the   editor's  set  of   token  delimiters,  set   via  the
set_token_delimiters control order.

Additional editor utility routines may be supplied in the future.


The current TTF mechanism has  many limitations to its ability to
support  video  terminals.   Some  of  these  limitations  can be
elimitated  through  minor  extensions to  the  current software,
while others require a new  implementation of the entire terminal
capability description system.

Video Plans                                               MTB 619

1.2.1 New Fields for Current TTF

There are several attributes of many modern video terminals which
are not described in the  current TTF language or data structure.
Many  of  these  attributes  are  either  state  flags  or simple
character sequences, and can therefore  be handled by the current
TTF and video data implementation.  These attributes include such
features as  whether or not the  terminal can overstrike, whether
or not  the terminal has native  full-screen scrolling, the begin
and  end  highlighting  sequences,  the begin  and  end underline
sequences (if any), and the clear  to beginning of line and go to
begining of line sequences (if any).

Several new keywords will be added  to the TTF format to describe
these new  sequences.  Their syntax follows  that of the existing
keywords  (e.g.   cursor_up).   These  keywords  are move_to_bol,
clear_to_bol,  begin_underline,  end_underline,  begin_highlight,
and  end_highlight.   The  state  flags  will  be  specified  via
keywords that  take no arguments.  These  keywords are overstrike
and native_scroll.  To complete support for these new fields, the
data structure  returned by ttt_info_$video_info  must be changed
to include  the new fields, and  new primitive terminal sequences
must  be defined.   The native_scroll  bit will  be added  to the
flags section of the  tty_video_table data structure (declared in
tty_video_tables.incl.pl1), and the named constands CLEAR_TO_BOL,
END_HIGHLIGHT  will  be  added  to  represent  the  new  terminal
sequences.  These changes are  completely upwards compatible with
the  current version.   Nevertheless, the  version number  of the
tty_video_table structure will  be changed from 1 to  2 to ensure
that  an  application written  to  rely on  the  new flag  in the
version 2 structure never mistakenly calls a version of ttt_info_
that only supports the version 1 structure.

1.2.2 New TTF Mechanism

There are some terminal attributes (such as VT100 scroll regions)
which cannot easily be described using the current TTF mechanism.
The design of a new mechanism to handle these capabilities is the
subject of a future MTB.

MTB 619                                               Video Plans


There   are   several   areas   of  the   current   video  system
implementation  which need  improvement.  Some  of these problems
are  actual  bugs, while  other  are limitations  of  the current


If  the  video system  is ever  to replace  tty_ as  the standard
terminal  I/O system,  it must  first provide  all of  the useful
features currently  available, as well  as some of  the less than
useful ones for compatability's sake.

2.1.1 Saving and Restoring tty_ State

Currently the video  system saves the tty_ modes  in effect which
it  is  invoked  and restores  them  when reverting  back  to the
non-video environment.  Unfortunately, this is the only attribute
of the  tty_ environment which  it does save.   The delay values,
conversion  tables,  output suspend/resume  characters  and frame
characters  should  also be  saved  and restored  across  a video
system invocation.  In addition,  the conversion tables in effect
when video  is invoked should  be used as the  initial values for
their video counterparts.

2.1.2 Output Conversions

In addition  to simply saving  the tty_ output  conversion tables
across a video  session, the video system will  be changed to use
the  current  output  conversion  table  values  when  processing
output.   Currently  output conversions  are performed  using the
conversion table  specified in the  TTF rather than  the table in
effect when the video system  was invoked.  The video system will
be  changed  to  copy the  tty_  output conversion  table  into a
per-window  conversion  table  as  each  window  is  created.  In
addition, the  tty_ control orders  set_ and get_conversion_table
will  be supported  on a per-window  basis in  the window_io_ I/O
module.  The original tty_ conversion table will be restored when
video is revoked.

2.1.3 Input Canonicalization

The video system  is currently incompatible with tty_  in that it
does  not perform  canonicalization on  lines read  via the input
line editor.  This decision is based on the "what you see is what

Video Plans                                               MTB 619

you get" model of real-time editing.  If the user types "B<BS>A",
the display shows B followed by  backspace followed by A, and the
input line returned to the  caller preserves that ordering.  This
is  the  same  result  that  Emacs  gives  when  editing  a file.
However, in order to maintain  compatability for those people who
are  concerned,  the setting  of "can"  mode (which  is currently
ignored) will determine whether or  not lines read with the input
line  editor will  be passed  through canonicalize_  before being
returned to the caller.

2.1.4 resetread and resetwrite

One of the major deficiencies of  the current video system is the
lack of support for the  resetread and resetwrite control orders.
Both of  these control orders  are difficult to  implement in the
current video  system, and were therefore  passed over in earlier
development efforts.  However, they must be added soon.

The major problem in  implementing resetread is determining which
of the  pending input characters are  intended for which windows.
A  resetread  order performed  on one  window should  not discard
input intended for another.  The  solution is to always designate
one window as the current window,  and earmark all input for that
window until some other window  is made the current window.  Thus
every call  to request input  will read all  available characters
out of  ring 0 into a  per-window buffer for  the current window.
This enables  the video system  to discard only  that input which
could  be  read by  input  requests on  the  window on  which the
resetread is performed.

The  resetwrite control  order is  a more  difficult problem.  In
order to manage  the video environment, the video  system must at
all times keep track of  exactly what characters are displayed on
the  screen and  where the  cursor is  located.  This essentially
amounts to  knowing the effect  of each character  or sequence of
characters  that  is  sent  to  the  terminal.   In  the  current
implementation, the state information is updated as the sequences
are  generated  in  the   terminal  control  level.   To  improve
performance, all characters so generated  are kept in an internal
buffer and  only sent to ring 0  and on to the  terminal when the
buffer  fills.   The contents  of  this buffer  cannot  simply be
discarded upon receipt of a  resetwrite control order because the
state information  has already been updated  to indicate what the
state  of the  terminal will  be after  it receives  the buffered

One solution to  this problem is to maintain  two parallel copies
of  all terminal  state information, including  the screen image.
The first copy  is updated as the terminal  requests are received
from the caller and the  character sequences are deposited in the
buffer.  This first copy of the  state information can be used in
subsequent  redisplay optimization  calculations, even  though it

MTB 619                                               Video Plans

does  not describe  the current  state of  the physical terminal.
When the buffer is finally sent to ring 0, all of the data in the
first  copy of  the state information  is copied  into the second
copy.   When   a  resetwrite  control  order   is  received,  the
partially-filled  output  buffer  is   discarded  and  the  state
information in copy one is "backed  out" by replacing it with the
information  currently  in copy  two,  which reflects  the actual
state of the terminal.


Currently,  the  video  system  has  no  provision  for  changing
terminal  types in  the middle  of an  invocation.  This presents
some  significant problems  during process  reconnection.  If the
user neglects to set the  Multics terminal type before connecting
to  a  suspended process  and  the default  terminal type  is not
supported  by the  video system  (e.g.  ASCII),  the video system
will not be  able to re-open the I/O switches  and the process is
destroyed.   The video  system should  instead try  to revoke the
video envionment and revert to a normal tty_ attachment.

Even if the  user sets the terminal type  to a supported terminal
before reconnecting the reconnection  may not succeed.  The video
system currently  reinitializes the state  information managed by
the terminal control level to  reflect the characteristics of the
new  terminal.   However,  the  window  level  state  information
remains unaffected  by the reconnection.   This can lead  to such
problems as windows that no longer can fit on the screen.  If the
user_i/o window is hit by this, the user receives a fatal process
error after reconnection.  The solution to this is to implement a
new  window  status  bit  to  indicate  that  a  reconnection has
occurred.  It is the  application's responsibility to re-size its
windows appropriately.  System windows (such as user_i/o) will be
handled by the video system on reconnection.

2.3  window_call Extensions and io_call Support

There are  several useful video  system functions that  cannot be
invoked  via  any command  level  interface.  This  means  that a
program  must  be written  to perform  such simple  operations as
setting the more prompt string and responses.  These capabilities
will be made more easily  accessable by extending the window_call
command and providing io_call support  for more of the window_io_
control orders.

Two new keywords should be added to the window_call command.  The
"supported_terminal"  keyword  is used  to  determine if  a given
Multics terminal  type is supported under  the video system.  The
terminal can be  specified via the -ttp control  argument.  If no
terminal type  is specified, the user's  current terminal type is

Video Plans                                               MTB 619

used.  This can  be used in start_up's to  determine if the video
system  can  be invoked  successfully in  the user's  process.  A
second keyword, "video_invoked", will indicate whether or not the
video system is in effect in  the current process.  Both of these
keywords   can  be   used  in  active   function  invocations  of

The  new  window_io_ control  orders  that will  be  supported by
io_call     are     get/set_more_prompt,    get/set_more_handler,
get/set_more_responses,                 get/set_token_characters,
get/set_window_status    and    get/set_editing_chars.     Syntax
specifications for these io_call command lines follow:

io_call control user_i/o set_more_prompt prompt_string

     where  the  prompt  string  is  an  ioa_  control  string as
     described  in  the  set_more_prompt control  order.   If the
     prompt string contains blanks  or special characters it must
     be quoted.

io control user_i/o set_more_handler more_handler

     where  more_handler is  the entryname  of the  routine to be
     used as the more handler  routine.  The name is converted to
     an entry using  the user's search rules and  is then used as
     described in the set_more_handler control order.

io control user_i/o set_more_responses yes_responses no_responses

     where  the yes_responses  and no_responses  will be  used as
     arguments  to  the  set_more_responses  control  order.   If
     either  of the  response strings contains  blanks or special
     characters, it must be quoted.

io control user_i/o set_editing_chars erase_kill_characters

     where  erase_kill_characters  is   a  two  character  string
     specifying the new erase and kill characters.

io control user_i/o set_window_status status_key_1 {status_key_2}

     where    status_key_i    is    either    screen_invalid   or

The  get_  form  of  each  control  order  listed  above  is also
supported,  and  may be  used in  active function  invocations of


MTB 619                                               Video Plans

The video system does not  currently support windows which do not
extend across the entire width  of the screen.  There are certain
problems  supporting  effecient  redisplay  of  such  windows  on
terminals   which   lack  certain   capabilities,  but   that  is
insufficient reason  to prohibit their use.   There are currently
provisions made for specifying window  widths in most of the data
structures describing window bounds,  but actual support for such
windows was never implemented.


Video  system performance  was improved dramatically  in MR 10.1.
However,  it  is still  more expensive  in terms  of cpu  time to
perform simple output in the video system than via tty_.

2.5.1 Tuning Output Buffering

The video system  was changed in MR 10.1 to  buffer output at the
terminal control level and send  the entire buffer to ring 0 when
the  buffer  fills.  The  number  of characters  that  ring 0 can
accept on each  call varies with the speed  of the communications
(i.e.  how fast the characters from the previous call can be sent
to the terminal)  line.  The output buffers is  currently a fixed
size  (256  characters),  but  it   should  be  tailored  to  the
characteristics of the user's  communications channel in order to
cut down on  the number of unsuccessful calls  into ring 0.  Some
metering has to be done to determine the correct buffer sizes for
various  baud  rates, and  the  size of  the  buffer can  then be
determined at the time the tc_io_ switch is opened.

Another solution  to this problem  is to adjust  the input buffer
size based on  the success rate of previous  calls to hcs_.  This
would require maintaining internal meters  on the number of calls
to hcs_ and the number of these  calls that failed due to lack of
avaiable buffer  space.  The buffer  size will range  from 100 to
1000 characters, with an initial value  of 512.  If the number of
failures grows  to 10% of  the total number of  calls, the buffer
size  will  be  recuded  by 100  characters.   If  the  number of
failures  drops  to  2% of  the  calls  the buffer  size  will be
increased  by 100  characters.  Using  this mechanism  the buffer
size  should be  optimized for all  ranges of line  speed and I/O

The first  of these two  solutions (matching buffer  size to line
speed) will  be implemented and  metering will be  performed.  If
the  results  of  this  metering indicate  that  further  work is
necessary, the second scheme will be implemented.

2.5.2 Code Restructuring

Video Plans                                               MTB 619

There is a  large amount of internal overhead  in performing even
simple  operations in  the video  system.  Each  call to  a video
system routine results in a large number of internal calls (32 to
output a  simple six-character string,  almost 400 to  print a 10
line file), as well as a fair amount of data copying.

Each  time  a  window_  entrypoint is  called  it  builds  a data
structure describing the operation to  be performed on the window
and  calls  iox_$control  to  pass   this  structure  on  to  the
window_io_  I/O  module.  The  control  order is  handled  by the
module  window_io_video_,  which  in  turn builds  a  second data
structure,  copies  all  of  the important  information  from the
structure that it was given,  makes another control order call on
the tc_io_  switch to perform the  actual terminal operation, and
then updates the window's state information.

Since window_ and window_io_video_ both  belong to the same level
of the video system and have  access to the same data structures,
this extra level of indirection  is unnecessary.  The two modules
will be merged so that each window_ entrypoint will call terminal
control  and update  the window  level state  information itself.
There will be  no user interface changes.  This  change will also
increase  the maintainability  of the  video system,  since it is
difficult to tell without looking which module is responsible for
which stages of the operation.

By merging these two modules and making one other minor change to
the  arrangement  of the  video  system code,  nearly 1/2  of the
external  calls  (and the  associated stack  frame manipulations)
among modules of the video system  for a simple file printing can
be eliminated.


Asynchronous  events (such  as timers  or terminal disconnection)
pose  a  big  problem  in  the  managed  video  environment.  Any
asynchronous change to a  window can invalidate assumptions being
made by an application about  current contents of the window, the
location   of  the   cursor,  etc.   Therefore,   an  error  code
(video_et_$window_status_pending)   is    returned   by   window_
entrypoints  whenever  such an  event  occurrs.  When  the caller
receives  this status  code, it must  perform a get_window_status
order call to determine exactly  what has happened, and then take
any necessary action before proceeding.

Unfortunately,  this  interface can  make  for some  very tedious
programming.  All  video applications must check  the status code
after each call  in order to determine if  any asynchronous event
has  occurred in  the window.  A  better solution  can be devised
using the PL/I signalling mechanism to pass this information from
the  video system  to the application.   Naturally this mechanism

MTB 619                                               Video Plans

cannot be  enabled by default, since  existing video applications
are  not  prepared  to  deal with  any  conditions  which  may be
signalled,  so  entrypoints  have  been  provided  to  enable and
disable this facility.

Under  the new  scheme, wherever  a window_  entrypoint currently
returns  the  window_status_pending error  code, it  will instead
signal  the  window_asynchronous_change  condition.   Each  video
application  will establish  a handler  for this  condition.  The
actions performed by this handler are the same as those performed
in   current  implementations   of  video   applications  when  a
window_status_pending error  code is received.   A data structure
is passed  to the handler (via  find_condition_info_) to indicate
what event caused the signal and which window was involved.

dcl 1 window_pending_status aligned based,
      2 version               char(8),
      2 window_iocb           ptr,
      2 status                aligned like window_status;

where    the    window_status    structure    is    declared   in

Note that these  signals are only generated by  calls to window_,
so it is  certain that the video application  is currently on the
stack  (and, in  the tasking environment,  that the  stack is the
correct  stack).  If  no handler can  be found on  the stack, the
standard unclaimed signal mechanism will be invoked.

Naturally the video system cannot simply begin signalling instead
of  returning  error  codes   since  all  existing  video  system
applications are  not prepared to handle  the condition.  Two new
window_        entrypoints,        enable_status_signal       and
disable_status_signal,  will be  implemented.  Applications which
prefer  to  use  the  signalling mechanism  over  the traditional
status  code  checking can  call  these entrypoints  to  turn the
signalling on and off.   All interactive video applications, such
as XMAIL, can benefit from this change.


The  video system  uses the  tty_write_whole_string entrypoint to
send output to the terminal.   The contract of this entrypoint is
to either write  all of the characters that it  is passed or none
of  them.  If  there is  not enough  room available  to write the
entire    string,   the    routine   is    supposed   to   return
error_table_$bigarg and queue a wakeup  for the process when more
room becomes available.  Unfortunately, the wakeup is not queued.
The   current  video   system  bypasses   this  bug   by  calling
timer_manager_$sleep and then trying again.  The ring 0 code will
be changed to queue a wakeup for the process.

Video Plans                                               MTB 619

                           3  SCHEDULE

The  implementation  of  all  of the  changes  described  in this
document  would require  a tremendous amount  of effort.  Clearly
some  ordering  of  the  items must  be  performed  and resources
allocated to complete the most important of these.


The following is a list of tasks discussed in this MTB and a time
estimate for the completion of each.

User definable key bindings                      4 weeks
New TTF fields                                   3 weeks
Preserving tty_ state across video invocation    2 weeks
resetread                                        4 weeks
resetwrite                                       4 weeks
Output conversion                                1 week
Input canonicalization                           1 week
Improve reconnection to video processes          4-6 weeks
window_call extensions and io_call support       1 week
Vertical windows                                 3 weeks
Tuning output buffering                          2 weeks
Code restructuring                               2 weeks
Asynchronous event handling                      4 weeks
hcs_$tty_write_whole_string fix                  1 week


There are 14 weeks remaining until  fiscal week 320, which is the
target  date  for completion  of  MR 10.2  video work.   Based on
requests from  customers and my  own feelings about  the relative
importance of the various video system improvements, I propose to
implement the following:

User definable key bindings                       4 weeks
Preservation of tty_ state                        2 weeks
Improvement of video reconnection                 5 weeks
hcs_$tty_write_whole_string fix                   1 week
window_call and io_call extensions                1 week
Code restructuring                                1 week
Total                                            14 weeks

MTB 619                                               Video Plans

If  there is  any time remaining  before the MR  10.2 freeze date
when the above work is completed, I will begin work on the output
conversion and asynchronous event handling items.