Operating Systems

As a rule of thumb any part of a computer or electrical system that has physical substance is hardware.

Any programs or data generated by programs or even data in transit are classified as software.

So to mix it up with an example A hard drive is hardware however the data/programs on it are software.

Although some will argue that unless it is a program it cannot be construed as software. My answer is that a program can't run without some form of data and it should therefore be included as a subpart requirement intrinsic to the software.

Regards

GlenMMacLean Kent UK

I think its Linux because it wont get so easily overloaded even if you have a lot of applicvations running.

1 Objectives and functions

1.1 OS as a user/computer interface - Usability

The reason for an operation system to exist is to make computers more convenient to use. An

OS aims to wrap the underneath hardware resources and provides services to end users in a

systematic way. These services may be divided into two types: services directly available for

end users through all kinds of I/O devices, such as mouse, keyboard, monitor, printer, and so

on; and services for application programs, which in turn provides services for end users.

If we look on these services as interfaces among different components of a computer system,

then the following hierarchical architecture may be obtained:

Users Programmer

| | |

v | |

+---------------+ | |

| Applications | v |

+-------------------------+ | OS designer

| Utilities | v |

+------------------------------+ |

| OS | V

+-----------------------------------+

| Hardware |

+-----------------------------------+

It is also common to consider Utilities and Applications that are distributed together

with an OS parts of the OS, but obviously they are not essential. Utilities are usually called

libraries or APIs, providing frequently used functions for the upper-level applications.

1

From the point of view of end users, a computer system consists of a variety of applications

they may use. An application is developed by programmers in a programming language. The

higher level the utilities are, the easier and more comfortable it is for programmers to code in

the corresponding programming language; or the lower, the harder. In an extreme case, the

assembly language is almost the same as machine instructions except that mnemonic symbols

are used to replace binary strings or opcodes. In this kind of language, programmers have to

deal with an overwhelmingly complexity of manipulating computer hardware. On the contrary,

in a higher-level language, more user-friendly APIs are available, e.g. opening a file by calling

open("C:/filename.txt", "rw")

1.2 OS as resource manager - Efficiency

It is not the OS itself but the hardware that makes all kinds of services possible and available

to application programs. An OS merely exploits the hardware to provide easily accessible

interfaces. Exploitation means management upon the hardware resources, and thus also imposes

control upon or manages the entities that use the services so that the resources are used

efficiently. In the classes later on, we will discuss this aspect, including process scheduling,

memory management, I/O device management, etc.

One thing worth mentioning here is that, different from other control systems where the controlling

facility, the controller, is distinct and external to the controlled parts, the OS has to

depend on the hardware resources it manages to work.

+-------------------+

+------------+ | |

| | | Controlled |

| Controller |-------->| components |

| | | |

+------------+ +-------------------+

As we know, an OS is in nature a program, consisting instructions, thus it also needs CPU to

execute instructions so as to function as a controller, and main memory to hold instructions

for CPU to fetch. At the same time, the OS has to be able to relinquish and regain later

the control of CPU so that other programs can get chance to run but still under the control

of the OS (An analogy to this is that an administrator of an apartment building might live

in the same building himself). By utilizing the facilities provided by hardware, the OS may

schedule different processes to run at different moments and exchange the instructions and

data of programs between external storage devices, like hard disks, and main memory. These

topics will be covered as the course proceeds.

2

1.3 Evolution of OS - Maintainability

It does not suffice to simply consider an operating system an unvariable unit. An OS may

evolve while time elapses due to the following reasons:

• hardware upgrades or new types of hardware: With hardware technologies development,

the OS also needs to upgrade so as to utilize the new mechanisms introduced

by new hardware. For example, Pentium IV extended instruction set of Pentium III

for multimedia applications and internet transmission. An OS designed for the previous

versions of Intel x86 series will have to be upgraded to be able to accommodate these

new instructions.

• new services: An OS may also expand to include more services in response to user

demand.

• fixes: No software is perfect, and any program may contain more or less bugs or defects,

thus fixes should be made from time to time. Microsoft Windows is a vivid example of

this kind.

These situations all require OS designers to build an OS in the way that the system can be

maintained and upgraded easily. All the common software design techniques may be applied

to an OS, such as modularization. With modularization, the OS is split into multiple modules

with clearly defined interfaces between them. Thus, as long as the interfaces are left untouched,

each single module may be upgraded independently.

The Computer being a very complex machine appears to us the users as a very easy to use machine all thanks to the operating system.

The operating system hides all the underlying processes that are going on in the computer like interrupt,memory allocation,time pulse etc and presents the user with a more simplified user friendly interface.

Because in general sense an ordinary user is not interested in the complicated processes that go on in the computer system.

Security is a difficult and sometimes controversial thing to analyze. The only truly "secure" operating systems are those that have no contact with the outside world. The firmware in your DVD player is a good example.

Among all modern general purpose operating systems (Windows, Mac OS X, Linux, Solaris, FreeBSD, NetBSD, OpenBSD) the most secure by defualt is by far OpenBSD. OpenBSD has an extremely stringent security auditing policy; only two remote attack vulnerabilities have been found in the last ten years. This is because OpenBSD doesn't create a large attack surface by running a large number of networked apps.

Of course, the sad fact is that any networked operating system can be made insecure through careful misconfiguration. Window's problems with security stem mainly from the fact that it runs with a large number of network services on by default, and that it (XP and prior) let the user run with full privileges by default. Windows Vista attempted to fix this issue, but people rejected it as "too confusing" and complained that their old apps did not work correctly under limited accounts.

Mac OS X is better about user permissions, but still has had a (in)decent number of remote exploits. Apple's slow response to patch many of these issues will be even more worrying if it gains significant market share.

Most Linux distributions have an excellent policy of quickly patching known security vulnerabilities. Unfortunately, two of the top ten distros deliberately use outdated code (Damn Small Linux) or make it too easy to run as a privileged user by mistake (Damn Small Linux, Puppy Linux). Were these distros to gain significant popularity, their users would be exposed to a larger number of vulnerabilites than if they encouraged proper security policies.

Because Linux is "sort-of-a-copy-of-Unix" (which is not), and Unix was written in C.

C was created to write Unix. Most portable operating systems or serious embedded devices are written in some incarnation of C and C++. Including MS-DOS and earlier copies of Window$ (which I am sure still uses it)

Yes, the ignition system starts the car and keeps it running. The starter system only turns the engine over.

Yes - when you create and add on multiple users to the OS such as Windows, Linux, or OSX, you're creating a shared environment. This is especially true when you "Switch Users"

System software, ie Operating System (Windows, Mac OS, Linux) Is the base of the application environment. Requirements for System software means, what hardware you're required to have in order for the operating system to run on your machine. Application software requirements are the same except for OS (Operating System) requirement, some software only runs on Windows, some only on Mac OS. Some run on both and more.

1) CRITICAL REGIONS

a) Motivation

The time dependent errors can be easily generated when semaphores are used to solve

the critical section problem. To overcome this difficulty a new language construct, the

critical region was introduced.

b) Definition and notation

A variable v of type T, which is to be shared among many processes, can be declared:

VAR v: SHARED T;

The variable v can be accessed only inside a region statement of the following form:

REGION v DO S;

This construct means that while statement S is being executed, no other process can access the variable v. Thus, if the two statements,

REGION v DO S1;

REGION v DO S2;

are executed concurrently in distinct sequential processes, the result will be equivalent

to the sequential execution S1 followed by S2, or S2 followed by S1.

To illustrate this construct, consider the frames CLASS defined in abstract data type.

Since mutual exclusion is required when accessing the array free, we need to declare

it as a shared array.

VAR free: SHARED ARRAY [l..n] OF boolean;

The acquire procedure must be rewritten as follows;

PROCEDURE ENTRY acquire (MAR index: integer);

BEGIN

REGION free DO

FOR index := 1 TO n DO

IF free[index] THEN

BEGIN

free[index] := false;

exit;

END;

index := 1;

END;

The critical-region construct guards against some simple errors associated with the semaphore solution to the critical section problem which may be made by a programmer.

c) Compiler implementation of the critical region construct.

For each declaration

VAR v: SHARED T;

the compiler generates a semaphore v-mutex initialized to 1. For each statement,

REGION v DO S;

the compiler generates the following code:

p(v-mutex);

S;

V(v-mutex);

Critical region may also be nested. In this case, however, deadlocks may result.

Example of deadlock)

VAR x, y: SHARED T;

PARBEGIN

Q: REGION x DO REGION y DO S1;

R: REGION y DO REGION x DO S2;

PAREND;

2) CONDITIONAL CRITICAL REGIONS

The critical region construct can be effectively used to solve the critical section problem.

It cannot, however, be used to solve some general synchronization problems. For this

reason the conditional critical region was introduced.

The major difference between the critical region and the conditional critical region

constructs is in the region statement, which now has the form:

REGION v WHEN B DO S;

where B is a boolean expression.

As before, regions referring to the same shared variable exclude each other in time.

Now, however, when a process enters the critical section region. the boolean expression

B is evaluated if the expression is true, statement S is executed. if it is false, the

process relinquishes the mutual exclusion and is delayed until B becomes lame and no

other process is in the region associated with v.

Example for bounded buffer problem)

VAR buffer: SHARED RECORD

pool: ARRAY [0..n-l] OF item;

count, in. out: integer;

END;

The producer process inserts a new item nextp in buffer by executing

REGION buffer WHEN count < n DO

BEGIN

pool[in] := nextp;

in := in + i MOD n;

count := count + 1;

END;

The counter process removes an item from the shared buffer and puts it in nextc by

executing:

REGION buffer WHEN count > 0 DO

BEGIN

nextc := pool[out];

out := out +1 MOD n;

count := count - 1;

END;

However, the CLASS concept alone cannot guarantee that such sequences will be

observed.

* A process might operate on the file without first gaining access permission to it;

* A process might never release the file once it has been granted access to it;

* A process might attempt to release a file that it never required;

* A process might request the same file twice;

Not that we have now encountered difficulties that are similar in nature to those that

motivated us to develop the critical region construct in the first place. Previously, we

had to worry about the correct use of Semaphores. Now we have to worry about the

correct useo higher-level programmer-defined operations, with which the comelier can

no longer assist us.

Windows 95 (partial, via USB add-on)

Windows 98

Windows ME

Windows NT 3.1

Windows NT 3.5

Windows NT 3.51

Window NT 4

Windows 2000

Windows XP

Windows Server 2003

Windows Vista

Windows Server 2008

Yes

The original motivation for the development of distributed computing operating systems was for high reliability computing where no downtime (even for maintenance and repair) could be tolerated.

These high reliability computing systems were of necessity composed of many redundant pieces of computing hardware modules (e.g. CPUs, memories, I/Os, hard disks) that a technician could unexpectedly remove at any time. These systems thus needed an operating system that would distribute itself and the applications redundantly too over the redundant hardware and recover from the unexpected removal of that hardware without the loss of any work making use of the removed hardware or a system crash. When the technician either replaced the removed module with a new one or expands the system with several new hardware modules the operating system must automatically distribute itself and the applications across the new redundant hardware without human interaction and without any system crashes.

Depends on what you are doing. If you are doing a Windows upgrade from 7 to 8 or 10 then no, they have support for that. If you are removing Windows completely and adding a Linux Distro then yes, so create a backup before doing so.

Warm

it is a multi user OS

Mac = Best

An open-source operating system is one that is available to the general public for use and/or modification from its original design free of charge.

No, Operating system is not resposible for file compression. It is the task of utilities that come bundled with OS or installed by you. Some well known utilities are 7-zip, WinZip, WinRar, etc.

No. Licensed Unix implementations are a proprietary flexible general purpose operating system originally marketed for minicomputers and mid-range computers to support multiple users and tasks. When Personal Computers became available, versions of Unix were created for them. Unix was also implemented for the IBM mainframe.

This is not the same as Linux which is an open source free system with many of the same capabilities and look & feel of unix but without the licensing requirement of unix.

4 generation operating system

CMOS holds many of the boot parameters, such as what type and size of hard disk, the type and speed of the processor and other critical information. Many times the computer can still boot with a dead CMOS battery, but the information will not be available and will affect the process. Replace the battery then run through the setup procedure to save the values.