SCHOOL OF COMPUTER SCIENCE AND ENGINEERING

Project On

Study Of “Visopsys”

By:

1) B V S ANIKETH-13BCE0031 2) DHEERAJ C AKSHAY-13BCE0834

3) DEVI PRASAD REDDY-13BCE0535

Under the guidance of

Prof. Gopinath M.P. ,SCSE

CONTENTS

Chapter No. Title Page No.

CHAPTER 1 ABSTRACT 1

CHAPTER 2 INTRODUCTION TO VISOPSYS 2

2.1 Broader Ideology of Visopsys 3

CHAPTER 3 MOTIVATION 4

CHAPTER 4 IMPLEMENTED/UNIMPLEMENTED SECTIONS 5

CHAPTER 5 PROJECT DESCRIPTION 6

5.1 Overview of IPC

7

5.2 Implementation and Analysis 8

5.3 Challenges 9

CHAPTER 6 SUMMARY 10 6.1 References 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.

SignatureName with Regno

SignatureName with Regno

SignatureName with Regno

ACKNOWLDEGEMENTABOUT VISUAL OPERATING SYSTEM DEVELOPER--------------------------------------------------------------------

The primary developer of Visopsys is Andy McLaughlin, a 30-something 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, old-fashioned way of producing software.

1

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 it’s 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.

2

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.

3

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 environmentThe 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 doesn’t 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" modeFully pre-emptive multitasking and multi-threadingVirtual memory, and memory protection

5

Flat linear memory managementGraceful processor fault and exception handlingGood random number capabilityBuffered, asynchronous disk I/OELF executable formatJPG, BMP and ICO image filesFilesystem 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 shellSmall, native C libraryNative installer programDynamic linkingHard disk partitioning program (Disk Manager)I/O ProtectionFPU state saves

Unimplemented Sections:Multi-user operationInter-Process Communications (IPC) facilityMost network functionalityFilesystem support for:- Writable Ext2/Ext3- Mounting NTFS filesystems (commonly used by Windows and Linux)- (others, as demand dictates)GIF and PNG image files

6

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.

Implementation and Analysis:

As we have already mentioned the style of which the design will be

under project description as passing the objects and some form of data

describing what the object is. We will be sharing these between separate

executable files that wont be sharing memory that’s requested to be

mapped into the memory space or by using the call back method also we

can pass the data.

Hence accordingly we have designed the following code as given below:

In this code we have also added the some kernel(API) calls as we have

to implement and embed it into visopsys. The window events, 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). So for such

applicative vroader aspect we ill be requiring this IPC as a critical

element.

9

Challenges:

While pursing the project we faced many backlogs as we were new to

the OS development environment, even the simpliest tasks appeared to

be difficult but later on as we moved on slowly we actullay understood

what is happening as in how the OS operates what are the different

sections which will have to again co-ordinated to form an Operating

System.

So while we were going through the open source codes it wasn’t easy to

understand so easily because the whole codes were under the library of

visopsys which is modified version libraries of Cent OS.

So with the knowledge of kernel libraries and the functionality of the

particular source code to some extent we did understand what and how

exactly the program is running.

So moving on, we moved on to work on IPC which seemed to be an

interesting area to explore. For this our work became easier and easily

understandable because of ANDY the core developer of Visopsys who

has helped us by giving insight of what problem statement to work on

and then we followed accordingly and hence we could actually come out

with some great ideas for IPC to be implemented.

But the code being written on higher level i.e kernel and the visopsys

being on the lower level couldn’t execute it in the visopsys background

10

but still the coding as the ideology of the way IPC works is almost

correct.

Summary:

So as we have seen and came across such an amazing developing

environment it gave us a lot of encouragement through out the course.

It changed the way we think and our perceptions towards almost

everything. Finally we have gone through the implemented part of the

OS and Visopsys was successfully running on VMWare too.

The OS is quite efficient though it seemed a little immature in

appearance but still the efficiency of codes were quite remarkable.

Over here the unimplemented part i.e the IPC being a very important

functionality, we have studied the various possible applicative

possibilities of IPC and keeping in mind those things we have tried our

best to come up with a code which could process information when

moved from kernel background to windows shell background, but only

thing is since it being the high level background it isin’t getting executed

on Visopsys.

Though we couldn’t execute it but still the programming and the

structure of the IPC code is correct as to the best of our knowledge.

11

REFERENCES:-

Ralf Brown's (indispensable Interrupt List )(http://www.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.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