Win7 x64 booting natively via EFI (no BIOS emulation)

xraydoc said:

I seem to be unable to install Win 7 x64 or x86 at all on my Mac Pro (1,1). I get a "CD Type 1 or 2. Please select" message, or something to that extent, on screen which then becomes unresponsive.

Click to expand...

Hmm, how curious. Not everyone seems to see that message.
I wonder if it is a difference in the machines or different ISO
images.

I think I am the odd duckling in this case. I installed Windows 7 using the EFI boot option.


I had to uninstall refit. Once I did that I held down the option key and it gave me three options to boot

Macintosh HD, Windows DVD, EFI BOOT (something to that affect)

I hit EFI and the installer proceeded to run without any problems. I'm using the 7 RC installer.

areusche said:

I think I am the odd duckling in this case. I installed Windows 7 using the EFI boot option.


I had to uninstall refit. Once I did that I held down the option key and it gave me three options to boot

Macintosh HD, Windows DVD, EFI BOOT (something to that affect)

I hit EFI and the installer proceeded to run without any problems. I'm using the 7 RC installer.

Click to expand...

Sounds interesting, although I'm not convinced yet. I've heard similar
reports in the past, but the result in every case was not a native EFI
installation.

So, to be sure, can you check the partitioning scheme for the disk
you installed Windows on, please? Would be terribly nice if you could!

Instructions: right click on your system volume in Windows Explorer
(e.g. C:\ ), choose properties, choose the hardware tab, select the
correct disk and then choose properties again (phew!).

You should see something like this:



You might have click "Populate" to get the full details.

Thanks very much.

Infrared,

I couldn't populate the results in a normal boot environment for some reason. It might be something related to mac drive. I restarted in safe mode and i was able to get the info.

Here it is
\

hope that helps!

VirtualRain said:

I believe that confirms you are using BIOS emulation as EFI would have created a GPT partitioned volume [...]

Click to expand...

Indeed. Native EFI is GPT only, not MBR. Better luck next time

Infrared said:

Indeed. Native EFI is GPT only, not MBR. Better luck next time

Click to expand...

Well that stinks.

What are the benefits of an EFI native boot over BIOS again?

EDIT:After a quick look around it appears that EFI's support for GPT style partitions is it allows 2TB+ partitions. Neato!

.

It actually works for most recent Macs

I've recently managed to make Windows x64 boot in UEFI on MacBook Pro 6,2 and am working on making it work also on MacBook Pro 5,3. To check if your machine supports booting Windows in UEFI mode, boot the Windows installer and even if there's nothing (or junk) on the screen the caps lock key should still work. If it works it means that your machine supports it, booted successfully
but can't use the video card. It just needs a small EFI application to run before the Windows loader that makes the discrete video card usable . If anyone is interested, I am currently writing such an application and am looking for testers.

Is anyone interested in booting Windows in 17 seconds instead of 30 and having support for GPT partitions? If so, let me know via a private message. Please include the model of your Mac. I will select 3 testers for each 64bit EFI Mac model. I will ask for technical information about their Macs and expect feedback.
The prerequisites for testing are 30 minutes of work on your Mac and a bit of technical inclination.

The EFI version itself is ignored by Windows. The Windows boot loader doesn't really care if your EFI declares version 1.10 or 2.10. If you still want to change it, you can and it can be changed upon boot to any arbitrary number with the application below (to 2.1 in this case), but it is not the problem that makes Windows unusable:

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/UefiApplicationEntryPoint.h>

EFI_STATUS EFIAPI UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
SystemTable->Hdr.Revision=((2 << 16 ) | 10);
return EFI_SUCCESS;
}

I tried to install using a GPT partitioned disk using diskpart to prepare the disk and the partitions. Windows will not have a bar of it on my mid 2010 Mac mini, it redoes the partitioning in MBR and then carries on. No matter what I tried more than that. Even did a backup and then tried to restore on a GPT prepared hdd but no sir, won't do.

On my T61p (core 2 duo T7400 with 800 Mhz fsb) I get diskmark 2.2 figures that on average are less than on the mid 2010 Mac mini, there was a larger difference for the sequential reads . (This on the Intel SSD.)

Booting windows from the moment that I press the button on the back of the mini until I have all loaded takes ~ 34 - 35 seconds. (and this mini first checks the DVD) (big picture is the T61p, the small one mac mini) PS this is with Windows 7 64 bit (T61p has also 4 Gb RAM, same as the mini)

MJL said:

I tried to install using a GPT partitioned disk using diskpart to prepare the disk and the partitions. Windows will not have a bar of it on my mid 2010 Mac mini, it redoes the partitioning in MBR and then carries on. No matter what I tried more than that. Even did a backup and then tried to restore on a GPT prepared hdd but no sir, won't do.

Click to expand...

That's because you booted in BIOS mode. For some unknown reason, Windows doesn't understand GPT in BIOS mode and only sees the MBR part (in case of a hybrid GPT partition table).
If booted in EFI mode, Windows will see the GPT only if it's not a Hybrid GPT. That is, only if the EFI Protective Partition of the MBR spans the whole disk! If it's a hybrid GPT partition layout, Windows will see it as an MBR disk and will refuse to install. Technically, there is no reason for Windows not to work on an MBR disk in EFI mode, but they chose not to allow it.

MJL said:

On my T61p (core 2 duo T7400 with 800 Mhz fsb) I get diskmark 2.2 figures that on average are less than on the mid 2010 Mac mini, there was a larger difference for the sequential reads . (This on the Intel SSD.)

Click to expand...

See my numbers in UEFI mode below. No IDE emulation, just plain SATA, that allows Windows to use SSD TRIM!

MJL said:

Booting windows from the moment that I press the button on the back of the mini until I have all loaded takes ~ 34 - 35 seconds. (and this mini first checks the DVD) (big picture is the T61p, the small one mac mini) PS this is with Windows 7 64 bit (T61p has also 4 Gb RAM, same as the mini)

Click to expand...

My SSD 2010 MBP boots a clean Windows 7 x64 in BIOS mode in 30-35 seconds and an UEFI installation in 17-20 seconds. The main difference comes from not loading the CSM (BIOS emulation).

Some screenshots:
1) System Information + Disk Properties (showing GPT partitioning) + SSD Controller drivers (showing native AHCI)
2) Disk Manager showing 5 GPT partitions (MBR can have only 4).
3) Crystal Disk Mark and Info showing SSD Trim and Apple SSD performance in UEFI mode.

I would love to test this one on my Macbook Pro 5,5. I currently have a 120GB Vertex 2 SSD + 500GB Hitachi HD on my Mac (only Win7 x64 in the SSD, OSX in the HD), but if it's needed, I can format/repartition my disks and reinstall both operating systems in order to have Windows booting in pure EFI and GPT mode.

@d3vi1: I would love to get to a gpt-only situation, as I currently have an osx+win7 combo on mbr/gpt and I am struggling to get linux onboard too (considering I use 2 partitions for windows, one for os and one for data).

Material: macbook pro beginning 2011, win 7 64bit sp1

My questions before embarking as tester are:
1. is there any chance to not have to reinstall everything (esp. the windows applications)?
2. now that my disk is gtp/mbr, are there tools to make it gpt-only?
3: did you try to get linux installed in pure gpt mode? do you know if it works?
4. will the 3 os recognize 5 partitions in pure gpt mode?

Bye
Gaetano

EFI boot Win7 x64 on MBP6,2

d3vi1 said:

...
If anyone is interested, I am currently writing such an application and am looking for testers.
...

Click to expand...

This may be the answer to the long awaited enabling of the integrated GPU when using Win7 for a much better battery life on my MBP6,2. Some people suspects that the reason the integrated GPU is not visible to the OS is because of the BIOS emulation which does not expose it. Do you think so?
Fingers crossed. Available to perform testing if you need.

Subscribed to this thread.

Awes0me!

d3vi1 said:

I've recently managed to make Windows x64 boot in UEFI on MacBook Pro 6,2 and am working on making it work also on MacBook Pro 5,3.

Click to expand...

Earlier models don't have the bits from the UEFI spec that Apple tagged on to their Intel EFI 1.x implementation. (To answer a lot of people's questions, the latest Apple EFI is neither EFI nor UEFI, I am not qualified to specifically outline the differences.) So don't bother checking.

Even earlier models like my first gen MBP don't even have 64bit EFI which is why their RAM is limited to what PAE can address. This was all the uproar when Snow Leopard debuted and people couldn't figure out why their 64bit cpu machines were unable to boot in LP64 mode. I'm surprised you guys don't remember this!

New EFI features were the MAIN reason why I waited until MBP 5,3 to upgrade. (Yes, I would love to test your code, d3vi1, on my machine. Were you thinking of making it into a full fledged EFI app? One could insert your code into the rEFIt source to make a very user-friendly solution.) A UI to toggle the GPU and "biosemulation" bits would be cool too.

d3vi1, was there any other initialization code required to compensate for Apple's EFI implementation or did you just flip the bits and it works OTB?

I love the fact VirtualRain setup this thread trying to do something outside of the box regardless of its support status. This is the kind of computing philosophy I grew up with and its good to see it still exists.

A lot of you guys seem to be really confused about what is going on here and thats totally cool. I suggest reading the OS X man page for bless, the wikipedia page for windows nt startup process, and probably the best resource is to install rEFIt, read the webpage, and finally poke around in the EFI shell. If you are worried about blowing things up, there is a SDK for Windows that lets you compile and run EFI apps in a sandbox.

d3vi1 said:

Is anyone interested in booting Windows in 17 seconds instead of 30 and having support for GPT partitions? If so, let me know via a private message. Please include the model of your Mac. I will select 3 testers for each 64bit EFI Mac model. I will ask for technical information about their Macs and expect feedback.
The prerequisites for testing are 30 minutes of work on your Mac and a bit of technical inclination.

Click to expand...

Seems I can't PM you unless you befriend me here on the forum, so I'm going to message you here for the time being

I have a MacBookPro6,2 just like you (I hope that doesn't make me an uninteresting candidate for a tester!), and you can definitely consider me a technically inclined person — I'm a computer scientist. I'd love to get Windows to cooperate with the handful of OSs I have installed on my MBP.


Cheers!

d3vi1 said:

I've recently managed to make Windows x64 boot in UEFI on MacBook Pro 6,2 and am working on making it work also on MacBook Pro 5,3. To check if your machine supports booting Windows in UEFI mode, boot the Windows installer and even if there's nothing (or junk) on the screen the caps lock key should still work. If it works it means that your machine supports it, booted successfully
but can't use the video card. It just needs a small EFI application to run before the Windows loader that makes the discrete video card usable . If anyone is interested, I am currently writing such an application and am looking for testers.

Is anyone interested in booting Windows in 17 seconds instead of 30 and having support for GPT partitions? If so, let me know via a private message. Please include the model of your Mac. I will select 3 testers for each 64bit EFI Mac model. I will ask for technical information about their Macs and expect feedback.
The prerequisites for testing are 30 minutes of work on your Mac and a bit of technical inclination.

The EFI version itself is ignored by Windows. The Windows boot loader doesn't really care if your EFI declares version 1.10 or 2.10. If you still want to change it, you can and it can be changed upon boot to any arbitrary number with the application below (to 2.1 in this case), but it is not the problem that makes Windows unusable:

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/UefiApplicationEntryPoint.h>

EFI_STATUS EFIAPI UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
SystemTable->Hdr.Revision=((2 << 16 ) | 10);
return EFI_SUCCESS;
}

Click to expand...

Hi d3vi1,

I used to do some coding back in the days, when we used to use injectors to enable graphics-drivers in os x for res-changing / qe /ci.

Also, these injectors helped people, using non EFI-ROM equipped graphics-cards in their Mac Pro systems.

The issue was, that Apples UGA-EFI-driver would not work without the correct Firmware on the card and therefore not provide the required settings to IORegistry (which would then be used by the OS's drivers to match and load).

Back to topic:

Using an EFI-Shell such as rEFIt, I already figured out, that the Win 7 setup will boot to a black screen just after it is switching from text- to graphics-mode, i.e. switching from 'loading files' to showing the windows animated-boot-logo.

Some details can be found in this PDF:

http://www.feishare.com/attachments/083_UEFIrequirements.pdf -> Boot Time Requirements -> Display at Boot Time.

I guess, what you are talking about is, to set some, injector-like, settings to get the windows drivers load and work correctly.

The biggest advantage for me, using a pure EFI environment, would be to have the SATA controller working in AHCI mode (whereas it is working in IDE / compatibility mode when using the BIOS emulation [CSM]), as well as some improved power-management functionality..

Count me in, if you're still working on this one (Using MBA 13" mid 2011 atm, also have a MBP 13" early 2011, so both use the Intel HD 3000..)

Cheers,
Max

PS: The reason Windows doesn't 'understand' GPT in BIOS-mode is because:

'Each GPT partition has a unique identification GUID and a partition content type, so no coordination is necessary to prevent partition identifier collision. Each GPT partition has a 36-character Unicode name. This means that any software can present a human-readable name for the partition without any additional understanding of the partition.'

And no BIOS out there, including the one provided by Apples CSM, has an implementation to read / handle / boot of these GUID-partitions in the GPT - therefore, windows just disables this ability.

EDIT: I read your article in http://blogs.technet.com/b/askcore/...talling-windows-7-on-uefi-based-computer.aspx. I really do like the idea of chainloading bootmgfw.efi after loading the correct option rom and mapping. On the downside, we need to dump the option rom for every single graphics-card and need to find correct mapping addresses for every model..

ty

TheMaxx32000 said:

I used to do some coding back in the days, when we used to use injectors to enable graphics-drivers in os x for res-changing / qe /ci.

Using an EFI-Shell such as rEFIt, I already figured out, that the Win 7 setup will boot to a black screen just after it is switching from text- to graphics-mode, i.e. switching from 'loading files' to showing the windows animated-boot-logo.

Some details can be found in this PDF:

http://www.feishare.com/attachments/083_UEFIrequirements.pdf -> Boot Time Requirements -> Display at Boot Time.

I guess, what you are talking about is, to set some, injector-like, settings to get the windows drivers load and work correctly.

The biggest advantage for me, using a pure EFI environment, would be to have the SATA controller working in AHCI mode (whereas it is working in IDE / compatibility mode when using the BIOS emulation [CSM]

Click to expand...

Totally awesome to have AHCI working in Windows.

Also, thank you Max for answering most of my questions with your pdf link. It is my understanding that Vista and 7 both support UGA and text-mode (for English language). That 7 also supports and prefers GOP in addition to UGA/text, and that Windows 8 will require GOP exclusively for EFI booting.

This is all just for the pre-NT kernel environment as the EFI equivalent of VESA. I don't know about with the Intel graphics but my EFI nVidia chip already has native driver support built into Windows by default, so I don't think this has anything to do with driver injection.

My first guess was that the Apple EFI simply wasn't correctly performing the EFI equivalent of the BIOS exporting tables. Then I read the link you posted and finally figured it out. It says that to EFI boot without GOP (UGA/text) a CSM is REQUIRED! Not a full BIOS emulation CSM necessarily from what I can tell, but emulation of INTERRUPT 10H is required or there will be no video before NT kernel loads native drivers, a latter stage one is unlikely to reach without first dealing with the former.

As d3vi1 wrote on

http://blogs.technet.com/b/askcore/...talling-windows-7-on-uefi-based-computer.aspx

we have two options:

-wait for MS to fix Win 7 to look for video devices by searching ACPI device-tree

-load a vga option rom suitable for your specific card, map the memory and afterwards start windows.

This makes it basically one option. As d3vi1 wrote in that article, the easiest way would be, to write a small EFI 'app', that loads PCI option ROM, maps memory and finally chainloads bootmgfw.efi to load windows

nemomeansnobody said:

Totally awesome to have AHCI working in Windows.

Also, thank you Max for answering most of my questions with your pdf link. It is my understanding that Vista and 7 both support UGA and text-mode (for English language). That 7 also supports and prefers GOP in addition to UGA/text, and that Windows 8 will require GOP exclusively for EFI booting.

This is all just for the pre-NT kernel environment as the EFI equivalent of VESA. I don't know about with the Intel graphics but my EFI nVidia chip already has native driver support built into Windows by default, so I don't think this has anything to do with driver injection.

My first guess was that the Apple EFI simply wasn't correctly performing the EFI equivalent of the BIOS exporting tables. Then I read the link you posted and finally figured it out. It says that to EFI boot without GOP (UGA/text) a CSM is REQUIRED! Not a full BIOS emulation CSM necessarily from what I can tell, but emulation of INTERRUPT 10H is required or there will be no video before NT kernel loads native drivers, a latter stage one is unlikely to reach without first dealing with the former.

Click to expand...

Sorry for the long and late reply, I'm on a weekend on the seaside so I might not answer until Monday. This reply is highly technical. For the non-technical audience: the app is 50% done and you should expect it for testing by mid-september. For the ones that have touched PreOS programming, see below.

Actually it's Windows that's at fault not Apple. There are three parts of Windows that need to work:

1) PreOS Windows: bootmgfw.efi and winload.efi. Those require GOP, UGA or VGA (in this order) for localized versions or simple EFI text-output protocol for plain english (export LANG=C equivalent). They both mostly work. The text stuff is actually an emulated console over the graphics EFI. No fixes are required here since it just works.
2) GOP with precisely 1024x768 or 800x600 for the wavy flag logo. Here Windows kernel is absolutely idiotic since you should never make assumptions about the resolution. Apple offers only one GOP resolution, the LCD panel native resolution. On the other hand, we can live without the wavy flag if the rest works. A possible fix is the EFI Edid Override Protocol to force the GOP implementation to use 1024x768 by faking an LCD panel of that resolution.
This is easy to fix but not high on my priority list.
3) The windows GUI which requires drivers. This is a special chapter since this is the ultimate failure of EFI Windows. I understand (but haven't tested) that Windows.Next has this part solved.

The Windows GUI time drivers chapter (aka ultimate redmond failure):

a) In the installer, Windows will try to use any of the bundled drivers. That basically means for modern hardware (for which it has no bundled driver) only VGA. Since VGA is by design a BIOS-only protocol you can't have it in EFI unless you hack around it. Assuming VGA presence on a non-BIOS firmware (regardless of the architecture) is completely idiotic, yet it's what Microsoft expects. VGA implies int10h and VGA BIOS. VGA BIOS implies real mode (aka pre i386) execution of the Option ROM. You don't have Real Mode on a true 64bit firmware. Real mode can't even address over 4Gb.
b) Assuming that to work around that you do the install in unattended mode and bundle the video driver, it still won't work due to another assumption: the VGAE register (0x3E) on the parent pci-bridge. Even if you have the NVidia drivers, you won't see anything on the video card (remote desktop still works if you configured it) unless you get the video card in bus mastering, IO access (PCI Reg 0x04=7) and the parent PCI bridge with VGAE (PCI Reg 0x3E=8). If you go into device manager, the driver work correctly but there are no monitor instances connected to it. I've tried forcing a monitor, but no success. Windows should do those things for the ACTIVE video card (it has DevicePath protocol in EFI to determine it as well as ACPI). We can work around that by setting them in a pre bootloader app that chain loads the Windows boot loader.
c) If you do set those PCI registers (specific to your mac model), and afterwards load bootmgfw.efi it will work like a charm.

----

I wrote an app that does those things manually for my Mac, but I am missing a few things before it comes out. Since I can't expect the end user to use an unattended install with bundled drivers, I need to provide Windows with VGA.

I need to shadow the VGA ROM manually at 0xC0000 and set the correct int10h value (firmware_version/logicboard_model specific hardcoded in the app). On NVidia Chipset Macs it works as the memory address is R/W. On Intel MCH style chipsets (pre Core i7) I also need to unlock the ram address by setting a value of 0x30, 0x33, 0x33, 0x33, 0x33, 0x33 on 90h-96h on the PCI Root Bridge since the address range is RO. On PCH style chipsets (core i5/i7) since the memory controller is in the CPU I need to unlock that RAM range using the fixed range MTRR. I still have a bit of work in order to make that happen.

Furthermore, another part that I'm missing is the source of the VGA BIOS. On some macs the EFI firmware includes the option rom for both discrete and integrated, on others only for the discrete card. On some macs the EFI firmware shadows the option ROM and only a gBS->CopyMem(ShadowAddr, 0xC0000, RomSize) is required once I identify ShadowAddr and RomSize with the PciIo protocol. On other Macs it's not shadowed (for a presumably faster boot) so I need to use the Firmware Volume protocol to scan for RAW files in the EFI Firmware and select the correct one (0xAA 0x55 means it's a ROM, and there is a PCI Description Table in the rom that states for which vendor/device id it's supposed to work). One XServe models there is no Firmware version of the ROM so we need to read it from the disk. I currently only implemented the reading from the boot disk of a vbios.bin file with the ROM.

If anyone wants to test out using Windows in EFI, it's simple: boot using DUET from el-torrito to install it (Windows from USB stick method). Install the BootCamp drivers (while booting through DUET). After that you can boot using the EFI Shell to set the PCI regs (see the 'mm -PCI' command) and afterwards booting the bootmgfw.efi file. I can make a static build of the app that just sets the PCI registers specific to your mac and then loads the bootmgfw.efi file.

What Windows should have done is:
1) Support GOP or UGA for a frame buffer also after the wavy flag. You can't expect VGA in EFI as it's completely as it is being the first 3 letters in 'assumption'.
2) Not assume setting the PCI bus registers by the firmware or not requiring them at all. All the other OSs work without them. All PCI device drivers should set their own bus-mastering rules by themselves and windows should not care about VGAE when using a non-VGA driver.

Watch the thread as it's getting interesting. Technical folks that can get their hands dirty in EDK should give me a PM and we'll cary on over email. Now I'll get back to Jack, Lucky Strike, and naked blondes dancing around the fire. I've been a geek for too long.

Hi d3vi1,

thanks for this detailed description of what is going on. I already did a Win 7 unattended install but as you said, even with integrated drivers it won't show any graphical interface, as no monitors are detected.

What I did so far is to dump VGA option ROM from my MacBookAir4,2 (SandyBridge i5 integrated Intel HD 3000)

http://www.2shared.com/file/kre_osAJ/c0000.html

Could you provide me with your app / source-code so I can adjust the hardcoded values to match my system?

Grüße aus Hamburg and have fun with the blondes

Max

knowledge is power

Thank you d3vil for answering almost ALL of my questions. (Including ones I didn't even know to ask.) You are doing some excellent work. I had no idea EFI Windows was so horribly broken. I thought the main point of EFI was to kill off CPU specific option roms, dirty int hooks, and 128k limit that were introduced by IBM in 1984. I can tell you are the type of programmer that considers writing a specific bootstrap for every possible hardware configuration more of a hack/workaround than a fix/solution. That being said, I think you are quite possibly the best person for this job. Furthermore, so Windows just HAS to be shown the path to the video then? Thank god other operating systems can parse MCFG tables.. Does EFI change this somehow? I think this is possibly a result of the way Microsoft separates between the NT kernel, the HAL, and the video driver. Specifically Windows' legacy support for non-ACPI compliant systems. The thing is I was under the impression that as of DXGI 1.1

IDXGIFactory1::EnumAdapters1 enumerates local adapter(s) without any monitors or outputs attached, as well as adapters(s) with outputs attached. The first adapter returned will be the local adapter on which the Desktop primary is displayed.

Click to expand...

In NT 6.1 kernel mode drivers are supposedly bare bones, and enumerating DX9 and higher cards is supposed to happen in user mode, and DWM is supposed to kick in full-screen automagically on the first enumerated card completely independent from the OS and kernel drivers... Almost. To enable DWM Windows first has to write to VRAM. The way this is accomplished, as well as for crippled editions, or if any incompatible application is running Windows seems to fall back to the same old tech that was introduced in NT 4. I realize most of what I just said has nothing to do with this thread except for that I can't see long-term use of the VGA bios/option rom in the presence of alternate code-paths/stacks on a 64-bit system, with ACPI HAL, native drivers, PCI compatible bus, booting off EFI with EFI drivers, with the two exceptions of the "pretty" boot-splash and multi-lingual text console. Oh wait, d3vil already answered that one, it is because MS never wrote a simple GOP frame-buffer driver for NT. Another question I have is, shouldn't either the EFI or native drivers register the adapter as a bus-master, set the latency, and specify the DMA type (packet/common buffer)? Sorry, d3vil answered that one already too, with.. yes. (This is fault of Intel, nVidia, AMD no? Please correct me.)

To get to the point, the most important thing I've learned here today is that this project is NOT about Apple using incompatible non-standard firmware. This IS about Microsoft advertising UEFI support for Windows when it just is not there yet. (At least for general computing outside of the server room.) In fact, there is no way this is limited to Apple hardware. Windows 7 is going to come up short on any "true" UEFI platform.

d3vils VGA enabler app is probably the best solution for Windows 7/Vista SP1. Eventually it could include auto-detection of some kind to handle non-standard hardware configurations (upgraded Mac Pro) but will always require access to a compatible VGA bios for the setup at least, something not necessarily built into EFI adapter cards. Support for copying binary images of bios' into memory is really cool feature, but it requires the end-user to obtain the file which is not always legal to redistribute. It could also contain a method for setting the internal display mux on MacBook Pro models with integrated and discrete GPUs.

Hopefully MS is working on this for Windows 8 (Windows.Next). I may very well wait for that day to come as I only use Windows for gaming. While you guys are hard at work implementing what is essentially a custom CSM tailored to work around Microsofts broken EFI support without the waste and loss of features which plague full bios emulation, I will begin investigating the alternate route of writing the Windows drivers that should already be there and creating a modified Windows 7 install media. These two project ideas compliment each other nicely with minimal overlap in function.

p.s. I really have to wonder what kind of hacks MS has used under the hood for all of their previous multi-platform releases. Unfortunately due to the obscurity of (Alpha, MIPS, PowerPC, ARM, Itanium) editions means I will probably never know. I speculate this is one of the big factors behind Microsoft not selling the upcoming ARM port directly to customers, but only to the SoC builders to be modified and pre-installed on devices.

I just realized...

Most of the issues with the Linux crowd trying to EFI boot their macs seem to be:

1. On nVidia macs with dual GPUs, the default state after boot is that the internal monitor is connected to the second adapter and not the primary.
2. X.org drivers for Intel Graphics require a dump of the video bios just like your app.

Have any of your tests been with a single nVidia graphics adapter connected to single monitor? (Like an iMac or standard Mac Book.)

Since Maxx air did the same thing as your MBP (showed adapter but no monitor in device manager) this is probably nothing, but don't want to overlook something simple and make things extra complicated.

Edit: I found that Linux has added GOP/EFI Framebuffer support. Site1 Site2 I am reading the source and laying out the groundwork for a Windows driver in my mind.