I was trying to study bootloader and OS and bios do. So
I found this link https://dev.to/frosnerd/writing-my-own-boot-loader-3mld
which lead to a lengthy tutorial from a university professor. from the tutorial I read that The way bootloader/bios (these two terms are used interchangbly by the writer I think) differentiates to find executable of OS and data and things is by using loop and check for a thing called magic number which is stored once in every disk at specific address location. Magic number is 0xaa55. So it means that its written in the hard disk(s). so let say I have two or three OS installed and at boot option I can select which one to boot from. where the magic number stored of second OS if I only had one hardware disk device but multiple partitions. as the boot sector magic number location for only disk is taken by first OS magic number: present at Cylinder 0, Head 0, Sector 0. Since I can make partition ,divided the disk into multiple parts let say Linux-A and Linux-B partitions. The author says
So, the easiest place for BIOS to find our OS is in the first sector of one of the
disks (i.e. Cylinder 0, Head 0, Sector 0),
...
an unsophisticated means is adopted here by BIOS, whereby the last two
bytes of an intended boot sector must be set to the magic number 0xaa55
the above led me to think that magic number may be one for every disk but not anymore after concept of disk partition there may be some other number too . I like know how OS starting address is found if there are multiple OSes and single disk with multiple partitions
also is 0xaa55 considering without partitions on same disk is it same for all CPU architectures(is 0xaa55 is magic number for both x86 and x86-64) and hard disks dependent? Or it a bios or bootloader dependent. like if someone makes own bootloader or edit grub code then one can consider any number as magic number let say 0xabcd. what thing defines the number 0xaa55 magic number should be 0xaa55.
My own understanding of these things is a bit rough as well, but hopefully I'll be able to shed a little light that will enable you to continue on your path. If anyone can correct errors in my text, I'd be happy!
Firstly, BIOS and bootloader aren't the same thing. BIOS is a bunch of code that is stored in a special chip on your motherboard (you can update this code with "BIOS updates" from your motherboard manufacturer). When your computer is turned on, the motherboard loads this code in RAM and then sets the CPU to start executing it. It's literally the first code that runs when your computer is turned on.
After BIOS has performed its work and initialized the hardware it needs to initialize, it starts to look for the OS to boot. It does this by going around and interrogating various devices until it finds one that can boot. Modern BIOSes can boot from a variety of devices, like hard drives, USB drives, floppy drives, CDs, network adapters, RAID controllers and possibly other exotic things.
For each of these devices the interrogation process varies, but for hard drives the BIOS looks for the magic bytes you've mentioned at a pre-determined location. In fact, what BIOS does is it loads the first 512 bytes of the drive in memory (it used to be that all hard drives had 512 byte sectors, so in the olden days this would have been 1 sector) and then checks for the magic bytes. If it finds them, it sets the CPU to execute the first (I think) byte of that sector and that's where it's job ends.
Now these first 512 bytes are the bootloader. Actually, 512 bytes isn't very much. In fact, if you have a MBR-style partition scheme, you have even less than that, because the whole partition table has to fit in there too. It's definitely NOT enough bytes to show a prompt to the user or do nearly anything else useful. Sure, if you're writing your own bootloader that might be enough, but for modern bootloaders it's not even close. So all that those 512 bytes do is load MORE code from somewhere else in the hard drive. And that code quite possibly load more code from elsewhere, etc. And eventually you've loaded enough data in the RAM to have a full-featured bootloader that can present prompts to the user, show splash screens and whatnot else.
What the bootloader then does and how it loads an OS is quite specific to the particular OS, so this is where the commonalities end. If there are multiple OSes on the system, the bootloader needs to know about them too, and how it does that also differs wildly from bootloader to bootloader. You can make your own scheme.
Now, a note about compatibility. This whole scheme is the "IBM PC BIOS" scheme. It was first used in the IBM PCs, but they became so wildly popular that everyone started to make their own "IBM PC Compatible" machines and thus they also had to include a BIOS that worked the same.
You see, in those early days the operating systems were very simple. The concept of "drivers" didn't exist yet and the BIOS filled its space. Since it knew the hardware it would be run on (PC customization wasn't nearly where it is today), it could also include some code that knew how to deal with that hardware. So, even when BIOS gives control over to the bootloader, it still leaves a bunch of code in memory in pre-determined locations, which the bootloader (and later the OS and programs) can use to interact with the hardware. Things like reading and writing to disks, showing stuff on the screen, sending data over serial/parallel ports, etc.
Now, modern OSes don't care about it anymore. They have their own drivers and they interact with hardware through their own code, so the leftover code from BIOS is useless to them. But since compatibility is such an important thing, all the BIOSes even into modern age had to emulate these aging standards. Even more, they had to initialize all the hardware while booting - something that a modern OS would redo anyway, so it was just wasted effort.
Because of this and other inefficiencies, the UEFI standard was born. It replaces the BIOS and... it's quite complicated and I don't really know how it works anymore. What I do know that the OS can actually load special drivers into the UEFI (or vice versa?) so that the hardware initialization work isn't wasted. It can also check the digital signature of the bootloader to prevent malicious code and other things. This results in a much faster boot process, but also all that stuff about magic bytes and whatnot else goes flying out the window. I don't really know how UEFI switches over to the bootloader.
And also, yes - this is all specific to the PC space. I don't know how Mac computers work. It's also quite possible that the new M1 macs do things differently. And other kinds of devices like smartphones and embedded systems have entirely different boot schemes too.
P.S. Just in case, about MBR vs GPT - you really don't need a disk partitioned with either of them. They are just two standards that most OS manufacturers have agreed upon so that they can use each others disks. But it's just a convention. BIOS doesn't care how your disk is laid out. It just cares about the first sector. As long as your bootloader and your OS can understand and work with your custom fancy scheme, everything is good. Except that I think UEFI did require the disk to be formatted as GPT, since it actually read some more data from it... but I'm not sure. BIOS definitely doesn't care.