Enable A20 line ( to address the full 4 GB): done by grub
Switch to protected mode and 32 mode: done by grub
VGA Memory text mode management: done
GDT,IDT,PIT,IRQ Remapping: done
Paging: done ;)
Memory management: under development
multitasking: under development
-security,users,sharedpages,priority,copy-on-write
IDE drive: future work
File System
Porting LIBC and Bash and GCC: future work
Executables loader
Inter Process Communication IPC
VM disk swapping
Device support
- DMA
- PnP
- Device drivers
--- MicroKernel
Friday, July 21, 2006
Thursday, July 20, 2006
ArabOS design decisions 1
Design decisoins is something that SW developers do when they program. But OS design decisions have a big influence that one decision can remove and add thousands or even millions of lines of code. Anyway this article is mainly about the design decisions of ArabOS and what I did choose and a rationale.
The first decision is to use a premade bootstrap loader, or a custom one. I read that for new OSs it is better to use a premade loader so one can focus on the development of the system rather than reinventing the wheel. Although I have made the bootstrap loader a long time ago, I decided to use GRUB (Grand Unified Boot Loader). It makes so many things for you. It supports Multiboot, loading from a CD or a flobby. It initialyzes 32-bit protected mode for you. It also queries the BIOS for the reserved memory areas.
The second decision is to use GCC or MSVC. Well, I didn't choose; I tried. Some stuff didn't work with MSVC, especially the multiboot support thing, and special functionality only provided by the linker script of GCC(LD). So I had to move to GCC, since having problems from that early stage, what whould happen after a long time ? (Also GCC have support for OS development)
The third one is to use NASM or GAS. After trying, especially I am not professional in GAS, I had to do stuff in NASM (long jmp didn't compile with GAS, I don't know why). I am using most of the asm files as NASM, but I am intending to move to GAS later.
Next is to develop under Linux or under Cygwin. Actually, Cygwin is PAIN. I can't use ELF file format which prevented me from linking my kernel to run in the upper 2 GB VM (Thanks to GRUB which didn't understand PE file format). But I used Cygwin because I used VMWare. Now using Bochs which run under Linux, I can move to Linux anytime. But I'd rather after a while.
After that paging VS segementation; Upper half VS lower half; has predefined answers. Paging and Upperhalf. Search for them.
C VS C++. Well, C++ in an un-hosted environment is a pain. I have to make the runtime support my self, not even the whole thing. So using C99 is actually fine and comfortable as long as I don't need namespaces, templates, and non-singleton classes.
VGA VS Text-Mode. Text mode. There is tons of VGA drivers out there, XServer+KDE will do it all.
Monolithic VS Microkernel VS Exokernel. In the current phase of development, I am going for monolithic cause of simplicity. Later I can switch to Micorokernel. I don't think Exokernel is an option.
Single or mutiple platforms. Not now, it's too early, so I'd go for single. Same for multiple CPU support.
The first decision is to use a premade bootstrap loader, or a custom one. I read that for new OSs it is better to use a premade loader so one can focus on the development of the system rather than reinventing the wheel. Although I have made the bootstrap loader a long time ago, I decided to use GRUB (Grand Unified Boot Loader). It makes so many things for you. It supports Multiboot, loading from a CD or a flobby. It initialyzes 32-bit protected mode for you. It also queries the BIOS for the reserved memory areas.
The second decision is to use GCC or MSVC. Well, I didn't choose; I tried. Some stuff didn't work with MSVC, especially the multiboot support thing, and special functionality only provided by the linker script of GCC(LD). So I had to move to GCC, since having problems from that early stage, what whould happen after a long time ? (Also GCC have support for OS development)
The third one is to use NASM or GAS. After trying, especially I am not professional in GAS, I had to do stuff in NASM (long jmp didn't compile with GAS, I don't know why). I am using most of the asm files as NASM, but I am intending to move to GAS later.
Next is to develop under Linux or under Cygwin. Actually, Cygwin is PAIN. I can't use ELF file format which prevented me from linking my kernel to run in the upper 2 GB VM (Thanks to GRUB which didn't understand PE file format). But I used Cygwin because I used VMWare. Now using Bochs which run under Linux, I can move to Linux anytime. But I'd rather after a while.
After that paging VS segementation; Upper half VS lower half; has predefined answers. Paging and Upperhalf. Search for them.
C VS C++. Well, C++ in an un-hosted environment is a pain. I have to make the runtime support my self, not even the whole thing. So using C99 is actually fine and comfortable as long as I don't need namespaces, templates, and non-singleton classes.
VGA VS Text-Mode. Text mode. There is tons of VGA drivers out there, XServer+KDE will do it all.
Monolithic VS Microkernel VS Exokernel. In the current phase of development, I am going for monolithic cause of simplicity. Later I can switch to Micorokernel. I don't think Exokernel is an option.
Single or mutiple platforms. Not now, it's too early, so I'd go for single. Same for multiple CPU support.
Monday, July 17, 2006
C# is subway, C++ is automobile
I've been thinking of an analogy between C# and C++ to the real world. Suddenly It popped into my head when I was in the subway. I was thinking of comparing the user of the subway to the driver of a car but it didn't seem fair so I decided to compare the subway driver to the car driver.
As a subway driver you don't have to steer, nor watch for intersections. In C# you don't have to make hard design decision, not to watch for platform support. But as a car driver you have to steer, change gears, and watch your sides even not in an intersection. Likewise in C++, you sometimes have to decide whether to sacrifice one thing for the other, usually memory VS time, or flexibility VS simplicity. You also have to watch different platforms Endianess, int size, and such stuff.
In subway you have predefined stations, and the path is optimized to fit for those, it would be costly to head somewhere that is not near a station. In C# you have predefined intentions in the language and the framework design, you would suffer if you decided to do something that wasn't intended to be done. For example, C# is business-oriented; its classes are best fit for common business tasks; would you consider doing a NASA space shuttle software using it ? In a car, you can virtually go anywhere, provided you have the right directions- and enough gas. Not always the paths will be perfect but some paths can be even shorter than the subway path, If you were an experienced driver or you have a good GPS map. In C++, you can do anything, provided you have the theoretical knowledge- and a linker that can link to ASM in case of system programming. You can do stuff in C++ by nature needs efficiency. Try to write a memory manager (in the system programming context) in C#, it is possible but it would take more time than to do it in C++ WITH the same efficiency.
Driving a subway is boring by nature, but it can be fun if you have a big speed. In C#, you do nothing special, every thing is ready for you. It would be fine in case you are making an enterprise-scale project. In a car, driving is boring and hell for people who can't drive well, they will keep banging in every turn, but if you know the tricks of it, and fair knowledge of the motor and its capabilities, you can do magic- see NFS: Underground 2. In C++, it is hard and ugly code if you don't have the essence of mastering it. If you do, you Will enjoy it, and can do software you never imagined it is possible- read for an example about loop-unrolling.
You would absolutely use subway if you are gonna a predefined place and you don't want to make a lot of effort. But you would use the car for a custom path that is not in the subway's map. Same in C# and C++, you don't have to use only one for all of the time. Just use what is suitable for what you wanna do. And remember, knowing only how to use the subway or the car, is not good enough, cuz at some point you will need the other.
Finally, some points here may have personal influence because I like C++. I admit I hate using C++ for some tasks, but I like its power and flexibility regardless of its complexity.
If you have another opinion or seeing something missing, you are welcome to comment.
As a subway driver you don't have to steer, nor watch for intersections. In C# you don't have to make hard design decision, not to watch for platform support. But as a car driver you have to steer, change gears, and watch your sides even not in an intersection. Likewise in C++, you sometimes have to decide whether to sacrifice one thing for the other, usually memory VS time, or flexibility VS simplicity. You also have to watch different platforms Endianess, int size, and such stuff.
In subway you have predefined stations, and the path is optimized to fit for those, it would be costly to head somewhere that is not near a station. In C# you have predefined intentions in the language and the framework design, you would suffer if you decided to do something that wasn't intended to be done. For example, C# is business-oriented; its classes are best fit for common business tasks; would you consider doing a NASA space shuttle software using it ? In a car, you can virtually go anywhere, provided you have the right directions- and enough gas. Not always the paths will be perfect but some paths can be even shorter than the subway path, If you were an experienced driver or you have a good GPS map. In C++, you can do anything, provided you have the theoretical knowledge- and a linker that can link to ASM in case of system programming. You can do stuff in C++ by nature needs efficiency. Try to write a memory manager (in the system programming context) in C#, it is possible but it would take more time than to do it in C++ WITH the same efficiency.
Driving a subway is boring by nature, but it can be fun if you have a big speed. In C#, you do nothing special, every thing is ready for you. It would be fine in case you are making an enterprise-scale project. In a car, driving is boring and hell for people who can't drive well, they will keep banging in every turn, but if you know the tricks of it, and fair knowledge of the motor and its capabilities, you can do magic- see NFS: Underground 2. In C++, it is hard and ugly code if you don't have the essence of mastering it. If you do, you Will enjoy it, and can do software you never imagined it is possible- read for an example about loop-unrolling.
You would absolutely use subway if you are gonna a predefined place and you don't want to make a lot of effort. But you would use the car for a custom path that is not in the subway's map. Same in C# and C++, you don't have to use only one for all of the time. Just use what is suitable for what you wanna do. And remember, knowing only how to use the subway or the car, is not good enough, cuz at some point you will need the other.
Finally, some points here may have personal influence because I like C++. I admit I hate using C++ for some tasks, but I like its power and flexibility regardless of its complexity.
If you have another opinion or seeing something missing, you are welcome to comment.
Friday, July 14, 2006
ArabOS news 1
Hiiii again :D
Finally I have managed to fix some annoying bugs about the cursor update and the programmable interval timer. I also have added a starter basic keyboard support. It seems clear now how to support DMA, and support devices. I am now being busy in reading about paging and virtual memory. Process management needs memory management. And virtual memory needs a file system. So I will not support VM now, just physical memory. You can visit http://del.icio.us/meemoxp for links about all that. I add each link I see interesting to it.
A quick summary about the OS state:
PIT: working fine.
Terminal: very basic but working fine.
KB: very basic and working fine.
I mean by very basic that the H/W stuff is working and all the remaining features are software stuff.
And by the way, another killer bug was also for using && instead of & !!!
The most of the past weeks was mainly for cleaning the code, setting constants instead of magic values, commenting on code, editing the makefile and well-structuring it, modifying the linker script, and fixing some bugs.
The main problem that you can't count on the code working well for being bug-less, and that you can't count that there is no better way of doing things. You also can't count that you know all features provided by each of the chipsets on the mother board, like APIC etc. You also can't count that you can catch and solve all the exceptions (especially hardware ones) because some may only occur at very rare occasions. Some exceptions once discovered might make you change more than 3 files and change a big structure of the system, especially at this early stage of development.
I am now going for monolithic kernel, not microkernel, and going for stack-swapping for process scheduling, not TSS.
Finally I have managed to fix some annoying bugs about the cursor update and the programmable interval timer. I also have added a starter basic keyboard support. It seems clear now how to support DMA, and support devices. I am now being busy in reading about paging and virtual memory. Process management needs memory management. And virtual memory needs a file system. So I will not support VM now, just physical memory. You can visit http://del.icio.us/meemoxp for links about all that. I add each link I see interesting to it.
A quick summary about the OS state:
PIT: working fine.
Terminal: very basic but working fine.
KB: very basic and working fine.
I mean by very basic that the H/W stuff is working and all the remaining features are software stuff.
And by the way, another killer bug was also for using && instead of & !!!
The most of the past weeks was mainly for cleaning the code, setting constants instead of magic values, commenting on code, editing the makefile and well-structuring it, modifying the linker script, and fixing some bugs.
The main problem that you can't count on the code working well for being bug-less, and that you can't count that there is no better way of doing things. You also can't count that you know all features provided by each of the chipsets on the mother board, like APIC etc. You also can't count that you can catch and solve all the exceptions (especially hardware ones) because some may only occur at very rare occasions. Some exceptions once discovered might make you change more than 3 files and change a big structure of the system, especially at this early stage of development.
I am now going for monolithic kernel, not microkernel, and going for stack-swapping for process scheduling, not TSS.
Subscribe to:
Posts (Atom)