making a simple operating system
Author
I have been reading this book about operating systems and it certainly has kept me interested and now I want to try implementing my own type of operating system (just for fun, I certainly don't expect to compete with the likes of modern systems). I will do this on a computer I'm not using for anything else so I don't have to worry about wiping out the hard drive or anything like that.
First off however, I want to learn how to get the bootstrap program (which is hardwired into EPROM I think so I can't change it) to load my OS, but before I actually go about coding an actual OS I just want to test it via various simple programs. The first one should output hellow world or a colored quad to the screen while maybe another will take in keyboard input and manipulate and output the results. By experimenting this way for awhile, I could get a feel for things work at the low level and how to interact with the hardware when I actually go about designing my OS.
So basically I am looking for advice, such as is there I a way I could write a simple C program onto a cd drive or floppy and have it be executed by the boot program?
On startup the program placed on the bootsector of the HD will be run (it has a limited size); First, you should find a way to get something on the boot sector and then write your OS. What are you aiming for? A multithreading OS or something like DOS?
Author
Eventually I want to experiment with multithreading but for now I just want to run simple C programs in order to learn how to interact with the hardware.
I am wondering if I would be able to use visual c++ to compile a program, and then disassemble the executable, and write the assembly code to the boot sector of a floppy disk? This is assuming I restrict my code to simple operations and don't do things like access win32 specific functions.
[Edited by - Khaos Dragon on January 10, 2005 4:28:02 AM]
I am wondering if I would be able to use visual c++ to compile a program, and then disassemble the executable, and write the assembly code to the boot sector of a floppy disk? This is assuming I restrict my code to simple operations and don't do things like access win32 specific functions.
[Edited by - Khaos Dragon on January 10, 2005 4:28:02 AM]
I don't think that would work.
What you might want to do, tho, is make a simple vm.
That allows you to do the things your used to doing (ie. changing vram, ect.) Safely, it also lets you add multi-tasking support, internal to the vm.
it'd be a real nice experement, if you have a hack-prof vm, no program could ever know that another existed, and it would be impossible to get a virus!
Either that, or some sort of lisp interpriter (easy to make, if you make your own dialect, you can select what you want it to do)
From,
Nice coder
What you might want to do, tho, is make a simple vm.
That allows you to do the things your used to doing (ie. changing vram, ect.) Safely, it also lets you add multi-tasking support, internal to the vm.
it'd be a real nice experement, if you have a hack-prof vm, no program could ever know that another existed, and it would be impossible to get a virus!
Either that, or some sort of lisp interpriter (easy to make, if you make your own dialect, you can select what you want it to do)
From,
Nice coder
I'd recomend two things:
Use GRUB for your bootloader, it'll take care of things like switching to PMode and activating the A20 line (which when activated allows you to address all of the memory rather than just 1mb, strangely you activate by talking to the keyboard controller x86 architecture can be rather odd sometimes [grin]). You'll need to add a multiboot header to your kernel image, which isn't too hard just take a look at the multiboot specification here.
Use bochs which is a free x86 emulator, this will make things like testing and debugging easier during development.
Oh and I wouldn't bother writing something like VC++ decompiling and then using the assembler from that, it'd be far easier just to the write the assembler yourself (NASM is a nice assembler that you can use), you can get away with writing minimal inline ASM for things like accessing ports setting up the GDT, LDT, calling interrupts etc. You can do all your development in VC++ you've just got to be careful at the linking stage and use /NODEFAULTLIB so that VC++ doesn't link in anything you don't want. I'd also write everything in C as opposed to C++ (at first anyway) as this would make things easier as with C++ you have some extra things to take care of to make sure everything works. I'm not sure if grub supports PE files but if it does this will make things easier.
Use GRUB for your bootloader, it'll take care of things like switching to PMode and activating the A20 line (which when activated allows you to address all of the memory rather than just 1mb, strangely you activate by talking to the keyboard controller x86 architecture can be rather odd sometimes [grin]). You'll need to add a multiboot header to your kernel image, which isn't too hard just take a look at the multiboot specification here.
Use bochs which is a free x86 emulator, this will make things like testing and debugging easier during development.
Oh and I wouldn't bother writing something like VC++ decompiling and then using the assembler from that, it'd be far easier just to the write the assembler yourself (NASM is a nice assembler that you can use), you can get away with writing minimal inline ASM for things like accessing ports setting up the GDT, LDT, calling interrupts etc. You can do all your development in VC++ you've just got to be careful at the linking stage and use /NODEFAULTLIB so that VC++ doesn't link in anything you don't want. I'd also write everything in C as opposed to C++ (at first anyway) as this would make things easier as with C++ you have some extra things to take care of to make sure everything works. I'm not sure if grub supports PE files but if it does this will make things easier.
Author
Interesting suggestions, one of my first projects when learning how to program was making up my own scripting language interpreter. It was real ugly and I am sure not very efficient compared to the standard ones, but it still ran fast.
Anyways, a virtual machine does sound fun but I think for now I want to do a real machine as a learning experiment and especially to learn how a real machine interacts with hardware.
Anyways, a virtual machine does sound fun but I think for now I want to do a real machine as a learning experiment and especially to learn how a real machine interacts with hardware.
What you could do (and I believe Linux worked like this in the beginning) is to make your os a DOS-executable. So you install DOS on your machine, you get a compiler for DOS (preferably one able to compile protected mode programs) on another machine.
Then you write your os. The first thing your os should do when starting up, though, is to kick out DOS, that is replace all irq-vectors with your own stuff. This way you can exchange part after part of DOS without having to write a whole os from scratch.
You could keep the same executable format as DOS for starters, which would simplify writing programs since you don't have to write your own compiler as well (or at least a back-end for GCC).
Good luck!
Then you write your os. The first thing your os should do when starting up, though, is to kick out DOS, that is replace all irq-vectors with your own stuff. This way you can exchange part after part of DOS without having to write a whole os from scratch.
You could keep the same executable format as DOS for starters, which would simplify writing programs since you don't have to write your own compiler as well (or at least a back-end for GCC).
Good luck!
I found a tutorial about boot sector usage long ago, and I'm hosting a copy at http://misc.psychosanity.com/vul-2.zip. I used it to help me make my Boot Sector Tic-Tac-Toe(which can act as a second example for how to do boot sector stuff since source is included).
As was said, you can write most of your code in C/C++, just make sure it doesn't link it with the standard libs, as they won't exist on your new OS. (Might have to strip the file of the extra headers and stuff that's added to .exe files as well, so the file only contains native code. Not sure if VC++ can do that directly)
This also adds a few restrictions to C++. As far as I can remember, constructors and destructors will have some limitations, execution starts at the first defined function instead of main, and you have to use C style linkage to be able to call them from your assembler code. At least those were some of the restrictions we ran into when we made a kernel last year at uni. I'm not sure how general this all is though. (We used Linux and G++ for development, which might change a few things, and our target computer was an Alpha, so again, might have some different issues there).
Anyway, good luck. I found it to be a really fun project when we did it. Especially adding multithreading was fascinating. Hope you get around to adding that. :D
Debugging stuff like this can be a major headache though.
This also adds a few restrictions to C++. As far as I can remember, constructors and destructors will have some limitations, execution starts at the first defined function instead of main, and you have to use C style linkage to be able to call them from your assembler code. At least those were some of the restrictions we ran into when we made a kernel last year at uni. I'm not sure how general this all is though. (We used Linux and G++ for development, which might change a few things, and our target computer was an Alpha, so again, might have some different issues there).
Anyway, good luck. I found it to be a really fun project when we did it. Especially adding multithreading was fascinating. Hope you get around to adding that. :D
Debugging stuff like this can be a major headache though.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
