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.
OOP OS, a matter of API design
-
The Legend
RE:OOP OS, a matter of API design
>On 2002-03-03 12:16:28, krillzip wrote:
>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.
Well, sounds good.
Most times, the C-Library handles that stuff.
When the program is started, it will fetch the
interface to the display driver and call main.
Using the interface, you can implement cin- and
cout-classes based upon it.
Talking about interfaces, I think you'll
not only need an OOP-Design, but a Component-Design.
The Legend
>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.
Well, sounds good.
Most times, the C-Library handles that stuff.
When the program is started, it will fetch the
interface to the display driver and call main.
Using the interface, you can implement cin- and
cout-classes based upon it.
Talking about interfaces, I think you'll
not only need an OOP-Design, but a Component-Design.
The Legend
-
J. Weeks
RE:OOP OS, a matter of API design
>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
Yes! This how, appoximately, how I had originally
designed my OS (I just used object oriented
C code, though, not C++)
> theDisplay = ObjectManager.ReturnDriver("Screen"); // Returning the pointer from the kernel.
You should never have to do that. The runtime linker
will take care of all that.
Just think to libc. Your code is dynamically linked
to that at runtime. The same would also be
true for a C++ program and libstdc++ (granted,
you'll have to rewrite that library).
>In this example the OS has to return the pointer to the driver for using the display.
Ideally, your run time linker will provide your
program with pointers to objects (such as ofstream,
or theDisplay), and there will be no need for
this.
>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.
I certainly respect a good OO OS, but don't you think
C++ would be _more_ difficult to port? There's
much more overhead to a C++ program as apposed to a
C program (new/delete, virtual functions, RTTI, etc)
>The hard question is the API.
The more dynamic you can get, the better, in my
opinion. The programmer need not even know
what's going on in the background, and it
yeilds so many different possibilities (ie,
replace this object very easily with this newer
updated driver...)
Jeff
>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
Yes! This how, appoximately, how I had originally
designed my OS (I just used object oriented
C code, though, not C++)
> theDisplay = ObjectManager.ReturnDriver("Screen"); // Returning the pointer from the kernel.
You should never have to do that. The runtime linker
will take care of all that.
Just think to libc. Your code is dynamically linked
to that at runtime. The same would also be
true for a C++ program and libstdc++ (granted,
you'll have to rewrite that library).
>In this example the OS has to return the pointer to the driver for using the display.
Ideally, your run time linker will provide your
program with pointers to objects (such as ofstream,
or theDisplay), and there will be no need for
this.
>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.
I certainly respect a good OO OS, but don't you think
C++ would be _more_ difficult to port? There's
much more overhead to a C++ program as apposed to a
C program (new/delete, virtual functions, RTTI, etc)
>The hard question is the API.
The more dynamic you can get, the better, in my
opinion. The programmer need not even know
what's going on in the background, and it
yeilds so many different possibilities (ie,
replace this object very easily with this newer
updated driver...)
Jeff
-
krillzip
RE:OOP OS, a matter of API design
>On 2002-03-03 14:21:00, The Legend wrote:
>>On 2002-03-03 12:16:28, krillzip wrote:
>>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.
>Well, sounds good.
>
>Most times, the C-Library handles that stuff.
>When the program is started, it will fetch the
>interface to the display driver and call main.
>Using the interface, you can implement cin- and
>cout-classes based upon it.
>
>Talking about interfaces, I think you'll
>not only need an OOP-Design, but a Component-Design.
The OS framework contains baseclasses for Component-Design,
if you want a Component-Interface you just inherit the baseclass
and modyfies it after your needs, you also inherit the Component-itself
from a component baseclass that you customize after your Component-Interface.
So this is not the real matter.
The problem is if the component interfaces should be compiled staticaly
and replace the ObjectManager class, or if the Component should be loaded
dynamicaly so it is much easier to customize the OS after your needs.
>
>The Legend
>>On 2002-03-03 12:16:28, krillzip wrote:
>>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.
>Well, sounds good.
>
>Most times, the C-Library handles that stuff.
>When the program is started, it will fetch the
>interface to the display driver and call main.
>Using the interface, you can implement cin- and
>cout-classes based upon it.
>
>Talking about interfaces, I think you'll
>not only need an OOP-Design, but a Component-Design.
The OS framework contains baseclasses for Component-Design,
if you want a Component-Interface you just inherit the baseclass
and modyfies it after your needs, you also inherit the Component-itself
from a component baseclass that you customize after your Component-Interface.
So this is not the real matter.
The problem is if the component interfaces should be compiled staticaly
and replace the ObjectManager class, or if the Component should be loaded
dynamicaly so it is much easier to customize the OS after your needs.
>
>The Legend
-
Guest
RE:OOP OS, a matter of API design
>On 2002-03-03 20:16:57, J. Weeks wrote:
>>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
>
>Yes! This how, appoximately, how I had originally
>designed my OS (I just used object oriented
>C code, though, not C++)
>
>> theDisplay = ObjectManager.ReturnDriver("Screen"); // Returning the pointer from the kernel.
>
>You should never have to do that. The runtime linker
>will take care of all that.
Maybe that could be done inside a header, that the programmer never sees,
but as you say, this SUCKS!
>Just think to libc. Your code is dynamically linked
>to that at runtime. The same would also be
>true for a C++ program and libstdc++ (granted,
>you'll have to rewrite that library).
>
>>In this example the OS has to return the pointer to the driver for using the display.
>
>Ideally, your run time linker will provide your
>program with pointers to objects (such as ofstream,
>or theDisplay), and there will be no need for
>this.
>
>>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.
>
>I certainly respect a good OO OS, but don't you think
>C++ would be _more_ difficult to port? There's
>much more overhead to a C++ program as apposed to a
>C program (new/delete, virtual functions, RTTI, etc)
Maybe I should do the kernel classes ni C instead have the framework over that,
but I am ready to do the work to port C++, even it will take the rest of my life.
>>The hard question is the API.
>
>The more dynamic you can get, the better, in my
>opinion. The programmer need not even know
>what's going on in the background, and it
>yeilds so many different possibilities (ie,
>replace this object very easily with this newer
>updated driver...)
If I does the kernel OO dynamicaly it will be easy to expand and customize the OS
but it will be a heavy work for the os-loader cause the kernel itself doesn't contain
the hardware drivers.
If I does the kernel OO staticaly I can compile drivers into the kernel file and it
will be able to initalize itself. This means that I will replace the ObjectManager with
some other basic classes like, DisplayManager, DiskManager, HardwareManager, PrintManager and etc.
>Jeff
PS. Thanx for not being bitchy.
// krillzip
>>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
>
>Yes! This how, appoximately, how I had originally
>designed my OS (I just used object oriented
>C code, though, not C++)
>
>> theDisplay = ObjectManager.ReturnDriver("Screen"); // Returning the pointer from the kernel.
>
>You should never have to do that. The runtime linker
>will take care of all that.
Maybe that could be done inside a header, that the programmer never sees,
but as you say, this SUCKS!
>Just think to libc. Your code is dynamically linked
>to that at runtime. The same would also be
>true for a C++ program and libstdc++ (granted,
>you'll have to rewrite that library).
>
>>In this example the OS has to return the pointer to the driver for using the display.
>
>Ideally, your run time linker will provide your
>program with pointers to objects (such as ofstream,
>or theDisplay), and there will be no need for
>this.
>
>>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.
>
>I certainly respect a good OO OS, but don't you think
>C++ would be _more_ difficult to port? There's
>much more overhead to a C++ program as apposed to a
>C program (new/delete, virtual functions, RTTI, etc)
Maybe I should do the kernel classes ni C instead have the framework over that,
but I am ready to do the work to port C++, even it will take the rest of my life.
>>The hard question is the API.
>
>The more dynamic you can get, the better, in my
>opinion. The programmer need not even know
>what's going on in the background, and it
>yeilds so many different possibilities (ie,
>replace this object very easily with this newer
>updated driver...)
If I does the kernel OO dynamicaly it will be easy to expand and customize the OS
but it will be a heavy work for the os-loader cause the kernel itself doesn't contain
the hardware drivers.
If I does the kernel OO staticaly I can compile drivers into the kernel file and it
will be able to initalize itself. This means that I will replace the ObjectManager with
some other basic classes like, DisplayManager, DiskManager, HardwareManager, PrintManager and etc.
>Jeff
PS. Thanx for not being bitchy.
// krillzip
-
J. Weeks
RE:OOP OS, a matter of API design
>Maybe that could be done inside a header,
>that the programmer never sees,
>but as you say, this SUCKS!
I wouldn't be that harsh, dude. I think you're on
the right track. Dynamic objects is the way to go.
In the kernel, yes, you'll probably have to have
lines like:
myVideo = filesystem->loadObject("video");
But that really isn't a big deal, is it? It's fairly
self explainatory. Besides, any kernel with
external drivers (wether it be written in C, C++,
asm... whatever) is going to have to do the same
thing.
If you're worried about a programmer writting applications
for your OS having to do this... don't. It wont
be an issue.
You don't have to do the following in C:
printf = void (*function)(etc)loadFunction("printf");
right?
And yet, in Linux, printf is still external to
your program (it's not statically linked).
This is all taken care of by your run time loader.
When you compile a program, your compiler will
notice that this function (or object) is external,
and will put some information in the binary header
to tell the run time linker that this program
requires extra linking at run time.
The linker will then read this information, find
the pointer to printf, and make sure that every
reference in your program points to the correct
location.
Make sense?
Don't worry about it, dude, you're doin' it right.
Just do a little research on run-time linkers.
It's complicated, yes, but the rewards are great.
>Maybe I should do the kernel classes ni C instead have the framework over that,
>but I am ready to do the work to port C++, even it will take the rest of my life.
Oh, no, by all means, if you want to write in C++,
do so! I didn't mean to try and convert you, or
anything, C++ kernels can be quite impressive, and
I applaud it! I just wanted to make sure you did
realize that you will have to rewrite a bunch of
those C++ low level routines that take care of
new and delete and what-not.
>If I does the kernel OO dynamicaly it will be easy to expand and customize the OS
>but it will be a heavy work for the os-loader cause the kernel itself doesn't contain
>the hardware drivers.
Don't worry about it, man. Your kernel will be
extremely versitile for the effort. Short term
pain, long term gain.
Every modern OS supports externally loadable modules.
Even Linux (which is, more-or-less, a mono-lithic
kernel).
Really, it wont be too much overhead. The process
can handle it, I garauntee
>If I does the kernel OO staticaly I can compile drivers into the kernel file and it
>will be able to initalize itself. This means that I will replace the ObjectManager with
>some other basic classes like, DisplayManager, DiskManager, HardwareManager, PrintManager and etc.
Thing is, the minor overhead you're gonna incur for
loading objects is going to result in a lot of
versitility afterwards.
The only major difference while the kernel is
running, is that with dynamic objects, is you'll have
to load the pointer to that object each time
before calling it, as apposed to already knowing
where the object resides. That's only one clock
cycle. Incredibly minor.
In short, I think dynamic objects are most
definitly worth it!
>PS. Thanx for not being bitchy.
Oi! That's gonna be my reputation forever, isn't it?
Jeff
>that the programmer never sees,
>but as you say, this SUCKS!
I wouldn't be that harsh, dude. I think you're on
the right track. Dynamic objects is the way to go.
In the kernel, yes, you'll probably have to have
lines like:
myVideo = filesystem->loadObject("video");
But that really isn't a big deal, is it? It's fairly
self explainatory. Besides, any kernel with
external drivers (wether it be written in C, C++,
asm... whatever) is going to have to do the same
thing.
If you're worried about a programmer writting applications
for your OS having to do this... don't. It wont
be an issue.
You don't have to do the following in C:
printf = void (*function)(etc)loadFunction("printf");
right?
And yet, in Linux, printf is still external to
your program (it's not statically linked).
This is all taken care of by your run time loader.
When you compile a program, your compiler will
notice that this function (or object) is external,
and will put some information in the binary header
to tell the run time linker that this program
requires extra linking at run time.
The linker will then read this information, find
the pointer to printf, and make sure that every
reference in your program points to the correct
location.
Make sense?
Don't worry about it, dude, you're doin' it right.
Just do a little research on run-time linkers.
It's complicated, yes, but the rewards are great.
>Maybe I should do the kernel classes ni C instead have the framework over that,
>but I am ready to do the work to port C++, even it will take the rest of my life.
Oh, no, by all means, if you want to write in C++,
do so! I didn't mean to try and convert you, or
anything, C++ kernels can be quite impressive, and
I applaud it! I just wanted to make sure you did
realize that you will have to rewrite a bunch of
those C++ low level routines that take care of
new and delete and what-not.
>If I does the kernel OO dynamicaly it will be easy to expand and customize the OS
>but it will be a heavy work for the os-loader cause the kernel itself doesn't contain
>the hardware drivers.
Don't worry about it, man. Your kernel will be
extremely versitile for the effort. Short term
pain, long term gain.
Every modern OS supports externally loadable modules.
Even Linux (which is, more-or-less, a mono-lithic
kernel).
Really, it wont be too much overhead. The process
can handle it, I garauntee
>If I does the kernel OO staticaly I can compile drivers into the kernel file and it
>will be able to initalize itself. This means that I will replace the ObjectManager with
>some other basic classes like, DisplayManager, DiskManager, HardwareManager, PrintManager and etc.
Thing is, the minor overhead you're gonna incur for
loading objects is going to result in a lot of
versitility afterwards.
The only major difference while the kernel is
running, is that with dynamic objects, is you'll have
to load the pointer to that object each time
before calling it, as apposed to already knowing
where the object resides. That's only one clock
cycle. Incredibly minor.
In short, I think dynamic objects are most
definitly worth it!
>PS. Thanx for not being bitchy.
Oi! That's gonna be my reputation forever, isn't it?
Jeff
-
Guest
RE:OOP OS, a matter of API design
Thanx for everything Jeff!
I toke a little deeper look inside my C++ Primer Plus
and guess what I found. Why use pointers when I can use references.
ok here comes the header file:
extern Manager & DisplayManager = ObjectManager.ReturnDriver("Screen");
This line initalizes a reference to the DisplayManager, like a pointer
but you use usual syntax so here the program comes
#include <myOSheader.h>
int main(void)
{
Image myPicture;
DisplayManager.Mode(0x13);
DisplayManager << myPicture;
}
Thanx to references and includes I can keep the best of both cases.
Sometomes you really should study your C++ bible better (talking about me).
Thanx for all help.
PS. Do you have any ISBN:s or links on dynamic linkers?
I toke a little deeper look inside my C++ Primer Plus
and guess what I found. Why use pointers when I can use references.
ok here comes the header file:
extern Manager & DisplayManager = ObjectManager.ReturnDriver("Screen");
This line initalizes a reference to the DisplayManager, like a pointer
but you use usual syntax so here the program comes
#include <myOSheader.h>
int main(void)
{
Image myPicture;
DisplayManager.Mode(0x13);
DisplayManager << myPicture;
}
Thanx to references and includes I can keep the best of both cases.
Sometomes you really should study your C++ bible better (talking about me).
Thanx for all help.
PS. Do you have any ISBN:s or links on dynamic linkers?
-
J. Weeks
RE:OOP OS, a matter of API design
>On 2002-03-05 02:21:35, Anonymous wrote:
>Thanx for everything Jeff!
No prob
>I toke a little deeper look inside my C++ Primer Plus
>and guess what I found. Why use pointers when I can use references.
Cool! Sounds good. Nice to see some good books
bein' used as references, too
>Thanx to references and includes I can keep the best of both cases.
>Sometomes you really should study your C++ bible better (talking about me).
Eh... can't know everything My C++ knowledge
isn't great myself, I couldn't have suggested
that.
>PS. Do you have any ISBN:s or links on dynamic linkers?
Off hand, no, however, I do recall seeing a book
called "Linkers and Loaders" which'd probably
be perfect for what you're looking for.
Also, although it's probably very cryptic, the
sources to the linux loader might be useful.
Be sure to check out Schol-R-Lea's book list further
down this page (search for "books" and I think you'll
find it).
Oh, and take a look at the formats to popular
executable binary formats (Win32 .exe's and elf
in particular). The first "section" of these
binaries is usually associated with the loader
(it will contain a list of all "fix-up address"
(of external functions, etc) which the loader must
fill in before the program will run). Could be
helpful.
Jeff
>Thanx for everything Jeff!
No prob
>I toke a little deeper look inside my C++ Primer Plus
>and guess what I found. Why use pointers when I can use references.
Cool! Sounds good. Nice to see some good books
bein' used as references, too
>Thanx to references and includes I can keep the best of both cases.
>Sometomes you really should study your C++ bible better (talking about me).
Eh... can't know everything
My C++ knowledge isn't great myself, I couldn't have suggested
that.
>PS. Do you have any ISBN:s or links on dynamic linkers?
Off hand, no, however, I do recall seeing a book
called "Linkers and Loaders" which'd probably
be perfect for what you're looking for.
Also, although it's probably very cryptic, the
sources to the linux loader might be useful.
Be sure to check out Schol-R-Lea's book list further
down this page (search for "books" and I think you'll
find it).
Oh, and take a look at the formats to popular
executable binary formats (Win32 .exe's and elf
in particular). The first "section" of these
binaries is usually associated with the loader
(it will contain a list of all "fix-up address"
(of external functions, etc) which the loader must
fill in before the program will run). Could be
helpful.
Jeff