In short, yes and no for a few different reasons. If Windows is booting from a GPT disk, it must be from UEFI. Windows boot manager and loader cannot boot to MBR disk from native UEFI. However, if the UEFI is configured for legacy BIOS boot mode then an MBR disk can be used for booting. This stems from the Windows boot mode (BIOS with MBR or UEFI with GPT) being contingent on the environment in which it is envoked.
Read on for a little tech --
The physical hardware (or virtual hardware, but hardware nonetheless) firmware (BIOS/UEFI) provides the initial operating environment (boot related data structures and conventions) and firmware services available to subsequent stages of the operating system boot process.
In the case of BIOS/MBR boot the first sector of the first bootable disk -- the master boot record (LBA 0) contains a handful of x86 (16 bit 8088) assembly, then the partition table, then a signature). The BIOS loads this sector into memory and begins executing -- the BIOS relinquishes its own program code control as soon as the MBR gets involved.
x86 assembly (Intel 8088 in most MBR's) in the MBR parses the partition table, searches for an active partition, and jumps to the first sector in that partition -- called the volume boot record. The volume boot record contains an x86 assembly jmp, a BIOS parameter block (not used by the system BIOS at all, so confusing name), and a bunch more x86 assembly that ultimately loads the operating system's boot loader (NTLDR or BOOTMGR in Windows environments) from the boot volume/partition itself.
NTLDR or BOOTMGR flip the CPU to protected mode, consult their boot-time configuration (boot.ini or the BCD respectively, both on the boot volume/partition), and load NTOSKRNL where the rest is history.
First let me state that I do not have much active experience with UEFI/GPT. However, as I have used it and understand it to operate -- the big difference (as it relates to our conversation) is that executable control is not transferred to the MBR.
Instead the UEFI firmware contains its own boot manager. This boot manager scans disks and media, -- glosses over the protective MBR of GPT formatted disks, arrives at the GPT header, and then dives into the EFI System Partition (ESP) where it looks for EFI executable programs -- which are supposed to be operating system boot loaders booting the OS directly, however as we have seen with the latest MS and Apple EFI executables, they are in fact boot managers adding another layer to th process and complexity.
The point to take away from this is that there is an expected environment in which the operating system's boot manager and boot loader expect to run. From firmware level services available (BIOS/UEFI interrupts), data structures (variables, stack conventions, etc), and even disk formatting conventions. Cannot be changed at runtime -- at least not the way I understand it.
Pre-install you can control the install by using BIOS/MBR or UEFI in legacy BIOS boot with MBR or UEFI with GPT.
Post-install -- there may be some interesting possibilities with changing the disk format (MBR to GPT and GPT to MBR) offline, then booting to a recovery console (in appropriate UEFI or BIOS mode) and working with bcdboot and bcdedit to get Windows boot manager set straight.
Listing options as I understand them to be, not actually making any formal suggestions.
Nevertheless, after doing a little more research on UEFI (recall that I don't have much active experience with it) I have discovered a few interesting tidbits about the UEFI boot manager and support for CD/DVD booting.
The El Torito Boot Specification, from '95 is still around today and is used with bootable CD/DVD's. A single CD/DVD may have to boot on several architectures -- and while ISO 9660 is rather platform independent, executable code is not. As such, the El Torito Boot Specification allows for multiple boot entries/images.
These entries/images contain a Platform ID, intended to indicate whether an entry is for PC, PowerPC, and other architectures so that architecture's BIOS (or firmware) can choose the right boot entry.
Standard x86 PC's with a BIOS has an El Torito Platform ID of 0x00. UEFI capable Platform ID is 0xEF -- rather creative.
Standard x86 PC BIOS's ignore all other entries except 0x00. UEFI firmware's that have legacy BIOS support (known as Compatibility Support Module (CSM)) -- while able to boot 0x00, will prefer a 0xEF native boot entry from the catalog.
The Windows 2008, 2008 R2, and 7 DVD media contain a multiple image El Torito catalog with both 0x00 and 0xEF. The 0x00 is the default, but a UEFI will gloss over it if a 0xEF exists and choose the 0xEF entry -- as it is native.
What is possible -- is to craft media that only contains the preferred Platform ID in the El Torito boot catalog. Instead of a multi-entry catalog, create a single entry catalog with a 0x00 Platform ID. This should force the UEFI firmware, if in fact it supports legacy BIOS boot, to choose the 0x00 Platform ID and boot the legacy BIOS boot entry on the Windows media.
How to do it?
Using Oscdimg it is possible. Below are several examples of people creating UEFI only media to get around the limitations in Apple's UEFI implementation. Note that this is the opposite of what we are trying to do -- we want to create a BIOS only, leaving out the UEFI boot entry from the catalog.
UEFI Only (Opposite) 1
UEFI Only (Opposite) 2
The process to create BIOS only media is similar with changes to the
-p arguments to the following
A great resource that shed some excellent light on Microsoft's chosen madness on the Windows install media is the UEFI Support and Requirements for Windows Operating Systems document.