OSDev.org

Which would you guys say is the better idea for a beginner to operating system development (not new to programming at all and familiar with many OS design concepts, but not very familiar with low level details and hardware interfacing)? Make a few smaller OSes before moving on to larger projects or just jumping in and extending the same project over time so that it gets larger and more complex as I learn more?

I vote for baby steps first

I think that it's better to go small in the beginning. This makes things simpler when you are trying to learn about the features of the hardware. Once you understand how the low level stuff works, then you could start a larger project.

I don't think that you should just keep adding parts until you get an OS(at least not when you're learning). Doing it this way would lead to a very messy OS and you would have to go back and rewrite earlier parts in order to continue working on newer parts. I think this is why many OS dev newbies fail. They just jump in expecting to make an OS without knowing how things really work from the start. This leads to nasty code and entire project rewrites(This has happened to me before... )

The approach I'm taking right now (that I have the Intel hardcopies ) is to make a list of things I want in my OS (kernel features mainly) then I research it in the manual + google and search for it here. Once I learn enough of it I implement. Not as fast but you understand things better imho

I created a roadmap, so to speak, so I can see where I want my kernel to go and how I'm going to get it there.

To oversimplify things: Your first OS will fail. So make it big enough to learn the things you'll need for your second attempt, and small enough so that you won't be too burned-out and disappointed when it fails.

Solar wrote: To oversimplify things: Your first OS will fail.

<yoda leftear="down">
Still so optimistic you are, eh !?
</yoda>

you may like to extend and extend ... yet you may fail to extend because it will require you to break the whole design.

That will all depend on how much you're happy with "hacking around something that's not perfect" and how strong you feel the need for "redo from scratch".

So far, i've been developing the current "Clicker" codebase for about 6 years now and still i haven't "redo from scratch" ... but virtually every bit of the code i initially wrote were replaced by something else, sometimes meaning the system doesn't boot for 1 or 2 months ...

I had two previous "codebase" for clicker before that, one being a realmode GUI, the other one being a extended version of a "protected-mode switching" code for DOS that was used as a petry dish for memory management algorithms. They indeed failed , but were they OSes ?

I agree with Solar here, you will probably dump your code and start over from scratch several times, but don't be afraid to do so. The code you've written might be lost, but not your experience!

Pype.Clicker wrote: So far, i've been developing the current "Clicker" codebase for about 6 years now and still i haven't "redo from scratch" ... but virtually every bit of the code i initially wrote were replaced by something else, sometimes meaning the system doesn't boot for 1 or 2 months ...

That probably shows that you are (and were) a talented designer from the beginning on (producing extensible and flexible code...).

cheers Joe

Pype.Clicker wrote: I had two previous "codebase" for clicker before that, one being a realmode GUI, the other one being a extended version of a "protected-mode switching" code for DOS that was used as a petry dish for memory management algorithms. They indeed failed , but were they OSes ?

If they were OSes, they wouldn't have failed.

A definition of words. Is a rewrite of all relevant code parts still the same project?

But I think my point is clear. Be prepared that your first few attempts will be good for little else but teaching you some things. If you chose your "toy projects" too little, though, there will still be things to learn (the hard way) once you scale your ambitions.

Nelson wrote: The approach I'm taking right now (that I have the Intel hardcopies ) is to make a list of things I want in my OS (kernel features mainly) then I research it in the manual + google and search for it here.

CPU programming manuals isn't enough, OS and kernel concepts are more important (to me) then specific CPU implementation. And also I think that planning is very important part of development process, and to do planning you must know how stuff works, so you must have previous experience in the field.

kataklinger wrote:

Nelson wrote: The approach I'm taking right now (that I have the Intel hardcopies ) is to make a list of things I want in my OS (kernel features mainly) then I research it in the manual + google and search for it here.

CPU programming manuals isn't enough, OS and kernel concepts are more important (to me) then specific CPU implementation. And also I think that planning is very important part of development process, and to do planning you must know how stuff works, so you must have previous experience in the field.

Well I was just using the manuals as an example but yea after you implement foundation features like interrupt/exception handling you can pretty much go in any direction planned with it.

kataklinger wrote: CPU programming manuals isn't enough, OS and kernel concepts are more important (to me) then specific CPU implementation.

You have to know what you can do with the CPU, and whether that makes sense or not, to be able to design your concepts. OK, so you know that CPUs have something that is called "paging". But to be able to devise a good paging algorithm, you must know what the CPU (or MMU) provides. Does it have a "dirty" bit? Does it have per-page read / write timestamps? How could you share memory areas? How do you switch address space? Can you map kernel memory into user space, and if yes, how?

Yes, virtually all OS concepts tutorials out there assume the x86. But which generation? Perhaps later generations provide some new way to do things, and you might be well-advised to skip compatibility so you could implement better concepts?

The CPU limits and enables. It is the pivot point of your kernel. You might be able to come up with nice abstractions higher up, but at the lowest levels you're doing a CPU driver.

If you would have to write an OS given only GRUB, Ralph Brown's Interrupt List, and a single book as a resource, with absolutely no other reading and no background information (and no internet connection), you should definitely chose the Intel Manual over Tanenbaum.

Solar wrote: The CPU limits and enables. It is the pivot point of your kernel. You might be able to come up with nice abstractions higher up, but at the lowest levels you're doing a CPU driver.

If you would have to write an OS given only GRUB, Ralph Brown's Interrupt List, and a single book as a resource, with absolutely no other reading and no background information (and no internet connection), you should definitely chose the Intel Manual over Tanenbaum.

This most definately implies that you need to know what a cpu COULD offer, before you can learn about methods for using those offerings, and why you need those offerings. That lets you judge stuff on their value, since you can determine what sort of processors can support it, how fast it'll be etc.

Knowing about loads of things you could do wrong is also a good thing, since you will recognise those things.

Knowing about loads of things you could do wrong is also a good thing, since you will recognise those things.

that is why i took the time to read every post ever posted to this board, before i ever posted anything -- i have seen what problems other people commonly have, and the most common solutions, and hopfully i can avoid similer problems (and if not, i know where to look for the most probable solutions)

I said: "it's not enough"!
I didn't say that you don't need to have it, you MUST have Intel (or AMD) manuals!
Before you start programming/planning an OS you should know basic concepts of operating systems and targeted hardware, but hardware changes very often so you must design system to be able to accept these changes the easy way, but very basic concepts of an OS haven't changed for a long time