Tips

1. Develop, test, debug and bugfix as much code outside the OS being written as possible. Make this code working under the OS in which you normally work on your PC (DOS, Windows, Linux, whatever). It will make your life much more easier.
2. For every module you do, make at least a small test program. Run tests to ensure correct work of your code.
3. Split big pieces of code and big tasks/problems into smaller ones. I mean it! Attack them separately from each other. First, make these smaller parts work. Then put everything together and correct any remaining interoperability problems. If you do not do so, you’ll fail because of being unable to locate a bug, isolate the erroneous portion of the code from the rest.
4. If the code being developed is still big and complicated by numerous condition checks (if-then-elses, switches, etc), make use of the state machine concept. It often helps. It will help you to do practically any kind of parsing and implement various data/control protocols.
5. In the code, check error conditions, don’t let the errors accumulate and propagate further than allowed, catch them and report of them by say logging. If you don’t do it, your system will most likely have hidden holes bigger and severer than in famous commercial OSes.
6. Don’t underestimate the power of such tools as a pen(cil) and paper. Don’t rush into coding something complicated. First, analyze it on paper. Draw pictures, diagrams, solve equations (you’ll need surely to solve equations in OS dev), etc. Make the solution to your complicated problem clear with all the illustrative means you can have. Keep these papers along with the other project documentation. If you have an idea, you can always implement it in code and have a product. If you only have some unfamiliar/forgotten, unreadable and probably incorrect code, you won’t make a product out of it. Keep the solutions. You can even photograph your papers and put it under source control! :)
7. Structure and comment your code to make it possible to maintain in future by you and others. Even the primary developer can forget what and why (s)he did in the code. Don’t make it happen. Document the code by outlining the algorithm behind it and keeping this document along with the code.
8. Read documentation (on hardware, on algorithms, on everything) carefully. Reread it, if you don’t get it. Really do it. Don’t give up. Try finding docs that explain the same things but easier. Discuss things on the Internet. But don’t expect anybody doing your work (especially homework assignment :) as nobody is obligated to help you with everything and in unlimited amount.
9. Use some version control software (like CVS, MS Visual Source Safe, etc) to keep track of the previous versions and development history. This will help you to roll back or find a new bug that wasn’t there in some of the previous versions of the code.
10. Use PC emulators (such as Bochs, VMWare, Virtual PC, etc) to avoid unnecessary hard disk data damages and simplify testing (if you run your code on a real PC, the PC is hardly useful when it’s busy running your code, whereas with emulated PC you can do some additional work in parallel to booting and running your OS).
11. Make use of the map files generated by the linker. It will help you to see incorrect code/data placement, wrong addresses, right addresses, function addresses, etc. It will also help you to find a place of exception inside your OS by the address of offending CPU instruction.
12. Make use of disassemblers to check that the addresses used in the instructions (in the OS image file) are OK. Many newbies have problems with addresses when setting up protected mode. I’m happily using HIEW and BIEW as file viewers with built-in hex editor and x86 disassembler.
13. Don’t burn the bridges! E.g. don’t put the code that switches the x86 CPU to the protected mode inside a small boot sector. Don’t or you will loose all disk I/O and won’t be able to load the OS or kernel (disk I/O isn’t possible in the x86 protected mode, this mode is not supported by the BIOS that offers disk and other I/O functions). The same applies to the file system. If you don’t want to waste too much time, don’t reinvent the wheel. Make a driver for the existing commercial file system (like MS FAT12/16/32) and avoid all problems of transferring data to and from your OS.

 

There’s rationale for each and every item on the above list. Try to understand it. It all will only help you to get done.

 

 

From :Alexei A. Frounze