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.