我一直在努力想出一种在笔记本电脑上安装Windows和Linux双重引导的简便方法，而不必按此顺序进行。我们通常要做的是先安装Windows，然后安装linux，并允许GRUB处理Windows。
因此，我要努力达到的目的是找到一种绕过讨厌的安装过程（Windows）的方法，仅使用映像直接复制到驱动器中即可。这也将允许我保留启动管理器（GRUB）。（不是我以后不能恢复它，而是垄断的Microsoft策略，在这种情况下，系统中不存在其他启动管理器）。
我首先获得Windows 8.1的合法副本，然后使用VirtualBox将其安装在虚拟机上。然后，我在GPT分区硬盘驱动器上创建了NTFS分区，并将Windows分区的内容从.vdi映像复制到了新创建的分区。
当然，它还行不通。我不知道如何替换bootmgr。它给
File: \Boot\BCD
Status: 0xc000000e
Info: The Boot Configuration Data for your PC is missing or contains errors.
因为它无法从用于引导，系统恢复等的其他分区中找到该文件。
现在，我读到bootmgr最终会执行winload.exe来启动Windows。我不知道下一步该怎么做。
我认为它在理论上应该可以正常运行，因为我拥有运行Windows所需的所有文件。我还认为，我不应该是唯一想到这一点的人，因此，我在这里可能会缺少一些非常基本的东西。也许已经完成了？
我不知道引导如何工作。我设法理解的是，当您同时启动Windows和Linux时，您将Windows Bootloader链接到Linux。因此，我试图实现的目标是摆脱Windows Bootloader。
编辑
我一直在看二进制文件bootmgr和\Boot\BCD。bootmgr读取BCD文件并列出您的选项，从中可以选择启动。
因此，诸如执行之类的信息winload.exe驻留在BCD文件中。现在，我认为bootmgr它本身是由syslinux使用该chain.c32模块执行的。我想做的是以某种方式执行Windows引导程序，即winload.exe直接从syslinux执行（如果可能），或进行修改bootmgr以使其winload.exe自身执行（其路径将直接在bootmgr可执行文件中）而无需查找BCD或其他任何内容。
在此步骤中，休眠（需要不同的过程）对我而言无关紧要。
编辑您的问题以告诉我们固件类型，以及（如果是EFI）您是否已在固件设置中启用兼容性支持模块
我的固件是EFI（启用了CSM），通常使用GRUB引导到Arch Linux。我发现它bootmgr可以System32\winload.exe在旧系统和System32\winload.efiEFI上执行。
我0.0对从这里做什么有想法。在过去的10天里，我一直在尝试对BCD进行更改，我想我即将取得成功。但这无关紧要，因为我真正想做的是完全绕开Windows Boot Manager。
如果您有任何想法，是否有办法winload.efi从EFI shell（只是一个猜测）或对GRUB的其他修改中执行该方法，以便它将在没有Chainloader的情况下以EFI模式启动Windows。
欢迎任何建议。
附录
关注论坛帖子可能会提供一些有用的见解：
http://reboot.pro/topic/19371-chainload-direct-to-winloadexe/
1。
现在，grub4dos可以链加载引导加载程序（例如NTLDR或BOOTMGR），因为它可以替代“常规”引导程序中包含的代码（例如300字节的机器代码）。
此代码仅设置了几个参数，然后调用了加载程序。
即使那样，也很难用不同的代码来理解和复制。
像BOOTMGR这样的NT系统加载器在一个.exe中或多或少具有一个“实模式”操作系统（与DOS完全不同）和用于解析纯文本和注册表配置单元的工具/工具，这是无法重新实现的从头开始轻松编写。
自从多年以来，@ ReactOS的好人正在编写FREELDR（其目标是替代更简单的NTLDR）（我相信ReactOS程序员中有些人真的很擅长）。
他们似乎（但没有明确记录）设法通过NTLDR尝试启动Server 2003。
2。
通过引入对（U）EFI的支持，BootMgr帮助抽象BIOS和（U）EFI之间的差异。例如，这是两个序列：
BIOS (PCAT) -> BootMgr { BootMgr stub -> embedded BootMgr.exe } -> WinLoad.exe -> Windows 64-bit (U)EFI -> BootMgFw.efi -> BootMgr.efi -> WinLoad.efi -> WindowsWinLoad期望存在某种环境（包括API）。BootMgr会处理此问题，因此，几乎相同的WinLoad程序将在两种环境中均可工作。
实际上，（U）EFI定义了一种用于存储和获取引导参数的方法，因此，无论BIOS /（U）EFI如何，BootMgr的BCD都可以实现相同的目的。
但是，除了BIOS和（U）EFI的不同之外，BootMgr还使您可以做出“引导选择”，而WinLoad可以引导知道如何引导的特定操作系统。
根据WinLoad预期存在的环境数量，可能可以直接调用WinLoad。迈克尔·布朗（Michael Brown）的wimboot直接调用BootMgr PE [1]，因此可以直接调用WinLoad，只是WinLoad可能需要更多的环境。你可以试试看！
[1]不要与GRUB4DOS和Syslinux的chain.c32可以调用的BootMgr混淆。该BootMgr包含一个存根，该存根知道如何调用嵌入式BootMgr PE。
setup实用程序中启用了兼容性支持模块。