Hi, can anybody help me?
I want to know peoples oppinions on writing a kernel for my os. My os is called Meganet, I'v been trying to get started for years. I have a boot loader but no kernel for it to load. What I want to knowis what language to use and how?
Kernel
-
Tim
Re:Kernel
Language: Most people use C, or C++
How: The normal way; writing statements in a text file, then compiling and linking.
If you could be persuaded to use GRUB instead of your own boot loader, you'd find a simple kernel in the GRUB distribution which you can build from. If you're sticking with your own boot loader, then the way you build your kernel depends on how flexible your loader is, and what it expects to load.
How: The normal way; writing statements in a text file, then compiling and linking.
If you could be persuaded to use GRUB instead of your own boot loader, you'd find a simple kernel in the GRUB distribution which you can build from. If you're sticking with your own boot loader, then the way you build your kernel depends on how flexible your loader is, and what it expects to load.
Re:Kernel
How: Learning.
Many people start their own OS project because they think it's fun, get stuck very early, and get into the habit of "asking themselves through" from problem to problem. It's a habit that dies hard once you go down that road, because it's so "easy" for you to have others do the thinking.
That's no offense intended, but it can be a pain for those others...
Before you start your own OS, be sure you have a *good* understanding of how other OS' work internally, what you would like to copy / make different, and how to achieve it.
To this end, the "Usual Suspects" (tm) like Tanenbaum's books, Bona Fide, the OSDev FAQ, Linux v1.0 etc. can be of help. (You'll find many references in the sticky threads on top of this forum's thread list.)
You should also have a very good understanding of the language of choice, and at least a fundamental understanding of Assembler (including how to use the tools). In no case should an OS be your first major programming effort. You will be in deep pain otherwise, sooner or later.
Get and use one of the available bootloaders (GRUB probably being the most popular and powerful). Don't roll your own. It's a challenging task, and you can't do anything "better" there than the existing tools already provide. Most of the stuff you learn you'll never need again, unless you write another bootloader some day.
Many people start their own OS project because they think it's fun, get stuck very early, and get into the habit of "asking themselves through" from problem to problem. It's a habit that dies hard once you go down that road, because it's so "easy" for you to have others do the thinking.
That's no offense intended, but it can be a pain for those others...
Before you start your own OS, be sure you have a *good* understanding of how other OS' work internally, what you would like to copy / make different, and how to achieve it.
To this end, the "Usual Suspects" (tm) like Tanenbaum's books, Bona Fide, the OSDev FAQ, Linux v1.0 etc. can be of help. (You'll find many references in the sticky threads on top of this forum's thread list.)
You should also have a very good understanding of the language of choice, and at least a fundamental understanding of Assembler (including how to use the tools). In no case should an OS be your first major programming effort. You will be in deep pain otherwise, sooner or later.
Get and use one of the available bootloaders (GRUB probably being the most popular and powerful). Don't roll your own. It's a challenging task, and you can't do anything "better" there than the existing tools already provide. Most of the stuff you learn you'll never need again, unless you write another bootloader some day.
Every good solution is obvious once you've found it.
-
Ozguxxx
Re:Kernel
Re:Get and use one of the available bootloaders (GRUB probably being the most popular and powerful). Don't roll your own. It's a challenging task, and you can't do anything "better" there than the existing tools already provide. Most of the stuff you learn you'll never need again, unless you write another bootloader some day.
DONT Get and DONT use one of the available bootloaders (GRUB probably being the most popular and powerful, ALSO UNWANTEDLY PROFESSIONAL). DO roll your own. It's a challenging task, BUT you CAN do SOMETHING ENOUGH FOR YOURSELF RATHER than the existing tools already provide. Most of the stuff you learn you'll LEARN A LOT, unless you write another bootloader some ANOTHER day.
I have written some binary code sequence which can be called a "boot loader" for pathetic kernel I am dealing with, which is of course cannot be %.0000001 as capable as GRUB, however it is doing my job already. And I am happy with 100% my code, and ready to deal with its future problems...
-
Tim
Re:Kernel
That's bad advice, IMNSHO. Sure, you learn a lot by writing your own boot loader before writing the kernel. But you learn a lot by writing a Tetris game before writing the kernel. The skills involved in writing boot sector code are just as irrelevant to real kernel development as the skills required to write Tetris.Ozgunh82 wrote:DONT Get and DONT use one of the available bootloaders (GRUB probably being the most popular and powerful, ALSO UNWANTEDLY PROFESSIONAL). DO roll your own.
What does writing boot loaders teach you?
- How to write code to fit into 512 bytes. Such micro-optimisation is dangerous for real programs without such restrictions on size, as small code is usually ugly code.
- How to interface to the BIOS. You won't need this after the boot sector is written.
- Assembly coding. Not necessary unless you really want to write the whole OS in assembler (which is a different rant).
- 16-bit assembly coding. Not necessary -- ever.
Most 'failed' OS developers that I've seen have started out trying to write the world's best boot loader, got bored, and given up. I'm not saying people don't give up if they start at the kernel stage, but at least they get further than the boot loader people.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Kernel
consider an ambitious objective (landing a man on the moon) ... What is the first step needed to land a man on the moon ? moving the rocket from the factory to the launcher platform. Will you start solving the problem with this end ? no!
Making sure you can get out of the Earth gravity with existing engine is far more important, as is making sure that there are materials that can keep your rocket in one piece once it'll be in outer space ...
Everything depends on where your motiviation is. If you want to write a bootloader, go for a bootloader. If you want to write a GUI, pick up an existing OS and write an alternative GUI for it ...
The impact of the bootloader choice on the resulting OS is virtually null once the OS is done, and you know what ? about 90% of your users will *not* use your home-made bootloader, because they'll rather use a configurable multi-os bootloader or because they'll not like the splash screen shipped with your loader.
Making sure you can get out of the Earth gravity with existing engine is far more important, as is making sure that there are materials that can keep your rocket in one piece once it'll be in outer space ...
Everything depends on where your motiviation is. If you want to write a bootloader, go for a bootloader. If you want to write a GUI, pick up an existing OS and write an alternative GUI for it ...
The impact of the bootloader choice on the resulting OS is virtually null once the OS is done, and you know what ? about 90% of your users will *not* use your home-made bootloader, because they'll rather use a configurable multi-os bootloader or because they'll not like the splash screen shipped with your loader.
-
Ozgunh82-Invisible Mode-
Re:Kernel
Hey, I think it will be a good idea to write a tetris game before writing an OS, well it will surely make people learn lots of programming stuff. An analogy with a ootloader, a bootloader can make people learn lots of things about 16 bit assembly(as Tim said) and also some intro to os programming. I dont mean that bootloader is a must to kernel programming but it might a good and ABSOLUTELY PAINFUL adventure to trying to do it in your own way. Well on the other hand, most of us are motivated to write OUR OWN CODE, right?
I dont agree with Tim in the way that bootloader is just squeezing 512 bytes of code, IMHO writing a bootloader is trying to get around that problem by adding 2nd step loader to actual 512 byte code. Surely you will need a boot SECTOR, but it can be as a primitive binary code sequence that just does a jump to second stage, which will be actual boot LOADER. I think GRUB does it in that way. (correct me if Im wrong)
Also I dont agree with Tim about bootloader being a pure 16 bit code. Since grub gets into pmode, it is in fact doing 32 bit programming, right? Also aint 16 bit asm programming ever necessary? I mean for ins. in programming vm86 tasks dont you ever use 16 bit assembly? again, I am not sure, correct me if im wrong.
I think blaming authors of grub about bugs in grub is not sth to justify using grub, I mean suppose there is a bug in grub, then you will have to wait until it is debugged to make your kernel work functionally again.
You might be right about maintenance of bugs in overall os. I mean it will surely be harder to both keep track of bugs in loader and os itself but, PERSONALLY I think it is worth it...
I think trying to write a bootloader might be a good prerequisite for starting an os, in the sense that if people get exhausted and they give up writing os after REALLY failing to write a bootloader, than let them fail os development, I mean they really cannot handle the workload of future problems. BTW, I do not know about definition of bootloader. Or what a bootloader formally is. I am not sure where a bootloader finishes and where actual kernel starts, I think this is a matter of personal taste, (once upon a time I checked about multiboot specification it gives some ideas but not completely...) I mean since it does not have a complete definition, you can call anything that is working as a bootloader, as long as it does what you want.
I dont agree with Tim in the way that bootloader is just squeezing 512 bytes of code, IMHO writing a bootloader is trying to get around that problem by adding 2nd step loader to actual 512 byte code. Surely you will need a boot SECTOR, but it can be as a primitive binary code sequence that just does a jump to second stage, which will be actual boot LOADER. I think GRUB does it in that way. (correct me if Im wrong)
Also I dont agree with Tim about bootloader being a pure 16 bit code. Since grub gets into pmode, it is in fact doing 32 bit programming, right? Also aint 16 bit asm programming ever necessary? I mean for ins. in programming vm86 tasks dont you ever use 16 bit assembly? again, I am not sure, correct me if im wrong.
I think blaming authors of grub about bugs in grub is not sth to justify using grub, I mean suppose there is a bug in grub, then you will have to wait until it is debugged to make your kernel work functionally again.
You might be right about maintenance of bugs in overall os. I mean it will surely be harder to both keep track of bugs in loader and os itself but, PERSONALLY I think it is worth it...
I think trying to write a bootloader might be a good prerequisite for starting an os, in the sense that if people get exhausted and they give up writing os after REALLY failing to write a bootloader, than let them fail os development, I mean they really cannot handle the workload of future problems. BTW, I do not know about definition of bootloader. Or what a bootloader formally is. I am not sure where a bootloader finishes and where actual kernel starts, I think this is a matter of personal taste, (once upon a time I checked about multiboot specification it gives some ideas but not completely...) I mean since it does not have a complete definition, you can call anything that is working as a bootloader, as long as it does what you want.
Re:Kernel
You have pretty strong opinions on this matter, which is OK with me. But I think you are just wrong in one regard:
GRUB is an official GNU project, and falls under the General Public License. That means, if there's a bug in it, just rip the source apart and fix it. If you send a patch to the maintainers, chances are they'll include it in the mainline.
As GNU / GPL project, I don't see how GRUB could be "unwantedly professional", unless you mean professional as in "very good code".
And to get back to the original poster, if you really want to roll your own bootloader, why not make it a Multiboot compliant one. The Multiboot specification would allow you to use any other compliant bootloader (e.g. GRUB...) as a drop-in replacement should you become disenchanted with your own, and - perhaps more importantly - if you get to implement some really nifty never-seen-before features, people could use your bootloader as a drop-in replacement for GRUB... ;D
(Multiboot doesn't specify anything you wouldn't do sooner or later anyway, it just specifies how to do it, so OS' and bootloader have a defined hand-over interface.)
GRUB is an official GNU project, and falls under the General Public License. That means, if there's a bug in it, just rip the source apart and fix it. If you send a patch to the maintainers, chances are they'll include it in the mainline.
As GNU / GPL project, I don't see how GRUB could be "unwantedly professional", unless you mean professional as in "very good code".
And to get back to the original poster, if you really want to roll your own bootloader, why not make it a Multiboot compliant one. The Multiboot specification would allow you to use any other compliant bootloader (e.g. GRUB...) as a drop-in replacement should you become disenchanted with your own, and - perhaps more importantly - if you get to implement some really nifty never-seen-before features, people could use your bootloader as a drop-in replacement for GRUB... ;D
(Multiboot doesn't specify anything you wouldn't do sooner or later anyway, it just specifies how to do it, so OS' and bootloader have a defined hand-over interface.)
Every good solution is obvious once you've found it.
-
Curufir
Re:Kernel
Actually I can think of one very good reason to write your own bootloader, and that is if you are using some custom filesystem that GRUB (And others) can't interpret. Since GRUB (And others) will quite happily chainload a partition's bootsector you don't restrict your users to not multi-booting.
If you aren't creating your own filesystem then the bootsector becomes fairly irrelevant. It's fun to see how much you can squeeze into 512 bytes (So far I have FAT12 with multiple files and directories
), but it makes sense to use someone else's code (Eg GRUB) and get on with coding the actual OS if you don't find writing bootsectors fun.
If you aren't creating your own filesystem then the bootsector becomes fairly irrelevant. It's fun to see how much you can squeeze into 512 bytes (So far I have FAT12 with multiple files and directories
), but it makes sense to use someone else's code (Eg GRUB) and get on with coding the actual OS if you don't find writing bootsectors fun.-
Schol-R-LEA
Re:Kernel
While it is important to understand what is going on during the boot process, writing a bootloader is not the best starting point for writing an OS. I learned this the hard way myself. I wouldn't discourage someone from trying to write one, but at the same time, I wouldn't recommend it, either. Writing a bootloader simply isn't relevant to OS design as a whole, and in fact can be very misleading.
In any case, Kieran has stated that the bootloader he's using wasn't his own design, anyway. The whole topic is meaningless for this discussion.
As for what language to use, the short answer is, C and assembly. The longer answer is, a small amount of assembly is necessary, but beyond that, the kernel can be written in any language suited for low-level systems programming. That is, it should be a language with a compiler which can produce efficient, stand-alone code (i.e., it doesn't require any pre-existing system calls or libraries) and supports linking of separately compiled/assembled code. It is useful, but not necessary, for the language to have facilities for low-level operations such as shifts, bitwise AND and OR, etc. It is possible to mix more than one language (indeed, it is necessary to, if you aren't writing it entirely in assembly), but the more languages used, the more confusing it is likely to become.
Outside of the kernel proper, the remainder of the system can be written in any language(s) you wish. Some OSes (ie.g., JavaOS, UCSD Pascal, Smalltalk-80) have only a very minimal kernel/interpreter, on top of which the rest of the system runs. Most others are written primarily in the same language(s) as the kernel code. The choices are limited only by the availability of suitable assemblers, compilers or interpreters.
That having been said, as a practical matter, the high-level language most available for kernel programming is C; C++ is an option, but may present problems with overhead (RTTI and exception handling require a lot of support). The next most common choices are the Pascal family languages (Pascal, Modula-2, Oberon), Ada, and FORTH (which is more or less the only interpreted language suitable for kernel programming). Compiled LISP is a popular choice for a small minority (including myself), but unless you intend to design your own dialect and write a compiler for it, it (and most other languages) is not a realistic option.
In any case, Kieran has stated that the bootloader he's using wasn't his own design, anyway. The whole topic is meaningless for this discussion.
As for what language to use, the short answer is, C and assembly. The longer answer is, a small amount of assembly is necessary, but beyond that, the kernel can be written in any language suited for low-level systems programming. That is, it should be a language with a compiler which can produce efficient, stand-alone code (i.e., it doesn't require any pre-existing system calls or libraries) and supports linking of separately compiled/assembled code. It is useful, but not necessary, for the language to have facilities for low-level operations such as shifts, bitwise AND and OR, etc. It is possible to mix more than one language (indeed, it is necessary to, if you aren't writing it entirely in assembly), but the more languages used, the more confusing it is likely to become.
Outside of the kernel proper, the remainder of the system can be written in any language(s) you wish. Some OSes (ie.g., JavaOS, UCSD Pascal, Smalltalk-80) have only a very minimal kernel/interpreter, on top of which the rest of the system runs. Most others are written primarily in the same language(s) as the kernel code. The choices are limited only by the availability of suitable assemblers, compilers or interpreters.
That having been said, as a practical matter, the high-level language most available for kernel programming is C; C++ is an option, but may present problems with overhead (RTTI and exception handling require a lot of support). The next most common choices are the Pascal family languages (Pascal, Modula-2, Oberon), Ada, and FORTH (which is more or less the only interpreted language suitable for kernel programming). Compiled LISP is a popular choice for a small minority (including myself), but unless you intend to design your own dialect and write a compiler for it, it (and most other languages) is not a realistic option.
Re:Kernel
I'd daresay that it would still be easier to implement a new stage1.5 (file system module) for GRUB, capable of reading your filesystem, and still leaving the details of partition tables, A20, protected mode enabling, network booting, reading memory maps from the BIOS etc. (i.e., the ugly stuff) to GRUB.Curufir wrote: Actually I can think of one very good reason to write your own bootloader, and that is if you are using some custom filesystem that GRUB (and others) can't interpret.
I doubt the GRUB maintainers would object to adding a new file system module to their mainline.
Every good solution is obvious once you've found it.
-
KieranFoot
Re:Kernel
Hey ::) Does anybody think it would be possible to dissasemble the qbasic 4.5 base library (QB45.lib) and reprogram the print, file, graphics and other routines so that in the end i would be able to use qbasic to write code for my kernel???
It could be possible, With lots of help...
It could be possible, With lots of help...