OSDev.org

Hello,

I have been interested in osdev and developing my own operating systems for about a year. First of all, I would like to thank OsDev and the OsDev forum for their help.

While developing my own operating system, I had the chance to use more than one bootloader. I think the most well-known of these are GRUB and Limine. In my own development, I thought it was also important to write my own bootloader. Of course, I know this is not necessary at all, but I want to write my own bootloader so that I can understand it more deeply and manipulate my own operating system more easily.

My question is, while the language used in almost all the bootloader tutorials I followed and looked at was Assembly, I saw that C was mainly used in grub or Limine. Of course, it is not possible to write a bootloader without using any assembly, but I thought that much more assembly would be used in these programs. However, it is not as I thought, mainly C is used.

This situation confused me a little. I'm trying to write a bootloader that loads a 64-bit operating system, but I've proceeded almost entirely using assembly. What are your opinions about these bootloaders using C? Thank you from now.

My opinion is that you use the bare minimum of assembly language that is needed. A higher-level language is easier to maintain, less mistake-prone and likely more efficient than pure assembly language.

The reason that tutorials use assembly language and GRUB and the like use C is that tutorials are written by amateurs and GRUB is written by experienced professionals.

iansjack wrote: ↑Mon Jul 08, 2024 5:10 am My opinion is that you use the bare minimum of assembly language that is needed. A higher-level language is easier to maintain, less mistake-prone and likely more efficient than pure assembly language.

The reason that tutorials use assembly language and GRUB and the like use C is that tutorials are written by amateurs and GRUB is written by experienced professionals.

Thank you, this was actually helpfull

With skillful use of the assembly language, one may develop very tiny loaders, fitting into e.g. a 512-byte disk sector (MBR or VBR).
If size isn't a problem, other languages can be used.

Hi,

Quite a few of us have written custom C loaders. So why? Its more easier to modify, extend, easier to incorporate with existing or future tools, and can abstract firmware and hardware specific details from the loaders and loader front end. Want to support a new device (physical, virtual, partition, network, etc.?) Or want to support a new file system? Just write a driver and it'll work for all devices and device types. Want to support a new firmware architecture? Just write a new layer. Want to support UEFI and Legacy BIOS at the same time? Want to support a graphical UI? Want to reuse some of the code for other tools or an installer? Want to support source level debugging? My train of thought is the back-end library and driver kit can be reused for an OS installer or other software - not just the loader. Our loader uses device and driver objects so the architecture allows all of this.

So why do tutorials use assembly? Its easier. That is it. C boot loaders for UEFI however are pretty simple and am sure you can find tutorials on that somewhere. C boot loaders that support Legacy BIOS is more tricky as it requires either unreal mode or switching between processor modes dynamically. I do the latter however I am aware of some doing the former. This uses carefully written assembly linked in C taking into consideration the constraints of multiple processor modes which can be very confusing for new folks. If you are willing to tackle the complexity of writing a C loader then might as well go all the way and design it carefully in accordance with your design goals. Most tutorials were written when UEFI was not an option or not yet widely available - and C boot loaders for Legacy BIOS I would consider an advanced topic.

But honestly, I did consider even tutorials that use assembly for boot loaders are not trivial. It is difficult to cover file systems or to even understand them while trying to fit it within the constraints of all of the other rules needed to develop an assembly loader. File system code is far easier to write and understand in C. So i think would recommend skipping the loader stage initially unless you are very comfortable with the details and willing to spend the time. I think my first loaders were ad-hoc and it took quite a few rewrites to figure out a design that i like. If starting out, using an existing loader is the way to go. Can always go back as you'll most probably end up scrapping the original code anyways as you learn new designs and approaches and eventually discover what you really want.