SCHOOL OF COMPUTER SCIENCE AND ENGINEERING

Project
On
StudyOfVisopsys
By:

1)BVSANIKETH13BCE0031
2)DHEERAJCAKSHAY13BCE0834
3)DEVIPRASADREDDY13BCE0535

Under the guidance of

Prof. Gopinath M.P. ,SCSE

CONTENTS
Chapter No.

Title

Page No.

CHAPTER

ABSTRACT

CHAPTER

INTRODUCTION TO VISOPSYS

2.1

Broader Ideology of Visopsys

CHAPTER

MOTIVATION

CHAPTER

IMPLEMENTED/UNIMPLEMENTED SECTIONS

CHAPTER

PROJECT DESCRIPTION

5.1

Overview of IPC

7
5.2

Implementation and Analysis

5.3

Challenges

CHAPTER

6
6.1

SUMMARY
References

10
11

May 2015

School of Computing Science and Engineering

DECLARATION
We hereby declare that the project entitled Visual Operating System submitted by us
to the School of Computing Science and Engineering, VIT University, Vellore in partial
fulfillment of the requirements for the PBL-CSE222 Operating System Course is a record of
bonafide work carried out by us under the supervision of Prof. Gopinath M. P. I further declare
that the work reported in this project has not been submitted and will not be submitted, either in
part or in full, for the award of any other degree or diploma of this institute or of any other
institute or university.

Signature
Name with Regno

Signature
Name with Regno

Signature
Name with Regno

ACKNOWLDEGEMENT
ABOUT VISUAL OPERATING SYSTEM DEVELOPER
-------------------------------------------------------------------The primary developer of Visopsys is Andy McLaughlin, a 30something programmer originally from Calgary, Canada.
Several years ago, she moved to London, UK, after a year in
Boston and 2 years in San Jose, California. Like many other
hobby OS writers, she build Visopsys in here spare time.
She is not actively seeking other programmers to assist in the
development of Visopsys at this time, but she does gladly accept
code submissions and suggestions.
An operating system kernel is a big enough challenge to be
discouraging at times. In comparison, the Pascal compiler she
wrote over an eight month period is trivial.
On the other hand, since she does everything by herself she is
able to keep the development on a unified path.
The architecture that develops is she hopes is consistent (for
better or worse) and thus the end product reflects the vision of a

single programmer. It can be argued that this is the good, oldfashioned way of producing software.

Abstract:
Basically an Operating System is an elementary part of any computer
running in the present generation since it being the mode of interaction,
hence there are a wide range of open source small scale operating
systems which have been developed from day to day irrespective
whether its being used or not and at the same time such exploration
plays a crucial role in developing the developed Operating systems
further for effectiveness because at the end of the day new applications
and the betterment of the present working systems is what aimed in any
case. So unknowingly the open source Operating Systems play a vital
role in the development of the Operating Systems.
One such OS is VISOPSYSwhich has been developed since 1997.
It is not much of a user usable OS on a wide scale but yet it can used for
small purposes since all the sub-parts have yet not been implemented.
In this Mini-Project we will be studying the insights of the Open source
Visopsys and will be trying to implement any one area of the
unimplemented part.

Introduction To VISOPSYS:
Visopsys (VISualOPeratingSYStem) is an alternative operating system
for PC-compatible computers, written "from scratch", and developed
primarily by a single hobbyist programmer since late 1997.
Visopsys is free software and the source code is available under the
terms of the GNU General Public License. The libraries and header files
are licensed under the terms of the GNU Lesser General Public License.
The bulk of Visopsys is a fully multitasking, 100% protected mode,
virtual-memory, massively-monolithic-style kernel. Added to this is a
bare-bones C library and a minimal suite of applications together
comprising a small but reasonably functional operating system which
can operate natively in either graphical or text modes. Though it's been
in continuous development for a number of years, realistically the target
audience remains limited to operating system enthusiasts, students, and
assorted other sensation seekers.
Other operating systems can do more than Visopsys; it doesn't include
many applications. Needless to say, it's not as good as Linux or even
SkyOS or Syllable. On the other hand, it's still a one-person project.

Broader Ideology behind VISOPSYS:

The primary goal of Visopsys is to cherry-pick the best ideas from other
operating systems, preferably contribute a few new ideas, and hopefully
avoid (re-) introducing some of the more annoying elements.
However many ideas Visopsys borrows from other products, it is not a
Windows or UNIX lookalike, nor a clone of any other system. On the
other hand, much of what you see in Visopsys will be familiar. There
are a number of command line programs that are superficially UNIX- or
DOS-like, so you shouldn't have too much trouble finding your way
around. It is compatible with existing filesystems, file formats,
protocols, and encryption algorithms (among other things).
Some of the higher-level conceptual goals are as follows:
1. "Native" Graphical environment
The base-level graphics server (analogous to an 'X' server in Unix, but
not X) is integrated into the kernel. A default GUI environment runs
"straight out of the box", with no setup procedure.
2. Strong command line capabilities (text windows and scripting)
Users must be given the ability to operate in a text-based environment if
they prefer to do so.
To the greatest extent possible, the user should be able to perform all
tasks, including administrative ones, using the text interface.
Configuring mysterious configuration files by hand is, therefore,
optional.
3. Compatible.

Visopsys will conform to existing standards to the greatest extent

possible. It is not a goal for Visopsys to define new formats (such as a
new filesystem type).
4

Motivation:
When we come across so many open source operating systems, it
obviously enthralls us to explore the insight of such Operating Systems.
In particular Visopsys being the Open source OS developed on Cent-OS
and implementing the coding further on kernel base gives an easy hands
on applicative scenario for us to explore and develop something new.
With addition to it, Visopsys still doesnt have all the implemented parts
though it has most of the basic requirements yet there are few crucial
parts which are yet to be implemented if aimed at broader scenario.
The Core Developer of VisopsysAndy McLaughlina 30-something
programmer originally from Calgary, Canada, who has helped us
during our project with issues which could be developed, which actually
helped us in a great way and gave us exact insight of what to work on
which led us on the major part of our project which will be coming
further in the report.

Implemented/Unimplemented Sections of VISOPSYS:

Visopsys is starting to look and feel like a 'real' operating system.
There's still a long way to go before Visopsys might be useful to the
average person, but it's getting there little by little.
Coding work was begun as a part-time operation in late 1997. The large
majority of the code is written in C, with portions in x86 Assembly
Language. Following is a list of some of the implemented and
unimplemented functionality.
Implemented Sections:

Graphical User Interface (GUI)

Fully 32 bits, "protected" mode
Fully pre-emptive multitasking and multi-threading
Virtual memory, and memory protection
5
Flat linear memory management
Graceful processor fault and exception handling
Good random number capability
Buffered, asynchronous disk I/O
ELF executable format
JPG, BMP and ICO image files
Filesystem support for:
- 12, 16, and 32-bit FAT filesystems (commonly used by DOS and
Windows)
- Read-only Ext2/Ext3 filesystems (commonly used by Linux)
- CD-ROM filesystems (ISO9660/Joliet)
- DVD-ROM filesystems (UDF)
Native command line shell
Small, native C library
Native installer program
Dynamic linking
Hard disk partitioning program (Disk Manager)
I/O Protection
FPU state saves
Unimplemented Sections:
Multi-user operation
Inter-Process Communications (IPC) facility
Most network functionality
Filesystem support for:
- Writable Ext2/Ext3
- Mounting NTFS filesystems (commonly used by Windows and Linux)
- (others, as demand dictates)

GIF and PNG image files

Project Description:
On insight analysis of the open source codes of Visopsys we have
analyzed few codes such as boot loader and cd loader, file management
codes.
So on many cases have been implemented butINTER PROCESS
COMMUNICATION(IPC) which is one of the most important file
management operation has not yet been developed under Visopsys so the
exploration of IPC would be beneficial in a great way.
Because IPC at some pint when working on kernel and windows base it
is needed, so as said effectiveness is always desired in any case.

Overview of IPC:
Inter process communication (IPC) is the activity of sharing data across
multiple and commonly specialized processes using communication
protocols. Typically, applications using IPC are categorized as clients
and servers, where the client requests data and the server responds to
client requests.Many applications are both clients and servers, as
commonly seen in distributed computing. Methods for achieving IPC are
divided into categories which vary based on software requirements, such
as performance and modularity requirements, and system circumstances,
such as network bandwidth and latency.
There are several reasons for implementing inter-process communication
systems:
Sharing information; for example, web servers use IPC to share web
documents and media with users through a web browser.

Distributing labor across systems; for example, Wikipedia uses multiple

servers that communicate with one another using IPC to process user
requests.
Privilege separation; for example, HMI software systems are separated
into layers based on privileges to minimize the risk of attacks. These
layers communicate with one another using encrypted IPC.
7
So as we can see how important role the IPC carries so hence the
implementation of IPC would definitely be beneficial to us.
Before we actually start exploring we have run Visopsys and checked its
applicative feasibility as a part of knowing the OS better in order to
understand it in a better way.
We have run the OS on VMWare Player which is a 3rd party OS
simulator where we able to run Visopsys and explore it.
And we also went through few basic codes related to the implementation
of few functionalities like image displaying and closing them, floppy
loading, boot loader etc.
So coming back to IPC Andy the core developer of VISOPSYS
suggested to move on with designing the IPC in order to work over
windows thread since in future it will be needed when required for inter
interactions and hence the design problem being that would be very
better.
In the simplest version, we need a way to pass data objects and some
form of metadata describing what the object is. We have to pass these
between separate executables that don't share memory space generally,
but can use specific pieces of shared memory -- memory that's requested
to be mapped into the memory space of both processes. So, most
userspace pointers have to be avoided, and data needs to be copied.
Another way of sending data is via the kernel and its memory; call the
kernel with the data, then the kernel wakes up the receiving process and
transfers the data to it, via a callback or similar.

A more sophisticated version would extend this to RPC (remote

procedure call) where you would say what function or service you want,
and any arguments (presumably using the data mechanism mentioned
above), with a way to return results. The caller should be able to choose
blocking or non-blocking calls.
We could design and test all of the basic non-kernel-specific stuff in user
space on another operating system, such as Linux.
8
The next part is to integrate all of this into Visopsys. The kernel is
monolithic, and usually manages things like this. So, you'd probably
want to add some kernel API calls (src/include/sys/api.h,
src/lib/libc/_kernapi.c, src/kernel/kernelApi.c) so that processes can
register for IPC. You can also look at/copy the way the GUI programs
receive windowEvents, using a bit of library code that registers
callbacks, then launching a GUI thread to poll the kernel for data
(src/lib/libwindow/windowMain.c).
Briefly this is what we will be dealing in the project further.

ImplementationandAnalysis:
Aswehavealreadymentionedthestyleofwhichthedesignwillbe
underprojectdescriptionaspassingtheobjectsandsomeformofdata
describingwhattheobjectis.Wewillbesharingthesebetweenseparate
executablefilesthatwontbesharingmemorythatsrequestedtobe
mappedintothememoryspaceorbyusingthecallbackmethodalsowe
canpassthedata.
Henceaccordinglywehavedesignedthefollowingcodeasgivenbelow:

Inthiscodewehavealsoaddedthesomekernel(API)callsaswehave
toimplementandembeditintovisopsys.Thewindowevents,usingabit
oflibrarycodethatregisterscallbacks,thenlaunchingaGUIthreadto
pollthekernelfordata(src/lib/libwindow/windowMain.c).Soforsuch
applicativevroaderaspectweillberequiringthisIPCasacritical
element.

9
Challenges:
Whilepursingtheprojectwefacedmanybacklogsaswewerenewto
theOSdevelopmentenvironment,eventhesimpliesttasksappearedto
bedifficultbutlateronaswemovedonslowlyweactullayunderstood
whatishappeningasinhowtheOSoperateswhatarethedifferent
sectionswhichwillhavetoagaincoordinatedtoformanOperating
System.
Sowhileweweregoingthroughtheopensourcecodesitwasnteasyto
understandsoeasilybecausethewholecodeswereunderthelibraryof
visopsyswhichismodifiedversionlibrariesofCentOS.
Sowiththeknowledgeofkernellibrariesandthefunctionalityofthe
particularsourcecodetosomeextentwedidunderstandwhatandhow
exactlytheprogramisrunning.

Somovingon,wemovedontoworkonIPCwhichseemedtobean
interestingareatoexplore.Forthisourworkbecameeasierandeasily
understandablebecauseofANDYthecoredeveloperofVisopsyswho
hashelpedusbygivinginsightofwhatproblemstatementtoworkon
andthenwefollowedaccordinglyandhencewecouldactuallycomeout
withsomegreatideasforIPCtobeimplemented.
Butthecodebeingwrittenonhigherleveli.ekernelandthevisopsys
beingonthelowerlevelcouldntexecuteitinthevisopsysbackground

10
butstillthecodingastheideologyofthewayIPCworksisalmost
correct.

Summary:
Soaswehaveseenandcameacrosssuchanamazingdeveloping
environmentitgaveusalotofencouragementthroughoutthecourse.
Itchangedthewaywethinkandourperceptionstowardsalmost
everything.Finallywehavegonethroughtheimplementedpartofthe
OSandVisopsyswassuccessfullyrunningonVMWaretoo.
TheOSisquiteefficientthoughitseemedalittleimmaturein
appearancebutstilltheefficiencyofcodeswerequiteremarkable.

Overheretheunimplementedparti.etheIPCbeingaveryimportant
functionality,wehavestudiedthevariouspossibleapplicative
possibilitiesofIPCandkeepinginmindthosethingswehavetriedour
besttocomeupwithacodewhichcouldprocessinformationwhen
movedfromkernelbackgroundtowindowsshellbackground,butonly
thingissinceitbeingthehighlevelbackgrounditisintgettingexecuted
onVisopsys.
Thoughwecouldntexecuteitbutstilltheprogrammingandthe
structureoftheIPCcodeiscorrectastothebestofourknowledge.

11

REFERENCES:

Ralf Brown's (indispensable

Interrupt List )
(http://www.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/f
iles.html);

David Jurgens' HelpPC.

Frank van Gilluwe's "The

Undocumented PC"

Tom Shanley's "Protected Mode

Software Architecture"

Lots of other sources, many of

them online