I think you are quite possibly the best person for this job.
I don't, not by far, since I'm not a programmer, but out of sheer luck I figured out what's wrong and have enough spare time to try to fix it. Who knows, maybe knowing C is not such a bad thing (N.B.: no, it wasn't a deliberate flaming attempt, just an attempt at humor). I did manage to write the static app for my specific computer, so not being a programmer hasn't stopped me. I also expect it not to stop me down the road since we are really talking about a 600 line app (currently ~300).
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?
From what I can tell, EFI is attempting to do as little as possible for setting up the hardware. It only attempts to be able to read and execute the OS loader (with the dependencies implied such as TCP/IP for network booting) and to give it access to a few basic resources (keyboard, mouse (including BT), disk, frame buffer). It does not set PCI registers (unless required by EFI drivers), it does not allocate IRQs, it does not do anything that is not strictly required as it assumes there's a lot more intelligence in an OS than in the Firmware. I'm all for that. You do get access to ACPI and SMBIOS which are proven technologies that are not limited by age (like the BIOS).
What Windows expects and tries to do is actually mostly beyond me. I'm a UNIX admin that started programming in C specifically for this project out of frustration. See PM for details on getting access to my results until now. I want 6-7 operating systems on the same hard-disk in multi boot on my 3000 laptop.
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.
NT4? I'm willing to bet that the code in question was there in all NT editions starting from the elegant 3.1/3.5/3.51 series! Might actually be as old as OS/2. Maybe we should give it some due respect. After all, it's been there in all major releases of the NT line until now and worked for x86. No, just kidding...
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.)
No, it's not EFI that should do that because EFI shouldn't make assumptions on what the loaded OS needs. Graphics is just like any other EFI provided function. Some OS or configurations might not need graphics, just like they might not need block device, mouse, keyboard, network or others. Based on ACPI information, the OS and it's drivers should do that and not EFI. EFI, by design doesn't do stuff that's not needed for chain loading the OS. This design keeps the amount of EFI implementation bugs to a lower level as well as allows future OSs with unpredictable hardware access strategies and needs do their own thing with the hardware. Don't assume that Windows 8 will need the same resources from the Firmware as Windows 7. We can rephrase that as: don't model a firmware on current OS releases needs, model it on ANY OS releases (including yet to be released ones).
It could also contain a method for setting the internal display mux on MacBook Pro models with integrated and discrete GPUs.
Planned, but there are a few other things in the pipeline before that.
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.
They actually should. AMD had a presentation about their EFI readiness state at a Microsoft hosted EFI Plugfest saying that the successfully booted Windows.Next using EFI only technologies and specifically not VGA option ROMs.
See second paragraph, page 22. Actually, the whole presentation highlights the fact that Windows is not yet ready for EFI in the graphics department. Maybe I should try a leaked build of Windows.Next. Just need to reach those 10 posts in BA.
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.
A GOP frame buffer driver for Windows? Try UGA. I don't think Windows in it's current version reacts nicely to a limitation of the available resolutions, refresh rates, and bit depths as is the case with GOP. In UGA you get lower level access to the hardware and can set your own resolution, refresh rate and a few other things. Apple's EFI implementation implements both for x64 firmwares (that is, UEFI firmwares).
In the long run, I think that writing a VGASave replacement that implements GOP, UGA and VGA (in that order) could save the day. However I already took on one big learning project for C when I decided to do this EFI app. Learning the insides of Windows NT is not really something I feel like being able to do.
As a side note, I'm curious about how much access you get to the EFI runtime services from Windows. Could I write a Windows APP to modify NVRAM variables? Apple's bootcamp startup disk app does that, but I'm not sure if it's through a Microsoft supported NVRAM manipulation API since I don't think we have any. I would really love to see a smarter startup disk app for both Windows and Mac.
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.
They weren't really hacks. The specific hardware support came from the OEM that gave HAL disks and driver disks. X86 and ARM are the only one where you have so much variation and no standards set in stone, just de-facto standards. PPC, MIPS and Alpha came with predictable firmwares (like OpenFirmware for PPC and Sparc). The OEMs (which was usually just one or two for each arch) would support Microsoft in customizing Windows for their arch to the extent of it working better than x86. It used to just work.