You've come to this page because you've asked a question similar to the following:
What is the difference between a "boot loader" and a "boot manager"?
This is the Frequently Given Answer to such questions.
A boot loader is a program that forms part of the bootstrap process for a specific system.
A boot manager is a general purpose utility that is the primary system bootstrapped on a computer that, in turn, allows the user to choose amongst multiple systems whose bootstrap loaders it will then load and invoke, just as if they had been bootstrapped directly by the machine firmware.
Boot managers, being systems in their own right, can have their own boot loaders too.
Some try to redefine boot managers to suit their own ends, relegating everything that does not fit their definition to "mere boot loaders".
The marketing literatures for some boot managers tout their abilities to load kernel images directly from files, and claim that that distinguishes them from "mere boot loaders". However, that does not make the distinction between a boot loader and a boot manager. OS2LDR understands filesystem formats, with the assistance of mini-FSDs, and loads and executes a program from an image file. Yet it is a boot loader, not a boot manager.
The marketing literatures for some boot managers tout their abilities to
manage partition tables and to perform other such tasks not directly
related to booting an operating system. However, that does not make the
distinction between a boot manager and a boot loader. Microsoft's
diskpart.efi is a utility program that can be invoked
directly from EFI firmware, without bootstrapping an operating system. It
allows manipulation of the partition table in a "pre-boot" run-time
environment. Yet it is neither a boot manager nor a boot loader. It is
simply a standalone utility program that uses only machine firmware
servies and that can be run without the benefit of an underlying operating
system being present.
The difference between boot managers and boot loaders lies in how specific they are to one particular operating system and one particular method of bootstrapping. Boot loaders are special-purpose programs that apply to one operating system, or to a homogeneous family of operating systems. Boot managers are general-purpose programs that apply to many operating systems, which are heterogeneous, often greatly so.
And boot loaders are not "mere". Boot loaders are vital parts of operating system bootstrap processes.
IBM's Boot Manager (also repackaged as the Partition Magic Boot Manager) is a boot manager. It can boot any operating system that bootstraps itself using a VBR (Volume Boot Record) in a disc volume. (And whilst this ability is normally only provided to primary partitions, Boot Manager extends it to secondary partitions as well.)
IBM Boot Manager lives in a primary partition, which is marked as the "active" primary partition. When a machine is bootstrapped, the firmware loads the MBR (Master Boot Record), the code in the MBR loads the VBR from the IBM Boot Manager partition, and the VBR code in the BM partition loads Boot Manager. (The code in the VBR is thus a boot loader program for IBM's Boot Manager.)
The repackaged Partition Magic Boot Manager can alternatively be stored in the very first track of the disc, with its boot sector code in the MBR itself, just like a computer virus. This is not a recommended configuration, for the simple reason that modern operating systems do not require (and have not required for over a decade) that disc partitions be aligned to track boundaries, and thus do not guarantee that this area of the disc will be "spare" space, unallocated to any partition.
Indeed, on discs partitioned with the GUID Partition Table scheme, it isn't. It's where the partition table lives.
IBM Boot Manager itself then reads the partition tables from all (firmware-accessible) non-removable DASDs, and presents a menu to the user of all partitions that it finds that have been marked with the "bootable" flag.
IBM implements an extension to the conventional partition table format that adds extra flags to each partition record. In IBM parlance, a partition marked with the conventional "active" flag is a "startable" partition. (Only the Boot Manager partition itself is "startable".) A partition marked with one of the extended flags is "bootable". IBM Boot Manager does not display non-bootable partitions in its menu.
Whilst the code in the Master Boot Record is only able to load and run a VBR from a primary partition, IBM Boot Manager is capable of loading and running the VBRs from both primary and secondary partitions. It loads them into the same region of memory that the machine's firmware loads boot sectors, adjusts them if they are VBRs of secondary partitions (by manipulating the "hidden sectors" field of their embedded BIOS Parameter Block) to account for the vagaries of the extended partitioning scheme, and then executes them in the same way that the code in an MBR would. As far as the VBR code can tell, it has been loaded and run directly by the code in an MBR, just as if it were from an active primary partition.
OS2LDR, a part of IBM OS/2, is a boot loader. It is loaded by the
mini-FSD for the volume's filesystem format (named os2boot on
both FAT and HPFS, but distinctly different for both). It is specific to
IBM OS/2. It looks for, reads in, applies relocations to, and invokes the
IBM OS/2 kernel, from a program image file. The name of the program image
file is hardwired, with the filename always being os2krnl
located in the root directory of the
boot volume.
OS2LDR understands and implements the specific loading requirements of the IBM OS/2 kernel. It passes specific data structures and values in memory and in registers when invoking the kernel, many of which are specific to the architecture of the OS/2 kernel. For it to be used with other operating systems, they would have to adhere to the same protocols and use the same filename. Thus OS2LDR is specific to IBM OS/2.
WINLOAD, a part of Windows NT 6, is a boot loader. It is loaded by
Microsoft's boot manager and is specific to Windows NT. It looks for,
reads in, applies relocations to, the Windows NT kernel, Hardware
Abstraction Layer, and system registry hive, from files on the
system volume
(system32\ntoskrnl.exe, system32\hal.dll, and
system32\config\System, respectively). It then invokes the
Windows NT kernel.
WINLOAD understands and implements the specific loading requirements of the Windows NT kernel. It passes specific data structures and values in memory and in registers when invoking the kernel, many of which are specific to the architecture of the Windows NT kernel. (The in-memory copy of the system registry hive that it creates is highly specific to the Windows NT architecture, for example.) For it to be used with other operating systems, they would have to adhere to the same protocols.
Indeed, WINLOAD is not only specific to Windows NT, it is specific to certain versions of Windows NT. Windows NT versions 5.0 or earlier cannot be loaded via WINLOAD (probably because they support non-ACPI systems, whereas Windows NT 6, and thus its boot loader, do not). They require a different boot loader.
Microsoft's Boot Manager is (in theory) a boot manager. It can (in
theory) boot any operating system that bootstraps itself via a
PE-format loader program (such as winload.exe, the boot
loader for Windows NT 6, discussed above) or using a VBR in a disc volume.
Microsoft's Boot Manager lives either (on non-EFI systems) in a primary partition, which is marked as the "active" primary partition, or (on EFI systems) in the EFI System Partition. On non-EFI systems it is loaded exactly as IBM's Boot Manager is: When the machine is bootstrapped the firmware loads the MBR, the code in the MBR loads the VBR from the active primary partition, and the VBR code in the active primary partition loads Microsoft's Boot Manager.
The primary difference between the two is where in the volume the Boot Manager code is stored. Microsoft's Boot Manager code is stored in a file in the root directory of the partition, and the partition is formatted as a regular disc volume, so the boot loader code in the VBR has to be smart enough to know how to load a program image file from the root directory of the volume. IBM's boot manager code is stored as a straight sector-by-sector image right after the VBR, and the partition is not formatted as a regular disc volume, so the boot loader code in its VBR is somewhat simpler.
On EFI systems, it is directly loaded by the EFI firmware, as an ordinary EFI executable. For details, see the description of the boot process of Windows NT version 6.
Unlike IBM's Boot Manager, Microsoft's boot manager performs no autodetection. It does not inspect the partition tables when it initializes. Rather, it relies on a statically-configured database of boot loader programs and Volume Boot Records, known as the Boot Configuration Data "system store". This database is (in theory) maintained by operating system installation and configuration tools and kept aligned with the disc partition tables and boot loader file locations.
The reason for the multiple "(in theory)"s is that, in practice, there are as yet no loader programs that can demonstrably be used with Microsoft's boot manager other than WINLOAD, there are as yet no other tools for editing the BCD database than Microsoft's tools for installing and configuring Windows NT itself, and the file format of the BCD database and the exact execution environment for the PE-format loader program are undocumented and considered secret by Microsoft. (Only Microsoft may employ the secret 7 on the dice.) So whilst in theory Microsoft's Boot Manager may be operating system neutral, in practice it may end up being either subtly or blatantly tied explicitly to Windows NT alone.
There's thus good reason to hope that Microsoft's boot manager will never take off as a fully fledged boot manager. An EFI boot manager can do everything that Microsoft's boot manager can do, and has the advantages that its configuration data and execution environment for boot loader programs are publicly documented in the EFI specification. Operating system developers should develop their operating system boot loaders for EFI, rather than for Microsoft's boot manager.