1/*- 2 * Copyright (c) 1990, 1993 3 * The Regents of the University of California. All rights reserved. 4 * 5 * This code is derived from software contributed to Berkeley by 6 * Edward Wang at The University of California, Berkeley. 7 * 8 * Redistribution and use in source and binary forms, with or without 9 * modification, are permitted provided that the following conditions 10 * are met: 11 * 1. Redistributions of source code must retain the above copyright 12 * notice, this list of conditions and the following disclaimer. 13 * 2. Redistributions in binary form must reproduce the above copyright 14 * notice, this list of conditions and the following disclaimer in the 15 * documentation and/or other materials provided with the distribution. 16 * 3. All advertising materials mentioning features or use of this software 17 * must display the following acknowledgement: 18 * This product includes software developed by the University of 19 * California, Berkeley and its contributors. 20 * 4. Neither the name of the University nor the names of its contributors 21 * may be used to endorse or promote products derived from this software 22 * without specific prior written permission. 23 * 24 * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 25 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 26 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 27 * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 28 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 29 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 30 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 31 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 32 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 33 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 34 * SUCH DAMAGE. 35 * 36 * @(#)README 8.1 (Berkeley) 6/6/93 37 */ 38 39Compilation notes: 40 41 Compiler options: 42 43 BYTE_ORDER (used only in ww.h) 44 It should already be defined in machine/endian.h. 45 The code knows about BIG_ENDIAN, LITTLE_ENDIAN, and PDP_ENDIAN. 46 It only cares about byte order in words, so PDP_ENDIAN 47 is the same as LITTLE_ENDIAN. 48 OLD_TTY 49 If you don't have Posix termios, then define this. 50 VMIN_BUG 51 Even if you have Posix termios, define this if the MIN and TIME 52 feature in noncanonical mode doesn't work correctly. 53 54 Ok, there's another one, STR_DEBUG. It turns on consistency checks 55 in the string allocator. It's been left on since performace doesn't 56 seem to suffer. There's an abort() somewhere when an inconsistency 57 is found. It hasn't happened in years. 58 59 The file local.h contains locally tunable constants. 60 61 The makefile used to be updated with mkmf; it has been changed 62at various times to use cpp -M and, currently, mkdep. The only library 63it needs is termcap. 64 65 Window, as is, only runs on 4.3 (or later) machines. 66 67 On 4.2 machines, at least these modifications must be done: 68 69 delete uses of window size ioctls: TIOCGWINSZ, TIOCSWINSZ, 70 struct winsize 71 add to ww.h 72 typedef int fd_set; 73 #define FD_ZERO(s) (*(s) = 0) 74 #define FD_SET(b, s) (*(s) |= 1 << (b)) 75 #define FD_ISSET(b, s) (*(s) & 1 << (b)) 76 add to ww.h 77 #define sigmask(s) (1 << (s) - 1) 78 79 80A few notes about the internals: 81 82 The window package. Windows are opened by calling wwopen(). 83Wwwrite() is the primitive for writing to windows. Wwputc(), wwputs(), 84and wwprintf() are also supported. Some of the outputs to windows are 85delayed. Wwupdate() updates the terminal to match the internal screen 86buffer. Wwspawn() spawns a child process on the other end of a window, 87with its environment tailored to the window. Visible windows are 88doubly linked in the order of their overlap. Wwadd() inserts a window 89into the list at a given place. Wwdelete() deletes it. Windows not in 90the list are not visible, though wwwrite() still works. Window was 91written before the days of X and Sunview, so some of the terminology 92is not standard. 93 94 Most functions return -1 on error. Wwopen() returns the null 95pointer. An error number is saved in wwerrno. Wwerror() returns an 96error string based on wwerrno suitable for printing. 97 98 The terminal drivers perform all output to the physical terminal, 99including special functions like character and line insertion and 100deletion. The window package keeps a list of known terminals. At 101initialization time, the terminal type is matched against the list to 102find the right terminal driver to use. The last driver, the generic 103driver, matches all terminals and uses the termcap database. The 104interface between the window package the terminal driver is the `tt' 105structure. It contains pointers to functions to perform special 106functions and terminal output, as well as flags about the 107characteristics of the terminal. Most of these ideas are borrowed 108from the Maryland window package, which in turn is based on Goslin's 109Emacs. 110 111 The IO system is semi-synchronous. Terminal input is signal 112driven, and everything else is done synchronously with a single 113select(). It is roughly event-driven, though not in a clean way. 114 115 Normally, in both conversation mode and command mode, window 116sleeps in a select() in wwiomux() waiting for data from the 117pseudo-terminals. At the same time, terminal input causes SIGIO which 118is caught by wwrint(). The select() returns when at least one of the 119pseudo-terminals becomes ready for reading. 120 121 Wwrint() is the interrupt handler for tty input. It reads input 122into a linear buffer accessed through four pointers: 123 124 +-------+--------------+----------------+ 125 | empty | data | empty | 126 +-------+--------------+----------------+ 127 ^ ^ ^ ^ 128 | | | | 129 wwib wwibp wwibq wwibe 130 131Wwrint() appends characters at the end and increments wwibq (*wwibq++ 132= c), and characters are taken off the buffer at wwibp using the 133wwgetc() and wwpeekc() macros. As is the convention in C, wwibq 134and wwibe point to one position beyond the end. In addition, 135wwrint() will do a longjmp(wwjmpbuf) if wwsetjmp is true. This is 136used by wwiomux() to interrupt the select() which would otherwise 137resume after the interrupt. (Actually, I hear this is not true, 138but the longjmp feature is used to avoid a race condition as well. 139Anyway, it means I didn't have to depend on a feature in a 140daily-changing kernel, but that's another story.) The macro 141wwinterrupt() returns true if the input buffer is non-empty. 142Wwupdate(), wwwrite(), and wwiomux() check this condition and will 143return at the first convenient opportunity when it becomes true. 144In the case of wwwrite(), the flag ww_nointr in the window structure 145overrides this. This feature allows the user to interrupt lengthy 146outputs safely. The structure of the input buffer is designed to 147avoid race conditions without blocking interrupts. 148 149 Actually, wwsetjmp and wwinterrupt() are part of a software 150interrupt scheme used by the two interrupt catchers wwrint() and 151wwchild(). Asserting the interrupt lets the synchronous parts of 152the program know that there's an interesting asynchronous condition 153(i.e., got a keyboard character, or a child process died) that they 154might want to process before anything else. The synchronous routines 155can check for this condition with wwinterrupt() or by arranging 156that a longjmp() be done. 157 158 Wwiomux() copies pseudo-terminal output into their corresponding 159windows. Without anything to do, it blocks in a select(), waiting for 160read ready on pseudo-terminals. Reads are done into per-window buffers 161in the window structures. When there is at least one buffer non-empty, 162wwiomux() finds the top most of these windows and writes it using 163wwwrite(). Then the process is repeated. A non-blocking select() is 164done after a wwwrite() to pick up any output that may have come in 165during the write, which may take a long time. Specifically, we use 166this to stop output or flush buffer when a pseudo-terminal tells us to 167(we use pty packet mode). The select() blocks only when all of the 168windows' buffers are empty. A wwupdate() is done prior to this, which 169is the only time the screen is guaranteed to be completely up to date. 170Wwiomux() loops until wwinterrupt() becomes true. 171 172 The top level routine for all this is mloop(). In conversation 173mode, it simply calls wwiomux(), which only returns when input is 174available. The input buffer is then written to the pseudo-terminal of 175the current window. If the escape character is found in the input, 176command mode is entered. Otherwise, the process is repeated. In 177command mode, control is transferred to docmd() which returns only when 178conversation mode is reentered. Docmd() and other command processing 179routines typically wait for input in a loop: 180 181 while (wwpeekc() < 0) 182 wwiomux(); 183 184When the loop terminates, wwgetc() is used to read the input buffer. 185 186 Output to the physical terminal is handled by the lowest level 187routines of the window package, in the files ttoutput.c and tt.h. The 188standard IO package is not used, to get better control over buffering 189and to use non-blocking reads in wwrint(). The buffer size is set to 190approximately one second of output time, based on the baudrate. 191 192 The result of all this complexity is faster response time, 193especially in output stopping and flushing. Wwwrite() checks 194wwinterrupt() after every line. It also calls wwupdate() for each line 195it writes. The output buffer is limited to one second of output time. 196Thus, there is usually only a delay of one to two lines plus one second 197after a ^C or ^S. Also, commands that produce lengthy output can be 198aborted without actually showing all of it on the terminal. (Try the 199'?' command followed by escape immediately.) 200