There are really two parts to starting up most modern operating systems.
The distinction may not seem important, but it is when you install multiple operating systems.
Booting starts with the BIOS. The BIOS loads just the very first sector of the boot device (usually first hard disk). That contains the MBR (Master Boot Record). Inside the MBR is some simple boot software and the partition table. The MBR is one sector (512 bytes).
The rest of booting depends on what software is in the MBR. The "standard" software will look at the partition table and find the partition marked as "Active". Linux fdisk refers to the Active flag as the "Boot" flag but it's still just one bit for each partition in the partition table.
The software in the MBR then reads the first sector of the Active partition (Partition Boot Sector). Since the software is extremely simple it uses BIOS services to read the hard disk. After reading the Partition Boot Sector the software in the Partition Boot Sector is executed.
Normally the Partition Boot Sector continues using BIOS services to read a boot-loader into memory. What each Partition Boot Sector does depends on the software installed there. Usually the operating system in a partition installs the software to the Partition Boot Sector for that partition. You can have up to four different partitions, and therefore four different boot-loader programs.
Each partition has a Partition Boot Sector precisely because a boot-loader for one operating system is not expected to know how to load a different operating system. Ignoring boot-loaders for a moment, the traditional way to boot an operating system was to set the Active flag for the partition containing the operating system and then restart the computer. One can still do that if the MBR is left with the "standard" software.
It is normal for GRUB to not know how to load Windows, and Windows "bootmgr" to not know how to load Linux. That's really the assumption in the traditional design of "booting".
So, how do you support multiple operating systems more conveniently than by changing the Active/Boot flags? Boot loaders may not be able to load some other operating system but they can usually read and execute a Partition Boot Sector for some other partition. To use the boot sector software, a boot loader simply has to "jump" to the software in the boot sector. The boot sector software never returns to the previous boot loader and probably reads in some other boot loader. That is called "chaining". Chaining allows a boot loader to start a different boot loader without knowing anything about the other boot loader. The only thing a boot loader needs to know to "chain" is the location of the boot sector (or the file containing the boot sector).
GRUB and LILO can chain directly to any sector of the hard disk, and also can chain to the contents of a file (usually a copy of some boot sector). The Windows bootmgr program can only chain to the contents of a file, but not directly to a sector of the hard disk. So, in order to have Windows start some other boot loader like GRUB, one has to first copy the boot sector from the hard disk into a file. Linux "dd" or the Windows DSKPROBE utility can copy disk sectors into files. For either GRUB or bootmgr you add a menu entry with the correct settings to "chain" to the sector or file.
Which boot loader happens to start first is not important if that boot loader can chain to the other boot loaders. In fact, every boot loader can have a menu choice to chain to the other boot loaders. Then it really won't matter which you start first, or even if you mistakenly select the wrong one from the menu. Just select a different boot loader from the new menu and start the correct one. You can even go around in circles, just starting boot loaders and staring other boot loaders without ever loading an OS
I mentioned five boot sectors, the MBR and one for each partition. It is possible to install a boot loader directly to the MBR. In that case it will always start first, and the Active/Boot flags of partitions are ignored. The default Linux installation often installs GRUB to the MBR. I don't like that because you can do exactly the same thing by installing GRUB to the Linux partition boot sector and then setting that partition's Active/Boot flag. Then you can easily change the Active/Boot flag later to start the Windows boot loader (bootmgr) first.
If you install GRUB to the MBR then the only way to start Windows is by having GRUB chain to the Windows boot loader. GRUB will always start first and if GRUB doesn't work you can't boot Windows either.
================
Now we get to loading. Why is loading separate? Part of the reason is filesystems. Boot code does not understand filesystems, and the BIOS doesn't even understand partitions. A loader has to access files for the operating system being loaded. Microsoft's boot loaders understand NTFS, FAT32 and FAT filesystems. GRUB and LILO understand ext2, FAT32, FAT16 and a few others. GRUB does not understand NTFS and Windows bootmgr does not understand ext2 or other Linux filesystems.
A loader for a particular operating system has to know how to load the operating system and start the operating system. The beginning of the loading process uses the BIOS to read the hard disk, but at some point the operating system takes over disk access using some kind of driver.
Once the operating system takes over disk access it usually continues startup and the boot loader is out of the picture.
Linux loading is rather straightforward. The boot loader reads in the entire kernel image from a file, and then may read an initialization RAM disk (initrd). All of that is read into memory before Linux starts. When Linux starts, it runs the kernel and an initialization task that may use scripts or files from the RAM disk (initrd). Eventually the "init" task on the hard disk runs and finishes Linux startup. The "init" scripts free the memory for the RAM disk image and reuse the memory.
Windows loading is more complicated because the boot loader (bootmgr) uses parts of the kernel and drivers to load other parts of Windows and other drivers. That is faster because the Windows disk driver is more efficient than the simple BIOS services. It's also a lot more complicated and depends on internal details of the Windows operating system. Windows is a lot bigger (in terms of memory used) than Linux and the bootloader has to be a lot more efficient to load Windows quickly.
The goals for GRUB and bootmgr are totally different. GRUB is designed to load as many different kinds of operating systems as possible using an open standard. However, GRUB can only load two files (a boot image and a RAM disk file). Also, those are not loaded very efficiently since the BIOS services are used. The Windows bootmgr is only designed to load the required Windows files (including drivers, registry, etc.) to get Windows started. It is designed to load an arbitrary number of files of different sizes efficiently using parts of the Windows kernel and drivers. Windows even keeps information about each boot and what was loaded so that it can load the files more efficiently on later boots.
GRUB supports loading things besides Linux. The file to be loaded can have a "multiboot" header in a standard format and GRUB can load it. I've used that myself to load embedded software that isn't based on Linux.
================
Since boot software uses the BIOS it has to refer to hard disks in a way that the BIOS understands. The BIOS uses a drive ID byte to identify each hard disk. I do mean hard disk here, and not partition (or drive letter). Here are the drive IDs in hexadecimal, followed by the GRUB device name that means the same thing.
80 (hd0) - First hard disk
81 (hd1) - Second hard disk
82 (hd2) - Third hard disk
83 (hd3) - Fourth hard disk
FF N/A - Disk drive used to load MBR
00 (fd0) - First floppy drive
01 (fd1) - Second floppy drive
When you install GRUB it usually puts drive ID FF in the software written into boot sectors. Windows always assumes that the first hard disk (ID 81) is being loaded and bootmgr must be somewhere on the first hard disk.
Windows identifies disks and partitions using a number of different schemes depending on how far it has gotten through the boot process. The Windows boot managers (NTLDR and bootmgr) each use a different method. NTLDR (Windows XP) uses a disk number (0, 1, 2...) and partition number (1,2,3...). The newer "bootmgr" (Vista / Windows 7) uses the drive serial number in the MBR along with a partition number or 128-bit Univerally Unique Identifier (UUID). NTLDR is configured using a simple "BOOT.INI" text file. Windows "bootmgr" uses a database file in a format similar to the Windows registry (but separate). Changing "bootmgr" menus and settings is done with a program called "BCDEDIT" included with Windows. When you use BCDEDIT the drive letters that it shows are how the currently running OS sees the partitions, and NOT always the drive letters some other Windows OS might use when it is booted by "bootmgr". You have to refer to the partitions using the drive letters assigned by the running OS in order to use "BCDEDIT". That's true even if you're changing the menu entry for booting some other Windows OS or chaining to a file.
As a general rule you should usually put boot loaders on the first hard disk and you should ALWAYS put a boot loader on the same disk with the boot sector that loads it. For example, you don't want to install GRUB to the MBR of the first hard disk if the GRUB files are on the second hard disk. That would require having both disks connected and working to even boot.
I prefer to leave the standard software in the MBR and only install a boot loader to the Partition Boot Sector of the partition containing the boot loader. Some disk partitioning programs don't write the standard software into the MBR and it may be necessary to install that MBR software when you don't install GRUB to the MBR. Since the standard MBR software is quite simple, many disk editing programs can install it. Windows Setup ALWAYS puts the standard software into the MBR and installing Windows may write over the GRUB software if you installed GRUB to the MBR.
When you copy boot sectors into files (for chaining) you can patch the files and change the drive ID bytes to handle unusual situations like a bootloader on some other hard disk. Since chaining is done with a menu choice, you can even have multiple versions of the same boot sector that refer to different drive IDs. You should usually not change drive IDs that are actually in boot sectors on the hard disk. They will almost always be either 81 or FF so that a disk will always boot if it is configured as the first hard disk. Patching boot sectors on the hard disk or in files requires detailed information about the boot sector software and layout for a particular boot loader. You can find the detailed information easily by searching the Internet.
The BIOS does not understand partitions. Boot software in boot sectors has to calculate the correct sector number for the BIOS, numbering the very first hard disk sector as 0. Most boot software does understand something about partitions, but usually not filesystems. It is the boot loader that usually understands filesystems.
The BIOS does not know or care what happens after it starts the MBR boot code. The only time the BIOS gets involved is if the boot software asks the BIOS to read some hard disk sectors into memory. If boot software decides that it can't boot the device it can jump back into the BIOS to try the next boot device.