Hmm, yes. I know the feeling. It's very frustrating in the extreme when you read every book you can find on OS development and they all dance around the garden when it comes to actually writing some code to see the theory in action.Furqan_Ullah wrote: Hi,
I want to write an operating System from scratch. I have just read some info and faq about the OS and got some idea. I want to write Boot Loader, Simple Scheduler, File manager, memory manager and a simple shell. I have a book that is Operating System Concepts, 5th Edition. But the main problem is, that book is havily based on heavy theories and there is no such path to follow.
May I suggest grabbing a copy of "Just For Fun: The Story of an Accidental Revolution" by Linus Torvalds. There's a good 70 pages or so in there about how he goes about writing his OS from scratch. The big secret is system calls. Basically everything is built on a small selection of these, notably Open(), Close(), Read() and Write(). Everything is obviously built on this foundation (of course others like Fork(), Exec(), WaitX() etc) because all processes use the kernel services. Unless they are using pure user-space code like some C library functions, the code paths eventually find their way down to system calls in the kernel.
To really understand this you need to have some knowledge of Unix and POSIX, the so-called Portable Operating System Interface. Also realise that Read() and Write() are abstractions where the "file descriptor" can be for a disk file, the console or keyboard, a network socket or practically any device in the system.
First up, your Write() can write directly into the video memory at 0xB80000. Your Read() can grab input from the keyboard. (You'll need an interrupt routine or task for the keyboard obviously). In Read() when you eventually dish out file descriptors and want to read from files, you can implement a file system inside a RAM disk to start with. Same for Write(). Once you have your filesystem code debugged and it's somewhat safe to use it, you can really read and write with the disk. Make sure you stick to your partition if your homebrew OS lives with other OSes!
You will need copies of the Intel Architecture manuals if you are using an X86 (and even if you aren't, grab a cheap old 486 to experiment with. The Intel docs are actually quite good and readable.)
Start off without any tasks or serious I/O, using a function that writes into video memory to print stuff out and examine variables here and there. I HIGHLY recommend you use an existing bootloader (hint: GRUB) for the time being until you get used to writing standalone code. Remember your code is the only code running on the bare metal in OS development. It takes a little while to really get used to it. If you want to write your own bootloader and that's OK, you can do it when you get your OS up and running.
As for development on Windows, you can use MinGW or Cygwin. Microsoft tools are not exactly easy or obvious to use for OS development. I have Visual Studio .NET 2003 and the tools are vastly improved over Visual C++ 6 (i.e. the C compiler, linker etc) but you will end up doing manual patching in certain places which can get to be a bit of a headache after a while. For instance the MS linker can specify the origin or starting address of code (e.g. 0x100000 for a kernel loaded at 1MB) but getting the end address and stuff is not obvious. Also I don't know how to control the placement of sections in the binaries like you can with GNU LD using scripts to automate that and export symbols that tell you where your sections start and end that you can refer to in your assembler or C code.
Windows is not an especially great environment for OS development, but usable with MinGW or Cygwin. Forget TASM, it's useless for OS development.
Also, make sure you get a copy of Bochs or VMware or both to start with. You can run your kernel inside Windows without rebooting all the time. Bochs is a bit of a pain because the timing is all off, but VMware is superb!
Good luck!
While it won't help with OS development per se, it will give you a very good sense of how all the parts of many existing systems go together.