A LITTLE OF HISTORY.

What and who is ZEUS OS?

Therefore ZEUS OS was born , students' José Juan Barco, Javier Cuevas, Oscar García and José Luis Vela initiative that evaluated the possibility to implement it and of creating it, being independent, and having programming tools and of communication through nets

Definition of first objectives, and form of work.

The objectives proposed for the year 1996/97 were:

• Practical study of the theory of O.S. see in the subject.

• Valuing the work in group.

• To know how to confront the challenges that it takes gets a project of this type.

• Taking out a very good note in S.O. II.

Also the premises of work.
The organization of the project is carried out by the work group, organizing the project in several phases described in the flowchart.

Inside the group there is not control hierarchy, so that they can be carried out the works of the project in a completely free way. The form of which they will take the decisions will be the following:

a) General decisions that concern to the whole project: they take for consent of the group, being all of agreement in what it is necessary to make.

b) Decisions in the different tasks: they take for the responsible one of carrying out this task.

The scheduling of the project was carried out in such a way that possible paralell went to the maximum the tasks to carry out in the project. In the first place, the analysis and design of ZEUS, the one which was developed jointly. Later on they spent to implement the system, the drivers and the tools that are necessary. Each task was developed by a component of the group. The tasks that were carried out were:

1. Kernel development.
2. Development of an agent memory.
3. Development of a system files server.
4. Development of a video server .
5. Development of a keyboard server.
6. I develop of a linker.
7. Development of a compiler.
8. Development of a net server.
9. Development of an interpreter of commands.

Alternative technological.

In principle they thought about two development lines tied to the architecture of the PC: the real mode or the protected mode.

If it was opted by the protected way it would be endowed the O.S. of big possibilities that would make it more attractive. Certain works are also facilitated like they can be the multitask, protection memory and administration of the virtual memory. Likewise it is necessary to say that this programming way hinders in great measure the given implementation the little experience in this land, and for the scarce and bad documentation.

On the other hand, the realization of the O.S. in real way, it limits the technical characteristics of the product strongly to develop, even other, they won't be possible to implement, as virtual memory, protection of data. But it is necessary to say that great quantity of bookstores, tools and bibliographies exist to work in real mode.

Question alternative to the creation of components they were:

• Scheduler: The different ones were evaluated planning that can be implemented cycle robbery, for priority or not, preventive multitask or cooperative... Each option has its characteristics, very different, and therefore they are equally different when implementing.

• Memory: the administration is intimately bound to operation of the CPU. The main questions to solve are the fragmentation, paging and virtual memory, lineal access to memory...

• Disk: The alternatives were to try to be the most flexible and independent in the format of the disk, allowing to make use of the maximum quantity of existent formats, or to create a format characteristic of storage. The first option was the most attractive and versatile, but also the most complex, since implies a considerable time of study and development. The second option is the simplest, but it only offers the freedom of placing the information in a simple way for the group that develops the system.

• Calls to the system: This characteristic should be deeply studied, since it is fundamental for the quick acceptance of the other parts of the O.S. This part is also very bound to the CPU. As options they were evaluated step of messages among processes, to implement an architecture Client-server, calls to the system for generation of interruptions, direct calls to procedures of the system in areas by heart shared by applications and O.S., by means of semaphores...

• Controllers of devices: The interfaces of the controllers of devices should be simple and stable. Also these should be strongly linked to the strategy of calls to the system. The controllers can be loaded or not dynamically in time of execution or being compiled directly in the nucleus.

• User's interfaces: There are two clear alternatives the way text and the graphic way. There are also several alternatives regarding the interactive and conceptualization of the interface, like they can be menus and windows, interpreter of commands...

Alternative of construction.

Of all the alternatives exposed in the previous point the following ones they were adopted:

• Real Mode: It was chosen a bigger experience since it exists in this field, and there was little time of development, a system of big technical characteristics was not also looked for, but obtaining information about the viability of the construction of a O.S.

• Scheduler: A scheduler was adopted by priorities that it endows the O.S. of a cooperative multitask. This is the most versatile, since starting from him they can be implemented the rest of scheduler.

• Memory: It was opted by the assignment control and liberation of this. The controller doesn't have any additional characteristic, excepting that he tries to diminish the fragmentation of the same one.

• Calls to the system: A system was implanted based on calls to the low system an architecture Client-server. This way, it is a system open to future amplifications, as for example migration to protected mode without having to change the form in that interacive the applications of the O.S.

• Interface with the controllers of devices: It uses the same architecture, Client-server.

• User's Interface: It was opted by the option of a simple interpreter of commands that allows the interaction with all the components of the system, and that it also facilitates the purification works and it proves of the group of routines that form the operating system.

Annotation 1.

Flowchart of the phases of the project ZEUS YOU. To return to the text.

zeusv2@geocities.com

This page is hosted by   Get Your Own Free Homepage