please wait
How hard is it to make an OS
Aug 15, 2011 at 5:39am
First of all this is not an OS fight okay. Please keep things civil and constructive.
Now to the question how hard is to make an OS I can not imagine the how hard the coding is. Does anyone know how an OS is is made and how hard it is. I have a tendency to make things WAY more complex than they really are. So am I really just over thinking it or is it really hard.
Now to the question how hard is to make an OS I can not imagine the how hard the coding is. Does anyone know how an OS is is made and how hard it is. I have a tendency to make things WAY more complex than they really are. So am I really just over thinking it or is it really hard.
Last edited on Aug 15, 2011 at 5:40am
Aug 15, 2011 at 6:42am
Yes, OS development is hard. It is probably the most difficult area of programming there is (along with game development and compiler development). I've tried it, and though it's fun and you learn alot, it is incredibly hard. I welcome you to try it, though; go through a tutorial or two, read some articles on the OSDev Wiki (which helios posted a link to), read the documentation for your chosen architecture (e.g., x86, x86_64, SPARC, etc.). I recommend x86 as most people on OSDev.org write their OS for x86 and it has easily the most documentation available. x86_64 is a little more complicated since you have to have an intermediate step between the bootloader and the kernel proper to switch the CPU to long (64-bit) mode (the computer starts in real (16-bit) mode, the bootloader should put you in protected (32-bit) mode, and then your intermediate code will switch to long mode so that your kernel can boot).
Advice:
- RTFM
- Learn the assembly language of your target architecture and learn it well. This is very, very important and lots of people try to skip this step
- Use this as a reference for interrupts (x86 only): http://www.ctyme.com/rbrown.htm
- Be prepared to write the same code over and over again until its perfect
- Be prepared for random, inexplicable bugs that seem to just appear, and then you realise there were some serious bugs in your string library implementation (did I mention that you have to implement every function you want to use by yourself? Because you have to implement every function you want to use by yourself)
- Linux seems to be more convenient, although me saying that is quite likely down to my own prejudice
- Follow the cross-compiler tutorial on OSDev wiki and build a gcc cross-compiler, it makes everything easier if you're on Windows (I'm not sure if you need to do it on Linux; I never bothered but it might be a good idea to do it anyway. The reason you need to do it on Windows is because otherwise you cannot create ELF executables, only Windows PE which is not supported by GRUB or other bootloaders*)
- Install Qemu and GDB; you can use GDB to debug your kernel while it's running under Qemu
- Don't code while sleep deprived, this leads to mistakes like this: http://forum.osdev.org/viewtopic.php?f=1&t=21947
- Set up a decent build system - learn to write your own Makefiles, ld (linker) scripts, other scripts that might be useful (I used numerous Bash and Perl scripts for generating test floppies, initial ramdisks, etc.)
- Get rid of bugs _early_. Check all your code for possible bugs. I cannot stress how annoying it is when you compile your kernel and find out that somewhere there is a bug (or several), but you don't know where and it's incredibly hard to find out (the only way (GDB can't do this when running with Qemu) is to remove sections of source code and try compiling without them, but removing parts of the kernel without modifying other parts is nearly impossible unless you design your kernel with that in mind)
* Unless you write your own, but then you have to write a PE loader. In assembly. With a maximum program size of 512 bytes (unless you use multiple stages, but then things get super complicated, super fast, because you have to deal with BIOS functions, BIOS incompatibility (seriously, BIOS is fucked up), stupid reasons why floppy disks randomly don't work, and a whole host of other problems that you have to predict and work around).
In short, writing an OS is really, really, really hard, and may well drive you insane. On the other hand, when things work it is incredibly rewarding.
Advice:
- RTFM
- Learn the assembly language of your target architecture and learn it well. This is very, very important and lots of people try to skip this step
- Use this as a reference for interrupts (x86 only): http://www.ctyme.com/rbrown.htm
- Be prepared to write the same code over and over again until its perfect
- Be prepared for random, inexplicable bugs that seem to just appear, and then you realise there were some serious bugs in your string library implementation (did I mention that you have to implement every function you want to use by yourself? Because you have to implement every function you want to use by yourself)
- Linux seems to be more convenient, although me saying that is quite likely down to my own prejudice
- Follow the cross-compiler tutorial on OSDev wiki and build a gcc cross-compiler, it makes everything easier if you're on Windows (I'm not sure if you need to do it on Linux; I never bothered but it might be a good idea to do it anyway. The reason you need to do it on Windows is because otherwise you cannot create ELF executables, only Windows PE which is not supported by GRUB or other bootloaders*)
- Install Qemu and GDB; you can use GDB to debug your kernel while it's running under Qemu
- Don't code while sleep deprived, this leads to mistakes like this: http://forum.osdev.org/viewtopic.php?f=1&t=21947
- Set up a decent build system - learn to write your own Makefiles, ld (linker) scripts, other scripts that might be useful (I used numerous Bash and Perl scripts for generating test floppies, initial ramdisks, etc.)
- Get rid of bugs _early_. Check all your code for possible bugs. I cannot stress how annoying it is when you compile your kernel and find out that somewhere there is a bug (or several), but you don't know where and it's incredibly hard to find out (the only way (GDB can't do this when running with Qemu) is to remove sections of source code and try compiling without them, but removing parts of the kernel without modifying other parts is nearly impossible unless you design your kernel with that in mind)
* Unless you write your own, but then you have to write a PE loader. In assembly. With a maximum program size of 512 bytes (unless you use multiple stages, but then things get super complicated, super fast, because you have to deal with BIOS functions, BIOS incompatibility (seriously, BIOS is fucked up), stupid reasons why floppy disks randomly don't work, and a whole host of other problems that you have to predict and work around).
In short, writing an OS is really, really, really hard, and may well drive you insane. On the other hand, when things work it is incredibly rewarding.
Aug 15, 2011 at 3:41pmclosed account (1yR4jE8b)
A version control system is also a very good tool for helping to find bugs. If you commit often, and in small chunks, it is very easy to find which chunks of code introduced bugs by bisecting individual commits.
After hacking on the Linux kernel, I cannot stress enough how much time
has saved me.
Using version control has many other benefits which make a programmer's life much easier when working with projects that evolve beyond simple toys. For me, it is an essential tool. I rarely ever code without one.
I recommend either Git or Mercurial for version control. Git is substantially harder to use but offers much more flexibility. Mercurial is very easy to learn and use, but doesn't give you as many options to fiddle with. If you're developing on Windows, I recommend Mercurial over Git because Git on Windows is treated as a second-class citizen...it was developed by Linux Torvalds afterall. Git is still very usable on Windows, but because the windows version is a fork of the original project you're more likely to find bugs in the Windows version that do not exist in the Linux/Mac version. If you're on Mac or Linux, either is a good choice.
http://git-scm.com/
http://mercurial.selenic.com/
After hacking on the Linux kernel, I cannot stress enough how much time
| git-bisect |
Using version control has many other benefits which make a programmer's life much easier when working with projects that evolve beyond simple toys. For me, it is an essential tool. I rarely ever code without one.
I recommend either Git or Mercurial for version control. Git is substantially harder to use but offers much more flexibility. Mercurial is very easy to learn and use, but doesn't give you as many options to fiddle with. If you're developing on Windows, I recommend Mercurial over Git because Git on Windows is treated as a second-class citizen...it was developed by Linux Torvalds afterall. Git is still very usable on Windows, but because the windows version is a fork of the original project you're more likely to find bugs in the Windows version that do not exist in the Linux/Mac version. If you're on Mac or Linux, either is a good choice.
http://git-scm.com/
http://mercurial.selenic.com/
Aug 15, 2011 at 5:40pm
Wow I never knew it was this hard. I might as well start learning assembly thanks chrisname ,
darkestfright , and helios.
Thanks chrisname for all the advice and detailed information.
Anyone know of any good assembly tutorials?
darkestfright , and helios.
Thanks chrisname for all the advice and detailed information.
Anyone know of any good assembly tutorials?
Last edited on Aug 15, 2011 at 5:43pm
Aug 15, 2011 at 6:56pm
Wouldn't you (well I actually) know it, someone asked a simlar question (assembly tutorials, not about making an OS), hope it helps:
http://cplusplus.com/forum/lounge/48232/
http://cplusplus.com/forum/lounge/48232/
Topic archived. No new replies allowed.