Page 2 of 2

Re: (Very incomplete) Concept design of an OS

Posted: Thu Aug 14, 2014 12:16 pm
by Marionumber1
iansjack wrote:There's not another good reason for writing a bootloader.
I disagree with that claim. Some people, like me, find that a custom bootloader is useful. It all depends on your OS design. But none of this is truly relevant to the main topic.

Re: (Very incomplete) Concept design of an OS

Posted: Thu Aug 14, 2014 9:16 pm
by SpyderTL
ignus wrote:In your opinion, is it so wrong to give some software full privileges? For example a particular driver that needs to answer to a request in a limited amount of time, it should be easier to archive the goal.
Nope, it's not wrong for drivers to have direct access. But giving applications (MSWord.exe) direct access is probably a bad idea, since it will probably take complete control over your IDE controller and hard drive, and not allow anything else access to it for some unknown amount of time.

Let's think about all of the interfaces involved for a second.

The hardware has it's own, hard-wired interface, which can not be changed. In order for all of your applications to use your various devices, you will need to come up with a high-level interface for each type of device (Hard Drive, Video Card, Sound Card, etc.), and write code that connects these two interfaces together.

Assuming you want to be able to run more than one application at a time (and want more than one application to be able to, say, play audio clips), you will probably want to have the applications communicate with a virtual device, rather than the real device. The virtual device(s) will need to make it look like each application has access to a real device, but in reality, will manage the actual physical device, itself.

The virtual device will be responsible for, say, mixing all of the audio coming from all of your applications into a single audio stream, and sending that stream to the real Sound Card. If you are clever, you can even use the same interface that the applications use to talk to the virtual device to allow your virtual device to talk to the real device. That way, you could give your application direct access by simply giving it the "real" device, instead of the "virtual" one.
ignus wrote:But it's just an impression, never seen/tested/worked on DOS or similar (unfortunatly)
Or, fortunately. :)

Re: (Very incomplete) Concept design of an OS

Posted: Fri Aug 15, 2014 11:49 am
by embryo
iansjack wrote:Writing a bootloader is part of learning and practicing using the tools needed for OS development. (There's not another good reason for writing a bootloader.)
Personal bootloader allows to control the system as tightly as a programmer wishes. No existing bootloader is flexible enough. Also it is possible to keep under tight control all development practices. For example, if a team has the rule of using only Java language, how can the team get flexible bootloader and still use Java only solutions?

Re: (Very incomplete) Concept design of an OS

Posted: Fri Aug 15, 2014 12:05 pm
by SpyderTL
embryo wrote:Personal bootloader allows to control the system as tightly as a programmer wishes. No existing bootloader is flexible enough. Also it is possible to keep under tight control all development practices. For example, if a team has the rule of using only Java language, how can the team get flexible bootloader and still use Java only solutions?
Or if you have written your own custom file system, you will likely need to write a custom boot loader.