As Intx13 says, the wiki page does cover that. I suspect you are having a bit of jitters, though, so let me reassure you by say that, for the standard x86 PC, almost any combination of a 32-bit C compiler, x86 assembler, and linker will work, and you can use any general programmer's editor for writing the code in. Some tools may require additional configuration, but if the compiler and/or assembler will produce freestanding executables (i.e., an executable file without the OS-specific initializer and without automatically linking in the standard libraries) with few or no runtime requirements, you should be able with enough effort get a working OS from it.
That having been said, the most direct course of action is to use the GNU toolchain. It is the same set of tools used for Linux development, and dozens of hobby operating systems have been written with them. They are the common denominator for most OS dev, and even if you are using a different toolchain you should at least have a passing familiarity with them, and specifically with using them from the shell (that is, the command line). In particular, you will want to have at least a basic understanding of the
gcc compiler driver program, the
ld linker (which can be invoked from GCC or by itself), the
gas assembler (ditto), the
make build tool, and the
dd raw-file reading and writing utility.
If you are using Linux or FreeBSD, you probably already have these installed; on MacOS X, they are the default toolchain for XCode (the standard Apple IDE and toolkit), as well. If you are hosting your development from Windows, there are a number of ported Unix-like environments you can use, with Cygwin and MinGW being the most commonly used (with Cygwin generally being preferred). If you haven't used these tools before, I recommend familiarizing yourself with them (downloading and installing them if necessary), so that when the wiki or the message board inmates use them in examples you at least can figure out what they are talking about.
Note that a lot of OS-Devs prefer to use the Intel style of assembly syntax rather than the AT&T syntax used by gas; Netwide Assembler (NASM) is quite popular, in particular. However, you should learn to read AT&T assembly, even if you don't want to use it, as it is the style produced by GCC.
Regardless of the toolchain you use, it is highly recommended that you set up a separate installation specifically for cross-compiling your OS. Operating systems have somewhat special requirements regarding executable file generation, library defaults, and build environment, so keeping your OS-Dev tools distinct from your general programming tools is very important. The wiki has a pages on configuring
GCC and
Visual Studio for this purpose.
As for the editor, that's a wide open field, with no real winners or losers - use whatever you feel the most comfortable with, as long as it will save plain text files you should be fine. If you decide to use an IDE such as Eclipse, Code::Blocks, or Visual Studio, you will have to configure it to use the cross-compiler, assuming you are using one.
There are two other tools you should use, and you'll want to give some thought as to the specific ones you'll want to use. The first is version control software, and, not to put too fine a point on the matter, anyone who is doing
any kind of substantive software development project in 2015 without using version control and an offsite repository for their code has already made their first mistake. Which one you use - Subversion, Git, Mercurial, Bazaar, even old reliable CVS - is less important than being absolutely dedicated to using it consistently whenever editing your code.
The other tool you will want is an emulator (e.g., Bochs, QEMU) or a virtualizer (VirtualBox, Virtual PC, VMware) for testing your OS in. Again, this may sound like an optional tool, but practically speaking, you will need one, preferably one that allows you to debug the emulated OS from the emulator. While it is your choice which one to use, I personally recommend Bochs, as it is the easiest to configure, load, and run, and it has the most comprehensive debugging suite. You will probably want two, actually, for cross-testing (to make sure that you haven't relied on some particular facet of the emulator) before going to live hardware - in which case I suggest VirtualBox as the second one.
With that out of the way, all you need to do is pick your poison. Before going on, though, perhaps you'll want to consider these questions, and maybe answer them for us as well:
- Why are you interested in OS dev? There are a lot of reasons people get into the hobby, and knowing your motivations can give you a better idea of what you should be doing here (and give us some idea of what advice to give you). A lot of devers want to learn about it, out of curiosity; others may see it as the ultimate macho challenge of their programming skills, or just love programming from the bare metal; still others may have broader ambitions.
- What do you want to do with it? Do you have a specific goal in mind, or just want to sort of experiment around with things? Do you want to re-implement an existing system, or are you looking to try something unusual? This wiki page might give you some inspiration regarding your direction.
- How do you want to do it? Are you looking to design a specific part first, or develop in several areas at once? Are you planning to use assembly alone, C and assembly, or assembly with some other language? What kind of kernel architecture do you want to use? I know that this is exactly the question you came here to ask, but you should ask yourself what you want to use, not us.
The last thing I want to say is, don't set your goals too high at the start. OS dev is among the hardest, if not the very hardest, programming challenge a coder can undertake. It takes patience and perseverance to get anywhere with it. Don't take on too much at the start, and be prepared to start over once you've made the
beginner's mistakes (and you
will make at least some of them). Take your time with it, and build up to the higher levels over time.
