FAT32 (kernel loading) bootsector

[TebexPL]

I some time ago i saw similar project on Github, but it only loaded first file on FAT32 partition. I've decided to make bootloader that:
1. Finds first FAT32, bootable partition
2. Searches for specified file(in root directory)
3. Loads and executes it

Another part that is different, is my custom script(made on ubuntu so it's not for windows) which:
1. lets you choose filename that bootloader will search for
2. lets you very easily choose device/partition for bootloader(writes bootsector on specified device - of course leaving MBR ,and sets boot flag on specified partition)

For me, and i think a lot of you guys this is a fast way to just run script, copy your extended loader(or small kernel) on a device and run OS on real hardware

If you want to check it out: https://github.com/TebexPL/FAT32-Bootsector

[zaval]

your code only checks for 0x0b in the OSType field. This is not how FAT32 is detected. There might be FAT12/FAT16 with that marker, or there might be FAT32 with a different marker. Also because of the same reason, your code will fail at Protective MBR. They should be common now.
Of course it's much easier to only check for 0x0b in one field rather than doing all those calculations as described in the spec, but that's how it should have been done should it be a "FAT32 boot sector".

[TebexPL]

your code only checks for 0x0b in the OSType field. This is not how FAT32 is detected. There might be FAT12/FAT16 with that marker, or there might be FAT32 with a different marker. Also because of the same reason, your code will fail at Protective MBR. They should be common now.
Of course it's much easier to only check for 0x0b in one field rather than doing all those calculations as described in the spec, but that's how it should have been done should it be a "FAT32 boot sector".

Well, that's what i will be trying to change in near future. Thanks for advice.

And by "Protective MBR" you mean GPT? I'm not sure if GPT handling and making sure it's FAT32 will fit in 446 bytes

[zaval]

your code only checks for 0x0b in the OSType field. This is not how FAT32 is detected. There might be FAT12/FAT16 with that marker, or there might be FAT32 with a different marker. Also because of the same reason, your code will fail at Protective MBR. They should be common now.
Of course it's much easier to only check for 0x0b in one field rather than doing all those calculations as described in the spec, but that's how it should have been done should it be a "FAT32 boot sector".

Well, that's what i will be trying to change in near future. Thanks for advice.

And by "Protective MBR" you mean GPT? I'm not sure if GPT handling and making sure it's FAT32 will fit in 446 bytes

Yes, GPT. The whole code might not fit 446 bytes of course, that's why it would be better to implement this functionality not as an MBR boot-code, rather as a boot-sector code doing something inside 512 bytes capability and proceeding as for example MS boot sector code does - it loads additional sectors with its continuation from the "reserved" area (sector 12 if i remember properly, relative to the FAT partition of course). This way it can do more sophisticated stuff. This is the case for the FAT boot-sector code, not to mention NTFS one. With the latter, it additionally loads way more than yet 1 sector. For dealing with GPT just 1 additional sector should be enough.

[TebexPL]

your code only checks for 0x0b in the OSType field. This is not how FAT32 is detected. There might be FAT12/FAT16 with that marker, or there might be FAT32 with a different marker. Also because of the same reason, your code will fail at Protective MBR. They should be common now.
Of course it's much easier to only check for 0x0b in one field rather than doing all those calculations as described in the spec, but that's how it should have been done should it be a "FAT32 boot sector".

Well, that's what i will be trying to change in near future. Thanks for advice.

And by "Protective MBR" you mean GPT? I'm not sure if GPT handling and making sure it's FAT32 will fit in 446 bytes

Yes, GPT. The whole code might not fit 446 bytes of course, that's why it would be better to implement this functionality not as an MBR boot-code, rather as a boot-sector code doing something inside 512 bytes capability and proceeding as for example MS boot sector code does - it loads additional sectors with its continuation from the "reserved" area (sector 12 if i remember properly, relative to the FAT partition of course). This way it can do more sophisticated stuff. This is the case for the FAT boot-sector code, not to mention NTFS one. With the latter, it additionally loads way more than yet 1 sector. For dealing with GPT just 1 additional sector should be enough.

Sorry for delay, but I've been making Windows install app.

The main focus for me was to have as much functionality in the boot sector as possible. In this project I don't focus on GPT loading, etc. I want to keep it simple(at least for now). It was a project to help me(and maybe someone else) understand the basics of FAT and MBR

In future, as I will learn more I will definetly make more functional and reasonable projects. Thanks for advice!