If it’s a USB external, that Windows install would be a Window-to-Go install, and may have some quirks, like no feature updates and limited to no Microsoft support. It might still run an occasional game fine though.
If it’s a Thunderbolt external, it’ll run just like a PCIe attached device.
But really, unlike the olden days, multiple OS booting is pretty straight forward in contemporary UEFI environment. You put your OS on separate drives, or partitions, a separate EFI System Partition (small FAT32 partition) has a bunch of small boot loader and menu configs files, the boot manager selects the boot loaders as desired/configured, and you can configure the boot manager either in your OS or your UEFI setup. Even if an OS changes the boot manager order, it’s not too hard to reset that back once you understand the EFI partition file structure – and unless someone trashes/rewrites the EFI partition while “troubleshooting”, all of the boot loaders should be there just sitting dormant, waiting to be reregistered in the boot manager.
Here’s some notes, I took digging around
[Managing EFI Boot Loaders for Linux: Basic Principles]
explaining the pieces:
Whether the boot disk uses GPT or MBR, EFI relies on a special partition, known as the EFI System Partition (ESP), to hold EFI-specific data. The ESP should officially use a FAT32 filesystem…
On an MBR disk, the ESP has a type code of 0xEF.
On a GPT disk, the ESP has a GUID value of C12A7328-F81F-11D2-BA4B-00A0C93EC93B
The ESP holds EFI drivers, EFI applications, EFI scripts, and EFI boot loaders, among other things
Each EFI boot loader is stored in its own subdirectory of the EFI directory on the ESP, e.g.:
/EFI/redhat
/EFI/ubuntu
/EFI/fedora
/EFI/refind
EFI/Microsoft/BOOT (holds bootmgfw.efi, Windows’ EFI boot loader)
Under Linux, ESP typically mounted in
/boot/efi
sometimes (e.g., Arch)
/boot
In Windows, you have to assign a drive letter to the ESP partition using diskpart.exe, running as administrator, and then you can view it in an application like Explorer++, running as as admin.
In addition to specific boot loaders in OS specific directories,
/EFI/BOOT holds the “fallback” boot loader – which UEFI boots will “default” to, if no other loaders are specified/found. The file looks like:
bootarch.efi
for example:
bootx64.efi (x86_64)
bootia32.efi (IA-32 (x86))
bootaa64.efi (ARM64)
in addition,
/EFI/Microsoft/BOOT/bootmgfw.efi
…is, in some EFIs, a secondary fallback boot loader
EFI loads the boot loader specified by the EFI’s built-in boot manager
boot manager maintains a list of boot options in NVRAM, along with an order in which to try them.
During OS installation, the OS’s boot loader is written to disk and its boot loader should be added to the built-in boot manager’s list of options—normally as the first entry.
In Windows, you can set the boot manager boot order, and add/delete entries, with bcdedit.exe, or a 3rd party (not free) app like EasyBCD.
In Linux, you can set the boot manager boot order, and add/delete entries, with efibootmgr
Your UEFI config also might let you reorder/delete boot manager entries.
boot loader launched by the firmware
can present a menu or prompt with additional options
can load an OS directly
Real word examples:
Menu systems:
Linux/Grub
(in /EFI/<distribution_label>)
grubx64.efi
shimx64.efi
mmx64.efi
configuration file in
/boot/grub
Windows
/EFI/Microsoft/BOOT/bootmgfw.efi
/EFI/Microsoft/BOOT/cdboot.efi
/EFI/Microsoft/BOOT/efisys.bin
configuration in
/boot/bcd
Direct OS loaders - which load the OS/kernel/initial RAM desk directly, without a menu system:
EFI Stub Loaders:
\EFI\arch\vmlinuz-arch.efi
\EFI\arch\bzImage.efi