OSDev.org

Hi! I have been doing a little bit of designing here and there. I have not had much time to do anything osdev related because I have a job now, but I got a little bit done, and I am looking for your opinions. Thanks!

So the load process is as follows:

On the System-Disk (floppy, there is currently no concept of installing to any non-removable storage device), the system's kernel (doskrnl.exe) and the kernel loader (dosldr.exe); of which, only doskrnl.exe is partially loaded, because of the fact that this 'executable file' contains 16 and 32 bit code; the loader is completely 16 bit, and the boot-sector does this work.

dosldr.exe then does nothing but detect hardware, load drivers, and enable the a20-gate. Once this is done, it moves doskrnl.exe past one megabyte, loads the rest of doskrnl.exe (everything 32 bit), and transfers execitution to it's 16 bit segment.

The 16 bit portion of doskrnl.exe sets up the descriptor tables, enables protected mode (The protected-mode part being everything that is not basic setup code, and everything which is functional), and then starts the actual kernel.

There is no concept of an 'init task' or an 'init process' like others talk about. The entire setup happens within the 16 bit segment of doskrnl.exe, and a very small portion of the non 16-bit code. (Should there be an init process? What would the pros and cons be?)

Really, the only 'setup' code that happens in protected-mode would be stuff like loading libraries, starting system services and kernel-drivers, and stuff like that. If it turns out that an actual process would be better than just wielding this into the kernel, I guess this could be put into a process, but I am trying to keep the concept of a 'process' as exclusive to user-mode as possible, and (POSSIBLY) only make exceptions for (certain) kernel-mode drivers.

Anyway, I think that it's a pretty solid setup routine. But I really would like some opinions and critiques. I feel like I'm taking a lot of inspiration from ntoskrnl.exe, but I don't completely know how it works, anyway, so meh. Hahahahaha

Hi,

Why don't you set up protected mode in the loader, and keep doskrnl.exe purely 32 bit?

Having an init process is a UNIX thing, but if you think about it, quite self-explanatory. There'll be a time when you start your very first user land process, therefore you'll have a process with pid 1. It makes sense to have that as a coordinator for other user space processes. In UNIX /sbin/init is responsible for spawning daemons and services, such as getty to provide you terminals with login prompt. Single user OSes usually start a command line interpreter as the first user space process. Either way, it's the first process that spawns the others.

Cheers,
bzt

bzt wrote:Hi,

Why don't you set up protected mode in the loader, and keep doskrnl.exe purely 32 bit?

Having an init process is a UNIX thing, but if you think about it, quite self-explanatory. There'll be a time when you start your very first user land process, therefore you'll have a process with pid 1. It makes sense to have that as a coordinator for other user space processes. In UNIX /sbin/init is responsible for spawning daemons and services, such as getty to provide you terminals with login prompt. Single user OSes usually start a command line interpreter as the first user space process. Either way, it's the first process that spawns the others.

Cheers,
bzt

Hi...sorry for the late reply.
Ah, okay. Never knew that the whole init thing was Unix thing.

The main reason that wanted to load it that way was an attempt to cram as much functionality of into the boot sector, instead of letting those good bytes go to waste.

I forgot to add that the whole 32 bit kernel thing is not in development right now; I'm still working on a 16-bit DOS-like clone, and eventually, I want to use the code that I have now, and just take what I can and create a 32-bit kernel out of it. My specs for this 32 bit system are just specs, and subject to many changes.

Just getting some info, so that I can figure out how to convert my 16 bit system (kernel, loader, etc) into a 32 bit system in the future.

Thanks,
~Joe

saltlamp wrote:Hi...sorry for the late reply.
Ah, okay. Never knew that the whole init thing was Unix thing.

No worries. Well, having an init process is very common, calling it the "init process" is a typical UNIX terminology.

saltlamp wrote:The main reason that wanted to load it that way was an attempt to cram as much functionality of into the boot sector, instead of letting those good bytes go to waste.

Don't. One of the biggest challange of a programmer is to find the best abstraction layer. I often forget that because with my several decades of experience it comes to me instantly. But I had to learn that, it's not something you born with.

The point is, find the proper abstractions, so to make your code simple and modular. Drawing layer borders at CPU modes (such as 16 bit and 32 bit) makes sense. Then you can compile and link your kernel in a pure 32 bit build environment which simplifies things. On the other hand I would not recommend to put device specific code into the loader as that would ruin your kernel's portability (would tie your OS to a specific device, as you can't easily change the loader code, or you would need many different loader implementations). It is hard to explain what is a good abstraction, you'll have to learn that for yourself by experimenting a lot. Sooner or later you'll see that you can predict the complications of a certain decision in advance, so that you can choose the best solution even before you start coding. But first you'll have to make many many bad choices to learn from them.

saltlamp wrote:I forgot to add that the whole 32 bit kernel thing is not in development right now; I'm still working on a 16-bit DOS-like clone, and eventually, I want to use the code that I have now, and just take what I can and create a 32-bit kernel out of it. My specs for this 32 bit system are just specs, and subject to many changes.

Just getting some info, so that I can figure out how to convert my 16 bit system (kernel, loader, etc) into a 32 bit system in the future.

That's okay, I usually spend 90% of the time with designing and thinking, and I do actual coding the remaining 10% only.

Cheers,
bzt