Beginner Mistakes: Difference between revisions

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 beginner mistakes 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.

Because this place can notcannot and does not cater forto beginner developers, the question forof somewhich other place that does provideprovides a tutorial, good explanations, or easy -to -understand reading is often requestedasked. However, '''they do not exist'''. Difficult subjects can notcannot be described with light prose, just like how there are enough things that are too complicated for a monkey to properly learn. If you have trouble reading official documentation, this would be a good time to practice.

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 how willwhat their final OS will look like,; therefore, they don't know in which direction to head and resort to asking, "Whatwhat next?".

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 takemake decisions that don't allowresult in usability and extensibility. This way, their assumption becomes a self-fulfilling prophecy.

Beginners often ask "What is the ''easiest'' way to do X?" rather than "What is the best, proper, correct way to do X?". This is dangerous as the newcomer doesn't invest time into understanding the superior way to implement something, but instead picks a conceptually simpler method copied from a tutorial. Indeed, the simpler route is often ''too simple'' and ends up causing more problems in the long run, because the beginner is ignorant of the superior alternative and doesn't know when it is better to switch. What's so bad about taking the hard route instead?

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 first (speciallyespecially detecting basic capabilities with the BIOS during boot and initialization), relying on [[BIOS]] calls or DOS services that are not standard, not learning to write hardware drivers in your own OS and under Windows and Linux for greatest convenience, and to openexposing test capabilities globally, using flat binaries instead of [[ELF]] or, not learning about executable, archive, graphics, document and other file formats and compression algorithms, and so on. Experienced developers use the superior alternatives for a reason, which you might not understand yet. Experienced developers are ablechoose to use the inferior method in some cases, but that's because they can carefully analyseanalyze whether it is appropriate, and they know when ''not'' to use it. As a beginner or intermediate developer you will likely not know these methods and technologies well enough to reason whether the inferior solution is good enough for you. Remember that if you oppose a method, you should know it well enough to know everything that is wrong (and right) with it. Either way, laziness and ignorance only leads to trouble down the road. When in doubt, pick what appears to be the conservative choice rather than the simpler.

It will likely take you several years, starting from scratch, to get to the point where you actually do anything GUI-related. And, theThe ''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.

Sorry, that's probably impossible. An OS using such little memory will be almost unusable. Forget about filesystem drivers, disk drivers, usb drivers, etc. IfFor you want to developdeveloping something small, just make a simple bootloader, not an OS.

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 / second stage loader parse the file system.

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,. makeMake use of a debugger or print statements to locate the exact point when an exception occurs. Using and emulator and a debugger (such as GDB and Bochs/QEMU) will help you to locate problems which are difficult to trace. If you provide some theory about the problem and actions you have already taken to solve it, people will be able to help you much easier (Eveneven if your theory is not correct, it at least gives people an idea of your views on the problem and the strategies you might have already tried, as well as what you might have missed.).

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 your others a way to look at the other parts of your code as well (if you're using something like GitHub or Bitbucket, this is slightly easier, but there are certainly many other ways.).

In regards to the forum, '''read the forum rules,. theyThey are required reading,''' and will improve the quality of your posts and make people more likely to help you. On the IRC channel, if you ask a question, don't expect an answer within 10 seconds, or even 5 minutes,. otherOther people have lives too. If you need to leave to do something, and want to check if you missed anything, there are logs available for you to look through,. seeSee the links in the IRC topic for those.

For a much more in -depth guide on how to be a good community member when asking for help, consult [http://www.catb.org/~esr/faqs/smart-questions.html How to ask questions]. It's a great read, and ideally, you should read the whole thing before asking for help anywhere (it's not that long, and well worth the read).

Naming is usually the last problem to be solved, even while we all wish for a cool name tofor our cool concept. Since the "coolness" of a name is a matter of taste, we cannot help you in 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 was a key feature. Nothing would be more stupid notthan to not evolve just because you "want to stick to a 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.

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. - suchSuch a website looks dead and creates a bad reputation. Announcing your website (such as in the Announcements forum on the OSDev.org forums) or linking to it in your signature when there's nothing more than a "welcome to <insert fancy project name here>" message on it just makes people lose interest in your project before you've even started, and if/when you do eventually produce something worth showing off, you'll be faced with an already-terrible reputation that will be hard to overcome.

The number one beginner mistake is seen in the Announcements forum. TheyIt usually comecomes in one of two forms, although theythe forms have quite a bit of overlap:

Brooks' Law states that the more people there are on a project, the longer itthe project takes. The only way around this is to split the project into parts thatwhich you get people working on, and only on that part. Good luck.