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.iansjack wrote:There's not another good reason for writing a bootloader.
(Very incomplete) Concept design of an OS
- Marionumber1
- Member
- Posts: 56
- Joined: Sun May 08, 2011 9:03 am
Re: (Very incomplete) Concept design of an OS
Programmer and security enthusiast
DarkSide OS Kernel
Those who do not understand Windows NT are doomed to criticize it, poorly.
DarkSide OS Kernel
Those who do not understand Windows NT are doomed to criticize it, poorly.
Re: (Very incomplete) Concept design of an OS
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.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.
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.
Or, fortunately.ignus wrote:But it's just an impression, never seen/tested/worked on DOS or similar (unfortunatly)
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Re: (Very incomplete) Concept design of an OS
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?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.)
Re: (Very incomplete) Concept design of an OS
Or if you have written your own custom file system, you will likely need to write a custom boot loader.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?
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott