Beginner Mistakes: Difference between revisions
| [unchecked revision] | [unchecked revision] |
(Formatted some more, and added a oart about "emulating every OS in the world.") |
(Renamed the categories, added some things, etc.) |
||
| Line 8: | Line 8: | ||
== Scope == |
== Scope == |
||
=== Dealines === |
|||
=== I have to write an OS for my studies, deadline is in three months... === |
|||
The Linux kernel took over one year of very dedicated work to get into a semblance of usefulness, and all Linus Torvalds did was ''mimic'' existing and well-documented behaviour to get an already-existing userspace to run on it. |
Whether for university, hobby, or commercial uses operating system development takes time. The Linux kernel took over one year of very dedicated work to get into a semblance of usefulness, and all Linus Torvalds did was ''mimic'' existing and well-documented behaviour to get an already-existing userspace to run on it. Moreover, for every project as successful as Linux, there are literally ''hundreds'' of projects that consumed a man-year or more of work without ever getting as far as hosting a functional shell. |
||
Therefore, plan a reasonable road map of what you want to get done. Do not assume that in 3 months your OS will have a GUI and voice recognition, because operating system development does not contain any RAD tools in it at all. In fact, it is completely void of them. (''void''. It's a joke. Get it?) |
|||
It took Linux almost a decade to really take off and attract a developer community. |
|||
=== Community Projects === |
|||
And for every project as successful as Linux, there are literally ''hundreds'' of projects that consumed a man-year or more of work without ever getting as far as hosting a functional shell. |
|||
| ⚫ | |||
=== I will build a team of people... === |
|||
=== Commercial OSDEV === |
|||
| ⚫ | |||
There really is no such topic. OSDEV will probably never land you a job. (As shown in the "Jobs" section of the forum.) |
|||
And that is not due to a lack of ''need''. |
|||
| ⚫ | |||
== Design == |
== Design == |
||
=== GUI Design === |
|||
=== I have designed an OS, here's a picture... === |
|||
It will likely take you several years, starting from scratch, to get to the point where you actually do anything GUI-related. |
It will likely take you several years, starting from scratch, to get to the point where you actually do anything GUI-related. |
||
| Line 30: | Line 32: | ||
''functionality'', and that isn't expressed in mock-up graphics. If your aim is creating a better look instead of a better OS, consider implementing an X Window Manager instead of a whole OS. |
''functionality'', and that isn't expressed in mock-up graphics. If your aim is creating a better look instead of a better OS, consider implementing an X Window Manager instead of a whole OS. |
||
=== OS Emulation === |
|||
=== My OS will emulate Mac OS, Windows, Linux, and every other OS out there! === |
|||
''My OS will be able to run programs from Windows, Mac OS, Linux, and even PDP-11 programs!!!'' |
|||
| ⚫ | I'm sorry to burst your bubble, but it probably won't. Emulating even just a single system takes years of work, especially when it's proprietary, such as Windows or Mac OS. (Linux is probably the easiest out of the |
||
| ⚫ | I'm sorry to burst your bubble, but it probably won't. Emulating even just a single system takes years of work, especially when it's proprietary, such as Windows or Mac OS. (Linux is probably the easiest out of the four.) So instead of focusing on emulating other systems, focus on your own. Design it, develop it, and be friends with it. |
||
| ⚫ | |||
=== Naming === |
|||
=== I have cool ideas, but i need a cool name for it. === |
|||
Naming is usually the last problem to be solved, even while we all wish for a cool name to our cool concept. Since the "coolness" of a name is a matter of taste, we cannot help you finding it. Moreover, if you tie your project name to a certain feature, you might discover somewhere down the road that no concept is perfect and that you might want to change what you initially thought a key feature. Nothing would be more stupid not to evolve just because |
Naming is usually the last problem to be solved, even while we all wish for a cool name to our cool concept. Since the "coolness" of a name is a matter of taste, we cannot help you finding it. Moreover, if you tie your project name to a certain feature, you might discover somewhere down the road that no concept is perfect and that you might want to change what you initially thought a key feature. Nothing would be more stupid not to evolve just because |
||
you 'want to stick to a name'... |
you 'want to stick to a name'... |
||
=== Programming Languages === |
|||
=== I want to write an OS in QBasic... === |
|||
Some languages are well suited to write an OS kernel, others are less so. Read the page about [[Languages | using some language other than C]]. |
Some languages are well suited to write an OS kernel, others are less so. Read the page about [[Languages | using some language other than C]]. |
||
| Line 47: | Line 49: | ||
== Kernel Image == |
== Kernel Image == |
||
=== Booting Problems === |
|||
=== I have successfully loaded my kernel. It works as long as it doesn't exceed XXX bytes. My Kernel got bigger, and now I keep getting exceptions and faults. Why? === |
|||
Especially in early stages and with a self-built boot loader, the reason is frequently that too few sectors are fetched from disk. Either adjust the amount of sectors you fetch from disk, or have the boot loader / second stage loader parse the file system. |
Especially in early stages and with a self-built boot loader, the reason is frequently that too few sectors are fetched from disk. Either adjust the amount of sectors you fetch from disk, or have the boot loader / second stage loader parse the file system. |
||
=== Strings === |
|||
=== When I use strings in my Kernel, it doesn't work/crashes/has a corrupt Multiboot-Header === |
|||
When your Kernel is written in C, gcc puts strings and constants in a special section called "read-only data". This section needs to be in your linkscript, in the |
When your Kernel is written in C, gcc puts strings and constants in a special section called "read-only data". This section needs to be in your linkscript, in the .text section, otherwise it can cause all sorts of weird problems (unable to print text to the screen, kernel suddenly becoming 1MB larger, GRUB giving a loading error saying "kernel too large", etc). The section is called ".rodata" in ELF and ".rdata" in COFF/PE (the output format for MinGW/Cygwin). Building a [[GCC Cross-Compiler]] will help you to safely assume ".rodata" everywhere. |
||
You could also tweak your linker script to include ''either'' section: |
You could also tweak your linker script to include ''either'' section: |
||
Revision as of 01:50, 7 April 2007
The idea to "write your own OS" brought you here. This Wiki is about giving you help, pointers, and references in your undertaking.
However, it is quite common that newcomers make certain mistakes, or have common misconceptions about what is involved in the topic. That is not bad - many others made these BeginnerMistakes before, and many will do so in the future. This page is about making sure you know what you're about, before digging into the provided information.
Scope
Dealines
Whether for university, hobby, or commercial uses operating system development takes time. The Linux kernel took over one year of very dedicated work to get into a semblance of usefulness, and all Linus Torvalds did was mimic existing and well-documented behaviour to get an already-existing userspace to run on it. Moreover, for every project as successful as Linux, there are literally hundreds of projects that consumed a man-year or more of work without ever getting as far as hosting a functional shell.
Therefore, plan a reasonable road map of what you want to get done. Do not assume that in 3 months your OS will have a GUI and voice recognition, because operating system development does not contain any RAD tools in it at all. In fact, it is completely void of them. (void. It's a joke. Get it?)
Community Projects
Don't overestimate your chances of getting people interested in your project. Even the more successful projects usually consist of one, perhaps two people actually working on the code. And that is not due to a lack of need.
Commercial OSDEV
There really is no such topic. OSDEV will probably never land you a job. (As shown in the "Jobs" section of the forum.)
Also, don't get your mind set that by building such a great OS that you'll be rich. If anything, history has shown us that the best operating systems never receive any commercial success, while the ones that have a near total lack of design and inspiration do.
Design
GUI Design
It will likely take you several years, starting from scratch, to get to the point where you actually do anything GUI-related. And, the looks of a GUI are secondary at best, as they can easily be changed retroactively; what really decides the usability of a GUI is the functionality, and that isn't expressed in mock-up graphics. If your aim is creating a better look instead of a better OS, consider implementing an X Window Manager instead of a whole OS.
OS Emulation
My OS will be able to run programs from Windows, Mac OS, Linux, and even PDP-11 programs!!!
I'm sorry to burst your bubble, but it probably won't. Emulating even just a single system takes years of work, especially when it's proprietary, such as Windows or Mac OS. (Linux is probably the easiest out of the four.) So instead of focusing on emulating other systems, focus on your own. Design it, develop it, and be friends with it.
Naming
Naming is usually the last problem to be solved, even while we all wish for a cool name to our cool concept. Since the "coolness" of a name is a matter of taste, we cannot help you finding it. Moreover, if you tie your project name to a certain feature, you might discover somewhere down the road that no concept is perfect and that you might want to change what you initially thought a key feature. Nothing would be more stupid not to evolve just because you 'want to stick to a name'...
Programming Languages
Some languages are well suited to write an OS kernel, others are less so. Read the page about using some language other than C.
Kernel Image
Booting Problems
Especially in early stages and with a self-built boot loader, the reason is frequently that too few sectors are fetched from disk. Either adjust the amount of sectors you fetch from disk, or have the boot loader / second stage loader parse the file system.
Strings
When your Kernel is written in C, gcc puts strings and constants in a special section called "read-only data". This section needs to be in your linkscript, in the .text section, otherwise it can cause all sorts of weird problems (unable to print text to the screen, kernel suddenly becoming 1MB larger, GRUB giving a loading error saying "kernel too large", etc). The section is called ".rodata" in ELF and ".rdata" in COFF/PE (the output format for MinGW/Cygwin). Building a GCC Cross-Compiler will help you to safely assume ".rodata" everywhere.
You could also tweak your linker script to include either section:
...
.text 0x100000 {
*(.text)
*(.rodata*) /* <---- ELF Cross Compiler or ELF *NIX (eg. Linux) */
*(.rdata*) /* <---- COFF/PE MinGW or Cygwin on Windows */
}
...