Possible Hack to Enable Windows Drivers on OSx86?

[iWin32]

Based on what I have read, I think that it might be possible to load Windows Drivers on OSx86, but I'm not sure. I apologize if this isn't the place to post this, but I don't know exactly where to post this. Anyway, because of my uncertainty of this principle, I wanted to see if any of you guys might know if it would work!

 

I was planning on constructing my own OSx86 bootloader, similar to David Elliott's Boot 132. I was researching some of the things needed to be implemented. I first thing I needed to implement was EFI, and I was mainly going to use an Open Source UEFI implementation to write and launch an EFI shell application to execute the main bootloader. I found this site called "UEFI Programming - First Steps". In it, it describes the EFI shell, a command-line console that does NOT require an operating system to launch. It can be found here: http://x86asm.net/articles/uefi-programmin...teps/index.html

 

I also quote a small portion of what the EFI Shell can do here:

 

So, we are in EFI shell. That means we can finally test any (64-bit) EFI application we write. Time to start writing one. We will of course write and compile applications in normal operating system, not in EFI shell.

 

EFI application or driver is just a plain Windows PE DLL file, just with different subsystem value in header. There are 3 new values: EFI application = 10, EFI boot service driver = 11, efi runtime driver = 12 (numbers are decimal). Question how to set subsystem will be answered later, for now let's focus on the DLL file.

 

 

 

Similar to Windows PE (or Windows Preinstalled Environment) is BartPE (or Bart's Preinstalled Environment). Based off of BartPE and the XPE shell is ReatogoXPE. It comes with a program called "Reatogo AutoDriver". It converts installed Windows drivers into a driver that ReatogoXPE can use. However, it is important to keep in mind that in order to create Video Card or Sound Drivers, you need to also download a FREE Premium Key.

 

If I'm correct, since we convert installed Windows Drivers into ReatogoXPE drivers, ReatogoXPE is based off of BartPE, BartPE is similar to Windows PE, Windows PE drivers can be loaded into the EFI shell, EFI can load Boot 132, and Boot 132 can boot Mac OS X, then, Windows Drivers can be loaded into Mac OS X!! (Sorry about the long sentence!! )

 

If it works, we could enable FULL support on incompatible/partially compatible hardware without ever having to write a new .kext file. It would also be easier to maintain.

 

Now, there is a catch. Since most EFI implementations for OSx86, like dfe, Chameleon, and Empire EFI enable direct booting to OS X without the access to the actual implemented EFI firmware, we would need to re-write a completely new bootloader. It would have to enable both access to OSx86 and the EFI shell in the implemented EFI that can boot on a BIOS-based Windows PC. Other than that, I think that it could really work.

 

Yet, I am not sure as I don't even know much about the regular PC BIOS. Yet, I intend to learn more, and one of the best ways to learn is to ask questions. So, I am wondering, is this even possible? Why or why not? Please let me know ASAP. Thanks!

[JCsHands]

Have you any updates on this idea of being able to convert and load Windows drivers into the EFI?

[iWin32]

I thought no one was interested in my idea until now. I would need to look at Boot-DFE's Source Code (Boot-DFE is the hacked version of Boot-132). I would then need to compile it without the fake EFI implementation and have it be started by a bootloader compatible with EFI. Then, use a UEFI implementation (there is an open source one, of course) to first give access to the EFI Shell before it attempts to boot. By default, both EFI and UEFI tries to boot an OS before prompting you with the EFI Shell, and Vista and Windows 7 can be booted from within EFI. That modification would be fairly easy.

Here's the catch: the drivers would need to be implemented in the EFI partition, and I know many ways of booting retail installation without the boot CD is through modifying that partition. We would need to not only create a modified version of Boot-DFE for CD, but also for the hard disk. I think even Chameleon uses a modified version of the EFI partition. The bootloader would need to work on a FAT32 partition on the hard disk with Windows. And I know that a modified version of SYSLINUX for flash drives would work, but what about on hard disks. For hard disks we would need GRUB or some other Linux bootloader. And as far as booting the installation CD, we would need to have two RAM disks. One to hold the EFI partition with the Windows Drivers, and the other to hold the kernel extensions and custom kernels needed to boot Mac OS X. Is it possible? Yes. Can I do it by myself? No, I am going to need a lot of developers to assist me. We need to re-write both Boot-DFE and Chameleon for the hard drive. We also need to re-write the open source UEFI implementation to go straight to the EFI Shell.

As far as the procedure goes, it would need to go something like this:

1. Create Windows PE drivers through any method.

2. Modify them to work with the EFI Shell in Windows.

3. Copy these .dll files to a flash drive.

4. Boot from the patched UEFI implementation CD.

5. Copy the flash drive to the RAM Disk, that is, the EFI partition.

6. Swap the UEFI implementation CD with the modified Boot-DFE CD.

7. In the shell, specify the Boot-DFE CD as the boot device.

8. Treat it as a regular Boot 132 installation and swap it with the Retail Leopard (or if compatible, Snow Leopard) DVD.

9. Install as necessary.

10. Repeat steps 4-8, except in Boot-DFE, specify the hard drive as the boot device.

11. Finally, install this bootloader to the hard drive, copying the Windows Drivers to the right partition.

12. Reboot, and hopefully, it will boot automatically without all these steps.

If you have any other interested developers, just let me know, and I will be sure to announce if this bootloader ever becomes available!!

[J.B]

just wondering, do you know how to code all this?

[Donk]

just wondering, do you know how to code all this?

 

I think you have misunderstood the EFI programming model. It doesn't have the Windows driver API and so all drivers would have to be re-written or some form of low-level Windows system API layer built on top of EFI base classes. The confusion I think comes from the fact that EFI uses the PE executable file format used by Windows, it does not imply that the Windows API is available. Just think of how ELF file format is reused in many different systems, Linux, BSDs, PS3 executables.

[iWin32]

I think you have misunderstood the EFI programming model. It doesn't have the Windows driver API and so all drivers would have to be re-written or some form of low-level Windows system API layer built on top of EFI base classes. The confusion I think comes from the fact that EFI uses the PE executable file format used by Windows, it does not imply that the Windows API is available. Just think of how ELF file format is reused in many different systems, Linux, BSDs, PS3 executables.

So, if I'm understanding you correctly, you're saying that the drivers would have to be re-written from the PE format due to the fact that EFI uses the same format of the executable for Windows PE, but uses its own API apart from Windows, similar how both Linux and OS X are Unix-based, but can't run the same programs due to different API implementation? Why not use some of Wine's code base? Wine can run many Windows programs on Unix-based systems. In fact, ReactOS, an open-source alternative to Windows that can run Windows programs and drivers, depends on Wine. Without Wine, it would have to be its standalone Operating System. If we implement Wine in some of the EFI code base, perhaps that EFI could execute the Windows drivers then, and then boot EFI-compatible Boot-DFE, and then OS X.

P.S. I only run Windows and occasionally OS X in either PearPC (I know its slow) or in VMware, and one day hope to dual boot OS X on my laptop. I may once in a great while run Ubuntu in a virtual machine, but otherwise I will stay away from Linux. Also, I'm not into gaming and don't own a PS3 as a result, so I don't really know anything about the ELF format.

[Donk]

So, if I'm understanding you correctly, you're saying that the drivers would have to be re-written from the PE format due to the fact that EFI uses the same format of the executable for Windows PE, but uses its own API apart from Windows, similar how both Linux and OS X are Unix-based, but can't run the same programs due to different API implementation? Why not use some of Wine's code base? Wine can run many Windows programs on Unix-based systems. In fact, ReactOS, an open-source alternative to Windows that can run Windows programs and drivers, depends on Wine. Without Wine, it would have to be its standalone Operating System. If we implement Wine in some of the EFI code base, perhaps that EFI could execute the Windows drivers then, and then boot EFI-compatible Boot-DFE, and then OS X.

P.S. I only run Windows and occasionally OS X in either PearPC (I know its slow) or in VMware, and one day hope to dual boot OS X on my laptop. I may once in a great while run Ubuntu in a virtual machine, but otherwise I will stay away from Linux. Also, I'm not into gaming and don't own a PS3 as a result, so I don't really know anything about the ELF format.

 

Possibly if you used Reactos as you need the low level Device Drive APIs. Similar to say the projects that run Windows driver on Linux, NDISWrapper. Pretty sure Wine is not at the right level for the Windows DDK. But overall I would say that is a huge project and undertaking, and would probably be easier just to try and port the drivers. Also not even sure Mac OS X could use the loaded drivers. For example, VMware's implementation of an EFI BIOS for Fusion actually has embedded Mac OSX X drivers so they can run a virtual Mac OS X guest inside VMware, and doesn't have much apart from the usual low level EFI drivers, such as VGA.

[dlambert]

Interesting.