MULTICS TECHNICAL BULLETIN MTB-744-01
To: MTB Distribution
From: Edward C. Brunelle
Al Dupuis
Ed Wallman
Ron Barstad
Date: November 15, 1986
Subject: MOWSE - Workstation Terminal Manager |
-----------------------------------
This MTB presents an overview of the features and tentative
design of the keyboard/screen manager for use on a MOWSE work- |
station. |
-----------------------------------
Comments should be sent to the authors:
via Forum:
>udd>Multics>jms>mtgs>workstation_working_group (wwg) on System-M
via Multics Mail:
Wallman at System-M
via Telephone:
Ed Wallman: (602) 862-3640
Forum transactions are preferred.
_________________________________________________________________
Multics project internal documentation; not to be reproduced or
distributed outside the Multics project without permission of the
Director of MDC.
CONTENTS
Page
1: Introduction . . . . . . . . . . . . . . . . . 1
2: Definitions . . . . . . . . . . . . . . . . . . 1
3: References . . . . . . . . . . . . . . . . . . 2
4: The Needs of User/Host Dialog . . . . . . . . . 2
5: System Overview . . . . . . . . . . . . . . . . 3
6: System Operation; Addressing the Needs . . . . 3
6.1: Listening to the Keyboard . . . . . . . . . . 4
6.2: Displaying Foreground Messages . . . . . . . 5
6.3: Displaying Background Messages . . . . . . . 6
7: Other Issues . . . . . . . . . . . . . . . . . 6
7.1: 7bit vs. 8bit ASCII . . . . . . . . . . . . 6
Workstation Manager MTB-744-01
1: INTRODUCTION
The essential purpose of a "workstation" (hereinafter referred to
as the PC) is to allow the user to communicate meaningfully with
the host computer into which he/she is logged. To this end, a
user communication package is needed on the PC.
Such a package implemented on a PC is commonly called a "terminal
emulator" and is designed to present (to the host) the character- *
istics of some data terminal that the host is able to support.
Typical of these data terminals are the IBM 32nn series, the DEC
VT* series, and the (most common) "glass TTY".
This MTB discusses the needs of the user/host dialog and how
those needs may be met in the MOWSE workstation manager. The |
product must contain a special communications package because all |
host communication takes place via MOWSE by means of packetized |
messages; an off-the-shelf emulator cannot deal with such mes-
sages.
2: DEFINITIONS
Personal Computer (PC)
Any of a number of IBM PC (or PC compatible) micro computers
available for use as Multics workstations.
Multics Online Workstation Environment (MOWSE)
The facility (running on both Multics and a PC) that
supports a Multics workstation.
Also, specifically, the supervisory module (most likely
MOWSE.COM) that resides and executes on the PC.
Capability
A MOWSE application normally supported on both Multics and
the PC.
Workstation Terminal Mangager (WSTERM) |
A PC foreground capability that supports user/host dialog. |
Major Capability (majcap)
The Capability Access Table (CAT) entry index number of a
capability.
Minor Capability (mincap)
The predefined index number of an "entrypoint" into a
capability.
mowse_io_ |
The communcations module that provides the MOWSE packet |
protocol on Multics. |
MTB-744-01 Workstation Manager
| ws_tty_
| The Multics module that provides the control functions
needed by the video system or emacs. When this module is in
use, the Multics virtual screen image and the PC screen are
synchronized, hence WSTERM is said to be in "sync mode".
When the module is not in use, WSTERM is said to be in
"async mode".
3: REFERENCES
KERMIT User Guide
Frank da Cruz, editor, Columbia University Center for Com-
puting Activities.
4: THE NEEDS OF USER/HOST DIALOG
| There are two "terminal emulators" in the MOWSE product. The
| first is embedded in MOWSE and is a "login TE". It supports only
those features needed to establish the communications link with
Multics. After MOWSE is booted and running on both PC and host,
| this emulator disappears.
The emulator addressed in this MTB is a more sophisticated one
with which the user communicates with the Multics command envi-
| ronment and any selected Multics applications when the communica-
| tion channel is in MOWSE packet mode.
Reference is made to the "KERMIT User Guide" in order that
readers may gain acquaintance with a mature and rich emulator.
Many of the features of a complete KERMIT are not needed by
WSTERM because MOWSE provides other capabilities that support
those features.
WSTERM *MUST* be able to ...
o Handle input data from the keyboard, including rawi input
and input line wrapping (NL convention).
o Display data on the screen.
o "Listen" for foreground traffic from Multics.
o Transmit foreground traffic to Multics.
o Handle any ansynchronous error/query messages that may
arrive from other MOWSE applications running in the back-
ground.
o Support the terminal features found in the VT100 terminal
type.
WSTERM need *NOT* be able to ...
o Send files to Multics.
o Receive files from Multics.
o Act as a file server.
Workstation Manager MTB-744-01
o Parse "wildcard" PC file specifications.
o Manage the DOS environment.
o Read user input from a file instead of the keyboard.
o Support a request interface and the ability to switch
between active communication mode and request mode without
loss of integrity.
o Support "macros".
o Support changable key bindings.
5: SYSTEM OVERVIEW
The design of WSTERM will be modular, that is, the major |
functions (sync vs. async, foreground vs. background, etc.) |
will each reside in its own internal module with shared service |
routines residing in a "utility" module. The modules will be |
coded in 'C' for consistency with the rest of the MOWSE product.
Source module names will be prefixed with "WST". The name of the |
linked, executable module will be "WSTERM". |
6: SYSTEM OPERATION; ADDRESSING THE NEEDS
WSTERM has no counterpart on Multics (other than mowse_io_ |
itself). Mowse_io_ will intercept output messages from Multics |
applications and transmit them to WSTERM with a mincap indicating |
the nature of the message. The set of mincaps to be used will
include at least ...
o A foreground message from foreground activities on Multics.
o A background message from another Multics MOWSE application.
o A control message from ws_tty_ (see MTB756) (for controlling |
input echoing and synchronizing the host and PC screen
images).
The foreground message buffer will be 3000 characters long; this
value will allow a complete 80x24 screen image liberally
sprinkled with control sequences. The background message buffer
will be 256 characters long since background messages are fetched
and displayed one at a time. The keyboard input buffer will also
be 256 characters long. WSTERM will operate in two "modes" ...
sync when the Multics foreground activity is maintaining a
screen image (eg, emacs or video).
async when output is single line, plain text messages.
Control information to and from WSTERM will flow by means of
control messages. Each control message will contain a three |
character message identifier and the byte count for any |
accompanying message text. |
MTB-744-01 Workstation Manager
It is the responsibility of mowse_io_ to inform WSTERM (with
control messages) of mode changes and of changes in other control
parameters.
When quiescent, WSTERM will be in a "listener" loop that samples
for keyboard input and for messages from Multics.
WSTERM will maintain a "minibuffer" in the 25th line for various
"out-of-band" communications.
While WSTERM does not have a "command interface", it does support
a number of escape requests, among which are ...
^]0 Send an ASCII NUL to the host. (This is supported
because not all PCs will transmit a NUL when ^@ is
entered.)
^]^] Send a literal ^] to the host.
* ^]B Send a line break to the host.
^]D In the full screen, display a pending foreground message
and replay any partial input line. In the minibuffer,
erase the current background message and display the next
* one (if any).
^]M Switch to the minibuffer and display the first background
message (if any). Entering another ^]M switches back to
the full screen.
| ^]Q, ^]<CR>
| Exit WSTERM, that is, return to DOS command level.
^]R Reply to a background query appearing in the minibuffer.
^]Y Replay an input line that has been inadvertently killed.
6.1: Listening to the Keyboard
* The erase, escape, and kill characters will be sent by mowse_io_
(in a control message). All ASCII control characters (and
literal DELs) will be single characters in the keyboard buffer
and 4 characters (nnn) on the screen. Note that local
overstriking is NOT supported; if overstriking is wanted on
| Multics, a literal BS must be used, for example, "N010_". The
| use of real control characters in escape processing is supported,
| that is, "<BS>" will yield the same result as "010".
All type ahead characters will be buffered, either by DOS or by
WSTERM.
Mode dependent actions ...
async Keyboard characters will be echoed, edited, and accumu-
lated into a keyboard buffer until a CR is entered.
The complete message will be transmitted when a CR is
entered.
Workstation Manager MTB-744-01
Character escaping and line editing will be done local- |
ly. |
Line editing will be done in "WYSIWYG" mode. Backspace |
will be handled after the fashion of can_type=replace. |
Erase and DEL will delete the last buffered character |
and erase it from the screen. Kill will wipe the |
keyboard buffer and erase the entire line from the |
screen. |
sync Keyboard characters will be accumulated into the key-
board buffer, and echoed only if the control message
from mowse_io_ was read_echoed. Erase and kill charac-
ters will be treated as break characters. Mowse_io_ |
must assure that the break table used by WSTERM matches |
the break table on Multics (by transmitting the table |
whenever it changes). The break table will consist of |
ASCII characters NUL through US (000-037) and DEL |
(177), plus any additional printable characters sent |
by mowse_io_ in the control message. |
Data will be sent ... |
o upon entry of any character in the break table. *
o upon receipt of any host message.
o when the keyboard buffer fills.
o when the count in the read_(echoed unechoed) control
message exhausts. |
o every second while the user is entering plain text. |
6.2: Displaying Foreground Messages
Foreground messages will be displayed politely, that is, they
will not be mixed with echoed input on a line and the visual
appearance of partial input lines will not be disturbed.
Mode dependent actions ...
async When the cursor is at its left screen edge "home"
position (as determined by any prompt string) and the
keyboard buffer is empty, foreground messages will be
displayed immediately.
When there is a partial message in the keyboard buffer,
"foreground message" will be displayed in the
minibuffer. Entering ^]D will cause the message to
overwrite the partial line on the screen and the
partial line to be replayed on a fresh line.
sync All foreground messages are assumed to be screen
refresh messages and will be displayed immediately upon
receipt.
MTB-744-01 Workstation Manager
6.3: Displaying Background Messages
Arrival of a background message will cause "background message"
to be displayed in the minibuffer. Entering ^]M will display the
first background message in the minibuffer. If the message is a
query, entering ^]R will permit a response to be sent from the
minibuffer. Entering ^]D will discard the displayed message and
display the next one (if any). Re-entering ^]M will discard the
displayed message and return to the full screen.
7: OTHER ISSUES
The following issues are mentioned for the record.
7.1: 7bit vs. 8bit ASCII
The initial release of WSTERM will support only 7bit ASCII
(however, any octal value may be entered by escaping). Care will
be taken so that a future extension to 8bit will be straightfor-
ward.