INTRODUCTION

Haiku is a free and open-source operating system compatible

with the now discontinued BeOS. Its development began in
2001, and the operating system became self-hosting in 2008.
The first alpha release was made in September 2009, and the
most recent was November 2012.
Haiku is supported by Haiku, Inc., a non-profit organization
based in Rochester, New York, US, founded in 2003 by former
project leader Michael Phipps.
Specifically targeting personal computing, Haiku is a fast,
efficient, simple to use, easy to learn, and yet very powerful
system for computer users of all levels. Additionally, Haiku
offers something over other open source platform which is
quite unique: The project consists of a single team writing
everything from the kernel, drivers, user and services, tool
kit, and graphics stack to the included desktop applications
and preflets. While numerous open source projects are
utilized in Haiku, they are integrated seamlessly. This allows
Haiku to achieve a level of consistency that provides many
conveniences, and is truly enjoyable to use by both end-users
and developers alike.
The key highlights that distinguish Haiku from other
operating systems include:

Specific focus on personal computing

Custom kernel designed for responsiveness
 Fully threaded design for great efficiency with multi-
processor/core CPUs
Rich OO API for faster development
Database-like file system (BFS) with support for indexed
metadata
 HISTORY
Development of HAIKU began with OpenBeOS in 2001 after
Palm Inc. bought Be Inc. and discontinued BeOS. OpenBeOS
differed from several other contemporary projects aiming to
continue BeOS. A first release of OpenBeOS was made in
2002. That release was no stand-alone operating system,
instead it was a community-created update for BeOS 5.0.3
that contained open source replacements for a few BeOS
components. In 2004 a new project name was chosen by an
official community vote and declared at that years
WalterCon. The name "Haiku" was chosen to reflect the
elegance and simplicity that attracted many to the BeOS
platform, and is also a direct reference to the distinctive
haiku error messages found in NetPositive, the default BeOS
web browser, and many other Be applications.
A number of major milestones were achieved in a six-week
period during March to April 2005, such as the first graphical
applications to run on Haiku itself (running with full 2D
acceleration), and the first use of a web browser (Links) on
Haiku. Another major milestone was reached in July 2005,
when the system was able to run the BeOS desktop shell,
Tracker. In January 2008, an official Java for Haiku team was
created and was unanimously accepted by the OpenJDK
Porters Group to port OpenJDK to Haiku.In April 2008, Haiku
became self-hosting, which means Haiku can be built from
within itself.On January 31, 2009, Haiku obtained a native
GCC4 port; this allows modern applications, like Firefox 3, to
be built on Haiku.On July 12, 2009, a first prototype version
of the FreeBSD WLAN-Stack was ported to Haiku, enabling
unencrypted WLAN connections as a first step. The first alpha
release "Haiku R1/Alpha 1" has been released on September
14, 2009. The second alpha release ("Haiku R1/Alpha 2") was
released on May 10, 2010.
 ARCHITECTURE
The Haiku kernel is a modular hybrid kernel and a fork of
NewOS, a modular kernel written by former Be Inc. engineer
Travis Geiselbrecht.
Haiku is based around client/server architectures, where
applications are clients to functional servers, and the
functional servers are in turn clients to the kernel, at the
lowest level.

The kernel type used in Haiku is Hybrid kernel. A hybrid

kernel is an operating system kernel architecture that
attempts to combine aspects and benefits of microkernel and
monolithic kernel architectures used in computer operating
systems.
The Haiku kernel provides the basic operating system
functions that the servers depend on. These functions
include: multi-threading, multiple processors/multiple cores,
preemptive multitasking, memory protection, virtual
memory, semaphores, loadable drivers, shared libraries, and
process scheduling. The scheduler was designed from
inception to support multithreading as well as multiple
processors. These features are intrinsic to Haiku and are the
heart and soul of the Haiku API.
 PROCESS MANAGEMENT
The functional servers that run on top of the kernel include:

the application server

the roster
the network server
the media server
the media addon server
the input server
the print server
Each server runs in its own protected memory space, and
together with the other servers implement much of the
functionality available through the C++ API .
The application server is the first server that applications
interface with. It is an instance of the BApplication C++ class
that gets things started. The application server handles
window management, graphics rendering, user interface
interaction, event handling and more. An exceptional feature
of Haiku that sets it apart from other operating systems is the
fact that every window has, by default, two separate threads.
One thread for graphic updates, and a second thread for user
interaction. One thread runs inside the application server,
and the other inside the application. This allows visual
updates to occur completely separately from IO. . It also
means that every Haiku application with a window is both
multithreaded, and supports multiprocessing by default.
More threads can be spawned as needed, and Haiku natively
supports the POSIX threads interface.
The storage server gives you direct access to directories, files,
indexes, and add/update/delete notifications that you can
design. This saves the effort of either writing your own
database functions, or having to use a 3rd party library. The
Haiku mail system uses these functions to store emails.
The network server provides inetd and configuration, such as
DHCP. The network server was recently extended to support
WEP wifi with encryption. Haiku includes applications for ftp,
ftpd, telnet, as well as the poor man web server. The diner
and Cherokee web servers are also available with many more
Haiku-specific features.
The media server is the backbone for processing multimedia
streams. It was designed to provide low latency access to
audio, video, and image data types. The server manages the
multimedia streams through a pipeline of buffers that are
dispatched to data handlers. Each handler can hook into a
media stream. Once it has done so, a handler can read or
change the media stream in the pipeline. Buffers are
implemented as shared memory, and are accessible by
multiple applications without the need to copy the buffers.
The media server can also synchronize different media
streams by means of a global scheduling object. This is vital
for processing video and audio together.
 MEMORY MANAGEMENT
It has been designed for threads to use virtual memory.
Threads are pre-allocated a memory address. However, the
address it not mapped to any memory until the thread runs,
and after terminating, the thread releases all memory to the
system. This gives developers the option of pre-allocating an
unlimited number of threads. However, with virtual
memory, memory cannot be given back to the system until it
is deleted first. This is implemented in C++ with pointers to
dynamic memory. There are several benefits to using virtual
memory. Areas can be shared among threads and processes.
Different virtual memory addresses can map to the same
physical locations (think pointers in C++). Also, the different
areas can belong to different applications. This allows
applications to share the same data.
The OS make use of malloc and rtm alloc for the pupose of
memory management.
malloc:
malloc first tries to reserve memory in RAM to give you what
you need. If there isnt enough room in RAM, the kernels
virtual memory system takes over. The kernel then swaps out
pages of memory from RAM to your hard drive to make room
for your request.
rtm alloc:
For most applications, the overhead incurred by malloc and
virtual memory is negligible compared to other performance
factors that affect your code, and the advantanges offered by
virtual memory far outweigh the cost.
For media nodes that must run in real time, however, malloc
is not good enough. rtm alloc is a mechanism which bypass
virtual memory and its vices. It is used by creating a pool of
memory ahead of time. rtm alloc then assigns chunks of
memory from this pool. In this case, allocating and freeing
memory are trivial operations on already extant memory. In
addition, the media real-time allocator will lock this pool of
memory into RAM, meaning that the memory cannot be
paged out by the virtual memory engine.
 DEADLOCK
Deadlock is a major issue when developing an operating
system. It can occur when one or more messages are sent to
a receiving thread before it has time to receive the previous
message. When this occurs, the receiving thread will block
until it processes the current thread.
One method to account for this, the developers of Haiku
used ports. Ports act as a message queue, and assure that
each thread receives any additional messages only after it is
finished processing the previously received message.
Therefore, by acting as an intermediary between sending and
receiving threads, ports eliminate the danger of deadlock.
Another problem associated with deadlock is the
manipulation of data by another process during execution.
This is where a semaphore is implemented. A semaphore is
used to prevent race situations or situations where multiple
instructions must execute without interference. It restricts
access to the data only one thread at a time by putting a
lock on the data for protection. This single thread access is
called the critical section. The semaphore restricts other
threads from changing data until the critical section has
executed.
The Haiku developers were not fully satisfied with the
semaphore so they developed the Benaphore. The
Benaphore helps the problem with the change in the
instructions between the times the first and second function
is executed; an error in the second function may occur. This
method is a combination of an atomic variable and a
semaphore. A major benefit of a benaphore versus the
semaphore is that the first thread enters the critical section
fifteen times faster than the semaphore.
The last problem associated with deadlock is the unknown
CPU times of each thread. Haiku developers established
priority levels for all threads, which helps to organize the
different CPU times within the current running threads. Each
thread priority level is entered into the function that the
thread will execute.
 CONTENT
INTRODUCTION
HISTORY
ARCHITECTURE
PROCESS MANAGEMENT
MEMORY MANAGEMENT
DEADLOCK
APPLICATION FUNDAMENTALS
 APPLICATION FUNDAMENTAL
At the core of any Haiku GUI application are the following
objects: BApplication, BWindow, BView, BMessage, and
BLooper. Each BLooper has a thread that acts as an event
loop, where messages are handled. BApplication and
BWindow are both derived from BLooper and so they each
have a thread that handles messages. This is how window
updates and IO are handled separately.
When an application is run in Haiku, it's BApplication object is
created. This starts the application's main thread and event
loop. It is at this point that an application can send and
receive messages. Once the application thread is started, the
application can create windows, which also create threads
with event loops. Once a window is created and displayed, it
can send and receive messages, which are generally related
to user interactions, such as mouse or keyboard events.
BMessage is used to encapsulate Haiku messages. BMessage
also has the capability to pass an arbitrary amount of
additional data in a message. BMessage provides a number
of member functions for packing or 'flattening' various data
into a message, and for finding, or 'unflattening' the data
after it is received.
REPORT ON HAIKU OPERATING SYSTEM

BY-

KUSHAL KUMAR SINGH-91/EC/12

KARMVIR KUMAR - 81/EC/12