>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