OOP OS, a matter of API design
Posted: Sun Mar 03, 2002 12:00 am
I have tought for a while how to design an API for
an Object Oriented OS in C++, this is not an discousion
about task switching or LTD:s or GTD:s and other low level styff like that.
This is a discussion about a totally new way to design an OS,
well it has the standard futures like Pmode memory handling, preemptive multitasking,
and signaling.
Imagine this:
The kernel has six static classes for handling basic things
The classes are those:
class TaskManager{}; // Handling multitasking
class MemoryManager{}; // Handling memory, the _new_ operator does it's calls to this class
class IOManager{}; // Handling hardware access, registers, microcontrollers
class ProcessingManager{}; // Handling multi processing
Now, the next two classes are OS-specific, especisally the last one
class StreamManager{}; // Handling data streaming and event handling and messaging
class ObjectManager{}; // The most revolutonary thing with this OS, keeps tracks o the FrameWork classes
The OS also has a C++ class framework making the os Object Oriented
All classes in the framework like the GUI classes (windows, menus), Driver classes, font classes and
all other kind of classes needed are inharited from one baseclass: class Object{}; so that all classes could be
handled by the ObjectManager. All classes in the framework are loaded dynamicaly.
Here comes the big question!
How should I design my API so it is easy to use but without any loss of my OOP OS philosofy.
If the drivers are loaded dynamicaly it will be hard for the programmer, cause then he/she first has to get the pointer to the driver,
but if the drivers are loaded staticaly it would be as easy to use as cout << "hello"; or cin >> intVar;
There are two ways I could design:
Case 1:
In this case the drivers are loaded dynamicaly.
The program want to print a picture to the screen.
#include <myOSheader.h>
int main(void)
{
OSdriver * theDisplay; // Declaring a pointer to the Display driver.
class Image myPicture; // Declaring the picture object.
theDisplay = ObjectManager.ReturnDriver("Screen"); // Returning the pointer from the kernel.
theDispplay -> Mode(_13h_);
theDisplay -> << myPicture;
}
In this example the OS has to return the pointer to the driver for using the display.
Case 2:
In this case the drivers are loaded staticaly.
The program want to print a picture to the screen.
#include <myOSheader.h>
int main(void)
{
class Image myPicture; // Declaring the picture object.
theDisplay.Mode(_13h_);
theDisplay << myPicture;
}
In this example it's just as simple as cout or cin.
What this discussion is about is finding the
middleway between Object Orientation and the easy to programming.
Why I want my OS to be like this is because I want it to:
1. be easy to expand.
2. I want it Object Orientated.
3. in C++ so it will be easy to port between platforms.
The hard question is the API.
Thanx on advance for tips and answers.
an Object Oriented OS in C++, this is not an discousion
about task switching or LTD:s or GTD:s and other low level styff like that.
This is a discussion about a totally new way to design an OS,
well it has the standard futures like Pmode memory handling, preemptive multitasking,
and signaling.
Imagine this:
The kernel has six static classes for handling basic things
The classes are those:
class TaskManager{}; // Handling multitasking
class MemoryManager{}; // Handling memory, the _new_ operator does it's calls to this class
class IOManager{}; // Handling hardware access, registers, microcontrollers
class ProcessingManager{}; // Handling multi processing
Now, the next two classes are OS-specific, especisally the last one
class StreamManager{}; // Handling data streaming and event handling and messaging
class ObjectManager{}; // The most revolutonary thing with this OS, keeps tracks o the FrameWork classes
The OS also has a C++ class framework making the os Object Oriented
All classes in the framework like the GUI classes (windows, menus), Driver classes, font classes and
all other kind of classes needed are inharited from one baseclass: class Object{}; so that all classes could be
handled by the ObjectManager. All classes in the framework are loaded dynamicaly.
Here comes the big question!
How should I design my API so it is easy to use but without any loss of my OOP OS philosofy.
If the drivers are loaded dynamicaly it will be hard for the programmer, cause then he/she first has to get the pointer to the driver,
but if the drivers are loaded staticaly it would be as easy to use as cout << "hello"; or cin >> intVar;
There are two ways I could design:
Case 1:
In this case the drivers are loaded dynamicaly.
The program want to print a picture to the screen.
#include <myOSheader.h>
int main(void)
{
OSdriver * theDisplay; // Declaring a pointer to the Display driver.
class Image myPicture; // Declaring the picture object.
theDisplay = ObjectManager.ReturnDriver("Screen"); // Returning the pointer from the kernel.
theDispplay -> Mode(_13h_);
theDisplay -> << myPicture;
}
In this example the OS has to return the pointer to the driver for using the display.
Case 2:
In this case the drivers are loaded staticaly.
The program want to print a picture to the screen.
#include <myOSheader.h>
int main(void)
{
class Image myPicture; // Declaring the picture object.
theDisplay.Mode(_13h_);
theDisplay << myPicture;
}
In this example it's just as simple as cout or cin.
What this discussion is about is finding the
middleway between Object Orientation and the easy to programming.
Why I want my OS to be like this is because I want it to:
1. be easy to expand.
2. I want it Object Orientated.
3. in C++ so it will be easy to port between platforms.
The hard question is the API.
Thanx on advance for tips and answers.
