Generic bootloader

[Griwes]

Still, without macros, you would need to copy-paste entire loading and jumping code into every filesystem's bootsector...

[rdos]

Hi,

That information is put in the image itself. It knows that it wants to be loaded in protected mode with paging disabled, or that it wants to be loaded in long mode with paging enabled. It is better to let the OS image supply this data rather than a configuration file, which eventually would be edited by an user that might not know the details of the OS image.

So that when a monitor doesn't accept some sort of a VBE mode (and the OS can't detect that), the user won't be able to change the configurations (or do so via something more tough than just changing a file)?

While I know this is part of UEFI, I don't think the boot-loader should mess with VBE modes. That task should be left to the device-driver that handles VBE. For instance, I'll refuse to accept the idea that video mode should be setup at boot time, and I will keep my functionality to dynamically change video mode as much as possible, and letting the VBE driver emulate video-mode changes (particulary text mode) only if absolutely necessary.

[Griwes]

As far as I was observing what Windows (8 at least) does at boot, it first changes mode into something lower than my max resolution (probably 1024x768), and I think that's because it wants to have ANY video mode before loading device drivers. And STAYS in it if there is none. I'm fairly sure it doesn't use crazy magic of 8086 emulation to do just that. In theory, that's why you have VBE/UEFI video protocols - to set up something temporary in easy way, and fall back to using it longer if you have no drivers for present hardware.

So, rdos, you just went full of retard.

[bluemoon]

My FAT16 code consist of 10 lines of code for the jump and registers setup, the other 90% code is the ReadFile API.

I could imagine each FS-stage has 10 lines of code in common, it's just not worth to introduce an entity - and by the way, the jump for HDD is different for CD, and there is no jump for PXE - so you can't actually do a universal macro for all loaders.

[Griwes]

You know, there is a difference between "each bootloader" and "1st stage for FSes that loads 2nd stage/FS driver/whatever". This was meant for bootsectors only, for partitions with "standard" boot from HDD - that is, read X sectors from Yth sector and jump to it. It's pretty the same for each filesystem out there - unless you do heavy filesystem parsing just in 1st stage...

[bluemoon]

It is the same if:
1. the VBR itself contain all the required FS code (we call that stage 1).
2. the VBR in turn loads extra sector for required FS code (we may call that stage 1 + 1.5).

For all intent and purpose it's the same in current discussion context, either way the code shared by different stage 1 ( or stage1+1.5 combo) is narrow, and not all stage 1 (or stage 1+1.5) have the same prologue code.

And if we limit the FS code to a restricted functionality(you don't need code to delete file, or decide to don't support sub-directory), it can be easily fit into the VBR.

[Griwes]

So in your scheme, without providing FS-agnostic parts, FS driver etc., someone implementing his own FS would need to reimplement the bootloader - not just implement FS support for it. I don't see the point of writing generic bootloader, then.

Also, there are other common things to be done than loading - memory map getting, parsing and sanitizing, VBE mode to be set, PIT/(IOA)PIC to be masked. In that way, if 1st stage barely loads X sectors from Yth sector (and I'm positive that it's possible to do with every FS out there - I mean, continuous sectors for one specific file, or reserved sectors) that contain 2nd stage, which does all the remaining things - memory map, vbe mode chaning, CPU mode setting, interrupt masking etc. - and only uses Z sectors starting from Wth sector as filesystem driver with strictly defined API to load specific file from filesystem - the common code never needs to be reimplemented, and in case of common 2nd stage code, never needs to be reassembled, when using different filesystem. The only things that would need to be reassembled would be bootsector (so it doesn't override some FS structures, or BPB if required, or w/e) - using exactly same code, but at potentially different offsets for different filesystems - and FS driver.

[bluemoon]

No, perhaps you missed the post about my design.

In short, the VBR (and there is no reason you cannot load more sectors behind the scene unless the specification forbid it) contain the FS specific code, and load boot.bin, it's the boot.bin that handle the business logic - using uniform API exposed by former stages.

[rdos]

As far as I was observing what Windows (8 at least) does at boot, it first changes mode into something lower than my max resolution (probably 1024x768), and I think that's because it wants to have ANY video mode before loading device drivers. And STAYS in it if there is none. I'm fairly sure it doesn't use crazy magic of 8086 emulation to do just that. In theory, that's why you have VBE/UEFI video protocols - to set up something temporary in easy way, and fall back to using it longer if you have no drivers for present hardware.

So, rdos, you just went full of retard.

64-bit Windows no longer supports running the command shell in text-mode because it cannot use V86 mode to call the video-BIOS to change modes. And when the protected mode VBE interface is buggy (and thus unusable), they have no other choice.

Thus, this idea that you cannot change video-mode dynamically is not a design-feature, rather a consequence of bad design-choices by hardware manufacturers and BIOS developpers.

[Griwes]

As far as I was observing what Windows (8 at least) does at boot, it first changes mode into something lower than my max resolution (probably 1024x768), and I think that's because it wants to have ANY video mode before loading device drivers. And STAYS in it if there is none. I'm fairly sure it doesn't use crazy magic of 8086 emulation to do just that. In theory, that's why you have VBE/UEFI video protocols - to set up something temporary in easy way, and fall back to using it longer if you have no drivers for present hardware.

So, rdos, you just went full of retard.

64-bit Windows no longer supports running the command shell in text-mode because it cannot use V86 mode to call the video-BIOS to change modes. And when the protected mode VBE interface is buggy (and thus unusable), they have no other choice.

Thus, this idea that you cannot change video-mode dynamically is not a design-feature, rather a consequence of bad design-choices by hardware manufacturers and BIOS developpers.

While I know this is part of UEFI, I don't think the boot-loader should mess with VBE modes. That task should be left to the device-driver that handles VBE. For instance, I'll refuse to accept the idea that video mode should be setup at boot time, and I will keep my functionality to dynamically change video mode as much as possible, and letting the VBE driver emulate video-mode changes (particulary text mode) only if absolutely necessary.

Oh, so now you disagree with yourself.

Also, it's rather natural that you cannot change the video mode dynamically if you don't have video drivers; both BIOS and UEFI need specific execution environments, that just cannot be kept endlessly. It's rather a technical impossibility to have a graphic-card agnostic way to change video mode dynamically... unless you make graphic card manufacturers to create common standard MMIO interface, which they won't for obvious reasons.

[rdos]

As far as I was observing what Windows (8 at least) does at boot, it first changes mode into something lower than my max resolution (probably 1024x768), and I think that's because it wants to have ANY video mode before loading device drivers. And STAYS in it if there is none. I'm fairly sure it doesn't use crazy magic of 8086 emulation to do just that. In theory, that's why you have VBE/UEFI video protocols - to set up something temporary in easy way, and fall back to using it longer if you have no drivers for present hardware.

So, rdos, you just went full of retard.

64-bit Windows no longer supports running the command shell in text-mode because it cannot use V86 mode to call the video-BIOS to change modes. And when the protected mode VBE interface is buggy (and thus unusable), they have no other choice.

Thus, this idea that you cannot change video-mode dynamically is not a design-feature, rather a consequence of bad design-choices by hardware manufacturers and BIOS developpers.

While I know this is part of UEFI, I don't think the boot-loader should mess with VBE modes. That task should be left to the device-driver that handles VBE. For instance, I'll refuse to accept the idea that video mode should be setup at boot time, and I will keep my functionality to dynamically change video mode as much as possible, and letting the VBE driver emulate video-mode changes (particulary text mode) only if absolutely necessary.

Oh, so now you disagree with yourself.

Not at all. Windows cannot do it because they cannot switch to protected mode dynamically. However, I suppose we discuss boot-loaders that can load OSes that run in various modes, and it is only long mode OSes that cannot handle dynamically switching VBE mode.

Also, it's rather natural that you cannot change the video mode dynamically if you don't have video drivers; both BIOS and UEFI need specific execution environments, that just cannot be kept endlessly. It's rather a technical impossibility to have a graphic-card agnostic way to change video mode dynamically... unless you make graphic card manufacturers to create common standard MMIO interface, which they won't for obvious reasons.

The UEFI guys could have put video mode changes as a dynamic service that could be run at any time. The BIOS guys could have provided a bug-free protected mode VBE interface. AMD could have supported V86 mode in long mode. There is no need for a common MMIO interface, but rather a piece of software that the OS can use to switch modes.

[Griwes]

Not at all. Windows cannot do it because they cannot switch to protected mode dynamically. However, I suppose we discuss boot-loaders that can load OSes that run in various modes, and it is only long mode OSes that cannot handle dynamically switching VBE mode.

Add "dynamically switching VBE mode without stupid hacks" and you can extend "long mode OSes" to "pmode and lmode OSes".

The UEFI guys could have put video mode changes as a dynamic service that could be run at any time. The BIOS guys could have provided a bug-free protected mode VBE interface. AMD could have supported V86 mode in long mode. There is no need for a common MMIO interface, but rather a piece of software that the OS can use to switch modes.

@UEFI: no, because you might've changed something card specific and it could not work. @BIOS, keep in mind that there was no point to do so, since you generally set VBE mode at boot and it's JUST A FALLBACK in case you don't have device drivers that are responsible for providing dynamic mode switching functionality. @AMD, bless them for dropping that silly hack.

[dozniak]

It seems to me that you're designing GRUB here, folks.

No trolling, despite some weaklings attempting to pose it so.

[Combuster]

You already made your point two pages back. You've been given counterarguments in return. Now you repeat the exact same point just for the sake of it which is a really bad idea - it adds absolutely nothing to the discussion and only gets more frustrations aimed at you.

[dozniak]

Sorry, it just seems way to obvious to me.

You want to support different boot modes via modules - grub has them, you wan to support different filesystems support through modules and different stages - grub has them, and so on.