[Closed Don't Reply] Old Question

[Octacone]

Right now I don't have any skills when it comes to abstraction layers, I think it is too early for me to think about stuff like that. I don't want to implement third party bootloaders because I hate using something that I don't understand. As for now I will continue using GRUB.

[Kevin]

My point is that if the committee that maintains the multiboot specification decided to modify it, then the compatibility issues would be spread across many projects (including most of operating systems originated from this community), so it wouldn't really happen. This way multiboot can't include some more useful features, unless a new version is released each time something wrong with the previous version is detected

Compatible extensions of data structures is often possible without defining a completely new version. For example, Multiboot has flags both in the kernel's header and in the structure passed from the bootloader, which can tell the other party whether a specific extension is supported or not.

[glauxosdever]

Hi,

Right now I don't have any skills when it comes to abstraction layers, I think it is too early for me to think about stuff like that.

You don't necessarily need an abstraction layer, but I don't think it would be really that hard to implement it. Furthermore, the case of determining whether to start a 32-bit kernel or a 64-bit kernel can be very trivial.

I don't want to implement third party bootloaders because I hate using something that I don't understand.

What do you mean by "implement[ing] third party bootloaders"? I think you meant "implement[ing] third-party boot specifications".

In fact, I advice against implementing third-party boot specifications (e.g. multiboot) because you could just as well use a ready bootloader (e.g. GRUB) in this case.

As for now I will continue using GRUB.

It always depends on your goals. You wanted to write your own bootloader, and some people told you not to do it. Fine. But then, you should consider whether the advice these people gave you is applicable.

If one of your goals is to write your own bootloader, then using GRUB is not applicable advice. If one of your goals is to write as less code as possible, then using GRUB may be applicable advice (may, because there are many bootloaders).

If one of your goals is to write a programming language specifically for your OS, then using C/C++ for your OS is not applicable advice. If one of your goals is to write your OS in a programming language people are familiar with, then using C/C++ may be applicable advice (may, because there are many programming language people are familiar with).

If one of your goals is to be compliant with the POSIX/WindowsNT/X/Y API, then rejecting the POSIX/WindowsNT/X/Y API is not applicable advice. If one of your goals is to do something entirely new, then rejecting the POSIX/WindowsNT/X/Y API is applicable advice.

Sometimes however, some people may have compelling arguments that are stronger than your goals. In this case you simply modify your goals to fit the arguments these people gave you.


Regards,
glauxosdever

[glauxosdever]

Hi,

My point is that if the committee that maintains the multiboot specification decided to modify it, then the compatibility issues would be spread across many projects (including most of operating systems originated from this community), so it wouldn't really happen. This way multiboot can't include some more useful features, unless a new version is released each time something wrong with the previous version is detected

Compatible extensions of data structures is often possible without defining a completely new version. For example, Multiboot has flags both in the kernel's header and in the structure passed from the bootloader, which can tell the other party whether a specific extension is supported or not.

In some cases indeed it is possible. But then, since they are only extensions, almost no-one would try to use them most likely.


Regards,
glauxosdever