Printable View
I know it's an extremely large goal and will probably never happen but I would like to try. I would like to create my own operating system. I have already reaserched and planed everything. I just need to write the code, but I don't know where to begin. I have already read all the beggining tutorials and i'm looking for the next step. Any help at all will be much appreciated.
What tutorials / resources have you read so far?
Bootstrap and simple console I/O would seem to be a good start.
Then perhaps a simple task switcher.
I've read the c++ tutorialls on this site. I have also wrote little practice programs and i believe that I understand the conscepts very well.
What is Bootstrap?
I already understand the booting process and I know how I can make my system run as the primary system. The problem arises when I actually attempt to code the system. I don't know how I should begin.
I'm already examining that site.
You have a long way to go grasshopper.Quote:
Originally Posted by histevenk
Bootstrap is the term for when the computer boots up its executes a specific piece of code found in sector 0 of the hard disk. This code then loads the rest of the OS using whatever filesystem it uses.
The term derives from the phrase 'Lifting your self up by your own bootstraps'.
A simple DOS-like bootloader is fairly easy to implement, just remember you have to wrap everything necessary to load the OS into 512 bytes, probably in assembly. Another good although very old reference is Ralph Brown's Interupts. I have a copy of it in storage, Ill have to post the ISBN sometime. I think you can find an online version of it around in a few places.
If you arent familiar with assembly, you probably should also check out several books on assembly language programmign fro 16 and 32 bit processors. If you want to write a 32 bit OS then you need to learn how to switch into protected mode from real mode. All Intel compatible computers boot up in real mode. Real mode is probably easier to write your first OS in, protected mode has a lot more complex behavior to take into account, such as paging tables and protection levels.
One way to avoid some of the tricky stuff with booting the system is to boot DOS on the system, load the OS code with a small DOS program, and then start your OS.
That way, you don't have to worry about boot-loading.
Once you have something that can load a binary file, you then have the task of "taking control of the processor".
In x86, that consists of:
Most of the above CAN be written in C, but you really need to know what you are doing. If not, it's probably easier to do in assembler.Code:1. Get into 32-bit protected mode,
a) set up a GDT (Global Descriptor Table) with one code-segment (CS) and one data-segment (DS).
b) set CR0.PE (bit 0) to one.
c) jump a far-jump using the index of the CS.
d) set DS, ES, SS, FS, GS to the datasegment.
2. Set up a protected mode vector table (Interrupt Descriptor Table, IDT).
3. Set up the interrupt controller (8259 or APIC) to use vectors 0x20 and up [you may choose other vector numbers, but I don't know of a good reason for that].
4. Configure a timer device (e.g. the 8254 or a High Res Timer). Set the corresponding interrupt up and enable interrupts.
Now you are ready to actually start writing task-switching code, etc.
By the way, another way to get the system started without writing your own boot-loader would be to use GRUB and write your code as "grub modules", which isn't very hard if you have access to GNU tools.
--
Mats
I'd rather hijack grub or lilo as the boot loader.
I'd rather hijack another OS :)
eg Heavily modify Linux, or Plan9 or something... sure starting from scratch is a good learning experiment, but it's kinda pointless unless there's a reason for it.
That's like learning to design a car by taking a Ferrari apart - it's probably better to start with a VW Beetle [the old model], as it's a much easier design.Quote:
Originally Posted by zacs7
Have you actually looked at the Linux source code enough to understand what it does? It is fairly complex, even for rather simple matters - because it has to be flexible enough to run on 17 different processor architectures, each with several flavours of implementations, etc, etc. So there are 5 different files just to implement some simple mechanism (say timekeeping), which if you have a more dedicated approach can be done in one or two files [not counting header-files].
If you want to learn how an OS works, then writing a simple OS is a good way to learn.
Obviously, it gets fairly tricky after some time, for example file-systems can be rather complex [and important to get right], memory management with virtual memory is another "interesting" aspect.
--
Mats
Sorry matsp, I haven't looked at the entire source :( - other than a little dadd'ling with the kernel.
Sorry if I was a fool, but starting fresh seems like a lot of work - surely there is another way?
Well, you could look at Minix. I heard it's written in a way that is easy to understand.
Not to worry. A lot of people think that the Linux kernel is easy to understand (and modify), when in reality it is very complex. It was a lot easier just a few years back, but even the 2.2 kernel is fairly complex. The 1.0 kernel may be a better choice - but then it's still a BIG kernel even there.Quote:
Originally Posted by zacs7
Minix as CornedBee suggests is one option to start with, because, as stated, it is written to be understandable, rather than the Linux kernel, which is written to support lots of options and being efficient at that.
--
Mats
I know it's very complex, and I know it's flexibility makes it more complex. I was mearly suggesting an alternative route to creating his OS ;)
You could at least take some chunks... Look at the source for ReactOS, Minix, Linux and a few others -- I'm sure it'd help.
Since this is your first attempt at an OS, getting past the boot loader and to something which prints "hello world" and then halts would be a pretty reasonable achievement.
Bootloaders arent that difficult to write, you just need to know which BIOS calls to make. You could even put the 'hello world' message in the bootloader. 512 bytes is huge when writing assembly. Like I said, get yoru boot loader runnign in real mode first, then you can have it load the code that switches you to protected mode later. 16 bit code is so much easier to write, not to mention the BIOS calls are pretty much static at this point.
If you can get the boot loader to work AND load your kernel AND then get a C program to run on your OS you will have gotten farther than a bunch of old Flashdaddeeans.
I got as far as the bootstrap but did not get to loading my kernel. BTW if on the rare chance you do get FAT32 working on your OS if MS finds out about it they will ask for royalties. Not likely they will find out but it's a fair warning.
The main goal for the OS bootup process is to bootstrap (starts at 0000:7C00) and load the kernel into memory and possibly perform a jump to more startup code.
Once you get the assembler code done you will want to move to C/C++ ASAP. The faster you get C code running on your own OS the faster your development time will be.
The one thing that absolutely MUST be coded in pure assembler is the 512 byte bootstrap code. This cannot be done in C. Since this is your first attempt at an OS I recommend a real mode operating system. Startup is easier and you can do interrupts easily. With protected mode you must at least setup the GDT and the IVT and perhaps the LDT. The easiest way in protected mode is to setup a simple 2 descriptor system. Each descriptor would cover 50% of the total system RAM. You would then allocate memory out of this RAM and so forth. One portion is for user code and one portion is for OS code. The Intel tech refs explain this system in great detail.
how would linux deal with that then?Quote:
Originally Posted by Bubba
Thanks everyone.
I guess it's off to learn assembly then.:eek: