i get the idea of a kernel now i just need hiw to get a command promt or somthing i need a program loader would i need a keyboard driver to do this stuff
then how do i get a graphical interface working and a mouse,network drivers,and all that what should i do
whats next
-
Schol-R-LEA
RE:whats next
That's a big list of questions that boil down to: how do I write my OS?
But that's OK, this is what the forum is here for.
To start, you'll need to write the kernel itself, or at least figure out how everything shoud fit together. This is itself a pretty big task, with a lot of decisions and few hard and fast rules. The one rule, which even then is a subject of great debate, is to keep things as modular as you reasonably can. The main premise behind Microkernels is to increase modularity compared to the traditional monolithic kernel; exokernels take this to the extreme of having *nothing* in the kernel at all, except the code for multiplexing hardware resources. How you want to handle the issue is your own call.
You have to choose how to implement it too, and in particular, what language to code most of it in. Some of it *must* be in assembly, but it should be possible to minimize the amount of assembly code if you prefer to. While C may seem a no-brainer, given it's simplicity, flexibility and efficiency, some programmers prefer to trade those issues off for stability and/or higher levels of abstraction; Java, Pascal, Ada, Smalltalk and Scheme each have small but active OS code bases. C++ is less common than one might expect, but is not unknown. Still, C seems to be the overwhelming choice these days.
As for device drivers, well, beyond a certain basic level, you're on your own. Every OS has it's own way of working with device drivers. Oh, there now is a standard, the Uniform Driver Interface, but it is extremely difficult to implement and has been generally ignored by professionals and amateurs alike. While there exst examples of how to write a simple driver for most of the common devices - see the Links section on the masthead above, especially the OS Resources Center - actually writing one that will work with your OS is up to you, and depends on how you design your driver interfaces and so on.
Note that you will want certain devices to have at least minimal support at the kernel level, for the boot up process, kernel panics and so forth; but aside form these, you will probably want the drivers as separate from the OS as you can make them.
At this point, you are almost ready to start writing code. The question then becomes how to begin.
The most common mistake made by OS designers is to begin at the beginning; i.e., the bootstrap loader. This is not a wise choice. The boot sector is the shoals on which 99.9% of all OS projects get sunk on. Now, dont get me wrong: it is not a bad idea to write a boot loader, as a learning experience, if only because you get a clearer idea of what actually happens at start up. Writing your own boot loader for your OS, however, is an act of futility. Unless your OS has some very odd requirements, you are much better off using an existing one like GRUB or BING. Take my word on this: it took me years of puttering around with it to get mine to work even as a test, and all along I knew I wasn't going to use it for my final OS design.
It is better by far to concentrate on the overall design issues of the kernel, driver interface, etc. first, and then fill in the low-level code, than the reverse. In some cases, you can write parts of the OS code (the shell in particular) as applications under your development platform first, then prot them to your OS. This let's you leverage the development platform as a testbed as well. While on that subject, I should point out that you will want to use two computers, one of which is set aside exclusively as a testbed, and that you will also want to test everything using an emulator like Bochs before runing it on the testbed machine. This both speeds up development and helps you avoid mangling you devlopment machine.
True, these last two points may seem like I'm saying, "Do what I say, not what I do". However, I don't consider myself to be writing my OS yet; I'm learning *how* to, by writing smaller parts one by one, and fitting them together into a sort of frankensystem. Once I'm satisfied that I know how to, *then* I will start actually writing my intended design. Part of this, to me, means being able to explain what I've done to other, which is the reason I came up with the LoIS Project.
Lastly, take to heart three ideas from the Extreme Programmers: write your documentation first, then your test scripts, then your prototype, then last write your working code; and run all tests, especially integration tests, with each new change.
But that's OK, this is what the forum is here for.
To start, you'll need to write the kernel itself, or at least figure out how everything shoud fit together. This is itself a pretty big task, with a lot of decisions and few hard and fast rules. The one rule, which even then is a subject of great debate, is to keep things as modular as you reasonably can. The main premise behind Microkernels is to increase modularity compared to the traditional monolithic kernel; exokernels take this to the extreme of having *nothing* in the kernel at all, except the code for multiplexing hardware resources. How you want to handle the issue is your own call.
You have to choose how to implement it too, and in particular, what language to code most of it in. Some of it *must* be in assembly, but it should be possible to minimize the amount of assembly code if you prefer to. While C may seem a no-brainer, given it's simplicity, flexibility and efficiency, some programmers prefer to trade those issues off for stability and/or higher levels of abstraction; Java, Pascal, Ada, Smalltalk and Scheme each have small but active OS code bases. C++ is less common than one might expect, but is not unknown. Still, C seems to be the overwhelming choice these days.
As for device drivers, well, beyond a certain basic level, you're on your own. Every OS has it's own way of working with device drivers. Oh, there now is a standard, the Uniform Driver Interface, but it is extremely difficult to implement and has been generally ignored by professionals and amateurs alike. While there exst examples of how to write a simple driver for most of the common devices - see the Links section on the masthead above, especially the OS Resources Center - actually writing one that will work with your OS is up to you, and depends on how you design your driver interfaces and so on.
Note that you will want certain devices to have at least minimal support at the kernel level, for the boot up process, kernel panics and so forth; but aside form these, you will probably want the drivers as separate from the OS as you can make them.
At this point, you are almost ready to start writing code. The question then becomes how to begin.
The most common mistake made by OS designers is to begin at the beginning; i.e., the bootstrap loader. This is not a wise choice. The boot sector is the shoals on which 99.9% of all OS projects get sunk on. Now, dont get me wrong: it is not a bad idea to write a boot loader, as a learning experience, if only because you get a clearer idea of what actually happens at start up. Writing your own boot loader for your OS, however, is an act of futility. Unless your OS has some very odd requirements, you are much better off using an existing one like GRUB or BING. Take my word on this: it took me years of puttering around with it to get mine to work even as a test, and all along I knew I wasn't going to use it for my final OS design.
It is better by far to concentrate on the overall design issues of the kernel, driver interface, etc. first, and then fill in the low-level code, than the reverse. In some cases, you can write parts of the OS code (the shell in particular) as applications under your development platform first, then prot them to your OS. This let's you leverage the development platform as a testbed as well. While on that subject, I should point out that you will want to use two computers, one of which is set aside exclusively as a testbed, and that you will also want to test everything using an emulator like Bochs before runing it on the testbed machine. This both speeds up development and helps you avoid mangling you devlopment machine.
True, these last two points may seem like I'm saying, "Do what I say, not what I do". However, I don't consider myself to be writing my OS yet; I'm learning *how* to, by writing smaller parts one by one, and fitting them together into a sort of frankensystem. Once I'm satisfied that I know how to, *then* I will start actually writing my intended design. Part of this, to me, means being able to explain what I've done to other, which is the reason I came up with the LoIS Project.
Lastly, take to heart three ideas from the Extreme Programmers: write your documentation first, then your test scripts, then your prototype, then last write your working code; and run all tests, especially integration tests, with each new change.