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.
> 
> 
>