/u/sy/beebe/tex/errata/tanenbaum-mos.txt, Sat Apr 4 09:18:35 1992 Edit by Nelson H. F. Beebe This file collects errata and comments for the book @String{pub-PH = "Pren{\-}tice-Hall"} @Book{Tanenbaum:MOS92, author = "Andrew S. Tanenbaum", title = "Modern Operating Systems", publisher = pub-PH, year = "1992", ISBN = "0-13-588187-0", } In the following, negative line numbers count up from the bottom of the page. p. 25, l. -10 ``to Pascal or Modula 2 programs'' -> ``to Pascal or Modula 2 programmers'' p. 32, l. 17 ``Actions such as saving the registers and setting the the stack pointer cannot even by expressed in c (or any other high-level language) to they are performed by a small assembly-language routine.'' Although this statement is true on many machines, it is certainly not true on all. In particular, on the DEC PDP-10, which formed the backbone of the Arpanet, the 16 registers were logically mapped into the first 16 words of memory (though they were of course implemented in higher-speed technology). This has some interesting ramifications. First, since those 16 words have faster access, short code segments can be moved there for execution. An array or string copy or fill operation would run 2 to 3 times faster if its code were moved into register memory. Second, registers are accessible just like memory, including from high-level languages that support pointers. The `return from interrupt' instruction, which on some architectures requires a different stack configuration, and is therefore inaccessible from high-level languages, is hidden inside the kernel (Monitor in DEC-10 and DEC-20 terminology). An interrupt routine ends by a system call, which can be done from any high-level language. The statement is also untrue for the Intel iAPX architectures, where most C compilers make the registers accessible through special symbols like _AX, _DH, ... p. 36, l. 17 ``...operating systems are often written in C, rarely in Modula 2, and never in Pascal.'' I disagree with the ``never in Pascal'' phrase. I believe that both the UCSD Pascal operating system of the late 1970s and early 1980s, and the now-defunct ElXsi mainframe operating system, belie this statement. Also, the Apple Macintosh operating system and IBM PC MS Windows systems have Pascal-like user interfaces, suggesting that perhaps major portions of those systems were written in Pascal (or likely, extended Pascal). For that matter, much of Prime's Primos was written in Fortran, and IBM's H and H Extended Fortran compilers were written in Fortran too. p. 60, l. -13 ``which counts number of'' -> ``which counts the number of'' p. 70, l. 18 ``beahvior'' -> ``behavior'' p. 70, l. 23 ``rocesses can communicate'' ``Processes can communicate'' p. 71, l. 1 ``well known scheduling algorithms'' -> ``well-known scheduling algorithms'' p. 94, l. 7 ``and a 20-bit Offset field'' -> ``and a 12-bit Offset field'' p. 96, l. -14 ``space anddo not'' -> ``space and do not'' p. 101, l. -10 ``page tables are kept in memory, due to their large size'' -> ``page tables are not kept in memory, due to their large size'' p. 115, l. 1--2 ``generates a sequences of memory references'' -> ``generates a sequence of memory references'' p. 118, l. 5 ``of the the distance string'' -> ``of the distance string'' p. 150, last paragraph ``The TOPS-20 .... any file to be executed.'' This is incorrect. I worked on a TOPS-20 system daily from 1978 to 1990. The TOPS-20 system runs executables by name, just like UNIX does. However, compilation and linking are normally done with the COMPILE, LOAD, and EXECUTE commands, rather than invoking the compiler, linker, and image load commands directly. COMPILE checks source and object file time stamps, and only recompiles those source files that are newer than their corresponding object files. Recompilation can be forced with a special switch. COMPILE chooses the compiler based on the file extensions (foo.for ==> Fortran, foo.pas ==> Pascal, and so on). Unfortunately, the mapping of file extensions to compilers is hard-coded into the assembly code of the EXEC (equivalent to the UNIX shells), so it is not easy to extend. COMPILE does not examine the contents of source files, so it cannot discover dependencies on included files. In this respect, the UNIX make utility is superior, although it of course relies on the include-file dependencies being correct and up-to-date. LOAD invokes COMPILE, then calls the linker to make an executable image in memory. This image can be run by typing START, or saved to an executable file image with the SAVE command. EXECUTE invokes LOAD (which in turn invokes COMPILE), and then executes the memory image without ever saving it to disk. For development of programs of modest size, most people just use the EXECUTE command. That way, disk space doesn't get tied up in lots of executable images that are run only once, as happens on most other operating systems. p. 152. Fig 4-4. There are many others. TOPS-20 records: * time of backup * time of last read (great for discovering which files haven't been used in a long time) * online/offline status (offline files reside on two separate tapes, but their directory entries remain, and they can be retrieved automatically when the file is referenced) * names of offline tape volumes * access bits (read, write, execute, and append for system, group, and world) * page count (both TOPS-20 and UNIX files can have holes in them; pages that are entirely empty need not be stored) * userid of last writer * userid of last reader * miscellaneous attributes like owner account, block size (for tapes), access passwords, ... p. 154, l. -10 ``ANSI C'' -> ``Standard C'' [and anywhere else in the book that this usage occurs] Members of the ANSI X3H3 committee, notably P. J. Plauger and Tom Plum, have pleaded publicly for people to say ``Standard C''. There is a joint ANSI/ISO Standard of 15-Dec-1989 for the language; it is not just an American National Standard. p. 160, l. -8 ``cp ../../lib/dictionary .'' -> ``cp ../lib/dictionary .'' p. 160, l. -7 ``twice (to the root directory)'' -> ``once (to the usr directory)'' p. 184, end of 4.4.2 Famous Security Flaws Here are some more from my own personal experience, all back in the late 1960s and early 1970s. (1) On IBM OS/360 (MFT, MVT), memory was not cleared between jobs (on ``efficiency'' grounds). I once got a core dump printout of my own job that contained in the dump payroll records of several top university officials, from the Computer Center director up to the President, all left over from the previous occupier of memory. It made for interesting reading! (2) On IBM OS/360, the lack of memory clearing was exploited by a fellow systems programmer to break security. Jobs entered into the system on punched cards had on their second card the text /*PASSWORD secret-password The machine-room card reader was arranged to output those cards into a second hopper, from which they were removed and destroyed. The systems programmer (a Computer Center staff member) wrote a PL/1 program to allocate a very large array, and then simply searched for the string "/*PASSWORD"; he collected hundreds of passwords this way, left over from card-reader input buffers. (3) On IBM OS/360 (MFT, MVT), users created files with job control language something like this //FT03F001 DD DSNAME=PHYSDATA, UNIT=3330, X // VOL=SER=USER03, SPACE=(TRK, (30,1)), X // DISP=NEW That is, besides the data set name (filename), the user had to remember the physical disk unit number, the disk volume name, supply the space allocation, and tell the file disposition (NEW, OLD, SCRATCH). While it was possible to have the filename stored in the system catalog by coding the last parameter as DISP=(NEW,CATLG), our Computer Center forbad this practice on the grounds that it made the file system lookup slow. With a catalog entry, only the DSNAME and DISP parameters were needed on subsequent DD statements. One day, a user input a job that had something like this: //XXX DD DSNAME=SYSCTLG, DISP=(OLD.UNCATLG) The effect was that the catalog was uncatalogued. The system continued to run, for the catalog had already been opened by the operating system. However, the next time the system was taken down for maintenance, it failed to reboot because the catalog could not be located, and no boot files could be found. The machine was down for several hours before the systems staff were able to determine what was wrong. p. 185, l. 12 ``with any further authentification'' -> ``without any further authentification'' p. 190, l. 24 ``one time password'' -> ``one-time password'' p. 270, l. 16 ``signals (which is largely taken'' -> ``signals (which are largely taken'' p. 316, l. 10 ``New York him a large bag'' -> ``New York, gave him a large bag'' p. 322, l. 4 ``to the the expert'' -> ``to the expert'' p. 324, l. 7 ``On the other named'' -> ``On the other hand'' p. 328, l. 8 ``placing a process at address 400K and 800K are different'' -> ``placing a process at address 400K and 800K is different'' p. 332, l. 11 ``(Microsoft, exist, it strongly'' -> ``??'' Text has been lost from the sentence, garbling it. p. 342, l. 6 ``UNIX shel'' -> ``UNIX shell'' p. 344, l. 13--14 ``the technique it is not portable'' -> ``the technique is not portable'' p. 345, l. 14 ``get_ypper_mem_link()'' -> ``get_uper_mem_link()'' p. 349, l. 5 ``A/I user programs'' -> ``All user programs'' p. 358, l. 21 ``do not to call'' -> ``do not call'' p. 380, l. -2 ``headers. if security is enabled.'' ``headers, if security is enabled.'' p. 392, l. -14 ``each each data record'' -> ``each data record'' p. 395, l. -10 ``Chap. 9. in more detail.'' -> ``Chap. 9 in more detail.'' p. 415, l. 9 ``is shown as a dashed line in Fig. 10-10(b).'' There is no dashed line in that figure. p. 419, l. 2 in Fig. 10-14(b) ``bytes'' -> ``nbytes'' p. 419, l. 8 ``fd or bytes'' -> ``fd or nbytes'' [The discussions elsewhere in this section use nbytes.] p. 430, l. -1 ``require more care.'' -> ``require more care).'' p. 443, l. 16 ``is run remote.'' -> ``is run remotely.'' p. 444, l. -12 ``a read driven pipeline'' -> ``a read-driven pipeline'' p. 446, l. 3 ``receiversin one'' -> ``receivers in one'' p. 470, l. 5 ``independent of the wiggling'' -> ``independently of the wiggling'' p. 498, l. 11 ``in due course of time'' -> ``in due course'' p. 508, l. -11 ``do they can they actually run in parallel.'' -> ``do they actually run in parallel.'' p. 522, l. 11 ``it it tries'' -> ``if it tries'' p. 534, l. -11 ``stared up'' -> ``started up'' p. 589, l. 9 ``Tromso'' -> ``Troms{\o}'' The town name ends in the letter slashed-o, the last letter of the Norwegian and Danish alphabets. p. 615, l. 4 ``slihgtly'' -> ``slightly'' p. 618, l. -1 ``in the fact of lost packets'' -> ``in the face of lost packets'' p. 619, l. 6 in Fig. 14-17 ``multicost'' -> ``multicast'' p. 623, l. 18 ``replicaton server'' -> ``replication server'' p. 640, l. -7 -- -6 ``it is suspending to give the port'' -> ``it is suspended to give the port'' p. 649, l. 9 ``te length'' -> ``the length'' p. 655, l. -12 ``onto to page 8'' -> ``onto page 8'' p. 658, l. -4 ``even it no process'' -> ``even if no process'' p. 667, l. -3 ``destination portis'' -> ``destination port is'' p. 675, l. 2 in Fig. 15-22 `cells' -> `calls' p. 675, l. 7 in Fig. 15-22 ``Sun 05'' -> ``SunOS''