My OS Development Plans

[NotTheCHEAT]

I'm planning to write a sort of a hybrid OS, somewhere between DOS, Minix, and Linux. I currently call it JOS1 (because my name is James) although it will eventually have a "real" name if I can think of one. (I can't do like Linus and Linux, because Jamesux sounds like "James sux" which of course won't do. Any ideas for an OS name would be appreciated, as I'm not very creative in that area.)

For what it's worth, here's how I plan to do things:

1.I plan to start with protected mode, paging, etc. A good OS needs these things. I'll then do memory management, RAM disks, etc. Then I'll reprogram the PIC and setup IDT tables. I'll write a PIT driver for multitasking, which is next.

2.I'll next get basic multitasking working. This might seem strange, but no matter how I do it I'll get chicken-and-egg syndrome. So I do multi-tasking, with static test tasks linked directly into the kernel (sort of like unit-testing, I guess).
That way I can test the multi-tasking, and IPC and process sychronization (probably semaphores).

3.Next I make a basic console driver. With keyboard and VGA, I can write a basic commandline with some built-in commands. This will be temporary, as the commandline will eventually be a separate process (not part of the kernel), but until there's a disk driver it has to be part of the kernel.

4.Writing parallel and serial port drivers wil be easy, and will open up new possibilities (such as debugging, printing, etc.)
It will not take very long either, yet these are important things to write, so writing them early on will make it easier to write more complex things without having to worry about those.

5.Now I'll write a floppy disk driver. We need to be able to access the disk somehow, and the sooner the better.
I'll also write a driver for the FAT12 filesystem (of course, eventually my OS will support many other filesystems, but for now I just need to support one, and this simple and easy-to-program filesystem will do).
Now that I'm finally able to load programs off the disk, I'll rewrite the multitasking and general system calls to account for this.

6.Now I'll write a real commandline, with some built-in commands and the ability to load programs off the disk. I'll also write a simple interpreter for shell scripts, but nothing fancy at this point. I will probably write a parser for things like I/O redirection and pipes (Unix-style).

7.I will now work on all the other things I need to work on: HDD (IDE, SCSI, etc.), Network Cards, other filesystems, mouse support, sound card support, and eventually, SVGA. At some point I will write a simple GUI to make some tasks easier and more intuitive, but like linux and unlike windows, the GUI will never be "the real operating system." However, I will later make a real GUI, after I have made virtually everything else.

What do you all think? Good, bad, what? Any ideas?

[GLneo]

bad idea, basic console after mutitasking + paging is not going to be easy, multitasking is going to be hard enough, with out kernel output IMPOSSIBLE!

[Warrior]

I'd suggest atleast getting basic screen output to help you debug whatever you implement.

[NotTheCHEAT]

Of course I'm going to have text output before I write the console driver! The console driver will only make it possible to switch screen modes and do graphics. Do I really sound that stupid?

[Dex4u]

As your called james, you should have a code name for you OS like 007 ;D.

[Tora OS]

my name works better for a 007 OS.

James Babb.....

lol anyway...a 007 name would still be cool for an OS.

Maybe something like:

Screen out put:

007 OS: Letting Task0 live, and now letting it die.

[NotTheCHEAT]

lol I might do that. The main name probably won't be 007 OS, but I can make humorous references to 007.

[Warrior]

What's an OS withought humor
Good luck.

[smiddy]

my name works better for a 007 OS.

James Babb.....

lol anyway...a 007 name would still be cool for an OS.

Maybe something like:

Screen out put:

007 OS: Letting Task0 live, and now letting it die.

That is a great start to my day, thanks I needed the laugh!

[Crazed123]

1.I plan to start with protected mode, paging, etc. A good OS needs these things. I'll then do memory management, RAM disks, etc. Then I'll reprogram the PIC and setup IDT tables. I'll write a PIT driver for multitasking, which is next.

The very first thing you should do is to set up text output (I know, you say you'll do that first) with which to debug. This is your debugging, so make it rock solid. The next thing is to set up an IDT with exception handlers that make use of your text output functions to report what happened and where. You'll probably want to start fiddling with assembler stubs now in order to get the hang of giving your C handlers access to register data on interrupts by setting the assembly stub routines into the IDT. Now that you've got exception handling you can go ahead with your stuff as planned, memory management (for physical you'll probably want it done before paging, but that's a choice, not a neccesity), paging, etc

3.Next I make a basic console driver. With keyboard and VGA, I can write a basic commandline with some built-in commands. This will be temporary, as the commandline will eventually be a separate process (not part of the kernel), but until there's a disk driver it has to be part of the kernel.

Why do you need a basic commandline built into the kernel? The user usually won't be in control before some form of disk driver and a decently complex user interface is online. Also, you may wish to put your VGA code in with your original text output to make a unified console driver.

4.Writing parallel and serial port drivers wil be easy, and will open up new possibilities (such as debugging, printing, etc.)
It will not take very long either, yet these are important things to write, so writing them early on will make it easier to write more complex things without having to worry about those.

Using serial ports to send debug output:

5.Now I'll write a floppy disk driver. We need to be able to access the disk somehow, and the sooner the better.
I'll also write a driver for the FAT12 filesystem (of course, eventually my OS will support many other filesystems, but for now I just need to support one, and this simple and easy-to-program filesystem will do).
Now that I'm finally able to load programs off the disk, I'll rewrite the multitasking and general system calls to account for this.

Why will multitasking need rewriting for that? A multitasking subsystem's job is to load, link and run new processes in memory, it would be a strange practice IMHO to involve it with loading things off the disk. General system calls, on the other hand, will need some additions and rewrites. I recommend creating a general system call to load and run a program from disk. It can call the other two subsystems without requiring them to know each other.

6.Now I'll write a real commandline, with some built-in commands and the ability to load programs off the disk. I'll also write a simple interpreter for shell scripts, but nothing fancy at this point. I will probably write a parser for things like I/O redirection and pipes (Unix-style).

7.I will now work on all the other things I need to work on: HDD (IDE, SCSI, etc.), Network Cards, other filesystems, mouse support, sound card support, and eventually, SVGA. At some point I will write a simple GUI to make some tasks easier and more intuitive, but like linux and unlike windows, the GUI will never be "the real operating system." However, I will later make a real GUI, after I have made virtually everything else.

Good ideas.

[NotTheCHEAT]

I need a commandline built into the kernel for debugging and testing purposes, otherwise I can't interact with my OS for a very long time. If you think it is a better idea I will make the VGA driver before multitasking (I was planning to have text output temporary, for debugging purposes only, and write a real console driver later).

Actually, I was thinking of using parallel ports to send debugging information since Bochs can put parallel port output into a file.

Multitasking will only need to be rewritten in this way: to print error messages to a log file instead of the screen. I suppose I should have made this more clear.

Thank you for the constructive, helpful criticism. Since I am just starting it is much needed and much appreciated