Latest revision as of 15:33, 8 November 2010

Question

What "operating systems" have been implemented in the following languages: LISP, Modula-3, Smalltalk, Java? To what extent do these systems match the capabilities of operating systems implemented in C and C++?

Answer

Introduction

Not so long ago people believed the Earth was a flat world at the center of the universe. This essay addresses a more recent falsehood: that all operating systems are written in assembly language and C. It's not surprising that students of computing in this century would genuflect at the academic altars of Kernighan & Ritchie. After all we grew up with our computer worlds already pre-formed into the conceptual continents of Apple OS, UNIX, and Windows. The more historically curious among us are vaguely aware that other island cultures do exist but they represent civilizations defeated in the marketplace. Explorations into these ancient worlds resemble documentaries about archeologists decoding rediscovered languages etched in stone. But scratch the surface of any of our so-called modern operating systems and you'll find echoes of these ancient languages in our own familiar worlds. Ellen Ullman said it best when she wrote,

We build our computer systems like we build our cities: over time, without a plan, on top of ruins.

In the sections below we present our explorations into a few truly foundational operating systems. We will also see some brand new ones that prove we stand, as one twelfth century scholar put it, on the shoulders of giants.

**Operating Systems By Language**
Language	OS List
Lisp	MIT's Lisp Machines, Genera
Modula-3	SPIN OS, Oberon
Smalltalk	Smalltalk-80 on Xerox Alto, Squeak
Java	JavaOS, JNode, JX, Android

Lisp Based

Overview

Lisp is the second oldest programming languages, established in the late 1960's as a list-processing language. It started out being perfect for math but when it came to programming with it, it left a lot to be desired. Since then there have been a number of different versions of it, from the first Lisp – called “pure Lisp” – to Scheme and Common Lisp. Unlike most object-oriented languages which are focused on classes and instances among other things, Lisp was initially focused more on functions, in which functions call other functions, though later versions of Lisp did eventually add in classes and other typical object-oriented features. It was after this that Genera was created, an operating system written entirely in Lisp, and developed from an earlier operating system on MIT's Lisp Machine.

The Lisp Machine project in began in 1974, where Richard Greenblatt and Thomas Knight, programmers at MIT, designed a computer for general use that was designed for a single user, in which the operating system was programmed entirely in Lisp. It was designed to be completely open to the user, so any changes the user wanted to make could be done during run-time. It was also one of the first systems to be programmed in a 32-bit architecture, making it far more versatile than a number of other operating systems at the time. Despite this, however, the first Lisp Machine was quite basic compared to later iterations, namely Genera.

Motivation

Genera is an evolution of the initial Lisp Machine operating system, and as such improved upon many of the basic features of the system. Genera was the first object-oriented operating system, making it stand out among the already well-known Lisp Machines, especially given the fact that it isn't a composition of languages like other operating systems – most using the primary language for the operating system and another language, such as assembly, to deal with hardware directly – but written entirely in Lisp – any of five different dialects of the language – including the lowest levels of the operating system that interact with hardware due to its effective lack of a kernel. Not having to deal with a kernel allows Genera to be very powerful and efficient in certain areas, most especially in the most complex applications such as those dealing with intelligent CAD and graphics, though when given very simple, very routine applications or processes it is much less efficient than other operating systems.

Achievements

Another primary difference from other operating systems is that Genera is a fully open system like the first Lisp Machines. Having an open system has its positive and negative aspects. Among the foremost positive aspects is that the user is in control and not left to the whims of the operating system as is common in non-open systems – if the user doesn't like how something is happening, they can simply go in and change it from happening that way again – and allows for very quick prototyping, not needing to wait to compile every little change. Also, due to utilizing very lightweight objects and the fact that everything is in a single address space rather than split across multiple spaces greatly increases efficiency, though again mainly in non-simple tasks.

Like operating systems written in C/C++, Genera has multiple inheritance and automatic garbage collection. Unlike C/C++, however, Genera uses object-oriented memory. This gives Genera a very useful feature that many other systems cannot do, which is that, given a memory address, the system is able to provide the start address, size, and the type of object in that memory location, which increases efficiency. Even the way files are accessed is very different from other operating systems, as it uses a generic file access system; in a generic file access system, rather than following a typical structure of keeping the commands needed for local and networked files different, the commands are the same, meaning that the system essentially acts like a file on a system on the other side of the world is a local file.

Problems

Not everything is great with an open system, however, as there are definite security concerns: with an open system, the user can change anything, and programs can interact with other programs and change anything, meaning that if a virus were unleashed on a Genera system it could be catastrophic. To counter this problem Genera systems are protected by a very simple method: keeping the physical system itself out of reach of all but authorized users and behind locked doors. To compare to other operating systems, such as those written in C/C++, it is generally less secure because of the open system, though they are both equally at risk when installing software, as both systems are completely open at that specific junction. Genera also has issues with modularity, as it allows for something to be called even when it is not supposed to be able to be called because, as it is an open system, there is nothing really stopping this from happening. Some versions of Genera and Genera applications are also very well-documented and run quite smoothly, but others are poorly documented and run quite slowly as they are built on top of older versions without any real plan beyond adding on an extra feature here or there over and over again.

Current Status

Genera and Lisp Machines, while still being used in a select few locations, are not currently being developed, as their time has passed. Their legacy still lives on, however, in the object-oriented operating systems still in use today.

Modula-3 Based

Overview

An idea came to mind. A question was proposed. Can an operating system have extensibility, safety, and good performance? A group of computer scientists from Washington University took on this question and tried to come up with an answer. That’s how SPIN operating system was created. SPIN is an operating system that blends the user-level with the kernel level. The main feature is that the kernel can be extended using modules that implement interfaces to meet the applications needs to optimise performance and safety. The programming language used is Modula-3, and the reason for using this language is for its type safe properties like interfaces, extension, and its automatic storage management. The operating system sits on the traditional monolithic kernel. This is because the authors of SPIN argue that microkernels are not extendible due to the massive overhead created from switching in and out of the kernel.

Motivation

A poorly matched implementation prevents an application from working well, while a poorly matched interface prevents it from working at all.

This is the sole purpose for creating SPIN. The team had to meet three important features to make this work, a Flexible kernel with safe extensions and a good overall performance. Operating systems based on C/C++ are too general that handle many applications. Therefore, some programs may fall through the cracks and suffer the lack of safety and performance. The goal for SPIN however, was to create a specialized operating system that can run a range of applications without sacrificing safety or performance. This system would allow the user programs and applications to manipulate and change the system’s interface to load and access the data or memory needed safely and with a good overall performance. This was possible through the type safe extensions of Modula-3. Unlike C/C++, Modula-3 is considered a safe language; it guarantees the protection of the kernel from dangerous extension by forcing them to interact with the kernel through specific interfaces. Such safety is essential because extensions are executed in the kernel's address space in supervisor mode, not in user space.

Achievements

SPIN operating system came through with positive results, it actually works. Most of the goals set by the creators were accomplished. SPIN overcame the large overhead of microkernels by enforcing the extensions to be run in the kernel’s address space. The number of switches dropped which actually improved efficiency significantly. By using Modula-3’s safe interfaces, there was no run-time checking of the code of the extensions. This was a huge advantage over languages like C/C++ due to the fact that a significant overhead was cleared from the execution time. SPIN addressed the latency issue by only allowing code with low latency, which is quite small, to access the system through extensions that access the kernel directly. This is another advantage of using a safe programming language.

Problems

Two general issues with extendible systems are adaptability and reliability. Using a safe programming language comes with a price. In SPIN, there is a loss of efficiency when the dynamic checks run for array index bounds. These checks also add a significant overhead to the execution time. SPIN is written with very few Modula-3 code lines and are much easier to understand compared to other operating systems written in C or C++. However, the kernel of the system is almost entirely written in C and Assembly. These two languages are considered unsafe in contrast to Modula-3. The mix of safe and unsafe code is a huge complication which leads to many bugs, which compromises the safe extensions and interfaces used by applications.

Current Status

SPIN, and extendible operating systems in general, is becoming the playground for research. The authors of SPIN at the University of Washington are performing projects and continuing the on-going research of improving extendible operating systems. The solutions they might come up with could greatly influence the operating systems as we see them today.

Oberon

Overview

The notion of creating an operating system that takes advantage of the unique properties of the Modula-3 language was not only investigated by the SPIN team at Washington University. Niklaus Wirth, the creator of the Modula language, along with Jürg Gutknecht investigated the possibility of creating an operating using Modula-2. However, due to limitations in the language, they instead opted to utilize a new language based upon the older Modula-2 one, creating the Oberon language. It is with this that they developed the Oberon operating system, a very simple yet effective system utilizing an unconventional text-based user interface.

Motivation

First developed in 1985, Oberon was designed for use on ETH Zurich's NS32032-based Ceres system. It was, at the time, one of the first object-oriented operating systems, utilizing one of the first 32-bit processors on the market. While it was originally planed to be created with the Modula-2 language, it lacked desired safe type-extension facilities, and so the team instead utilized a purpose built language that drew heavily from Modula, which, like the operating system itself, was entitled Oberon.

In addition to being a safer language than its predecessor, Oberon also made use of a garbage collector, and was vastly more streamlined than Modula-2, with the Oberon report being a third of the size of that of its predecessor and a full compiler at only around 4000 lines of code. As a result of the safety facilities in place within the language, the Oberon operating system could be built with significantly lower risk of logical errors and bugs in runtime.

Achievements

Perhaps one of the most interesting features of the Oberon operating system can be seen in a particular version entitled Native Oberon. While most versions of Oberon were incredibly compact, to the point of the entire OS, along with an Oberon language compiler an assorted utilities, being able to fit on a single 3.5" floppy disk, Native Oberon was unique in that it could be run directly from the floppy on bare PC hardware.

In addition to this uncommon and convenient feature, Oberon also made use of an unconventional text-based user interface. This system allowed for the point-and-click convenience of a GUI, with the versatility of a command line.

Problems

It is difficult to accurately discern what if any problems arose within Oberon. It was successfully completed and implemented for use with the Ceres system. Due to the safe nature of the Oberon language which the operating system was built off of, run-time errors within Oberon were minimized. The language itself however did and still does suffer from some flaws in the form of certain safety features commonly implemented in other safe languages being omitted, which can potentially cause problems for developers who are unaware of the absence and are expecting them to be present.

Current Status

The original Oberon has ceased further development for a number of years now, but this is not the case for operating systems based around the Oberon language. ETH Zurich has since developed a number of additional systems with the knowledge gained from the first Oberon operating system.

The latest of these is the Bluebottle OS, also known as A2. It is an efficient environment, with multiprocessor support, while retaining the compact size and text-based interface of its predecessor. While the original Oberon was targeted for simply in-house hardware, both the operating system and the language has since been ported to a variety of platforms.

Smalltalk Based

Overview

The best way to predict the future is to invent it. -- Alan Kay

If you are reading this paper on a personal computer, and it has a GUI with overlapping windows, desktop icons, and a mouse pointer then you owe a debt to a group of researchers led by Alan Kay at Xerox's Palo Alto Research Center, or Xerox PARC. Many of those ideas had appeared elsewhere in one form or another, but the first time they came together in a demonstrable and portable form was in the early 1970s at Xerox on a machine called the Alto [1]. Their example of a working personal computer was to be the inspiration that launched Apple into the history books.

Motivation

Searching for operating systems written in Smalltalk is an exercise in recursion. The Smalltalk OS was written in -- what else -- Smalltalk. But Alan Kay's Learning Research Group (LRG) didn't just set out to write a clever new language that could bootstrap its own environment. Their goal was to produce an entirely new learning environment to "amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." [2]

Achievements

They did manage to invent new ways of think about computing. Alan Kay coined the term "object-oriented programming". His inspiration had come from notions of objects already well known in LISP but he wasn't shy about giving credit where it was due. Kay believed his knowledge of LISP helped him think more clearly about computer problems. He felt it contained "great thinking patterns" and "deep beauty" and he vowed to preserve these qualities in the language that would become Smalltalk.

But Kay wasn't just interested the symbolic language at the heart of a system. He incorporated recent studies on learning and cognition from such experts such as Maria Montessori, Jean Piaget, and Jerome Bruner in his goal to form a complete vision of the personal computer. For instance, Bruner's research implied that people learn new thoughts in a loose sequence of translations [3]. First there are actions, or enactive representations which transform into images or iconic representations, and finally into language or symbolic representations. We may take it for granted today, but it was human insights such as these that helped Kay form the basis of graphical user interfaces as channels through which we perceive ideas represented in a computer.

Still the language is no small point. The central idea in Smalltalk (and Smalltalk-80 as an example of a whole system) is that "everything is an object". This includes what we already might think of as objects, such as files, forms, and fields but it also includes transformational methods such as actions, behaviors, and calculations. This places it in distinct contrast with operating systems written in C, and even those written in C++. Gone are such notions as process and semaphore. In their place are messages between objects and events to which interested objects may react.

Another difference in Smalltalk from C-based operating systems is the lack of security. The only means Smalltalk has of protecting anything is through the visibility (private or public) of an object's methods and properties. But if you know how to dig through the system you can modify -- and break -- just about everything. This may be offer a sense of freedom to some. In the networked world this seems more than a bit risky. Yes, Smalltalk has networking.

Problems

Performance in Smalltalk-80 wasn't what we expect from our machines today. A later version of the system called Squeak made some attempt to address this issue (and that of portability) by writing a C language generator to create its virtual machine. This was reasonably successful, and you can now run Squeak on a number of platforms including stand-alone inside of VirtualBox.

Most non-programmers don't know much about Smalltalk-80 or Squeak though it's tempting to speculate what might have happened if Xerox had chosen to keep its secrets from Apple and commercialize the Alto. The decision not to commercialize was one that hurt Alan Kay's team, one of whom in fact seized the moment and went to work for Apple. By the mid-seventies Kay wasn't sure they had completely solved the problems for which they had set out. In his disillusionment he sought to burn everything and start over. He was concerned he would be fulfilling both claims of Marshall McLuhan, namely that "our tools reshape us" and "inadequate tools still reshape us", though presumably not always for the better.

Current Status

The Smalltalk world continues to have ripples around the world, though perhaps less than the incredible splash they made in the 1970s.

Java Based

Overview

Java is used on a plethora of devices and systems throughout the industry from cell phones to web applets. With Java being a language that creates a virtual machine for each application, one would think that it is already suited to be an operating system in itself but this is not the case. Java is built to run on top of other operating systems such as Microsoft Windows, Mac OS X and Ubuntu Linux rather than being a standalone system. This section will discuss various operating systems that are written in Java such as JavaOS, Android, JNode and JX.

JavaOS is Sun Microsystems very own creation. This system runs on different layers to make a scalable and easily updateable operating system ^[4]. The first layer is the microkernel which handles the memory architecture, booting, interrupt handling, threading, traps and DMA handling. The Java Virtual Machine is also compiled into native code for the system and is run on top of the microkernel. The second layer consists of the JavaOS for Business software which extends the memory module to optimize for systems with limited memory^[5]. All device drivers for the system are written and run in Java and are what the third layer is consisted of. Finally, the fourth layer is a stand-alone JDK runtime environment used to run user applications.

Android was created by a very ambitious team at Google for use with cell phones. It is basically an operating system running on top of another minimalistic operating system. At the very lowest end of Android, a Linux 2.6 kernel is what powers it. All device drivers are written and compiled for the native hardware or compiled using Google’s Native Development Kit and core system libraries such as libc, OpenGL | ES and SQLite are dynamically linked in per application ^[6]. In the Android runtime, the Dalvik Virtual Machine (DVM) controls applications similar to the Java Virtual Machine. Dalvik is similar to the aforementioned JavaOS as it relies on the kernel to manage threading and low-level memory management. Running on top of the DVM are core libraries and application frameworks for the Android operating system. These frameworks include resource management, window management, notification manage just to name a few. Applications are then built on top of these frameworks and are the end result in which the user will actually interact with.

JNode began as the Java Bootable System (JBS) in 1995. Ewout Prangsma, the creator, was unhappy with the amount of native C and assembly used for the system so he began a new project, JNode. JNode only uses a small amount of assembly code for booting the system now compared to the initial JBS ^[7]. The rest of the system is completely written in Java including its graphical user interface. Applications in JNode are referred to as plugins ^[8] including the device drivers, filesystems, networking and user applications.

JX was created at the University of Erlangen. At it’s base is a microkernel that the basic Java Virtual Machine runs on which is similar to JavaOS. The system runs on the idea of domains where the microkernel runs at domain level zero and subsequent programs run in domain A, B, C, etc. Domains contain their own threads, heap and garbage collector and can communicate with other domains using portals. A portal is essentially the same as inter-process communication but using domains as processes instead ^[9].

Motivation

Java is a powerful language that already contains the code necessary for running on many different platforms. With the concept of virtual machines for each individual application it provides a layer of security that not every operating system has. Each virtual machine has it’s own heap which keeps other processes from accessing and writing over already allocated memory since the kernel manages the memory paging. With the use of just-in-time (JIT) compilers, these operating systems can almost achieve comparable run times when compared to native compiled applications.

Since all Java applications are compiled into the same set of bytecode, third-parties can develop their own implementation of the Java runtime. For example, Google has created the Dalvik Virtual Machine for use with the Android platform so it will run more efficiently on small devices while reducing the memory footprint ^[10]. Google has just recently released Android 2.2 which includes a new JIT compiler for their Dalvik Virtual Machine which can improve speeds of applications up to 2-5 times ^[11]. IBM also has their own version of the Java Virtual Machine, J9, that is used in many of their own pieces of software and also includes its own implementation of a JIT compiler.

Achievements

Android is probably one of the most well-known and mainstream Java based operating system currently on the market. Even though it’s the youngest of the operating systems discussed, it has become one of the newest standards for smartphones. With over 150 devices and counting, Android continues to grow and develop.

Problems

One major issue with using Java for an operating system is completely relying on the operating system and kernel to manage memory. Since Java is a garbage collecting language, developers do not have direct access to the memory and have to rely on the operating system to clean up after any objects have been left behind. This can be an issue with lower memory systems while running multiple applications at the same time.

Current Status

Each operating system has been created or worked on in the last ten years but some have either halted development or have not seen a major stable release in quite a while. JavaOS is still being maintained by Oracle after they had purchased Sun Microsystems. JNode has not seen an update in over a year and a half ^[12]. JX also seems to be at a stand still in development with only a minor update after its 0.1 release ^[13]. Finally, Android is the most active with minor or major updates coming out every few months. The current state Android is in is Android 2.2 with Android 3.0 currently being hinted for quarter four of 2010 ^[14].

References

Moon, David A. "Genera Retrospective." 1991 International Workshop on Object Orientation in Operating Systems (1991): 2-8. Print.

Moon, David A., Thomas F. Knight, John T. Holloway, and Richard D. Greenblatt. "A Lisp Machine." ACM SIGIR Forum 15.2 (1980): 137-38. Print.

Pleszkun, A. R., and M. J. Thazhuthaveetil. "The Architecture of Lisp Machines." Computer 20.3 (1987): 35-44. Print.

FOR SPIN

B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, Safety and Performance in the SPIN Operating System. In the Proceedings of the 15th ACM Symposium on Operating System Principles (SOSP), Copper Mountain, CO, December 1995.

W. C. Hsieh, M. E. Fiuczynski, C. Garrett, S. Savage, D. Becker and B. N. Bershad. Language Support for Extensible Operating Systems. Workshop on Compiler Support for System Software, University of Washington, February 1996.

S. Savage, B. N. Bershad. Issues in the Design of an Extensible Operating System. Proceedings of the First USENIX Symposium on Operatings Systems Design and Implementation (OSDI), November 1994 (Unpublished).

University of Washington, Dept. of Computer Science. The SPIN Operating System. [15]

For Oberon:

Bluebottle OS. (n.d.). Retrieved February 3, 2010, from Wikipedia: http://en.wikipedia.org/wiki/Bluebottle_OS

Ceres (workstation). (2010, August 24). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Ceres_(workstation)

Native Oberon. (n.d.). Retrieved March 5, 2010, from Wikipedia: http://en.wikipedia.org/wiki/Native_Oberon

Niklaus Wirth. (2010, October 13). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Niklaus_Wirth

NS320xx. (2010, June 30). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/NS320xx

Oberon (operating system). (2010, September 1). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Oberon_(operating_system)

Oberon (programming language). (2010, October 3). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Oberon_(programming_language)

Oberon. (2008, July 10). Retrieved from ETH Zurich: http://www.oberon.ethz.ch/

Wirth, N., & Gutknecht, J. (2005). ETH Oberon. Retrieved from Project Oberon: The Design of an Operating System and Compiler: http://www.oberon.ethz.ch/archives/systemsarchive/sys_genealogy_new

For Smalltalk:

Alan Kay, The Early History of Smalltalk [16]