Download Embedding Object Files in an Existing Operating System: A Practical Approach

Embedding Object Files in an Existing Operating
System: A Practical Approach
Udom Silparcha, Nipon Charoenkitkarn, Sutinee Amornphathanakul, Warawit Wiriyachat
Pathumwan Institute of Technology, [email protected]
King Mongkut’s University of Technology Thonburi, [email protected]
King Mongkut’s University of Technology Thonburi, [email protected]
King Mongkut’s University of Technology Thonburi, [email protected]
ABSTRACT
This article describes an approach to embed ObjectOriented file structure in an existing operating system.
The Object-Oriented file structure (Object File) is a part
of an effort to create a fully Object-Oriented Operating
System (OOOS). The concepts, design, and
implementation are explained. Text and multimedia files
are tested. The experiment has shown that tested files can
be handled correctly by the standard applications without
any unsatisfactory effect from existing environment. With
this concept, the application and platform dependency
constraints can be avoided. To the users, the files are
transparently manipulated.
Keywords: Object, File, Object-Oriented concepts,
Operating System
1. INTRODUCTION
This article introduces an Object-Oriented paradigm for
use in Operating System. The Object File is a part of an
effort to create a fully OOOS. Object-Oriented modelling
technique offers us the reusability, encapsulation,
information hiding and dynamic binding. We are
implementing an object file model to be embedded in an
existing operating system. Such file model creates file
objects. It is possible to introduce Object Files to any
existing operating system by using our proposed objectoriented file model. To allow usable between the same
file object in different operating systems, our system
architecture provides a mechanism for cross-platform
communication.
Operating system is a very complicated substance. It
contains several parts such as Memory Management,
Process Management, and Network Management etc. We
decided to choose the part of data storage in form of
“structure of file” to implant an Object-Oriented
paradigm. The major benefit form this implementation is
that the flexibility will be added to a structure of file
which make that structure of file extensible and
independent. Moreover, an implementation on a stable OS
will protect our system from unexpected situations.
2. BACKGROUND
This section reviews the concepts of Object-Oriented
methodology and other related topics. It also introduces
the previous works done by other researchers.
2.1 Object-Oriented Concept
The Object-Oriented paradigm focuses on the behavioural
and structural characteristics of entities as complete units,
called objects which are generated from classes. The
paradigm covers and supports the following concepts;
Encapsulation,
Inheritance,
and
Polymorphism.
Encapsulation involves the packaging of information by
focusing on the hiding of details to facilitate abstraction.
The object's variables are hidden within the protective
custody of its methods. Inheritance involves the relating
and reusing of existing classes to define other ones. The
new class is called subclass, and the original class is
called superclass. It allows the subclass to use the
properties existing in the superclass without redefinition
of them. Polymorphism involves the ability of new
objects to be defined as variations of existing
representations. The new implementations are introduced
but specifications remain the same such that a
specification has many implementations. Polymorphism
and Dynamic Binding are closely related and essentially
provide well-known flexibility of Object-Oriented
systems.
2.2 Principle of Object-Oriented Operating System
OOOS is implemented as a collection of objects. Objects
belong to classes that designate some of the properties of
the object [3]. For example, there may be one class for
file objects, one for processes, etc. Each object
encapsulates a data structure and defines a set of
operation on that data structure. For file object, for
instance, typical operations are reading, writing,
appending and deleting. The operations defined for
objects are called methods. When a user program needs to
perform some operation on an object, it does so by
invoking one of the methods defined for that object.
2.3 Related work
Embedding the Object-Oriented paradigm in the structure
of file provides more functionalities than the conventional
file. However, there have been several projects related to
this area including Choices: An Object-Oriented
-1-
Operating System and Frigate: An Object-Oriented File
System for Ordinary Users.
Campbell et al. [2] has implemented an OOOS
written in C++, called Choices. Choices extends existing
design
approaches
by
explicitly
encouraging
specialization and code reuse. It is developed following
the methodology as project progressed, adopting many
useful ideas from the Object-Oriented programming and
software engineering research communities. Choices
supports an Object-Oriented API based on encapsulation,
inheritance and polymorphism.
Kim [4] introduced Frigate, an OO file system,
implemented on the SunOS 4.1.1. Frigate provides such
open access to all users, not just to those with system
privilege or specialized training. Frigate combines a userlevel server framework with an Object-Oriented interface.
The user-level structure provides adequate performance
and, at the same time, free developers from the constraints
of development in the operating system address space.
The server process boundary also acts as a firewall for
added safety and security.
3. DESIGNING OBJECT FILE MODEL
In this section, we will illustrate the contribution of
Object-Oriented concepts to the structure of file, and
description of the design methodology permitted by this
structure of file.
3.1 Motivation for Building Object File
The Object-Oriented approach to operating system design
has many advantages [1]. The fundamental operations
performed by all user processes and most operating
system routines consist of invoking methods on objects.
By invoking methods, processes can request operating
system services, send messages to other processes, and
perform remote procedure calls. These three functions,
which are implemented using different mechanisms in
conventional operating system, are all handled in the
same way in an Object-Oriented system.
One of the OS components that, once implemented,
clearly demonstrates the Object-Oriented concepts is the
file storage. Generally, the implementation of Object File
should be supported by the OOOS. Since fully
implemented OOOS is not available and accepted, it will
be more useful under the present situation to implement
Object Files as a part of the existing OS that are widely
used e.g. Windows and UNIX. Our challenge is to make
the Object File run transparently to users, on a NonObject-Oriented OS too.
Fig.1: Conceptual view of Object File Model
3.2 Object File Model
The first design principle we discovered from our work
with Object File is that to apply three concepts of objectoriented: encapsulation, inheritance and polymorphism
paradigms to contribute new structure of files which has
the content of file and application that compatible to that
file itself should be hidden by an Object-Oriented
framework through which they can be manipulated. In
particular, this requires constructing a file model of the
system software. This model is unlikely different from
other structure of files. Instead of a traditional file model
which consists of just file content only, our file model is
embedded with its own application.
According to our file model design, the new Object
File will obtain the properties of Object-Oriented
paradigm. The content of the file is hidden and isolated
from each other. With the inheritance property, the
Object File can be reused in order to generate the new
familiar files. Moreover, our new Object File contains all
the necessary components it needs and will no longer
depend on any software platform or in additional, it is
application-platform independent.
4. IMPLANTING OBJECT FILE IN NON-OO
OPERATING SYSTEMS
In this section, we will explain the typical problems that
occur in existing data storage systems and the proposed
technique used in order to design our system.
4.1 Typical Problems
In general, file system is designed for a specific operating
system [5]. File system always considers whether the
operating system should recognize and support file types.
If an operating system recognizes the type of a file, it can
then operate on the file in reasonable ways. For example,
a common mistake occurs when a user tries to print a
binary file. This attempt normally produces garbage, but
can be prevented if the operating system has been told
that the file is binary. A common technique for
implementing file types is to include the type as part of
the file name.
File types may also be used to indicate the internal
structure of the file. Files have structures that match the
expectations of the programs that can recognize them.
Furthermore, certain files must conform to a required
structure that is understood by the operating system. For
example, the operating system may require that an
executable file has a specific structure so that the OS can
determine where in memory to load the file into, and what
location the first instruction is. Some operating systems
extend this idea into a set of system-supported file
structures, with sets of special operations for
manipulating files with those structures.
The above discussion brings us to one of the
disadvantages of having the operating system that
supports multiple file structures: The resulting size of the
operating system is cumbersome. If the operating system
defines five different file structures, it needs to contain
the code to support these file structures. In addition, every
-2-
file may need to be definable as one of the file types
supported by the operating system. Severe problems may
result from new applications that require information
structured in ways not supported by the operating system.
4.2 The Proposed Technique
In this section we will discuss about Object File internal
design data structure. We can categorize data structure of
our Object File into two patterns.
First, simple Object File is defined as the first
platform of our object file model. Once we generate an
Object File, we encapsulate all kind of contents together,
i.e. data, methods and application paths. Fig.2
demonstrates our Object File data structure, while the
descriptions are displayed in Table 1.
Fig.2: Object File Data Structure
The applicationPath attribute provides the
polymorphism feature for an Object File. In traditional
file concept, when an operating system needs to recognize
which file belong to which application it uses file type.
For example, the file “ABC.doc” should be exploited by
using Word Processor. The idea is that we also need
some kind of mechanism to be embedded into the content
of file in order to tell which application the data content
belong to. To show the concept of polymorphism, one
kind of file types should not be supported by just only one
application. Instead, we can embed more applications into
the Object File and let that Object File overload
applications as it wants.
Table 1: Object File Attribute Description
Attribute Name
b
dataContent
methodContent
applicationPath
parentPtr
Description
Define inherited property (bool)
Data content e.g. compressed data
Method content e.g. compression
Overloading application
Pointer to parent Object File
binding, we will keep the method content only in the
parent file while deriving a new file which has a pointer
that points to the parent file. So we can use the methods
of the parent file as if they were encapsulated in a new
derived Object File. The parentPtr attribute is a pointer
that points from a new derived Object File to its parent. In
a root Object File, this attribute has the value of NULL.
5. IMPLEMENTATION
In our experiment, we implemented Object Files on
Microsoft Windows XP Professional. Our decision to use
C++ was circumscribed by the need to demonstrate an
efficient procedure of embedding object file model into a
Non-Object-Oriented OS. Most of the available ObjectOriented languages rely on slow interpreters and require
much run-time. Since C++ supports a minimalist view of
Object-Oriented programming. The strengths of C++ are
that it is efficient, portable, and available upon a variety
of platforms.
The process of encapsulating an Object File is in a
module called GenerateFile. This module provides the
object transformation to the file. When we use this
module, our source file will be encapsulated with the
method contents, which are implemented in JAVA, hence
become an Object File. This Object File is now totally
independent from the OS. When we input a data file and
method contents (Compression and Decompression
methods) to the system, the file transformation will start
by activating the compression method to compress the
data file. The compressed data will be read and kept in a
buffer. And the first bit of an Object File will be set as a
false value (b=0) indicating a non-inheriting file. Then the
system will encapsulate the compressed data and method
contents together and also overload the applicationPath
into an Object File, so that the file can later be used.
The InheritFile module, which illustrates inheritance
property of Object-Oriented paradigm, is provided in the
system. The method within Object Files can be extended
into the other Object Files using this module. When we
input a data file to the system, the system will repeat a
GenerateFile module. In non-overriding case, the derived
Object File will call the method content from its parent
file. The benefit from this feature is that we can manage
and save memory utilization by maintaining the method
contents only in the parent file. The child Object File
contains a pointer that points to its parent and the first bit
of the derived file will be set to true (b = 1). But in case of
overriding, the system will first attempt to apply a method
of the Object File. If this fails, a method from the parent
file will be used.
The second structure that we will discuss is an Object
File which has the same kind of methods and attributes as
some existing Object Files. For example, a compression
method is put into every Object File. We may have to
waste much memory spaces if every individual Object
File contains the same compression method. We can
avoid this problem by gaining an advantage from
inheritance property. Following the concept of dynamic
-3-
Fig.3: Inherited Object File Process
The module that extracts Object File is called
ExtractFile. This module is invoked when users want to
manipulate the data of the Object File. In order to exploit
the real contents of the Object File, the Object File needs
to be extracted by decomposing the object itself. Then the
system will recognize first bit of the Object File, if (b = 0)
the system will activate the method content, which was
encapsulated in an Object File, to decompress a data
content in order to obtain the original data. ExtractFile
module will read an applicationPath attribute to
recognize and locate the applications that are suitable for
this kind of data.
Decompression technique is included in the method
contents. In this section, a text file is compressed and
used as a demonstration case.
The module GenerateFile was tested when we
created an Object File. The compressed data,
decompression technique and other contents were stored
as an Object File. When we were extracting the Object
File, we used ExtractFile module. The decompression
method was activated by ExtractFile module, and was
applied to the compressed data to obtain the original data.
Then the original text file would be realized by the
applicationPath attribute in order to be sent to the
supported applications such as MS Word or Notepad. We
manipulated and modified the extracted Object File
(original text file) using an application, then saved it. The
modified file was stored as an Object File.
As a result, the Object Files worked properly. We
could extract data from Object Files and update them
similarly to the original files. The manipulation of objects
worked very well.
7. CONCLUSION
The structures of file storage contained in operating
systems have generally been designed to support their
own platforms. Object File could provide great benefits
by avoiding this constraint. However, it is very difficult to
extend operating systems and structure of files. What
needed is an infrastructure with extensibility in a file. We
also believe that Object File shows the viability of a
particular approach to system software technology. This
approach advocates building a modular extensible
framework rather than constructing the new systems.
According to the increasing of complex and diverse
demands made on system software, we believe that
Object-Oriented style of system building will become
norm.
8. REFERENCES
Fig.4: Extract File Process
The major role of an Object File is the way it handles
an inherited file using a dynamic binding concept. When
the ExtractFile process recognizes first bit of a derived
file, if b = 1, the child Object File will be extracted. Its
pointer will point to the parent file (this process will be
repeated until the root/recently overridden file is found) to
find and activate the method content. The difference of
an overridden file is that the method content will be
obtained from itself.
[1] Campbell Roy H., Johnston Gary M., Madany Pater
W., and Russo Vincent F., Principles of ObjectOriented Operating System Design, Technical Report
UIUCDCS-R-89-1510, University of Illinois at
Urbana-Champaign, April 1989.
[2] Campbell Roy H., Islam Nayeem, Madany Pater W.,
and Raila David, Designing and Implementing
Choices: An Object-Oriented System in C++,
Communications of the ACM, September 1993.
[3] Beck Leland L., System Software: An Introduction to
Systems Programming, Addison Wesley Longman,
Inc., New York, 1997, ch. 6.
[4] Kim Ted H., Frigate: An Object-Oriented File System
for Ordinary Users. USENIX COOTS’ 1997.
[5] Silberschatz Abraham, Galvin Peter B., and Gagne
Greg, Operating System Concepts, John Wiley and
Sons, Inc., New York, 2003, ch. 11.
6. EXPERIMENTS AND RESULTS
We tested the system by creating Object Files for
compressed text and multimedia data (image, sound etc.).
-4-