All about OSs

     A / B / C / D / E / F / G / H / I / J / K / L / M / N / O / P / Q / R / S / T / U / V / W / X / Y / Z




Visit also:

U UCSD-p(outdated)
UCSD-p runs on all usual systems, IBM PC included. Pascal- and Fortran-Compiler available.


UNIVAC early computer

Ken Thompson of Bell Labs -co-author of  Multics - needed a system for a game. He found a unused PDP-7 and wrote a simplified version of Multics . This lead later to UNIX. 
     The idea of an OS made up of simple and efficient tools, esp. the pipe concept allows doing complex things by combining modular building blocks. Interoperability and plattform-independence was a design issue because AT&T used machine by all the national vendors. Multi-user, multi-tasking. A hacker's OS, not an enduser OS. 
The main reason for the success of Unix was, that it was freely available for the academic comunity in source code: You could find the source code of Unix at every University in the world. Everybody could change some lines of code and feel himself as Operating-System guru. The original Unix was a very short piece of code: just a half 8" floppy.

     UC at Berkley collected the new contributions for the next release. 
     "UNIX has evolved from an operating system to a way of thinking about computing" (Mahoney o. J., S. 1). "It is more than an operating system. It is a philosophy of Programming" (Libes & Ressler 1989:37). "UNIX is a lot more than an operating system. It is actually a large, worldwide culture that is intimately connected to the Internet" (Hahn & Stout 1994:6). 

The Need for Operating System Research at Bell Labs  
     Even though AT&T withdrew from the research collaboration on Multics, computer scientists at Bell Labs wanted some way of continuing the advanced form of programming research that their work with CTSS and  Multics had made possible. As early as 1957, Bell Labs had found they needed an operating system for their inhouse computer center which was then running lots of short batch jobs. Describing the situation then facing the Labs, Vyssotsky explains, "We just couldn't take the time to get them on and off the machine manually. We needed an operating system to sequence jobs through and control machine resources."(20) The BESYS  operating system was created at Bell Labs to deal with their inhouse needs. When asked by others outside the Labs to make a copy available, they did so but with no obligation to provide support. "There was no support when we shipped a BESYS tape to somebody," Vyssotsky recalls, "we would answer reasonable questions over the telephone. If they found troubles or we found troubles, we would provide fixes."(21) 
    By 1964, however, Bell Labs was adopting third generation computer equipment and had to decide whether they would build their own operating system or go with one that was built outside the Labs. Vyssotsky recounts the process of deliberation at the time, "Through a rather murky process of internal deliberation we decided to join forces with General Electric and MIT to create Multics." He explains that the Labs planned to use the Multics operating system, "as a mainstay for Bell Laboratories internal service computing in precisely the same way that we had used the BESYS operating system."(22) 

Unix Is Born and the Introduction of Pipes 
     When AT&T made the decision to pull out of the Multics collaboration, they took the research operating system off their GE 645 computer and put up the GECOS operating system. Though GECOS was adequate 
for applications, it was "nowhere near as satisfactory if you were trying to do things that were technically difficult and imperfectly defined," explained Vyssotsky, "which is the main task of research."(23) 
     For the pioneering work of Bell Labs research programmers like Ken Thompson and the research purposes of the Labs, an operating system more like what Multics had promised was needed. Along with the advantages of  immediate feedback which time-sharing provided, the Bell Labs researchers wanted to continue the ability to work collaboratively which time-sharing had made possible. 
    "What we wanted to preserve," one of the creators of Unix, Dennis Ritchie writes, "was not just a good programming environment in which to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied by remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close communication."(24) 
    Ritchie describes how an informal group led by Thompson had begun investigating alternatives to Multics before the GE-645 Multics machine had been removed from the Labs.(25) Thompson and Ritchie presented Bell Labs with proposals to buy them a computer so they could build their own interactive, time-sharing operating system. Their proposals weren't acted on. Eventually, Thompson found a little used PDP-7 computer. According to Vyssotsky, the orphaned PDP-7 computer was a machine, "more in the class 
of a Commodore 64 than the class of a PC-AT."(26) 
    Ritchie, Thompson, and Rudd Canady, who had been part of the Multics project, applied the lessons they had learned to the design of a file system for an experimental operating system. Writing on a chalk board, 
they created a file system design based on "the particularly simple way of viewing files that was suggested by the Multics I/O system."(27) 
     "Soon," Ritchie recounts, "Thompson began implementing the paper file system (perhaps `chalk file system' would be more accurate) that had been designed earlier." Thompson was eager to get a working model so he 
could test it out. He proceeded to create the other aspects of an operating system. "A file system without a way to exercise it was a sterile proposition," notes Ritchie, "so he [Thompson] proceeded to flesh it out with the other requirements for a working operating system, in particular the notion of processes."(28) 
    Describing the primitive conditions that Thompson faced, Ritchie writes, "At the start, Thompson did not even program on the PDP itself, but instead used a set of macros for the GEMAP assembler on a GE-635 
machine."(29) A paper tape was generated on the GE 635 and then tested on the PDP-7 until, according to Ritchie, "a primitive Unix kernel, an editor, an assembler, a simple shell (command interpreter), and a few 
utilities (like the Unix rm, cat, cp commands) were completed. At this point, the operating system was self-supporting, programs could be written and tested without resort to paper tape, and development 
continued on the PDP-7 itself."(30) 
     Ritchie describes how Thompson's PDP-7 assembler was a model of simplicity. "There were no libraries, no loader or link editor," he writes, "the entire source of a program was presented to the assembler, and the output file -- with a fixed name -- that emerged was directly executable."(31) Once the assembler was completed, "the system was able to support itself. And thus the operating system we now call UNIX was 
born," notes Ritchie.(32) 
    Among the other active contributors during this period were Bell Labs researchers Rudd Canady and Joe Ossanna. The researchers were anxious to continue their work on a more advanced computer than the PDP-7. However, their efforts to get AT&T to buy them a more advanced computer for their time-sharing 
research hadn't succeeded. With the help of Ossanna and another Bell Labs researcher Lee McMahon, they were finally able to convince management to buy them a new PDP-11 computer. To obtain this agreement, though, the researchers promised to create a text processing system. Doug McIlroy explains that "typists everywhere were seen as potential customers of the promised document-preparation program. Only later did Ossanna spot the patent department as a ripe candidate. By then there had already been clients in the telephone-operations business."(33) By Spring 1971, the Bell Labs Unix pioneers had a text formatter, 
fulfilling their promise. They had translated one they had created for the PDP-7 from a program McIlroy had written in the BCPL language while working on Multics. The text formatter was an assembler program for the PDP-11.(34) 
     One of the important developments in Unix was the introduction of pipes. Pipes had been suggested by McIlroy during the early days of creating Unix. Ritchie explains how "the idea, explained one afternoon on 
a blackboard, intrigued us but failed to ignite any immediate action. There were several objections to the idea as put....What a failure of  imagination," he admits.(35) McIlroy concurs, describing how the initial effort to add pipes to Unix occurred about the same time in 1969 that Ritchie, Thompson and Canaday were outlining ideas for a file system. "That was when," he writes, "the simple pipeline as a way to combine programs, with data notationally propagating along a chain of (not necessarily concurrent) filters was articulated."(36) However, pipes weren't implemented in Unix until 1972. "Thanks to McIlroy's persistence," Ritchie writes, "pipes were finally installed in the operating system (a relatively simple job), and a new notation was introduced."(37) Several of the old commands had to be changed to make them usable with pipes, notes Ritchie. Summarizing how pipes found their way into Unix, Vyssotsky notes that Thompson put them in, but "it was McIlroy who said, `look you ought to do it.' Pipes, like most things in Unix were not a radically new idea."(38) He describes how similar ideas had appeared in other languages like SIMULA as early as 1967. 
      Dick Haight, a Unix pioneer who helped develop the Programmer's Workbench of Unix tools, was present the day that pipes were introduced into Unix. He describes what happened: 

     "I happened to have been visiting the research crew the 
     day they implemented pipes. It was clear to everyone 
     practically minutes after the system came up with pipes 
     working that it was a wonderful thing. Nobody would ever go 
     back and give that up if they could help it."(39) 
Also describing the day pipes were introduced, McIlroy writes: 
   "Open Systems! Our Systems! How well those who were 
    there remember the pipe-festooned garret where Unix 
    took form. The excitement of creation drew people to 
    work there amidst the whine of the computer's cool- 
    ing fans, even though almost the same computer ac- 
    cess, could be had from one's office or from home. 
    Those raw quarters saw a procession of memorable 
    events. The advent of software pipes precipitated a 
    day-long orgy of one-liners....As people reveled in 
    the power of functional composition in the large, 
    which is even today unavailable to users of other 

The Software Tool 
     Pipes had been created by the time the Version 3 Unix Manual appeared in February 1973. The date listed for the creation of pipes is January 15, 1973(41). Not only were pipes a significant addition to Unix, but according to McIlroy, pipes made possible a subsequent important discovery. "In another memorable event," he writes, "the unarticulated notion of software tools, which had been bolstered by pipes, was finally 
brought home by the liberation of the pattern matching program grep from within the editor." 
      McIlroy describes how he asked Thompson to create a program to help him with some work that he was trying to do. This program resulted in the invention of the software tool `grep.' Following is McIlroy's account of how `grep' was taken out from the editor, leading to a clearer understanding of the notion of a software tool. He writes: 

     "Grep was invented for me. I was making a program to read 
     text aloud through a voice synthesizer. As I invented 
     phonetic rules I would check Webster's dictionary for words 
     on which they might fail. For example, how do you cope with 
     the digraph `ui', which is pronounced many different ways: 
     `fruit', `guile', `guilty', `anguish', `intuit', `beguine'? 
     I would break the dictionary up into pieces that fit in ed's 
     limited buffer and use a global command to select a list. I 
     would whittle this list down by repeated scannings with ed 
     to see how each proposed rule worked." 
     "The process was tedious, and terribly wasteful, since the 
     dictionary had to be split (one couldn't afford to leave a 
     split copy on line). Then ed copied each part into /tmp, 
     scanned it twice to accomplish the g command, and finally 
     threw it away, which takes time too." 
     "One afternoon I asked Ken Thompson if he could lift the 
     regular expression recognizer out of the editor and make a 
     one-pass program to do it. He said yes. The next morning I 
     found a note in my mail announcing a program named grep. It 
     worked like a charm. When asked what that funny name meant, 
     Ken said it was obvious. It stood for the editor command 
     that it simulated, g/re/p (global regular expression print)." 
     "Progress on my talking program accelerated dramatically. 
     From that special-purpose beginning, grep soon became a 
     household word. (Something I had to stop myself from writing 
     in the first paragraph above shows how firmly naturalized 
     the idea now is: `I used ed to grep out words from the 
     dictionary.') More than any other single program, grep 
     focused the viewpoint that Kernighan and Plauger christened 
     and formalized in `Software Tools': make programs that do 
     one thing and do it well, with as few preconceptions about 
     input syntax as possible."(42) 

     Grep is listed in the Manual for Version 4 Unix which is dated November, 1973. The date given for the creation of grep is March 3, 1973, following the creation of pipes.(43) The creation of grep, McIlroy 
explains, was followed by the invention of other special purpose software programs that could be used as tools. He writes: 

     "A while later a demand arose for another special-purpose 
     program, gres, for substitution:  g/re/s.  Lee McMahon 
     undertook to write it, and soon foresaw that there would be 
     no end to the family:  g/re/d, g/re/a, etc.  As his concept 
     developed it became sed, a tool of remarkable utility that 
     is largely unappreciated today, because it capitalizes on 
     the perfect familiarity with ed that was universal ten years 
     ago, but no more.  Sed covers a lot of needs.  For example, 
     we have never seen fit to adopt the widespread `head' 
     utility because `sed 10q' does just as well."(44) 
     What McIlroy refers to as "the unarticulated notion of software tools...brought home by the liberation of...grep from within the editor" has become one of the significant achievements of the Bell Labs research work on Unix. By making it possible to use `grep' to search for a data pattern in a file, without having to use an editor to go inside the file, the Bell Labs researchers discovered that they could create a plethora of software tools to be used in varying combinations, thus facilitating the customized application by a user, a goal sought by those doing research in programming.(45) 
      McIlroy explains that the notion of "software tool" only became articulated among the Bell Labs researchers with the publication of the book "Software Tools" by Kernighan and Plaugher. "Still unnamed in our circles," McIlroy notes, "until Kernighan and Plauger wrote their book, the idea nevertheless became a guiding principle."(46) McIlroy adds that "We were definitely building tools before K&P, though we lacked the suggestive word."(47) 
     Describing how the notion of software tools helps to create an effective programming environment, Brian W. Kernighan and Rob Pike, authors of The Unix Programming Environment, explain that each tool is 
designed to be used with other tools and achieving this end is more important than how each is designed internally.(48) The most important aspect considered with each tool is the function that the tool is to have. New tools are designed once a new function is intended. 
     "The guiding principle," they write, "for making the choice should be that each program does one thing. Options are appropriately added to a program that already has the right functionality. If there is no such program then a new program is called for. In that case the usual criteria for program design should be used: the program should be as general as possible, its default behavior should match the most common usage and it should cooperate with other programs."(49) 
      Thus Unix, according to Kernighan and Pike, created "a new style of computing, a new way of thinking of how to attack a problem with a computer. This style," they explain, "was based on the use of tools: using programs separately or in combination to get a job done, rather than doing it by hand, by monolithic self-sufficient subsystems, or by special-purpose, one-time programs."(50) 
      The philosophy of using software tools that developed from research in Unix is outlined in the "Foreward" to the special issue of The Bell System Technical Journal published in 1978, on "The Unix Time-sharing System." Describing the principles which they have found to be an important component of the Unix 
philosophy of software design, the researchers write: 

     "UNIX utilities are usually thought of as tools -- sharply 
     honed programs that help with generic data processing tasks. 
     Tools were often invented to help with the development of 
     UNIX programs and were continually improved by much trial, 
     error, discussion, and redesign, as was the operating system 
     itself. Tools may be used in combination to perform or 
     construct specific applications."(51) 
     They explain that a distinctive style evolved as part of Unix research. "Unix software works smoothly together; elaborate computing tasks are typically composed from loosely coupled small parts, often software tools taken off the shelf."(52) 
      "Sophisticated tools to make tools have evolved," they observe. (53) Software development tools such as "nroff" and "troff" were created. Not only was it important to create tools, but soon tools to create tools, like "yacc" and "lex", were developed. "Yacc" and "lex" were used to create numerous little languages and applications like eqn and awk that greatly enhanced the popularity of Unix. 
     The evolution of the tool "diff" created by McIlroy, a commonly used software tool, is an example of how tools were continually improved, based on the experience gained using them. McIlroy reports how he based 
his work on algorithms created by others and then he tried three different algorithms before settling on the one finally used.(54) Other Unix tools were created through a similar process. Each program was created to fulfill some simple capability and was called a tool. The programs were designed to be fun to use and to be helpful to programmers. Among the principles guiding the toolbuilders were: 

     "(i) Make each program do one thing well. To do a new job, 
     build afresh rather than complicate old programs by adding 
     new features. 

     (ii) Expect the output of every program to become the input 
     to another, as yet unknown, program. Don't clutter output 
     with extraneous information. Avoid stringently columnar or 
     binary input formats. Don't insist on interactive input. 

     (iii) Design and build software, even operating systems, to 
     be tried early, ideally within weeks. Don't hesitate to 
     throw away the clumsy parts and rebuild them. 

     (iv) Use tools in preference to unskilled help to lighten a 
     programming task, even if you have to detour to build the 
     tools and expect to throw some of them out after you've 
     finished using them."(55) 
     "Our goals throughout the effort," write Ritchie and Thompson, in describing the research objectives of their work on Unix, "when articulated at all, have always been to build a comfortable relationship with the machine and to explain ideas and inventions in operating systems and other software." (56) 
      Frederick P. Brooks Jr is another computer pioneer who recognized the importance of pipes and combining single function programs into what he calls "a unified programming environment" to make the 
work of programmers more productive. Brooks describes Unix as one of "the first integrated environments to come into widespread use," which "improved productivity by integral factors."(57) 
     In explaining how such an environment functions, he writes: 
    "They attack the accidental difficulties that result 
     from using individual programs together, by providing 
     integrated libraries, unified file formats, and pipes and 
     filters. As a result, conceptual structures that in 
     principle could always call, feed, and use one another can 
     easily do so in practice." (58) 
     Following the development of single function software tools which could be used together via pipes in a programming environment, came the development of whole toolchests and workbenches of tools to rationalize the work of programmers. 
(On the Early History and Impact of Unix. Tools to Build the Tools for a New Millenium, Chapter 9 of  Ronda & Michael Hauben's "Netizen's Netbook") 

Mike Gancarz, The Unix Philosophy, Digital Equipment Corp, 1996 


Peter H. Salus, A Quarter Century of Unix, Addison-Wesley Pub Co, 1994 


General Help for UNIX (also available in PostScript  and PDF  formats) 
Advanced Help for UNIX (also available in PostScript  and PDF  formats) 
Basic UNIX Commands and Utilities 

Free Unices (referenced here only for completeness)

  • The standard of BSD systems has become POSIX, and 4.4BSD has split into lots of diverging projects: FreeBSD for Intel platforms NetBSD focuses on portability and networking and supports many platforms; OpenBSD ,an offspring of NETBSD focuses on stability and security.
  • GNUStep  aims to implement a free clone of NeXTStep
  • Linux :
    • There are versions for Alpha (64 bit!), ARM, Sparc, Ultrasparc, m68k [runs on Atari and Amiga , PalmPilot; for Mac , and for NeXT Cube], PowerMac (Mach microkernel mklinux) and other PowerPC , MIPS (including some SGI workstations), HP-PA (with mklinux), more in progress.
  • Mach is a free microkernel upon which many experimental OSes are built.
  • The Flexmach project tries to implement objects above Mach in C++ according to the related OMOS model and implementation over plain unix. (University of Utah has stopped maintaining Mach4, concentrates now on Flux project and Fluke microkernel)
  • THix (dead project)

Commercial Unices which follow POSIX convention

  • MachTen commercial version of BSD4.4 using Mach on 680x0 and PPC MacIntoshes. (free: MacBSD.)
  • Plan9 Commercial OS, but freely available for academic use.

Modern Unices

SVR4 AT&T and Sun
has integrated features of SVR3, SunOs, 4.3 BSD, MS Xenix. Total rewrite of system V. Process scheduling classes,virtual mem management, virtual file system, preemptive kernel. Data structures are dynamically allocated.

Virtual memory system. Most widely used in academic world. Basis for many comercial Unices.

Sun Solaris 2.x (2.8)
Multithreaded kernel , support for SMP


Unix today Linux BSD...

Linux is the perfect alternative to Windows if you're looking for server applications or a ( windowed ) command line system. But today Linux is also usefull as  graphical alternative to Windows even for  demanding multimedia applications, graphical 3d applications with moving objects, gaming etc (Opengl today needs a facelift).

 But even more attractive could be the many variants of BSD: OpenBSD, NETBSD, FreeBSD.... If only the developpers could manage their egos. A reunited BSD could be a strong opponent to Windows.

If you insist in using Windows software: For all Unices there is today a free Windows emulator WINE, which is since 2009 available in stable  versions (Linux, FreeBSD).

Ultrix (DEC)  (outdated)



All about OSs


     A / B / C / D / E / F / G / H / I / J / K / L / M / N / O / P / Q / R / S / T / U / V / W / X / Y / Z



Visit also: