Lecture 3 - Structure of OS
Lecture 3 - Structure of OS
Bilal Ahmed
1
STRUCTURE OF OPERATING SYSTEM
• A common approach is to partition the task into small components, or modules, rather
than have one monolithic system. Each of these modules should be a well-defined portion
of the system, with carefully defined inputs, outputs, and functions.
MS-DOS (1981-1995):
• Monolithic Kernel: MS-DOS was a single-tasking operating system with a monolithic
design. The OS had minimal kernel functionality, providing direct access to hardware
without the abstraction or protection found in modern kernels.
• No Protected Mode: MS-DOS ran entirely in real mode, which meant there was no
memory protection or multitasking. Programs had unrestricted access to system
memory and hardware, which made the system prone to crashes and instability.
• Single User, Single Task: MS-DOS was designed for single-user, single-task
operations, meaning only one program could run at a time.
WINDOWS
Early Windows (1.x, 2.x, and 3.x):
• MS-DOS Underpinnings: These versions of Windows (starting with Windows 1.0 in 1985)
were essentially graphical shells running on top of MS-DOS. While they introduced a
graphical user interface (GUI), they still relied on the underlying MS-DOS kernel for many
system operations.
• Cooperative Multitasking: Windows 1.x to 3.x introduced basic multitasking, but it was
cooperative multitasking. In this model, programs themselves had to yield control back
to the OS for the next program to run, which often led to poor stability if a program failed
to cooperate.
• No True 32-bit Processing: These early versions of Windows ran in 16-bit mode and had
limited access to the advanced features of modern CPUs, such as protected memory or
preemptive multitasking.
WINDOWS
Transition to Windows NT:
• By the early 1990s, the limitations of MS-DOS and early Windows (like lack of
multitasking, memory protection, and stability) became increasingly problematic as
computer hardware advanced.
• Windows NT, introduced in 1993, was a complete rewrite of the Windows operating
system, designed from scratch to be more robust and modern. It introduced the hybrid
kernel architecture and supported preemptive multitasking, protected memory, and 32-
bit processing, marking a significant departure from the earlier MS-DOS-based systems.
In summary, the kernel model used before Windows NT was primarily a monolithic kernel in
MS-DOS, with early versions of Windows acting as graphical extensions running on top of it.
These systems lacked the advanced kernel features that were later introduced in Windows
NT and subsequent versions.
USER AND OPERATING-SYSTEM INTERFACE
• There are several ways for users to interface with the operating system. Here,
we discuss two fundamental approaches.
• Command-line interface, or command interpreter.
• Graphical User Interfaces.
? Operating
System
COMMAND-LINE INTERFACE, OR COMMAND INTERPRETER.
• Command Interpreters - Some operating
systems include the command interpreter
in the kernel.
• Others, such as Windows and UNIX, treat
the command interpreter as a special
program that is running when a job is
initiated or when a user first logs on (on
interactive systems).
• On systems with multiple command
interpreters to choose from, the
interpreters are known as shells. For
example, on UNIX and Linux systems, a
user may choose among several different
shells, including the Bourne shell, C shell,
Bourne-Again shell, Korn shell, and others.
GRAPHICAL USER INTERFACES
• Graphical User Interfaces - A second
strategy for interfacing with the operating
system is through a user- friendly graphical
user interface, or GUI. Here, users employ
a mouse-based window- and-menu system
characterized by a desktop.
• The user moves the mouse to position its
pointer on images, or icons, on the screen
(the desktop) that represent programs, files,
directories, and system functions.
• Depending on the mouse pointer’s location,
clicking a button on the mouse can invoke a
program, select a file or directory—known as
a folder —or pull down a menu that contains
commands.
NEXT LEVEL OF GUI
Any Example?
• Types of System Calls - System calls can be grouped roughly into six major categories: process
control, file manipulation, device manipulation, information maintenance, communications,
and protection.
• Process control
1. end, abort
2. load, execute
3. create process, terminate process
4. get process attributes, set process attributes
5. wait for time
2. open, close
Kernel-mode
components
WINDOWS
ARCHITECTURE
User-Mode
Processes
ANDROID ARCHITECTURE
• The Android operating system is a Linux-based system originally designed for mobile
phones. It is the most popular mobile OS by a wide margin: Android handsets outsell
Apple’s iPhones globally by about 3 to 1
• Initial Android OS development was done by Android, Inc., which was bought by Google
in 2005.
• The open-source nature of Android has been the key to its success.
ANDROID
ARCHITECTURE
Dalvik Virtual Machine (DVM)
Dalvik was Android's original runtime environment from its launch up until Android 4.4
(KitKat). It is a type of virtual machine designed to run Android applications, which are
compiled into bytecode (similar to Java bytecode).
Key Concepts:
• Just-In-Time (JIT) Compilation:
• Dalvik uses a JIT compiler. This means that parts of the code are compiled into
machine code right before they are executed. The JIT compiler compiles code on-the-
fly as needed, rather than compiling the entire app beforehand.
• This results in quicker initial startup times for apps, but less overall performance
since the code is recompiled during each execution.
• Bytecode Execution:
• Android apps are written in Java (or Kotlin), which is compiled into Java bytecode
(.class files). These bytecode files are then converted into Dalvik Executable (DEX)
format. Dalvik executes this DEX bytecode.
Dalvik Virtual Machine (DVM)
Continued…
• Register-based:
• Unlike the Java Virtual Machine (JVM), which is stack-based, Dalvik is register-
based. This architectural difference is optimized for mobile devices and is more
memory-efficient for the limited resources available on smartphones.
• Memory Efficiency:
• Dalvik was designed to minimize memory usage, which is important for mobile
devices. Multiple instances of the Dalvik VM could run simultaneously, allowing for
multiple apps to run concurrently without consuming excessive memory.
Limitations:
• Since Dalvik uses JIT compilation, it has some performance drawbacks, particularly
during startup and runtime, as the JIT compiler has to compile code dynamically during
execution.
Android Runtime (ART)
Android Runtime (ART) was introduced as an experimental runtime in Android 4.4 (KitKat)
and became the default runtime in Android 5.0 (Lollipop) and later. ART was designed to
replace Dalvik and address its performance shortcomings.
Key Concepts:
• Ahead-of-Time (AOT) Compilation:
• ART uses Ahead-of-Time (AOT) compilation, which compiles the entire app's code
into machine code when the app is installed. This means that the app's code doesn't
need to be recompiled during runtime, improving performance and reducing the time
it takes to start an app.
• AOT helps by eliminating the need for JIT compilation and results in better overall app
performance, smoother execution, and faster app startup times.
• Improved Garbage Collection:
• ART introduced a more efficient garbage collection mechanism. This results in
smoother app performance because garbage collection (reclaiming memory that is
no longer in use) causes fewer delays or pauses during app execution.
Android Runtime (ART)
Continued…
•Better Debugging and Profiling:
• ART provides enhanced debugging and profiling tools for developers, making it easier
to track down performance bottlenecks and improve app efficiency.
• Memory Management Improvements:
• ART optimizes memory usage more effectively than Dalvik, reducing memory
fragmentation and providing a more stable experience when running multiple apps or
large applications.
• Larger Disk Space Usage:
• One of the trade-offs of ART is that the pre-compilation (AOT) requires more disk
space. Since the entire app is compiled to native code at installation time, apps take
up more storage space compared to Dalvik.
Android Runtime (ART)
Continued…