Beginner Mistakes: Difference between revisions
[unchecked revision] | [unchecked revision] |
Content deleted Content added
m gr comma |
|||
(38 intermediate revisions by 12 users not shown) | |||
Line 1:
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
== What this is NOT ==
Line 13:
This Wiki will ''not'' be expanded into a beginner's handbook, because that is not its purpose. It is for answering the ''advanced'' questions that arise when people feel they're ready for the plunge into kernel space programming.
=== A Hard Truth ===
'''''Programming novices should probably not be considering OS Dev yet. Experience in low-level coding in assembly language and/or a systems language, such as C, is pretty much the minimum necessary to even understand the topic well enough to work in it.'''''
What's more, this is growing ever more true by the year, as the number of different 'standards', computer and mobile device models, peripherals, and design concepts continues to expand.
It was one thing for someone like Dennis Ritchie, Richard Greenblatt, Gary Kildall, or Steve Wozniak to write a simple OS for hardware which was relatively straight-forward in comparison to current machines, which they already knew intimately, and which had no standards specifications to adhere to or existing cruft to maintain backwards compatibility with. This is no longer true on current-generation stock hardware. Furthermore, each of them was already a seasoned engineer who had already done years of systems programming. Even then, they only provided the foundations for the systems; the bulk of the work was done by small armies of subordinate developers after the nucleus of the system--the kernel, in modern jargon--was in place.
There are exceptions to this rule, but not many; don't expect yourself to be that one in a thousand. If you think you are, read up on the [https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect Dunning-Kruger Effect] and consider the matter again.
Oh, and for the record, Linus Torvalds wasn't quite one of them--he was a graduate student when he wrote the Linux kernel and had been coding in C for years. While he was well short of that ten year mark, as a grad student who had turned his hobby into his master's thesis, he had more time on his hands to work on the project than most people would. In any case, the 'Linux 0.0.1' release he famously posted to USENET in 1991 was little more than a round-robin scheduler, nowhere close to a full system. Getting to that point took him a year. Get the picture?
While it is true that most of the contributors to this wiki started much sooner, for most of us, that was a mistake born out of a lack of experience. Most of the pioneers of this group had no idea of the sheer scale and complexity of even a small OS project, no inkling of what they were getting themselves into. This was a difficult pill to swallow, especially back '''before''' resources like this Wiki were widely available. We cannot force you to learn from our mistakes, but at least we can pass on this warning.
Now, you shouldn't get ''too'' discouraged by this; the point is not that you can't do this, but that--if you are like most of us were when we started out--you probably can't do it ''yet''. Patience can be a virtue when starting out on a project this large.
=== Is there a tutorial on...? ===
Because this place
In fact, the vast majority of tutorials currently out there are known to be broken in at least one way, so you are generally better off not trusting them in the first place.
Line 26 ⟶ 41:
=== End Goal Definition ===
When starting out a project, you should estimate your end goals, your end users, the purpose for which the project is developed, etc. Operating system development is no different to this. Having a rough idea about your goals will give you motivation and the direction where you need to head. However, don't get stuck at your initial end goals when something better comes to your mind.
Unfortunately, many OS developers don't estimate
It should be mentioned, however, that to estimate your end goals you should be aware of the whole (technical) concept of how existing operating systems work.
=== Commercial OSDev ===
Despite that, and despite the relative emptiness of the "Jobs" section of the forum, a few sole-developer operating systems have had some commercial success. One example is [[User:01000101|01000101]] with "Drop-in Network Security", an OS designed to act as a specialized deep-packet analyzer. Note that it's specialized to a particular application. To market your OS in this way, you need to understand the application just as well as you do OS dev, perhaps more, and you need to be quite good at coding both. Your customers will expect you to be professional.
▲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, because of clever business moves and being in the right place, in the right time, with the right cover-up.
Another possibility is marketing your OS to companies which presently use MS-DOS for process control. This may seem easier in that you're not responsible for the final application, but you will need to be professional and responsive to your clients problems and queries. They may require long-term support. They may not like a feature you really want to implement.
=== Assuming It Will Go Nowhere ===
In contrast to the above, some people assume their OS will go nowhere. For this reason, their projects have ugly code, don't take important aspects into account, and in general rely on ugly hacks. Worst of all, they
In reality, while the chances of getting your OS running outside of your test machines are low, there are enough advanced OS projects that started from this very community.
=== Avoid Ignorance ===
Beginners often ask "What is the ''easiest'' way to do X?" rather than "What is the best, proper, correct way to do X?"
Common examples include being too lazy to use a [[GCC Cross-Compiler|Cross-Compiler]], not understanding [[Real Mode]], [[Unreal Mode]], [[Protected Mode]], and [[Long Mode]] and jumping far too fast from one to the other without first understanding how to gather all of the vital configuration and use all of its capabilities fully
== 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.
''My OS will be more popular than Windows, Mac OS, and Linux!''
This is extremely unlikely. To achieve this requires quite a lot of time, money, and knowledge. Not everyone will download your operating system because:
* they may not know what an operating system is or how to install one
* your operating system has security risks
* your operating system supports fewer applications
* your operating system is not fully functional (minimal command line interface or bad GUI)
You will be lucky to get a few people to use yours. The only reason why the popular operating systems of today are popular is because they were available and addressed needs decades ago when there were fewer alternatives.
=== Memory usage ===
''I want to use less than a couple of kilobytes for my OS!''
Sorry, that's probably impossible. An OS using such little memory will be almost unusable. Forget about filesystem drivers, disk drivers, usb drivers, etc.
Another option would be to try a native Forth; it's like a little OS with the kernel, command interpreter, and assembler all in one tiny binary! Parts of the kernel can even be scripted. It doesn't even need a filesystem; many Forths directly edit and load disk sectors. There's a big catch: Forth is not light on skill. Writing good Forth is a whole other planet which programmers would need to understand to get beyond the bare basics. Surprisingly, some Forth fans are good at writing Forth interpreters but are poor Forth programmers. An OS developer will need to be a good(-ish) Forth programmer to fit OS design concepts to Forth, or to figure out which concepts are not needed. Otherwise, the OS would be ''much larger'' than it needs to be. ;)
It can take a lot of time and thought to write compact Forth code. Charles Moore, inventor of Forth, wrote a CAD program which was structured around just 5 lines of code; it took him about 2 years.
=== OS Emulation ===
Line 68 ⟶ 101:
== Kernel Image ==
=== Booting Problems ===
Especially in early stages and with a self-built bootloader, the reason for booting problems 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
▲=== Strings ===
== Troubleshooting / Asking for Help ==
Before asking for help on the forums or IRC, you should be taking all the possible steps to diagnose the nature of the problem yourself. In the case of problems like triple faults or "random" exceptions, it's a common mistake to make assumptions about the cause of a problem
In general, put as much work as possible into solving a problem yourself before asking others for help. Before you post, ask yourself, "Have I done everything I can to diagnose and solve this problem?" Often you will learn a lot in the process, and you'll likely be able to solve the problem (and similar problems in the future) yourself, without the help of others, which is a good thing. When you ask for help, provide the code '''relevant''' to your problem. However, the problem may be located somewhere else, so give
In regards to the forum, '''read the forum rules
For a much more in
== Promotion ==
=== Naming ===
Naming is usually the last problem to be solved, even while we all wish for a cool name
A lot of good information on naming can be found in [[Topic:15250|this]] thread. Simply put, naming your operating system <name>OS (JackOS, FredOS, etc.) may seem like a good idea, until you get a second project member. A good idea (courtesy of Solar) is to choose a codename (like Longhorn, Chicago, etc.) and then make up a better name closer to release time.
=== Project Website ===
Many newcomers to osdev create project websites before they have anything worth showing on the website. There's no value in creating a website making dramatic claims about the future plans for your project before you've got any idea where your project is heading or any code, screenshots, or downloads to showcase what you've already produced.
== Teamwork ==
The number one beginner mistake is seen in the Announcements forum.
=== Community Projects ===
Don't overestimate your chances of getting people interested in ''your'' project. Even the more successful [[Projects|projects]] usually consist of one, perhaps two people actually working on the code. And that is not due to a lack of ''need''.
Brooks' Law states that the more people there are on a project, the longer
=== Recruiting ===
|