OSDev.org

i havnt worked on ym OS latley due to many things. however, ive gotten a boot laoder to work, and now am stumped. wat shoudl i do first for my OS?

I would do:

1. Screen Output Functions (printf & Co.)
2. Interrupt handling
3. Memory Management
4. Process management
5. Device Drivers

wouldnt it make more sense to write a memory manager after creating a device driver so you can load bytes into memory?

slacker wrote: wouldnt it make more sense to write a memory manager after creating a device driver so you can load bytes into memory?

No, not really. You will need memory management support anyway for writing a File System driver. Memory Manager handles virtual memory, memory allocation & co., you will probably need them when writing your Device Drivers.
So implement Memory Management before File System support.

First comes the lowest level: the interrupt handling code. with out them you barely can read in a keystroke or react on an event triggered by the disk (job done f. ex.).

I have second implemented process management, because it is tightly tied to my interrupt handler code: the stubs all contain process context saving and process restarting functionality.seems to me like the typical micro kernel approach for I also will have some message passing for system calls.

Hi I think memory management is the most basic part of all these things becuase memory is a resource that every part of os needs to have so its management should be done firstly before going through process management, device drivers but some device drivers might be implemented before it but the very basic level like floppy, hd and keyboard drivers. I cannot imagine how I could start writing process manager without having a memory manager... But again these are all my ideas other people might do in some other way...

i did:
0. display stuff on screen
1. interrupts & very basic keyboard hook (not called a device driver, really ... just an interrupt handler and a table of make code that haven't been broken yet )
2. memory management
3. internal system database (might be bound to my design choice .. helps creating modules and provides the same role as /proc)
4. multithreading
5. multiprocessing

device drivers loading, hardware resource accounting, hardware detection etc. are currently under development.
I don't mean that's the right way to do things, but i wanted to focus on modularity first. Hardware management will be run in user space whenever possible ...

My order:
1. Screen display (working printf with %d, %c, %x and /t very very important)
2. Interrupts - Keyboard, Timer
3. malloc() - really simple, just add's the size given to a global variable, incrementing the starting memory address of the next malloc'ed variable - but it works and is expandable. this lets you use malloc early and often, and write a more complicated on later on that uses a mm.
4. Hard disk - because it's fun
5. Processes/Meory

I look at process and memory as which came first, the chicken or the egg? How can one do processes without pages? How can on have pages without a process to manage them? Zen and the art of OS Design.

- Simrook

(re: GT Sphere - Thanks for the code, i ended up getting things to work after redoing all my chs translation routines.)

i should add that formatted output and memory allocation, as well as any needed complicated storage structures like hash tables, dynamic vectors, avl trees, etc. can be trained in Unix on Windows (or whatever your host system is, including DOS so that you can track errors in them before you include them in your kernel.

If you're not 100% sure what your printing function will do, then do not include it in your kernel because it won't help. Of what use is a print if you're not sure that what is printed is what has been asked ?

same for memory : what is a MALLOC good for if you're not 100% sure it will not allocate twice the same zone in any case ...

In my opinion, it is important for every programming art to know exactly what each little piece of code does - and, this is to be brought out, the programmer has to keep at all times the great Picture ot his project in mind - how each little piece fits in the thing - as well as the program flow.

Even in a single processor os, you have just ONE thread of execution at ONE time. Not two, not three, just ONE. Once one 's got this into his mind, he/she finds programming the os much easier. There is of course to be taken care of concurrency issues f.ex. two processes want to have the same ressource at "same" time -> to be handled "comes first served first", and the others have to wait (block).

One point more: os programming is a kind of event driven programming. there comes an event (HW-INT,SW-INT,EXCEPTION), and the corresponding procedures in the kernel are triggered - a message sent, a task scheduled, a task blocked, a message received, a task set ready ... what else you can imagine.

@pype: avl tree == binary tree??

beyond infinity lazy wrote: @pype: avl tree == binary tree??

more or less. AVL trees (stands for the initial of their inventors -- can't remember them) are balanced binary trees in which you can guarantee a maximum depth (and thus a maximum seek time) for a given amount of stored items.

The first thing I implemented was an algoritme that would randomly crash the OS and blame to user for it.

Oooh wait I just thought of it this has already been done. :-[

i just can't resist ...

http://www.nist.gov/dads/HTML/avltree.html

Looks like there is a "Dictionnary of algorithms and Data Structure" somewhere online ... may worth a check if you're in doubt of a technical term while reading something

smurf975 wrote: The first thing I implemented was an algoritme that would randomly crash the OS and blame to user for it.

The screen wouldn't happen to be blue-coloured when this happens?

Personally, I believe that any "death screen" should be violet-coloured...black's too obvious and cliched as the colour of death and blue's just too "friendly" a colour for death...but violet is a soft yet authoritative colour (the colour of priests' and Kings' / Queens' robes), which seems perfect as a gentle but final way of saying "sorry, but your computer has blown up"...

Seriously, though, _never_ blame the user for anything...ever...always have the machine apologise for being stupid, even if it actually was the user's fault...a machine has no pride so why prioritise that over deeply, deeply annoying the hell out of your users? Doesn't make sense to do that...graciously accept all blame, even the stuff that isn't really the OS's fault...give the user the feeling that they are all powerful and it's the OS that's dumb and faulty...yes, that's all just psychological candy for the user but that is a valid reason to do this in itself..."being user friendly" and all that jazz...plus, simply, chances are that it _was_ the OS's fault and not the users, don't presume to patronise your users and assume mistakes "must" be their fault

For example, whenever I see that "you should have shutdown the PC" message on Windows' scandisk, I just want to throw something through the monitor...I _always_ shutdown properly...if that message ever appears, it was _Windows_ that messed up, not me...bloody arrogant computer...that's not the way to go about getting on my good side...and you don't want to be invoking my wrath...not a good idea...hehehe

Beth