iansjack wrote:Not quite true. One of the features of protected mode is to allow the operating system to impose limitations on what userland programs can do. (But you don't have to choose to do that if - for some inexplicable, crazy reason - you don't want to.) This is a significant increase in the capabilities of the OS. Very few people start off their OS design by saying "I want userland programs to have the ability to trash each others memory and (important in view of your previous remarks) overwrite the IDT so even the timer interrupt doesn't work".
Yea, my point exactly. I never said that the limitations were bad just that the point of protected mode was to add limitations that limit the effect programs can have on the operating system not to remove limitations on programs since in real mode they don't have any.
Also in my previous remarks I just meant the system would keep working if they mess up a single non-essential interrupt handler i.e. a keyboard handler not IRQ 0.
bluemoon wrote:I don't quite get you here.It's your kernel that swap the process out, why don't you know the location? Just think a way to pass this information out, like storing on process's information node.
Ah, but it's not the kernel that swaps processes out. This task is done by an independent multitasking layer. The multitasking layer keeps track of who's who and how they access certain resources plus any global variables. The kernel has many API calls which can be called by programs and contain temporary buffers with their workings that need to be preserved.
Each process has it's own copy of the kernel, which it uses independently as it would in a monotasking environment except it gets interrupted at timer ticks and shifted in and out of memory and the low level BIOS interface that it uses is manipulated by the multitasking layer to change the effect of it's actions depending on the conditions.
Prochamber wrote:What if the task is paused or killed before the request is complete? The data might never be collected
The kernel need to handle resource cleanup upon task end, including process's memory, buffers, locks and perhaps device's handle.[/quote]
Brendan wrote:Who cares? You'd only care which address the task wants when you're copying data from the cache to the task (reads) or from the task to the cache (writes). Further, you won't be switching tasks if any actual disk IO is involved because your entire OS will be "locked up" (waiting) while it's using BIOS's "int 0x13" code. Also note that if you had your own drivers for disk IO there still wouldn't be any problem because the driver would be reading/writing data into the cache and not into the task's buffer.
I meant if I used caching instead of freezing the system. I suppose having a disk cache for each task would be realistic, I can have a 32k memory handle for each task that data gets put if when it arrives. However looking at the disk controller specifications on the OSDev Wiki they are anything but simple. Even a floppy disk controller is very complex. If I do add disk drivers, it might need to be a few more releases down the track.
Brendan wrote:I was hoping you'd be smart enough to see how it works and implement your own version (or just make whatever changes) based on the same simple/easy idea. I was also hoping that (after seeing how simple/easy it is) you'd realise that not using protected mode is completely and utterly pointless; and that it doesn't prevent you from using the BIOS and doesn't prevent you from achieving any of your goals (e.g. you'd still be able to make an extremely bad OS despite using protected mode a little).
Protected mode is certainly an interesting idea but I'm fine with real mode. I really don't see any reason why I should go to the effort of rewriting my operating system for protected mode when real mode works fine for me as it always has. I'm not saying that there is anything wrong with protected mode but it's just not for me.
Brendan wrote:Why would you have a maximum of only 16 tasks and a maximum of only 8 MiB? Are you worried that someone might think you're a competent programmer, or is there some sort of "worst OS possible" contest where you might win a banana?
I learnt from MikeOS, which taught me that making operating systems isn't about jumping right into complex features and implementing
them in the most complex way imaginable. Sixteen tasks is more than enough for what I need.
In a standard system I might be running:
- A kernel service
- A graphical interface service
- A rendering service (maybe even part of the interface service)
- A text editor
- Another Desktop Program
I can't really see where all sixteen tasks would go. I only have five windows open on the operating system I am using to write this post and most of the system tasks are complex things I wouldn't need in my operating system anyway. I would have thought that sixteen tasks would be enough for almost all the operating systems on this site.
I am a realist. I do not want to waste years on something that it too complex and difficult for me to ever complete. I know what I can do in a realistic time frame and I know what I can't. If there is some way to make my job easier I will take it because it will allow me to create something better in the same time frame. BIOS happens to do this so I use it. Writing my own disk drivers does not.
If I want to write my own disk drivers, I will do that at a later release. For now I will work on getting the multitasking system working
then add features to it. I'd rather do what I do now and have frequent releases, slowly adding features than spend years building up to some almighty release that I may or may not finish. It's worked well for me so far.
On subject of competitions I don't think you're going to win and for politeness. I see that your next post will be your 5000th on this forum, so I recommend you have a good rest and a few extra teaspoons of sugar in your morning coffee before hand.
