From: William M. York
Date: March 4, 1983
To: MTB Distribution
Subject: Video System Plans for the Foreseeable Future
Abstract
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.
1.1 USER DEFINED EDITOR KEY BINDINGS
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
requests.
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
sequences.
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
later.
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);
where:
line_editor_info_ptr
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");
where:
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
automatically.
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
(line_editor_key_binding_info.binding_count)),
3 sequence char(0 refer
(line_editor_key_binding.longest_sequence)) varying,
3 type fixed bin,
3 editor_routine entry (pointer, fixed bin(35));
where:
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.
binding_count
is the number of editor requests described in the structure.
longest_sequence
is the length in characters of the longest keystroke sequence
defined in the structure.
sequence
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.
type
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
FORWARD_CHARACTER, BACKWARD_CHARACTER, FORWARD_DELETE_CHARACTER,
BACKWARD_DELETE_CHARACTER, MOVE_TO_END_OF_LINE,
MOVE_TO_BEGINNING_OF_LINE, KILL_TO_END_OF_LINE,
KILL_TO_BEGINNING_OF_LINE, FORWARD_WORD, BACKWARD_WORD,
FORWARD_DELETE_WORD, BACKWARD_DELETE_WORD, QUOTE_CHARACTER,
CLEAR_WINDOW, TWIDDLE_CHARACTERS, DISPLAY_EDITOR_DOCUMENTATION,
SELF_INSERT, YANK_FROM_KILL_RING, YANK_PREVIOUS_FROM_KILL_RING,
TERMINATE_INPUT_LINE, UNDEFINED, and PROCESS_INPUT_ESCAPE.
editor_routine
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.
1.2 TTF ENHANCEMENTS
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,
MOVE_TO_BOL, BEGIN_UNDERLINE, END_UNDERLINE, BEGIN_HIGHLIGHT, and
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
2 IMPROVEMENTS TO EXISTING CAPABILITIES
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
implementation.
2.1 CO-EXISTENCE WITH tty_
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
characters.
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.
2.2 VIDEO RECONNECTION
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
window_call.
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
asynchronous_change.
The get_ form of each control order listed above is also
supported, and may be used in active function invocations of
io_call.
2.4 VERTICALLY-DIVIDED WINDOWS
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.
2.5 PERFORMANCE IMPROVEMENTS
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
load.
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.
2.6 ASYNCHRONOUS EVENT HANDLING
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
window_status.incl.pl1.
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.
2.7 HARDCORE CHANGES: HCS_$TTY_WRITE_WHOLE_STRING
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.
3.1 TIME ESTIMATES
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
3.2 RECOMMENDATIONS
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.