Anyone need a developer?

[mmiikkee12]

OK, so I've pretty much decided that I can't do my own kernel, it's just too much work for one person. (I used to have 2 other developers, but they ran off and created a separate project with different (and somewhat pointless imo) goals.) However, I'd still like to do some kind of OS work, so does anyone need a developer? Here's what I'd like an OS to have for me to join it:
- Not aiming for compatibility with other major OSes - if I want to run Linux apps, why not just run Linux?
- A GUI-based OS - I have a graphics card, I'd like to use it (and I don't mean a bunch of terminals/command prompt windows floating around on a desktop with nothing resembling a menu.) Note that I don't mean you already have to have a working GUI, but "completely text-based interface" shouldn't be anywhere in your list of goals.
- Should be open to new ideas - I won't try to force all of my design ideas onto your OS, but if I see something that could be implemented better chances are I'll say something.
- Must be x86 or x86-64, and written in C or C++ (I prefer C++).
- Must be compileable on x86 Linux with standard GNU tools.

(If the above seems overly aggressive, it wasn't meant to be. I just don't want to contribute to a project I don't like

[AndrewAPrice]

OK, so I've pretty much decided that I can't do my own kernel, it's just too much work for one person. (I used to have 2 other developers, but they ran off and created a separate project with different (and somewhat pointless imo) goals.) However, I'd still like to do some kind of OS work, so does anyone need a developer? Here's what I'd like an OS to have for me to join it:
- Not aiming for compatibility with other major OSes - if I want to run Linux apps, why not just run Linux?
- A GUI-based OS - I have a graphics card, I'd like to use it (and I don't mean a bunch of terminals/command prompt windows floating around on a desktop with nothing resembling a menu.) Note that I don't mean you already have to have a working GUI, but "completely text-based interface" shouldn't be anywhere in your list of goals.
- Should be open to new ideas - I won't try to force all of my design ideas onto your OS, but if I see something that could be implemented better chances are I'll say something.
- Must be x86 or x86-64, and written in C or C++ (I prefer C++).
- Must be compileable on x86 Linux with standard GNU tools.

(If the above seems overly aggressive, it wasn't meant to be. I just don't want to contribute to a project I don't like

I'm thinking of downgrading my kernel to C from C++. I'm going to use C++ for the drivers and modules though, but the actual microkernel 'kernel' is going to be C.

[mmiikkee12]

I'm thinking of downgrading my kernel to C from C++.

Any particular reason?

Anyway, I'd like to try to boot your OS but can't find a download link.

(One last semi-complaint - why the portal page? Why not just

Code: Select all

<?php header('Location: /portfolio/perception_os/perception_os.htm');

or

Code: Select all

<meta http-equiv="refresh" content="0;url=http://messiahandrw.netfast.org/portfolio/perception_os/perception_os.htm">

?)

[piranha]

Yeah, I was wondering about that too.
Are you going to post a downloadable image?

-JL

[AndrewAPrice]

Sorry, I haven't released any sources/binaries yet

My signature says: "14 todos away from 0.1". A basic outline of what these are include (I won't list them all since it means digging through my source directories looking for my todo.txt):
- Finish IPC (half-implemented)
- Optimise my system calls
- Move trivial code (for disks, FS, keyboard, etc) outside of the kernel.
- Fix a lot of bugs and finish my VFS.
- Work on a more elegant way to communicate window contents between Application <->Window Manager <-> Video Driver

My last 4 todos are simple applications I'm going to write (a program launcher, a text-based calculator, a process manager front end, a simple pixel manipulation example).

So basically, 0.1 will include a basic GUI with 2 types of windows (console and window frame buffer), a VFS (with floppy/FAT reading), IPC, and a few programs.

After 0.1 I plan to release 0.1.5 which won't add any features, but while I was developing I was making a list of potential optimisations which I'll implement to 0.1.5 (as well as concentrating on bug fixes). When I'm happy with the stability I'll progress to developing 0.2.

For 0.2 (the details haven't fully been planned) I'm going to get a mouse system working then focus mostly on my third and last type of GUI windows; control windows. Control windows will contain widgets, and the drawing of widgets and controlling widgets (passing text, mouse events, etc) will be handled by the library. When I have a base widget system working I'll add a few primitives (labels, checkboxes, text boxes, etc). Possibly if I have time I could add an image box widget that I can load a bimap image into.

I planned on reaching 0.1 this Chrismas break, but I've been extremely busy and haven't been able to find the time. And my motivation has been jumping between my OS and my other project (my game framework which shares concepts with a microkernel - drivers represent Direct3D, OpenGL, Windows, etc. and servers represent scene graphs, garbage collection, logic, etc.).

--------

Anyway, I'm sort of half/half in switching to C or staying with C++. There are limitations, but some of my greater design goals over come these.

Against C++:
I can't point to functions within C++ classes making vtables practically useless. I know I can use interfaces but only if I know the function I want to be called (and it's parameters and make it's the same function in every class) and inherit from the interface. Mostly used for IRCs and timer events.

For C++:
Some of my 'greater' design goals get around this. As things are moved out of the kernel I don't need function pointers because my drivers receive events (IRQ fired, timer expired, etc).

Against C++:
It's sometimes hard to define what should go into a struct and what should go into a class. e.g. A process and thread can be represented as a class since it's the Process class is the reasonable place to put a function for association a thread with a process. A FAT header would be be better stored in a structure, since it's a more like data you read from rather than an object you interact with. Some things are less blurred. E.g. An mounted instance of a file system, a struct would be simpler to pass around between my file system drivers and VFS, except in I could make the mounted instance a class with Read/Write/etc operations so I can just call those without having to find which FS the instance belongs to and pass the struct as a parameter.

For C++:
Interfaces and objects greatly simplify code and make it possible to wrap the messiest low level code in elegant and abstract classes (and also vice versa ). Inheritance is a god send (devices and drivers all inherit from a base device and driver class which common functions (detect, install, read, write, etc) and reduce the need for long function names: io_device_read() can be named read() in the Device interface class (with each specific device having it's own implementation) existing in the IO namespace.

The differences between using C/C++ in my kernel aren't really to do with the differences in the language but rather the methodology of programming usually associated with the language (C: store everything inside of structs that are passed around vs. C++: wrap everything in classes and namespaces).

For now I'll probably stick with C++. I only thought about using C for my kernel (not my drivers) because in a perfect microkernel the only thing which should exist inside of the kernel is process mangement, IPC, and minimal device management. The more I move out of the kernel the simpler the kernel core becomes making C (and representing processes and devices as simple memory structures) seem feasible again. And the overhead of calling a function is much lower than calling functions between classes since you don't have the overhead of saving and changing the class states (although in reality this is only a few extra instructions).

[bluecode]

I can't point to functions within C++ classes making vtables practically useless.

I am not sure what you mean here, but there are pointers to member functions.

It's sometimes hard to define what should go into a struct and what should go into a class.

The class and struct keyword are equivalent in C++. edit: except for the default visibility: struct has public as default and class has private, JamesM pointed that out on IRC.

And the overhead of calling a function is much lower than calling functions between classes since you don't have the overhead of saving and changing the class states (although in reality this is only a few extra instructions).

In C functions would save and change a structs state, so where do you see a difference?

[mmiikkee12]

Against C++:
I can't point to functions within C++ classes making vtables practically useless. I know I can use interfaces but only if I know the function I want to be called (and it's parameters and make it's the same function in every class) and inherit from the interface. Mostly used for IRCs and timer events.

IRC is a communication protocol. IRQ maybe?
Anyway, member function pointers (although they're slightly larger than normal pointers)

Against C++:
It's sometimes hard to define what should go into a struct and what should go into a class.

My general rule: if it has to be in a specific order, use a struct. If not, use a class. (I know it doesn't matter, but it helps me think.)

For C++:
... Inheritance is a god send (devices and drivers all inherit from a base device ...

That was one of my original plans when I switched to C++. But then I started thinking... how would you do that without having a monolithic, non-modular kernel? Unless you can think of a way to load classes/objects from files.

For now I'll probably stick with C++.

Good

The more I move out of the kernel the simpler the kernel core becomes making C (and representing processes and devices as simple memory structures) seem feasible again. And the overhead of calling a function is much lower than calling functions between classes since you don't have the overhead of saving and changing the class states (although in reality this is only a few extra instructions).

Actually it's the same. In C you'd do something like this:

Code: Select all

typedef struct
{
    int pid;
    ...
} process_t;

void kill_process(process_t *p, int signal);

But in C++, you're actually doing the same thing, since there's an invisible *this pointer passed as the first argument to a member function. So

Code: Select all

some_process.kill(signal);

is the same as

Code: Select all

Process::kill(&some_process, signal);

assuming your process class is called Process.

----

Getting back to the subject, do you think I should join another project or try to continue with mine? I just seem to have a lot of trouble with paging and multitasking, and lose motivation quickly after poking the same bug for 5 hours

[Jeko]

OK, so I've pretty much decided that I can't do my own kernel, it's just too much work for one person. (I used to have 2 other developers, but they ran off and created a separate project with different (and somewhat pointless imo) goals.) However, I'd still like to do some kind of OS work, so does anyone need a developer? Here's what I'd like an OS to have for me to join it:
- Not aiming for compatibility with other major OSes - if I want to run Linux apps, why not just run Linux?
- A GUI-based OS - I have a graphics card, I'd like to use it (and I don't mean a bunch of terminals/command prompt windows floating around on a desktop with nothing resembling a menu.) Note that I don't mean you already have to have a working GUI, but "completely text-based interface" shouldn't be anywhere in your list of goals.
- Should be open to new ideas - I won't try to force all of my design ideas onto your OS, but if I see something that could be implemented better chances are I'll say something.
- Must be x86 or x86-64, and written in C or C++ (I prefer C++).
- Must be compileable on x86 Linux with standard GNU tools.

(If the above seems overly aggressive, it wasn't meant to be. I just don't want to contribute to a project I don't like

If you want you can help me with my project.
It is developed for x86 (and maybe it will also developed for x86-64).
I work on it using linux (in particular ubuntu).
It's open to new ideas.
I want to do a GUI based OS with only few things in command line.
But I want to port some applications from linux.

Are you interested?

[mmiikkee12]

I think I've changed my mind - I'm just going to continue working on my current OS.

[Wave]

Against C++:
It's sometimes hard to define what should go into a struct and what should go into a class.

My general rule: if it has to be in a specific order, use a struct. If not, use a class. (I know it doesn't matter, but it helps me think.)

If it has functions as members it goes into a class. If it doesn't you probably have functions outside it to manipulate its member variables. If you have that, move those functions inside the struct and make it a class.

[Alboin]

Against C++:
It's sometimes hard to define what should go into a struct and what should go into a class.

My general rule: if it has to be in a specific order, use a struct. If not, use a class. (I know it doesn't matter, but it helps me think.)

If it has functions as members it goes into a class. If it doesn't you probably have functions outside it to manipulate its member variables. If you have that, move those functions inside the struct and make it a class.

If the members of said data type are public, use a struct. If they are private, use a class.

[jtlb]

if you want i am always looking for developers. I am doing my operating system with a friend. Our goal is to make something simple to play multimedia files. I know that it will be pretty hard to reach this goal but that's for fun! If you are interested, just tell, thank you.

[elfenix]

That was one of my original plans when I switched to C++. But then I started thinking... how would you do that without having a monolithic, non-modular kernel? Unless you can think of a way to load classes/objects from files.

This actually isn't all that hard - microkernel or modular monolithic.

First, you'll need to make a superclass has all the substantial portions as virtual functions.

Second, you'll need a superclass which implements a factory to create your clases from.

Last, you'll need to create/export some sort of 'plugin manager' which has a public function to register your factory superclass.

Then, use the exact same methodology you would use to load a C module.

You can do this with a microkernel as well - but you will need to create a library of 'bridge classes' that you can inherit that handle messaging the kernel. Also, one would need to keep in mind the extra overhead method calls into those objects would have.......

[AndrewAPrice]

Also, one would need to keep in mind the extra overhead method calls into those objects would have.......

That was what I was referring to before about the overhead of class states. Unlike global functions there is a little more overhead in jumping to function within another class.

[Wave]

The only (and I really do mean only) overhead of calling a function in another class is that the function pointer will have to be passed on the stack.

So the overhead of myClass.myFunc(a) is exactly the same as of myFunc(&myInstance, a).