Is it possible to boot Windows 8.1 without its own bootmanager?

I have been trying to come up with an easier way of installing Windows and Linux dual booting on my laptop, not necessarily in that order. What we generally have to do is install Windows first, and then install linux and allow GRUB to handle Windows.

So what I'm trying to achive is to find a way to bypass that pesky installation process (windows) and just use an image to directly copy into my drive. This would also allow me to retain my boot manager (GRUB). (not that I cannot restore it afterwards, but it is Microsoft policy to monopolize, in this case denying the existence of other boot managers in the system).

I first obtained a legal copy of Windows 8.1, then proceeded to install it on a virtual machine using VirtualBox. Then, I created an NTFS partition on my GPT partitioned hard drive and copied the contents of the Windows partition from the .vdi image to the newly created partition.

Of course, it doesn't work yet. I don't know how to replace bootmgr. It gives

File: \Boot\BCD
Status: 0xc000000e
Info: The Boot Configuration Data for your PC is missing or contains errors.

because it can't find that file from the other partition which is used for booting, system recovery, etc.

Now, I've read that bootmgr eventually executes winload.exe to boot Windows up. I have no clue what to do next.

I reckon it should work theoretically because I have all the files required to run Windows. I also think that I should not be the only one who has thought of this, and hence I may be missing something very basic here. Maybe it is already done?

I have little idea how booting works. What I managed to understand is that when you dual-boot Windows and Linux, you chain the windows bootloader to linux's. So what I am trying to achieve is to somehow get rid of the Windows bootloader.

EDIT

I have been looking at the binary files bootmgr and \Boot\BCD. bootmgr reads the BCD file and lists your options, among which you can select to boot into.

So information like executing winload.exe resides in the BCD file. Now, I think bootmgr itself is executed by syslinux using the chain.c32 module. What I am trying to do is somehow execute the windows bootloader, i.e. winload.exe directly from syslinux (if possible), or modify bootmgr so that it executes winload.exe itself (whose path will be directly in the bootmgr executable) without looking for BCD or anything else.

Hibernation (which requires a different procedure) is of no concern to me at this step.

Edit your question to tell us the firmware type, and (if EFI) whether you have enabled the Compatibility Support Module in the firmware's setup

My firmware is EFI (with CSM enabled), and I normally boot into Arch Linux using GRUB. I have discovered that bootmgr executes System32\winload.exe on legacy systems, and System32\winload.efi on EFI.

I have 0.0 idea on what to do from here. For the last 10 days, I have been trying to make changes to BCD and I think I am about to reach success. But that is irrelevant, because what I really want to do is to bypass the Windows Boot Manager altogether.

If you have any idea whether there is a way to execute that winload.efi from the EFI shell (just a guess), or some other modification to GRUB so that it will boot Windows in EFI mode without the chainloader.

Any advices are welcome.

Addendum

Following forum posts might provide some useful insight:

http://reboot.pro/topic/19371-chainload-directly-to-winloadexe/

1.

The grub4dos right now can chainload a bootloader (like NTLDR or BOOTMGR) because it can act as a replacement of the code contained in a "normal" bootsector (i.e. something like 300 bytes of machine code).

This code simply sets a few parameters and then calls the loader.

Even that is (was) not easy at all to understand and replicate with different code.

A NT system loader like BOOTMGR has more or less in a single .exe a "real mode" operating system (not entirely unlike DOS) and facilities/tools to parse both plain text and Registry hives, it is not something that can be re-written from scratch easily.

The good guys @ReactOS are working on writing the FREELDR (which aims to be a replacement for the much simpler NTLDR) since YEARS (and believe me there are among the ReactOS programmers some really good and good at it guys).

It seems (but it is not documented clearly) that they managed to boot experimentally a Server 2003 with NTLDR.

2.

With the introduction of support for (U)EFI, BootMgr helps to abstract the difference between BIOS and (U)EFI. For example, here are two sequences:

BIOS (PCAT) -> BootMgr { BootMgr stub -> embedded BootMgr.exe } -> WinLoad.exe -> Windows
64-bit (U)EFI -> BootMgFw.efi -> BootMgr.efi -> WinLoad.efi -> Windows

WinLoad expects a certain environment (including API) to be present. BootMgr takes care of this, so [almost] the same WinLoad program will work in either environment.

In fact, (U)EFI defines a method for storing and fetching boot parameters, so BootMgr's BCD covers that same purpose, regardless of BIOS/(U)EFI.

But beyond BIOS and (U)EFI differences, BootMgr lets you make a "boot choice," whereas WinLoad boots a particular operating system that it knows how to boot.

Depending on how much of an environment WinLoad expects to be present, it might be possible to invoke WinLoad directly. Michael Brown's wimboot invokes the BootMgr PE[1] directly, so it could invoke WinLoad directly, except that WinLoad probably wants more of an environment. You could try it!

[1] Not to be confused with the BootMgr which GRUB4DOS and Syslinux' chain.c32 can invoke. That BootMgr includes a stub which knows how to invoke the embedded BootMgr PE.

To answer your original question, no. Windows cannot be loaded without going through it's own bootloader (in the case of UEFI installs, bootmgfw.efi). This is because Windows expects that bootmanager to be there AND to call winload.efi. If that does not happen, then Windows will crash until you fix the problem. There are many reasons to this (practical and ignorant). Mostly, it is because Microsoft wrote the bootmanager to handle all things (loading the OS, loading the recovery environment, pseudo pre-os environment, and etc). The only way to currently achieve any semblance of sanity is to chain load using Grub-efi.