Introduction to Operating Systems

Total Page:16

File Type:pdf, Size:1020Kb

Introduction to Operating Systems Introduction to Operating Systems Daniel Bosk1 Department of Information and Communication Systems (ICS), Mid Sweden University, Sundsvall. intro.tex 1417 2013-11-05 13:50:22Z danbos 1 This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported license. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/. 1 Overview 2 Overview 3 Schedule The schedule is in the central scheduling system in the Student Portal. This schedule is not synchronised with that in the virtual learning environment (Moodle). The sessions and lectures in the schedule are the only ones offered, so there are no sessions planned after the course. Daniel is the principal lecturer and grades the final exam. Alexandra and Tobias are the TAs and will tutor you and grade your hand-ins. 4 Literature Silberschatz2013osc 9th edition [Silberschatz2013osc]. 5 Virtual Learning Environment The virtual learning environment (VLE) used for the course is ”Lärplattformen 2.0”, i.e. Moodle. In the section ”Course Material” found in the VLE you will find recordings of lectures and lecture slides. In the section ”Examination” you will find all things related to the examination, i.e. hand-in assignments. In each hand-in box you will find the instruction for that particular assignment. Read the instructions carefully! The hand-in assignments are numbered starting on 0 and are prefixed with a letter indicating the type of assignment. Theory assignments are prefixed T and laboratory assignments are prefixed L. 6 Examination Hand-ins: theory assignments, laboratory assignments. These are spread evenly across the course. Final exam the last week of the course. 7 Examination Hand-ins T0 Overview T1 Processes T2 Memory L3 Paging Algorithms T4 Storage 8 Examination Final exam The final exam will cover the entire course. The hand-in assignments serve as a good preparation for the exam. 9 Overview 10 Development UNIX was originally developed at Bell Labs. This timeline is derived from documents in Bell Labs’ historical archive [BellLabs2002tco]. 11 Development timeline The 1960s 1965 Multiplexed Infomation and Computing Service (MULTICS) was a joint effort between MIT, Bell Labs and GE to “develop a convenient, interactive, useable computer system that could support many users” [BellLabs2002tco]. 1969 Bell Labs withdrew from the project, but Ken Thompson, Dennis Ritchie, Douglas McIllroy, and J. F. Ossanna continued on their own. Started to write the system on a PDP-7, at first simply as a file system. The system then got a shell, an editor, and an assembler. 12 Development timeline The 1960s 1965 Multiplexed Infomation and Computing Service (MULTICS) was a joint effort between MIT, Bell Labs and GE to “develop a convenient, interactive, useable computer system that could support many users” [BellLabs2002tco]. 1969 Bell Labs withdrew from the project, but Ken Thompson, Dennis Ritchie, Douglas McIllroy, and J. F. Ossanna continued on their own. Started to write the system on a PDP-7, at first simply as a file system. The system then got a shell, an editor, and an assembler. 12 Development timeline The 1970s 1970 Brian Kernighan suggests the name UNIX. They port the current code to a PDP-11. Focused for use in text-processing, patent applications for Bell Labs. 1971 Ritchie improved Thompson’s B programming language into the C programming language. 1972 Thompson started rewriting UNIX in C. (And continuous improvement of C.) 13 Development timeline The 1970s 1970 Brian Kernighan suggests the name UNIX. They port the current code to a PDP-11. Focused for use in text-processing, patent applications for Bell Labs. 1971 Ritchie improved Thompson’s B programming language into the C programming language. 1972 Thompson started rewriting UNIX in C. (And continuous improvement of C.) 13 Development timeline The 1970s 1970 Brian Kernighan suggests the name UNIX. They port the current code to a PDP-11. Focused for use in text-processing, patent applications for Bell Labs. 1971 Ritchie improved Thompson’s B programming language into the C programming language. 1972 Thompson started rewriting UNIX in C. (And continuous improvement of C.) 13 Development timeline The 1970s, continued 1973 UNIX completely rewritten in C. Thompson added McIlroy’s concept of pipes. With this came the UNIX philosophy: “Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface.” [BellLabs2002tco] Ritchie took initiative to manual pages, McIlroy soon took over and is the mind behind the layout of manual pages. 14 Development timeline The 1970s, continued 1973 UNIX completely rewritten in C. Thompson added McIlroy’s concept of pipes. With this came the UNIX philosophy: “Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface.” [BellLabs2002tco] Ritchie took initiative to manual pages, McIlroy soon took over and is the mind behind the layout of manual pages. 14 Development timeline The 1970s, continued 1973 UNIX completely rewritten in C. Thompson added McIlroy’s concept of pipes. With this came the UNIX philosophy: “Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface.” [BellLabs2002tco] Ritchie took initiative to manual pages, McIlroy soon took over and is the mind behind the layout of manual pages. 14 Development timeline The 1970s, continued 1975 Thompson is visiting professor at University of California-Berkeley (UCB). While there he developed version 6 of UNIX. 1978 Professors at Berkeley continued the enhancement of UNIX and distributed their work as Berkeley Software Distribution (BSD). 15 Development timeline The 1970s, continued 1975 Thompson is visiting professor at University of California-Berkeley (UCB). While there he developed version 6 of UNIX. 1978 Professors at Berkeley continued the enhancement of UNIX and distributed their work as Berkeley Software Distribution (BSD). 15 Development timeline The 1980s 1983 Sockets API added to BSD (4.2BSD), i.e. TCP/IP made easily available. David Korn develops the Korn Shell scripting language. Bjarne Stroustrup develops the first version of C++. 1984 AT&T, owner of Bell Labs, started selling UNIX-licenses to companies. 16 Development timeline The 1980s 1983 Sockets API added to BSD (4.2BSD), i.e. TCP/IP made easily available. David Korn develops the Korn Shell scripting language. Bjarne Stroustrup develops the first version of C++. 1984 AT&T, owner of Bell Labs, started selling UNIX-licenses to companies. 16 Development timeline Present To this day, UNIX-like operating systems operate “most large Internet servers, businesses and universities, and a major part of academic and industrial research in operating systems is based on UNIX” [BellLabs2002tco]. 17 Evolution of UNIX 1969 Unics 1969 Open Source 1971 to 1973 UnixTSS 1 to 4 Mixed/Shared Source 1971 to 1973 1974 to 1975 UnixTSS PWB/Unix 5 to 6 Closed Source 1974 to 1975 1978 BSD 1978 1.0 to 2.0 UnixTSS 1979 7 1979 Unix 32v 1980 BSD 1980 3.0 to 4.1 1981 Xenix System III 1.0 to 2.3 1981 1982 Xenix 1982 3.0 1983 BSD 4.2 Sun OS System V 1983 1 to 1.1 R1 to R2 1984 SCO Xenix 1984 UnixTSS 1985 8 SCO Xenix 1985 AIX W286 System V 1986 BSD 4.3 1.0 R3 HP/UX Sun OS 1.0 to 1.2 1986 1.2 to 3.0 SCO Xenix 1987 UnixTSS V386 1987 (Time Sharing HP/UX 1988 System) BSD 4.3 System V R4 2.0 to 3.0 1988 9 to 10 Tahoe SCO Xenix 1989 W386 1989 BSD 4.3 1990 Reno 1990 BSD NET/2 1991 Linux 0.0.1 1991 Sun OS Minix 4 1.x NEXTSTEP/ 386BSD OPENSTEP 1992 1992 1.0 to 4.0 HP/UX NetBSD 6 to 11 Linux BSD 0.8 to 1.0 1993 1993 0.95 to 1.2.x SCO Unix 4.4 to 3.2.4 Unixware FreeBSD 4.4 lite2 1.x to 2.x 1994 1994 1.0 to 1995 2.2.x NetBSD OpenBSD 1995 1.1 to 1.2 OpenServer 1.0 to 2.2 5.0 to 5.04 Solaris 1996 AIX 2.1 to 10 1996 3.x to 6.x 1997 1997 NetBSD 1.3 1998 FreeBSD 1998 3.0 to 3.2 Minix OpenServer Unixware 1999 2.x Mac OS X 5.0.5 to 5.0.7 7.x Linux Server 2000 1999 2.0 to 2.6.x OpenBSD 2.3 to 4.x 2000 FreeBSD NetBSD 2001 to 2004 3.3 to 8.0 1.3 to 5.x 2001 to 2004 Mac OS X HP/UX 11i to 11i v3 2005 10.0 to 10.7 2005 Minix (Darwin) OpenServer OpenSolaris 3.x 6.x 2008.05 and 2006 to 2010 later 2006 to 2010 Figure: A simplified overview of UNIX history. For details see http://www.levenez.com/unix/. Image: https: //en.wikipedia.org/wiki/File:Unix_history-simple.svg. 18 ReferenserI 19.
Recommended publications
  • Reasoning About Programs Need: Definition of Works/Correct: a Specification (And Bugs) but Programs Fail All the Time
    Good programs, broken programs? Goal: program works (does not fail) Reasoning about Programs Need: definition of works/correct: a specification (and bugs) But programs fail all the time. Why? A brief interlude on 1. Misuse of your code: caller did not meet assumptions specifications, assertions, and debugging 2. Errors in your code: mistake causes wrong computation 3. Unpredictable external problems: • Out of memory, missing file, network down, … • Plan for these problems, fail gracefully. 4. Wrong or ambiguous specification, implemented correctly Largely based on material from University of Washington CSE 331 A Bug's Life, ca. 1947 A Bug's Life Defect: a mistake in the code Think 10 per 1000 lines of industry code. We're human. -- Grace Hopper Error: incorrect computation Because of defect, but not guaranteed to be visible Failure: observable error -- program violates its specification Crash, wrong output, unresponsive, corrupt data, etc. Time / code distance between stages varies: • tiny (<second to minutes / one line of code) • or enormous (years to decades to never / millons of lines of code) "How to build correct code" Testing 1. Design and Verify Make correctness more likely or provable from the start. • Can show that a program has an error. 2. Program Defensively • Can show a point where an error causes a failure. Plan for defects and errors. • Cannot show the error that caused the failure. • make testing more likely to reveal errors as failures • Cannot show the defect that caused the error. • make debugging failures easier 3. Test and Validate Try to cause failures. • Can improve confidence that the sorts of errors/failures • provide evidence of defects/errors targeted by the tests are less likely in programs similar • or increase confidence of their absence to the tests.
    [Show full text]
  • The AWK Programming Language
    The Programming ~" ·. Language PolyAWK- The Toolbox Language· Auru:o V. AHo BRIAN W.I<ERNIGHAN PETER J. WEINBERGER TheAWK4 Programming~ Language TheAWI(. Programming~ Language ALFRED V. AHo BRIAN w. KERNIGHAN PETER J. WEINBERGER AT& T Bell Laboratories Murray Hill, New Jersey A ADDISON-WESLEY•• PUBLISHING COMPANY Reading, Massachusetts • Menlo Park, California • New York Don Mills, Ontario • Wokingham, England • Amsterdam • Bonn Sydney • Singapore • Tokyo • Madrid • Bogota Santiago • San Juan This book is in the Addison-Wesley Series in Computer Science Michael A. Harrison Consulting Editor Library of Congress Cataloging-in-Publication Data Aho, Alfred V. The AWK programming language. Includes index. I. AWK (Computer program language) I. Kernighan, Brian W. II. Weinberger, Peter J. III. Title. QA76.73.A95A35 1988 005.13'3 87-17566 ISBN 0-201-07981-X This book was typeset in Times Roman and Courier by the authors, using an Autologic APS-5 phototypesetter and a DEC VAX 8550 running the 9th Edition of the UNIX~ operating system. -~- ATs.T Copyright c 1988 by Bell Telephone Laboratories, Incorporated. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopy­ ing, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America. Published simultaneously in Canada. UNIX is a registered trademark of AT&T. DEFGHIJ-AL-898 PREFACE Computer users spend a lot of time doing simple, mechanical data manipula­ tion - changing the format of data, checking its validity, finding items with some property, adding up numbers, printing reports, and the like.
    [Show full text]
  • The Evolution of the Unix Time-Sharing System*
    The Evolution of the Unix Time-sharing System* Dennis M. Ritchie Bell Laboratories, Murray Hill, NJ, 07974 ABSTRACT This paper presents a brief history of the early development of the Unix operating system. It concentrates on the evolution of the file system, the process-control mechanism, and the idea of pipelined commands. Some attention is paid to social conditions during the development of the system. NOTE: *This paper was first presented at the Language Design and Programming Methodology conference at Sydney, Australia, September 1979. The conference proceedings were published as Lecture Notes in Computer Science #79: Language Design and Programming Methodology, Springer-Verlag, 1980. This rendition is based on a reprinted version appearing in AT&T Bell Laboratories Technical Journal 63 No. 6 Part 2, October 1984, pp. 1577-93. Introduction During the past few years, the Unix operating system has come into wide use, so wide that its very name has become a trademark of Bell Laboratories. Its important characteristics have become known to many people. It has suffered much rewriting and tinkering since the first publication describing it in 1974 [1], but few fundamental changes. However, Unix was born in 1969 not 1974, and the account of its development makes a little-known and perhaps instructive story. This paper presents a technical and social history of the evolution of the system. Origins For computer science at Bell Laboratories, the period 1968-1969 was somewhat unsettled. The main reason for this was the slow, though clearly inevitable, withdrawal of the Labs from the Multics project. To the Labs computing community as a whole, the problem was the increasing obviousness of the failure of Multics to deliver promptly any sort of usable system, let alone the panacea envisioned earlier.
    [Show full text]
  • Computer Science Undergraduate Program
    Princeton Computer Science Undergraduate Program JP Singh and Brian Kernighan Directors of Undergraduate Studies March, 2020 Why Computer Science? • it's fun and it's interesting • computers are a part of everything – daily life: mail, web, Facebook, phones, ... – lots of hidden computing too: phones, cars, ... – unlimited applications, always something new • so everything is a potential topic for – CS courses – independent work – summer jobs – permanent jobs, doing a startup – grad school What do majors do next? • software companies both large and small • Wall St, consulting • grad school in CS • grad school in law, medicine, business, ... • their own startups • teaching • ... Princeton Computer Science Faculty • 45 regular faculty, 13 lecturers – theory – operating systems & networks – programming languages – graphics & vision – artificial intelligence, machine learning – computational biology – security & privacy, policy, … – ... Other important people Director of Undergraduate Director of Undergraduate Studies Studies - Pre-majors - Ugrad Curriculum - Non-majors - Honors, Awards - Study Abroad - Certificate Program - Transferring In to COS Brian Kernighan JP Singh Current Students • COS is the most popular major with 454 concentrators • 162 seniors – 128 BSE, 34 AB – 53 females (33%) • 171 juniors – 114 BSE, 57 AB – 62 females (36%) • 121 sophomores (BSEs only) – 51 females (42%) – AB sophomores declare in late April • COS 126 is Princeton’s most popular course – Nearly 70% of all students take at least one CS course 6 Undergrad CS
    [Show full text]
  • Oral History of Brian Kernighan
    Oral History of Brian Kernighan Interviewed by: John R. Mashey Recorded April 24, 2017 Princeton, NJ CHM Reference number: X8185.2017 © 2017 Computer History Museum Oral History of Brian Kernighan Mashey: Well, hello, Brian. It’s great to see you again. Been a long time. So we’re here at Princeton, with Brian Kernighan, and we want to go do a whole oral history with him. So why don’t we start at the beginning. As I recall, you’re Canadian. Kernighan: That is right. I was born in Toronto long ago, and spent my early years in the city of Toronto. Moved west to a small town, what was then a small town, when I was in the middle of high school, and then went to the University of Toronto for my undergraduate degree, and then came here to Princeton for graduate school. Mashey: And what was your undergraduate work in? Kernighan: It was in one of these catch-all courses called Engineering Physics. It was for people who were kind of interested in engineering and math and science and didn’t have a clue what they wanted to actually do. Mashey: <laughs> So how did you come to be down here? Kernighan: I think it was kind of an accident. It was relatively unusual for people from Canada to wind up in the United States for graduate school at that point, but I thought I would try something different and so I applied to six or seven different schools in the United States, got accepted at some of them, and then it was a question of balancing things like, “Well, they promised that they would get you out in a certain number of years and they promised that they would give you money,” but the question is whether, either that was true or not and I don’t know.
    [Show full text]
  • USENIX April 06
    FOR THE PAST SIX OR SEVEN YEARS I have been teaching a course called BRIAN KERNIGHAN “Advanced Programming Techniques”[7] to (mostly) sophomore and junior computer science majors. The course covers an eclec- tic mix of languages, tools, and techniques, code testing and with regular coding assignments and final its role in teaching group projects. Brian Kernighan was in the Computing Science Dijkstra famously remarked that “Program testing Research Center at Bell Labs and now teaches in the CS department at Princeton, where he also can be quite effective for showing the presence of writes programs and occasional books. The latter bugs, but is hopelessly inadequate for showing are better than the former, and certainly need less their absence.” Nevertheless, programmers who maintenance. think about testing are more likely to write cor- [email protected] rect code in the first place. Thus I try to encour- age the students to do intensive testing of their code, both in one-week assignments in the first half of the semester and as part of their eight- week projects. My personal interest in testing comes from main- taining a widely used version of AWK for the past 25 years. In an attempt to keep the program working, and to maintain my sanity as bugs are fixed and the language slowly evolves, I have cre- ated somewhat over 1000 tests, which can be run automatically by a single command. Whenever I make a change or fix a bug, the tests are run. Over the years this has caught most careless mistakes— once fixed, things tend to stay fixed and new code rarely breaks old code.
    [Show full text]
  • The AWK Manual Edition 1.0 December 1995
    The AWK Manual Edition 1.0 December 1995 Diane Barlow Close Arnold D. Robbins Paul H. Rubin Richard Stallman Piet van Oostrum Copyright c 1989, 1991, 1992, 1993 Free Software Foundation, Inc. This is Edition 1.0 of The AWK Manual, for the new implementation of AWK (sometimes called nawk). Notice: This work is derived from the original gawk manual. Adaptions for NAWK made by Piet van Oostrum, Dec. 1995, July 1998. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Foundation. Preface 1 Preface If you are like many computer users, you would frequently like to make changes in various text files wherever certain patterns appear, or extract data from parts of certain lines while discarding the rest. To write a program to do this in a language such as C or Pascal is a time-consuming inconvenience that may take many lines of code. The job may be easier with awk. The awk utility interprets a special-purpose programming language that makes it possible to handle simple data-reformatting jobs easily with just a few lines of code.
    [Show full text]
  • The A-Z of Programming Languages: AWK
    CS@CU NEWSLETTER OF THE DEPARTMENT OF COMPUTER SCIENCE AT COLUMBIA UNIVERSITY VOL.5 NO.1 WINTER 2008 The A-Z of Programming Languages: AWK Professor Alfred V. Aho talks about the history and continuing popularity of his pattern matching language AWK. Lawrence Gussman Professor of Computer Science Alfred V. Aho The following article is reprinted How did the idea/concept of language suitable for simple It was built to do simple data with the permission of the AWK language develop data-processing tasks. processing: the ordinary data Computerworld Australia and come into practice? processing that we routinely (www.computerworld.com.au). We were heavily influenced by As with a number of languages, GREP, a popular string-matching did on a day-to-day basis. We The interview was conducted just wanted to have a very by Naomi Hamilton. it was born from the necessity utility on UNIX, which had to meet a need. As a researcher been created in our research simple scripting language that Lawrence Gussman Professor would allow us, and people of Computer Science Alfred V. at Bell Labs in the early 1970s, center. GREP would search I found myself keeping track a file of text looking for lines who weren’t very computer Aho is a man at the forefront savvy, to be able to write of computer science research. of budgets, and keeping track matching a pattern consisting Formerly the Vice President of editorial correspondence. of a limited form of regular throw-away programs for of the Computing Sciences I was also teaching at a nearby expressions, and then print all routine data processing.
    [Show full text]
  • The A-Z of Programming Languages (Interviews with Programming Language Creators)
    The A-Z of Programming Languages (interviews with programming language creators) Computerworld, 2008-20101 Ada: S. Tucker Taft ...................................................... 1 Arduino: Tom Igoe ...................................................... 5 ASP: Microsoft .......................................................... 9 AWK: Alfred Aho ....................................................... 11 AWK & AMPL: Brian Kernighan ....................................... 15 Bash: Chet Ramey....................................................... 17 C#: Anders Hejlsberg.................................................... 20 C++: Bjarne Stroustrup ................................................. 27 Clojure: Rich Hickey .................................................... 35 ColdFusion: Jeremy Allaire .............................................. 38 D: Walter Bright ......................................................... 41 Erlang: Joe Armstrong................................................... 44 F#: Don Syme .......................................................... 48 Falcon: Giancarlo Niccolai ............................................... 51 Forth: Charles Moore .................................................... 59 Groovy: Guillaume Laforge .............................................. 61 Haskell: Simon Peyton-Jones............................................. 65 INTERCAL: Don Wood................................................. 76 JavaScript: Brendan Eich................................................ 79 Lua: Roberto Ierusalimschy..............................................
    [Show full text]
  • Operating Systems
    CS101 – Fundamentals of Computer and Information Sciences – LIU 1 of 2 Operating systems OS History We covered a (slightly rambling) story about the history of operating systems. Batch computing Batch systems were extraordinarily large and expensive, so that organizations could afford at most one or two. The machines had a human operator who was responsible for scheduling tasks for the machine, in order to make best use of its (very valuable) time. • Norwich council takes delivery of its first computer –@StuartSumner • Punch cards • IBM ad feat. punched cards • Keypunch machine • IBM 704 with card reader • LEGO Grace Hopper with Univac TODO: scheduling and calculating turn-around time using First-Come First-Served (FCFS) vs. Shortest Job First. (See book section 10.4, pages 350–351.) Time-sharing When mini-computers became available (just the size of a refrigerator, not a whole room), then we could have one for each workgroup or department within an orga- nization. They were powerful enough that multiple users could share the computer at the same time, by connecting multiple terminals (keyboard and monitor) to the same machine. The job of the human operator was now automated, and this was the golden ageof operating systems. Not only did they have to schedule tasks effectively, but they had to switch efficiently among serving different users, protect those users from interfer- ing with each other’s work, and so on. Some of the operating systems developed in this era were Multics, VMS, and UNIX. • PDP-11 with Ken Thompson, Dennis Ritchie • VT-101 terminal • IBM 7090 time-sharing video • Brian Kernighan on Bell Labs (Computerphile video) 2 of 2 Prof.
    [Show full text]
  • COMSW 1003-1 Introduction to Computer Programming in C
    COMSW 1003-1 Introduction to Computer Programming in C Lecture 1 Spring 2011 Instructor: Michele Merler C http://www1.cs.columbia.edu/~mmerler/comsw1003-1.html Course Information - Goals “A general introduction to computer science concepts, algorithmic problem- solving capabilities, and programming skills in C” University bulletin • Learn how to program, in C • Understand basic Computer Science problems • Learn about basic data structures • Start to think as a computer scientist • Use all of the above to solve real world problems C Course Information - Instructor • Michele Merler – Email: [email protected] or [email protected] – Office : 624 CEPSR – Office Hours: Friday 12pm-2pm • 4th year PhD Student in CS Department • Research Interests: – Image & Video Processing – Multimedia – Computer Vision C Course Information- TA • TDB – Email: [email protected] – Office : TA room ? – Office Hours: TDB C Course Information- Courseworks We will be using Courseworks (https://courseworks.columbia.edu/) for: • Message board for discussions • Submit Homeworks • Grades Check out the board before you send an email to the instructor or the TA, the answer you are looking for could already be there! C Course Information Requirements and Books Requirements • Basic computer skills • CUNIX account Textbooks • The C Programming Language (2nd Edition) by Brian Kernighan and Dennis Ritchie http://www1.cs.columbia.edu/~mmerler/coms1003-1/C Programming Language.rar • Practical C Programming (3rd Edition) by Steve Oualline C Course Information - Grading •
    [Show full text]
  • The Development of the C Languageߤ
    The Development of the C Languageߤ Dennis M. Ritchie Bell Labs/Lucent Technologies Murray Hill, NJ 07974 USA [email protected] ABSTRACT The C programming language was devised in the early 1970s as a system implementation language for the nascent Unix operating system. Derived from the typeless language BCPL, it evolved a type structure; created on a tiny machine as a tool to improve a meager programming environment, it has become one of the dominant languages of today. This paper studies its evolution. Introduction This paper is about the development of the C programming language, the influences on it, and the conditions under which it was created. For the sake of brevity, I omit full descriptions of C itself, its parent B [Johnson 73] and its grandparent BCPL [Richards 79], and instead concentrate on characteristic elements of each language and how they evolved. C came into being in the years 1969-1973, in parallel with the early development of the Unix operating system; the most creative period occurred during 1972. Another spate of changes peaked between 1977 and 1979, when portability of the Unix system was being demonstrated. In the middle of this second period, the first widely available description of the language appeared: The C Programming Language, often called the ‘white book’ or ‘K&R’ [Kernighan 78]. Finally, in the middle 1980s, the language was officially standardized by the ANSI X3J11 committee, which made further changes. Until the early 1980s, although compilers existed for a variety of machine architectures and operating systems, the language was almost exclusively associated with Unix; more recently, its use has spread much more widely, and today it is among the lan- guages most commonly used throughout the computer industry.
    [Show full text]