618
edits
Beginner Mistakes: Difference between revisions
m
gr comma
| [unchecked revision] | [unchecked revision] |
m (Grammar and formatting touch-ups. Meaning adjustment in Popularity section.) |
m (gr comma) |
||
| (12 intermediate revisions by 8 users not shown) | |||
Line 15:
=== A Hard Truth ===
'''''
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.
Line 48:
=== 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 building such a great OS will make you 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, at 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 ===
Line 60 ⟶ 62:
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 (especially detecting basic capabilities with the BIOS during boot and initialization), relying on [[BIOS]] calls
== Design ==
Line 81 ⟶ 83:
''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 96 ⟶ 102:
=== 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/second stage loader parse the file system.
== 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. Make 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 (even 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).
| |||