Could drivers be objects??

[soilwork]

So far Ive only used CPP limited.. didnt find fit for it everywhere but now Im thinking, could the drivers be objects, rather then just functions.

and for example the video driver... the GUI when loaded needs to be passed an instance of the video object, and I suppose only one will be created for the whole session of the OS...
would that work for all drivers??

thanks, later

[Pype.Clicker]

well, this is another way to state the very same thing ... in a way, your driver is a software component that will implement a defined interface (open/close/read/write/ioctl in unix model). Now, nothing should prevent you to describe other kind of interfaces and make them implemented by your driver ...

nothing distinguish this from a structure that holds function pointers at a low level: this is just syntactic sugar ...

you could have
interface BasicDriver {
status open();
status close();
}

interface CharDeviceDriver extends BasicDriver {
status putch();
status getch();
}

interface BlockDeviceDriver extends BasicDriver {
status read(block_id, &buffer);
status write(block_id, &buffer);
}

etc. (yes, i know: this is java syntax just because i'm not a C++ guru

[soilwork]

me=confused due to lack of knowledge of java...

I only know =new and =null for java as opposed to ->new and ->delete for dynamic alocation of objects... no more java for me though Id like to learn...

[dronkit]

ok, basic intro so you understand what pype.clicker suggests:

in java you have classes, abstract classes and interfaces.

a class can be instantiated (when you create an object of this class). a class can also be "extended", thus giving you a sub-class of the original class (the super-class). each subclass generally inherits stuff from its parent (or super-) class.

an abstract class is a normal class but which can not be instantiated (but CAN BE "extended") because one, more or all of its methods are abstract (that is, they're not coded because it is expected that the class extending an abstract class implements them).
In c++ abstract methods and classes are defined by using the "virtual" keyword.

an interface is like an abstract class but with no code at all, just definitions. the interfaces are used to overcome the limit that java imposes that no class can descend from more than one class (no multiple-inheritance support).

so classes are "extended" and/or "instantiated" while interfaces can be "implemented" and "extended" but not "instantiated".

So in the example given by pype.clicker you have a basic interface that every generic driver would have to "implement" (that is, code all the methods and have all variables needed to be a "driver") and you have some examples for higher-level interfaces like block and character devices.

You have no drivers in this examples, just their interfaces. An object can be an abstract class that implements some generic interfaces and define some other abstract methods implemented by its "extending" classes (or subclasses).

Hope it helps ;)

[soilwork]

That cleared it up perfectly, but there is one thing:

if u dont have an instance of the object in the kernel, how is it gonnna be in memory to work as a driver???

I was thinking for ex for a video driver that has all the variables and procedures in the class... then the kernel creates ONE instance of the class(U only need one driver) and then the gui is being passed the instance through an argument of the constructor of the GUI.

To me it makes sence and should work, but I dunno wether it really is the way.
Thanks

PS.. how would I make that Java no instance thing work??? if the actual thing is not loaded in the memory???

Can you please explain this?? And if I CAN use a no instance class for a driver, how would I do that in C++???
Thanks a lot.

[dronkit]

That cleared it up perfectly, but there is one thing:

if u dont have an instance of the object in the kernel, how is it gonnna be in memory to work as a driver???

you can have instances of all your basic drivers from inside the kernel, then as you load new modules you can just change references to them.

Anyway, if you compile the code for abstract or normal classes, you can instance them whenever you want... you don't need to "have the code in memory" but rather have the code just where it needs to be (very basic low-level function in an abstract class and some advanced i/o in the child class, for example).

Each new driver could be just a class loaded whenever you want to. In java, they would all be .class files (this is the extension for compiled classes).

I was thinking for ex for a video driver that has all the variables and procedures in the class... then the kernel creates ONE instance of the class(U only need one driver) and then the gui is being passed the instance through an argument of the constructor of the GUI.

To me it makes sence and should work, but I dunno wether it really is the way.
Thanks

ok, you can do that... I'm not sure about passing the gui object as an argument.. maybe you should wrap the calls through your kernel object.. the gui could call the kernel instead of the driver directly.. this is a nice thing to discuss here

PS.. how would I make that Java no instance thing work??? if the actual thing is not loaded in the memory???

Can you please explain this?? And if I CAN use a no instance class for a driver, how would I do that in C++???
Thanks a lot.

I'm not sure what you mean... once you have all things compiled, you can just serialize the objects you need and/or use dynamic libraries. These libraries can contain instantiable classes...

You can code an abstract class which represents a generic driver or several generic drivers for every kind of device you expect to handle. You can work in your code by using this abstract class (as long as you're not trying to instantiate it). You can assume you already have the object loaded/instantiated by using interfaces and/or abstract classes...

then again.. i'm not sure what you mean by "not having the code in memory"

[.bdjames]

extern int printf();
extern int getchar();

typedef int(*print)(char*, va_list args);
typedef int(*get)();

struct console{
print p;
get g;
} = c;

void Init(){
c.p = printf;
c.g = getchar;
}

[.bdjames]

opps

struct console{
print p;
get g;
} c;

[soilwork]

in order for a driver to be usable it has to be in mem and accessible to the programs...

u only have one instance of the video driver class in the whole os for all the programs so programs wont override each other...

that is my ideea

what u were saing is not having an instance of the object... Then how would u access the driver from programs???

and u need the driver to be static.. its not like u can load it whenever u want it dynamically, cuz u want only one and u want it to ALWAYS be available.. so a static instance is what Im thinking of but ur talking about some kind of interface that uses no instance...

thanks now

James, is that standard C???

when I say class I think of procedures and data together...

like maybe this would be it:
Video.H

class video{
private:
int mode, resolution[][], colors;
blah blah
.
.
public:
Video(int mode);
~Video();
void Putpixel(int x,int y,RGB c); //RGB colour class
void Line(int x1, int y1,int x2,int y2,int algorythm, RGB c); //algorythm=horiz line, vert, ... for different faster algorythms
void Circle(int x,int y,int d,RGB c);
void Ellipse(int x,int y,int w,int h,RGB c);
void Rectangle(int x,int y,int xw,int yh,RGB c);
void WinButt_Borders(int x,int y,int xw,int yh,gui obj); //gui obj tells colour shades to be used in the configuration
};

the implementation goes in Video.CPP

Sorry for sloppy editing.. anyway, this is my ideea... and ONE instance of this class.. an object to be passed to the GUI.. and the GUI will use every way it needs... the gui would be responsible for full screen games too saving the GUI buffer and allowing the game use the driver directly... and then on exit just regaining the control..

does it make sence?? help me if Im wrong.. thanks

[soilwork]

or depending on what is more efficient I might stick the winbutt function in the GUI classes.. just the code in the Draw functions for the 3d objects

[dronkit]

That's ok, you can *explicitely* instantiate it in your main()

I suggest a more layered-design, tho. For example, you can have one object per screen. A screen can be one of the monitors connected to the pc or even one portion of the current screen... maybe playing with some ideas first will end up in some cool design

What you have to decide first is where does the Video class code job starts and where it ends to make it as simple and fast possible. The more abstract the better. Then you have to decide wether your gui asks the kernel for a Video object and gets it reference or needs to call some of your kernel methods as wrappers. (thus giving it some kind of indirect access to the object).

It is a nice topic to discuss!

[soilwork]

cool.. the thing with more monitors and the screen areas, but I think that should be a layer using the video driver... the driver should however support 2 monitors or would that mean 2 instances of the same video driver object??

And the Video driver doesnt need to get info from the gui, does it???

I mean when the GUI constructor is instantiated, it is being passed a video driver obj as an argument:
Gui(Video vidobj);

and then the Gui class has access to variables(public)from the Video class when it wants to give some info if ever neeed... and will get back info in the same maner...
when it(the gui) runs functions from the video class like putpixel.. etc, the values go through arguments and come back as returned values.. pretty basic I guess, writting this down I clear stuff up.. and u reading it might clear stuff up for urself or find mistakes in my logic

so that is the ideea..

the gui class is something like Desktop.. class... same thing.. the class that communicates with programs(API) and kernel and windowing classes and video drivers.. for requests and ...

here is the design I made a while ago:

3days_in_darkness.tripod.com/kernel.bmp

cut and paste... I basically want to make the whole thing in pure C++ with classes.. what I still cant get right though is the memory management..

Im stuck on that.. I couldnt make a simple kernel that just outputs somehing on the screen yet.. Used watcom and borland C++ compillers and ELINK for linker and the data is not found properly therefore the output on the screen is wrong.. I even stopped trying that cuz elink was just not designed to do that and borland C++ wasnt either... Watcom seems to be a good choice if I can get JLOC working too but I have no ideea how to use that thing... GPP is good I just dont like it.. I just love the "perfect" kind of structure in borland style ANSI...

also, I dont know what to use as executable and OS executable(the actual kernel and OS code).. flat binary seems good but sensitive...

and how would I go about fixing the IDT and GDT and everythign so I can run that simple kernel??
I tried to use John Fines boot sector with my tries for getting output on the screen..

thanks now


OH YEA, the video driver being a class.. Im thinking of making it somehow modular... make it call Vesa for my dev and then have drivers for the actual video cards.. but in the same class shape...

later

it is indeed interesting.. makes my brain feel clear and structured, while when I try to program fractals my brain feels overwelmed by what the comp can calculate and how the code is wierdly arranged...

btw, if any of u know a simple algorythm for a fractal(the simplest but it has to look half cool), email me
sorry for the lengthy msg

[dronkit]

Well, you still have to decide a lot of stuff

You can use grub to load your kernel so you can start right into C programming. you may also do your basic setup and memory manager in C so you can then use C++ code properly.

Maybe if you post some of the code in a proper thread i could give you a hand. If not, someone else will

[Pype.Clicker]

what u were saing is not having an instance of the object... Then how would u access the driver from programs???

and u need the driver to be static.. its not like u can load it whenever u want it dynamically, cuz u want only one and u want it to ALWAYS be available.. so a static instance is what Im thinking of but ur talking about some kind of interface that uses no instance...

So what you definitively want is a singleton pattern:

Code: Select all

class VideoDriver implements Driver {
    static private VideoDriver driver=null;
    static public VideoDriver getDriver() {
         if (driver==null) driver=new VideoDriver();
         return driver;
    }
    private VideoDriver() {
         // initialization & stuff
    }
}

note that you also might want to have only *one link* to your driver:

Code: Select all

class VideoDriver implements Driver {
     private static VideoDriver driver=null;
     public static VideoDriver getDriver() 
             throws ResourceBusyException {
           if (driver!=null) throw new ResourceBusyException(driver);
           driver=new VideoDriver();
           return driver;
     }
}

[soilwork]

is that the java implementation of the exact thing I wrote in C++???