858 ;;Quote: Oberon is a single process for pursuing multiple tasks usually shown as displayed documents; command initiated operations with operands

858 ;;Quote: Oberon switches processes only between user commands (except for interrupt handlers); no need for interlocking

858 ;;Quote: an Oberon command consists of module_name.procedure_name; click on text or type in, a few on mouse buttons

859 ;;Quote: Oberon parameters are typically displayed, and command output is non-volatile with a visible representation; everything is accessible

859 ;;Quote: in Oberon, commands are atomic (without a dialogue); no modes or hidden states that cause user-unfriendliness

859 ;;Quote: Oberon tools are short texts or graphics containing frequently-used commands; users can edit like any text

859+;;Quote: Oberon menus are commands listed in viewer headers; take their viewer as argument

859 ;;Quote: Oberon is extensible; e.g., any application can read text from the screen by importing the type Text

859 ;;Quote: can extend imported Oberon data types without losing compatibility with the base type; motivation for the Oberon language

859+;;Quote: Oberon has polymorphic operations

861 ;;Quote: Oberon's modules form an import/export hierarchy; no distinction between operating system and applications

861+;;Quote: Oberon's workspace consists of a stack of procedure activations and a heap of dynamically allocated variables

861 ;;Quote: Oberon's loader transforms modules into executable code by linking object code files on disk

862 ;;Quote: an Oberon handler is a procedure-valued variable or record field; caller doesn't know callee, so it's "sending a message"

864 ;;Quote: most operating systems run sequence(s) of program activations; free resources and store data in disk files between activations

864+;;Quote: in most operating systems, the interface between programs is disk files or pipes

864 ;;Quote: Oberon's interface between consecutive commands is primarily global variables; efficient and flexible; storage reclamation more difficult

864 ;;Quote: Oberon's garbage collector must be safe; use type guards, range checks, and NIL tests for all pointers

865 ;;Quote: Oberon's modules only released by explicit command; imported modules released by reference counting (no reference cycles)

865 ;;Quote: Oberon uses virtual memory for delayed loading, write protection, and simplified allocation for modules; no demand paging

868 ;;Quote: each Oberon module includes a table of commands giving name and entry address; called by M.P

868 ;;Quote: each Oberon module includes a pointer reference list of all global pointers; used for garbage collection

869 ;;Quote: Oberon allocates memory for modules sequentially in virtual memory; Free releases the physical page but not the virtual page

869 ;;Quote: Oberon allocates imported modules but does not load them; delayed loading on first call by paging; supports larger systems

871 ;;Quote: Oberon memory management by 5 lists for 16, 32, 64, 128, and 128*n bytes; efficient allocation and coalescing; low wastage; like buddy system

871 ;;Quote: Oberon types include a pointer to the base type's descriptor; name equivalence of types, not structural equivalence; for type tests/guards

874 ;;Quote: Oberon files include a header of disk addresses for each sector; extension table for large files

874+;;Quote: Oberon file directory by a B-tree

876 ;;Quote: Oberon uses tiled windows with a user track for documents and a system track for system data, tools, and logs; allows automatic allocation

877 ;;Quote: a typical Oberon viewer has a header frame giving a name and menu, and a main frame for the viewer's contents

877+;;Quote: Oberon display is organized into frames (a rectangular bit map with subframes)

878 ;;Quote: Oberon frames and viewers can respond to messages, e.g. for a viewer becoming visible, updated text, or input events

879 ;;Quote: each Oberon viewer has a command interpreter bound to it for handling input events; e.g., editor or mail handler

881 ;;Quote: text plays a key role in computer systems; for input, output, object names, and commands; Oberon predefines Text documents

883 ;;Quote: an Oberon writer initially creates an anonymous file; extension of memory since the disk space is reclaimed on system boot

884 ;;Quote: Oberon describes texts as a linked list of text pieces; e.g., insert a string by splitting the piece (3 pieces when done)

890 ;;Quote: each Oberon command is an atomic action in the user-computer dialogue; switch tasks between commands

891 ;;Quote: Oberon's mark-and-sweep garbage collector only runs between commands when the stack is empty; no local variables

891 ;;Quote: extended, Oberon objects are byte compatible with their base type; can be integrated into existing structures

891 ;;Quote: Oberon users do not miss enumerations, subranges, submodules, automatic qualifications, general indexing, for-statements, etc.

891 ;;Quote: the Oberon system and compiler is described by 15 KLOC of source