OSDevver wrote:I want to start writing my OS, well do i start from Linux or anyother OS for staters like me. Also could anybody kindly tell where do i get a full Linux system coz when i visited
www.kernel.org, and downloaded a 1.9kb file(well the link said something like"click here for the kernel" or so), also a kind request i want a graphical version.
P.S:just tell me which file in a OS source code should i refer to?I am blank
A full Linux system is a distribution, which contains all the extra software that you need to use Linux, because at kernel.org you will only get the kernel (well, there is a mirror of some distributions, but there are lots elsewhere) which by itself is not useful, unless you have been staring at hand-optimised and somewhat obfuscated system-level code for a good decade or so.
Anyway, I asked this same question myself of Alan Cox, an early Linux hacker who eventually ended up at RedHat, perhaps some ten years ago if I recall correctly. He told me Linux 0.1 was useless as a starting point to learn how to write a kernel. In retrospect I agree with that. I second the recommendations to start much, much smaller.
To begin writing an O/S (or even just a kernel), you will need to know a lot about the machine you will write your O/S for, and where to find hardware programming specifications, like the ATA/ATAPI spec for PATA disks, programming the keyboard, clock and things like that. Plus you must have the Intel CPU manuals on hand, assuming you want to target the x86 architecture. You must have a firm command of the C language because most O/S code worth learning from is written in C. You must also have a passing knowledge of x86 assembly language. You should understand pointers, and understand in a general sense PC (or whatever platform) architecture. For example the chipsets you will typically find in them and how they work together.
You should have a grasp of how to debug code, and know the difference between object code and linked executable code. You should know the different number representations like hexadecimal, binary, octal and decimal and know how to convert between them. You should be prepared to disassemble code and read a lot of hexadecimal and know what the difference between executable and data sections are in the various executable file formats.
You should read and understand a few books on O/S theory and concepts for the "big picture" before attempting to write code, like scheduling, memory management, file systems, multiprogramming, interprocess communication and a lot more.
If you've never written system level programs before, using just the kernel's API (the system calls like the bare read(), write(), open(), close(), etc.) then you should write lots of programs that exercise those functions and program just above the kernel level.
You should understand that you're on your own when writing a kernel, so there's no C library or any other library available unless you make one yourself and put it in your kernel. So the luxuries of printf() and so on are not available unless you write them yourself or "port" a C library to your kernel or O/S. Of course, you should be familiar about the difference between a kernel and an O/S.
Unfortunately, there's also a lot more, like bootstrapping or using an existing bootloader, what can happen if you have more than one processor on your system and how to deal with true parallel execution of processes or tasks, and you should know about interrupts, traps and exceptions.
I know this sounds daunting, but it will be extraordinarily difficult, if not impossible, to write an O/S without knowing (at least) these things and perhaps also having been at least a hobbyist programmer for five or more years.
I'm saying this because it's difficult to help if the poster doesn't give any background information on what they already know. If you're a beginning programmer and don't have any knowledge of computer architecture and interfacing with the hardware, you're staring down many years of hard work, sweat and blood. Don't let this discourage you: if you really want to write an O/S, you can get there, and all the years of learning and head banging will be worth it. But you need to be prepared for a long journey and don't let yourself be discouraged by failure after failure.
Having said that, once you have a knowledge of the environment you'll be programming in (you're on your own, without libraries and such, on "the bare metal") then you should start with tutorials like this one:
Bran's Kernel Development Tutorial
... and lots of others.
In summary: be familiar with already working systems, especially UNIX-like systems because they have smaller and somewhat more elegant APIs than Windows, don't try to design a new O/S without cloning part of one first (in my opinion), have the manuals for your architecture handy at all times, be very familiar with C, be somewhat familiar with assembly language, know the tools you will work with (compiler, assembler, linker, debugger, other utilities), know your environment (the bare metal), know the theory behind O/S's and a bit of history about them, know where to download specifications for standardised hardware, be familiar with pointers and little details like that, understand concurrent processing on one CPU and true parallel processing and how to deal with it (I still have problems here myself and I've been at O/S developing on and off for 10 years), know about executable file formats, booting, getting to the stage where you can run user programs, know about interrupts, traps and exceptions, memory management, file systems, and human-computer interaction (keyboard, the interface, such as a shell) and perhaps more.
I hope this doesn't put you off!
But be prepared for hard work, and probably many years of it.
