Operating Systems 2014F Lecture 6

Library - code you did not write but it is sitting in your address space. The routines in there can be called, but to a first look, it is opaque. I am going to call it to do something, and it should do whatever I ask. On older systems, that's what the operating system does, they are just routines, you might call them directly, or you might call a dispatcher. Let's say you don't like what this operating system does, you just write your own routine to do it.

What happens if the operating system changes? Your code becomes tied to the exact version of the operating system.

When you call a library you call an API. If accessing private functions / data structures, you can do it, it will work, but when the api changes your code will break.

When you used an Apple 2 or commodore 64, you wouldn't normally have a hard disk with everything you are running, you would load off of a floppy. There might be multiple programs on that disk. It had the operating system on the disk as well. It would first load the OS and then the program would load off the disk. Every bootable floppy would have a copy of the OS. Stick in the first floppy of the program, and at some point the program would request you to put in another disk.

What would you do for copy protection? You would modify the operating system on the disk. The operating system had such low level control. Take one, create one from scratch or modify one. On these systems, the OS is just a library. A library that can do I/O stuff.

If you don't like it, you want to mess with it, you can. You can overwrite the OS. It's just routines to help you. This is good when your program essentially controls the machine. Lets' say I want to run more than 1 program. Instead of code and data..

Every time you see something new, it is built upon something older. An operating system, code and data, all sitting in one address space. We'll give everyone their own address space. Everyone will have their code and data.

A process cannot see the other processes running. Address spaces, with some number of virtual cpu attached. Single threaded processes have 1 virtual cpu. Library, code that is linked into your address space. This code knows how to access the larger operating system. You want a clean api that takes care of the mess so you don't have to. Which of the libraries are part of the operating system, and which aren't?

No one talks directly to the kernel. Something in the libraries has to know something about the kernel. What abstracts the kernel? What services does this os kernel provide? Provide access to disk, memory, gpu / video hardware. All different hardware it can provide access to. at what level of abstraction does this stop? Ok the OS provides access to graphics to the screen as a simple memory frame buffer, or is it a higher level library that provides windows, widgets. Does it provide compositing? These are all libraries that are provided in some way. They may in fact delegate some tasks to a special process. Why do you do this? because the kernel gets too big. You may want to provide some high level functionality so you dump it into another process. At the end of the day it is a bit arbitrary, where do you say this functionality is in the operating system, and this is not. Modern mobile operating systems provide an embeddable web view object, that provides a standard service (windows OS, IOS, Android) you can't easily change it, you can install alternate browsers on those systems. Are we saying the web browser is part of the operating system now? It kind of is. It's big, doesn't look like the other stuff we're talking about.

What defines the operating system changes over time depending on what you are expecting of it. Why don't we optimize that old stuff, and simplify it. There's still code that assumes the old ways.