OSDev.org

Just a little of what I'm realising even more now. Anybody who hopes to make an OS that is much more than barebones has definitely got to have a solid design first. You cannot hope to have a reliable system and understand every single line of code in your OS and know keep all the information on how it works in your head all at once. Writing things down also let's you see problems that you need to figure out before coding. All to often a newbie will start writing code from the barebones and then get all confused when it starts to get complicated. Please, do it, save yourself the trouble, and yes I know this applies to other software development as well. Yes, this is not a question but maybe it will spark some discussion...

If you do all of your design first, it's hard to modify structures for changing requirements. Much better to iterate over smaller designs, adding features as you go.

I'm not saying complete stone, but it needs to be pretty solid before you code.

Edit: Just something to get that annoying add off the index.

You know what.

"Is a sentence fragment" is a sentence fragment.

Seriously? TBOS didn't have much of a beginning design. I planned out the following at the beginning:

• Kernel segment = 2000h
• Programs loaded to CS:8000h
• System calls executed by interrupts
• Intel 80186 compatible instructions only

I still don't have much of a design.

More of a big os thing. Lol, and "you know what was some text to get that ahole ad outa the way".

I agree with the OP for psychological reasons. Every time I try a bigger project, I fail because I keep adding features and optimizations in the middle of the process. Then I loose the overall picture and delete my work and start all over.

Knowing in advance exactly what the program should do and do not, really helps me stay focused.

Roel

well
in this case, it is good to start with a "small" design( a litlle ideer) , and then make it.
after that you will see alot of "problems", that you could not at design time.
this also helps at improvement, because at some point you see that your design is either limited, or not good enough, and then start over.
I have already many things im starting over with (in os of cause), because my previous design failed, even my own filesystem is not good enough desigend ( i realized this after i began knowing a little more on "lba", ...)
But that is what make your "new" design better: you have (maby) learned from the mistakes !

so, my opinion:
start with a "small" design, and then work with it, and if you see a problem, that can be solved smarter than just a "extra" function, then make it.
And at some point, try start all over( maby "re" use some code)


KMT dk

I design stuff more on the fly.. and really, it seems to work better than one big design. I mean, some stuff you have to have laid down from the start, memory maps and syscall methods.. but the way I've been doing so far.. I code "somewhat" in mind of the future. Such as when I started multi-tasking code, I didn't put things like ESP0 and paging support into the process structure. Now that I've added ring3 support, it now has ESP0 and I am currently adding paging support so that I can begin loading applications. If I need something else sometime, I'll add that..

well, idk what this really had to do with anything.. lol.. but I like small general designs that as you code you get more specific on the big design..

You shouldn't usually start all over, but much less should you ever delete your work. Even if you find yourself in a situation where you need to start over, it's good idea to keep a copy of the old stuff in case you need to refer to however small fragment of it later.

Unless your development method is to write code, see if it works, and start over if it doesn't (that is, to never debug anything), your previous versions almost certainly contain a lot of accumulated information, which can be helpful later.

Plus I actually don't believe in starting over at all. Even the largest redesigns can usually be done by some form of refractoring. Avoiding feature creep and optimizations is one thing, but unlikely to be the real reason why you fail: more likely you keep adding the features and optimizations without adapting the rest of the design. Once you discipline yourself to always properly refractor rest of the design to accommodate the extra features and optimizations, you gain two benefits:

1. Your code stays cleaner and easier to work with when new features are integrated properly by changing the design rather than by finding a way around it it.

2. Resisting feature creep gets easier when you learn to count the "time-to-restructure" into the cost of adding a feature. I think this is the biggest benefit.

Sometimes you do need a rewrite, but even THEN I'd really reuse as much of the old code as possible.. and usually that's a lot.



Unfortunately, that never works for any larger project, because actually the whole idea of "design first" is rotten: the act of programming itself is part of the act of design, and you don't have a complete design before you have a working program.

That doesn't mean you shouldn't start with the big picture; you probably should. But pretending that you can do complete design, set it into stone, and then go implement that design without having to go back and adjust the big picture is not going to work well: you typically end up with features hacked together to work around the limitations of the design, rather than with a system where the design enables the features naturally.

So I personally suggest: do a big picture design, but as soon as you notice the slightest problem with it, stop writing code, go back to the design, see how much you need to adjust it, and then do the adjustments in code. If you learn to do such adjustments as soon as there is a need for them, it's actually rather easy to keep the code workable no matter what you need to do with it. Sometimes you need small changes, sometimes you need huge changes like turning the whole control flow up-side-down or inside-out. But very rarely you actually need anything as drastic as a full rewrite.

Anyway, that's just the personal thoughts after some 15 years of banging my head against the wall. YMMV.

QFE.

You should always begin with a good but generalized design and idea of what you are constructing first. Do not worry about designing the details at the beginning stages because, in most cases, you may not know what is all needed for the end product.

Also, noticing problems with the design at its earliest stage also tends to make it easier to readjust the design so the problem can be solved with resorting to hacks.

Mystran and Neon,
Thanks for your replies. Look like good advice to me. I understand that the distinction between what a program should do and how it should do it, is not that strict. When a design gets too detailed, the "what" shifts into the "how", and the design may get too restrictive.

What I meant by "knowing in advance exactly what the program should do and do not" is what input the program should accept and what output it should produce. (Don't take that too literally -- in an OS, the "input" could be a system call and the "output" could be a newly running process, for example.)

Roel

"I agree with the OP for psychological reasons. Every time I try a bigger project, I fail because I keep adding features and optimizations in the middle of the process. Then I loose the overall picture and delete my work and start all over.

Knowing in advance exactly what the program should do and do not, really helps me stay focused.
"


This is correct but can work the other way , if you try to get a great design you will always focus on having the best design and elegant code.

IMHO its better to have a strong IPC design , a skeleton overall design and build basic skeleton components , once you have a complete RUNNING structure , remove the Hacks and then flesh out and redesign the individual components. Also flexibility is more important than anything in an early design eg Windows started as Mach 3 and regularly systems move between user and kernel mode ( Video , Sound etc)

Note the communication between components is probably the most important thing to get right esp in a Micro Kernel.

Regards,

Ben

Why do you say that? I personally don't agree, for the reasons given by mystran, as well as others. If you write a design document, you shouldn't need to throw away anything.

Edit: What I mean to say is, back up your statements.