Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
It's just a little time that I'm working on my Operating System(I would like to make my "own" DOS), I've already done a simple Bootloader but now I'm stuck with the developing of the kernel. I know what a kernel does and I know some basically things like the programming of the int21h or other basic operation (I forgot to say that I would like to do a 16-bit DOS to avoid problems with the drivers for the VGA, devices...) and at the moment I've programmed 4-5 functions of the int21h like the output and input of chars and strings. Now I want to work on the devices and then on the FAT, directories, files etc. etc. Where should I start? I saw a thing named Drive Parameter Block thanks to I should know some informations about the devices on my computer. This DPB is important for the 32h function of the int21h that I should write, is this function really important? Must I write this function to read a floppy or a cd? Or is it better to program the other functions and overcome this one?
I don't know because I'm planning to implement all the most common programs that other DOS have(MS-DOS, FreeDOS...). For example to read from an external device do I need that function? If it's important how can I program it?(I'm talking about the ah=32h funct of the int21h) Because if it's not important it would be fantastic!
You must implement all functions used by a program in order to run that program.
If you write the program, you get to decide which functions it uses.
alex00 wrote:For example to read from an external device do I need that function?
If you want to read from a USB device, you will need to stop using the BIOS, so you should probably consider that before you continue working on your kernel.
Mhh...anyway at the moment I'm programming this function because I've read that when I will use an external device like a USB pen I can use some parameters from this table instead of getting them every time. Also because I want my kernel to load .com programs and generaly programs written in C/C++ so this interrupts are basically I think. Aren't them?
It's just a little time that I'm working on my Operating System(I would like to make my "own" DOS), I've already done a simple Bootloader but now I'm stuck with the developing of the kernel. I know what a kernel does and I know some basically things like the programming of the int21h or other basic operation (I forgot to say that I would like to do a 16-bit DOS to avoid problems with the drivers for the VGA, devices...) and at the moment I've programmed 4-5 functions of the int21h like the output and input of chars and strings. Now I want to work on the devices and then on the FAT, directories, files etc. etc. Where should I start? I saw a thing named Drive Parameter Block thanks to I should know some informations about the devices on my computer. This DPB is important for the 32h function of the int21h that I should write, is this function really important? Must I write this function to read a floppy or a cd? Or is it better to program the other functions and overcome this one?
Thanks everybody
Are you registered in any IM services? Facebook etc. If yes, write to the private messages.
And, for your OS:
1) RM is obsolete.
2) Use GRUB2, do not do the dirty work, it'll do it for you.
3) Implement the VM8086 (I can help) and use it. Why? See №1.
4) Do not, just do not use BIOS interrupts for screen and KBD I/O. It's slow.
5) About 32h function - I don't know.
catnikita255 wrote:
Are you registered in any IM services? Facebook etc. If yes, write to the private messages.
And, for your OS:
1) RM is obsolete.
2) Use GRUB2, do not do the dirty work, it'll do it for you.
3) Implement the VM8086 (I can help) and use it. Why? See №1.
4) Do not, just do not use BIOS interrupts for screen and KBD I/O. It's slow.
5) About 32h function - I don't know.
About the bootloader I've already done all the dirty work so it's done
About the RM and the VM8086, can I use interrupts in VM8086? I want to do a simple DOS in real mode and interrupts are just to make my work less hard. And my goal is to make a DOS which supports MS-DOS programs so I have to run it in real mode (I think).
catnikita255 wrote:
Are you registered in any IM services? Facebook etc. If yes, write to the private messages.
And, for your OS:
1) RM is obsolete.
2) Use GRUB2, do not do the dirty work, it'll do it for you.
3) Implement the VM8086 (I can help) and use it. Why? See №1.
4) Do not, just do not use BIOS interrupts for screen and KBD I/O. It's slow.
5) About 32h function - I don't know.
About the bootloader I've already done all the dirty work so it's done
About the RM and the VM8086, can I use interrupts in VM8086? I want to do a simple DOS in real mode and interrupts are just to make my work less hard. And my goal is to make a DOS which supports MS-DOS programs so I have to run it in real mode (I think).
OK. And I'll repeat: Are you registered in any IM services?
catnikita255 wrote:And, for your OS:
1) RM is obsolete.
2) Use GRUB2, do not do the dirty work, it'll do it for you.
3) Implement the VM8086 (I can help) and use it. Why? See №1.
4) Do not, just do not use BIOS interrupts for screen and KBD I/O. It's slow.
5) About 32h function - I don't know.
As he is trying to make a DOS clone, it doesn't seem too unreasonable to use real mode. That'll be much simpler than trying to run everything in V86 mode, unless he's wanting to "improve" on DOS such as by implementing multitasking or whatever.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
onlyonemac wrote:As he is trying to make a DOS clone, it doesn't seem too unreasonable to use real mode. That'll be much simpler than trying to run everything in V86 mode, unless he's wanting to "improve" on DOS such as by implementing multitasking or whatever.
Yes, at the moment I'm trying to make a sort of DOS clone (but with some personal feature obviusly). I'll try things like multitasking when I will do a 32 bit OS, but first I want to finish the 16 bit one so I can use part of that code for the 32 bit OS (putting the drivers instead of the interrupts).
Just a personal opinion, but if you are planning a Protected Mode OS I think that almost everything that you now do in Real Mode will be a waste of time. And you will end up having to unlearn a lot that you learn now. Unless you are going to rely on BIOS interrupts to do all the interesting bits for you, Real Mode programming is harder than Protected Mode.
A DOS clone is of no interest to me, so I can't comment further on your current problems.
iansjack wrote:Just a personal opinion, but if you are planning a Protected Mode OS I think that almost everything that you now do in Real Mode will be a waste of time. And you will end up having to unlearn a lot that you learn now. Unless you are going to rely on BIOS interrupts to do all the interesting bits for you, Real Mode programming is harder than Protected Mode.
In my opinion; it'd make far more sense to use long mode - e.g. identity map the physical address space, and provide an API that 64-bit applications can use to read/write files, allocate/free memory, get/set the time, do (unicode) console text output, set graphics video modes, etc.
The beautiful part of this idea is that the entire "OS" can be implemented in less than 30 seconds (assuming modern hardware). All you need to do is create a text file with a single sentence: This "OS" requires UEFI.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
The one objection I would have to going straight to Long Mode is that it requires paging, which is an additional complication for a novice. Most lessons learnt in Protected Mode are applicable to Long Mode, so it is a useful intermediary. Targeting very modern hardware only seems a little overrestrictive.
iansjack wrote:Just a personal opinion, but if you are planning a Protected Mode OS I think that almost everything that you now do in Real Mode will be a waste of time. And you will end up having to unlearn a lot that you learn now. Unless you are going to rely on BIOS interrupts to do all the interesting bits for you, Real Mode programming is harder than Protected Mode.
A DOS clone is of no interest to me, so I can't comment further on your current problems.
My project consists in making a DOS which supports MS-DOS executable and I will start to build a version which uses BIOS interrupts and then I will write my own drivers. Then I will modify these drivers and implement them in the 32 bit OS (drivers are the same in Real Mode and Protected Mode). I think that it's a good way to learn all the steps and to do everything starting from the bottom.
