OSDev.org

Hi everybody... I know that you might get tired of seeing the old same question but here it is, please answer it for me: I have recently completed tracing a boot strap loader, it looks fine to me and I think it will do the things that I want for my real mode operating system. Why I do not use pmode is a long story... Anyway. My question is: Where should I go next? I mean in what area should I study? File system? Kernel? Memory management? Processes, threads ??? I got stuck here, I need advices about this subject... Thanx in advance to soul who read this thread...

Hm, a real mode OS won't do it. You won't be able to access data over 1MB (I presuppose you don't enable A20), and there won't be any good memory protection... . Switch to PMode, it isn't that hard!

After that, I would first of all begin by writing some basic string functions (kprintf, printf, putchar), memory functions (memmove, memcopy), etc. Next, I would try to implement processes, because it would be stupid to implement a file system without using it (running file = process). Of course, you can first implement some memory management like paging and so on. This is up to you...

regards,
A. Blessing

Agreed... using protected mode is well worth the learning and debugging you put in at first. Programming for protected mode is so much easier than real mode: there are virtually no restrictions on what you can do.

Switching to PMode is simple. It can take as little as 40 lines of assembler, including the descriptor tables! PMode will allow you to access a full 4GBytes of RAM, open Paging support, help with multi-tasking... Read mode is sad in comparison... You will have to deal with constantly switching to different segments... Also, PMode will make memory management more efficient.

Why else would everyone else on this forum use Protected mode?(Sorry to single you out - for your own good, and for your OS)

Ozguxxx wrote: Hi everybody... Where should I go next? I mean in what area should I study? File system? Kernel? Memory management? Processes, threads ???

Well, as both file system and process require some dynamic allocation (usually), the memory management is a good place to start (at least a kalloc function). It is also possible to live with a very reduced mman (i.e. top/down allocator) and start dealing with task switching & semaphores earlier.

Imho, the right place to go on is the development of some I/O components (display & keyboard input), not necessarily meaning that you'll have a complete stdin and stdout, but at least a "kprint" and a installhandler(key, function) for further debugging.

What pmode/rmode concerns, do not select a mode based on what *you* prefer but on what *your OS* will prefer.