Does Windows XP have EFI?

[Beta12]

OK, the problem with the signatures solved

WinXP x64 boot in VMware 8 and in Oracle VM VirtualBox 5.2.18 using EFI files from Windows Server Longhorn 6001.16497, but only with the option Disable Driver Signature Enforcement. You do not need any .CAT files. To run WinXP x64, press F8 at startup time or add an option in the BCD file that always displays the Advanced Boot Options menu - DisplayAdvancedOptions:




On X220 there is no longer a problem with a white bar (and signatures) but there is another problem. Loader start, a green wallpaper appears with the words Starting Windows Vista:

but after a few seconds a black screen appears only.

In the laptop I do not have a serial port or firewire to debug in WinDbg.

P.S. BCD file is get from installed Windows Server 2008 6001.16497 in VMware. Next edited with BOOTICE on running WinXP x64 in VMware 8 in BIOS mode. I have removed unnecessary entries and elements make the file more readable. This is file from VMware (NTFS driver integrated) where WinXP x64 is on the one NTFS partition:
https://www.dropbox.com/s/uwt74jyrt0blb ... n.zip?dl=0
To use on real machine (without NTFS driver) FAT32 C: + NTFS D: you need edit options ApplicationDevice and OSDevice from running WinXP x64 in BIOS mode on your real machine (laptop).

[destroyer_sandwich]

The answer is no, except if you have access to the source code or you have some software trickery

[Beta12]

I am trying to understand why WinXP x64 starts in VMware? I thought that it works because there are Legacy modules in the firmware. Using UEFITool, I removed such modules from the 6021 firmware:

Code: Select all

LegacyMemoryAllocatorDxe
WinCSMDxe
CSMLinkerDxe
LegacyBiosDxe

but WinXP is still booting without a problem

I found information that EFI VMware firmware is UEFI Class 3 platforms - it is a "pure UEFI" platform lacking a CSM:
The VMware virtual platform does not support the use of a Compatibility Support Module, which means that OSes that are not EFI-aware may only be booted by configuring the virtual machine to use BIOS. When a virtual machine is configured to use virtual EFI firmware, it is a "pure UEFI" platform lacking a CSM, often referred to as a UEFI Class 3 platform. (There is the need for a small amount of compatibility code to boot earlier versions of Windows atop our virtual EFI firmware, however it is not a full Compatibility Support Module.)

This means that WinXP x64 boots in UEFI Class 3 so he should also boot on a physical machine after disabling CSM in CMOS

[Hyoenmadan86]

I am trying to understand why WinXP x64 starts in VMware?

I still think the problem lies in the Video handling part. My though is that you machine with the latest files from windows server is already booting to XP (aka NTOSKrnl is already loaded and running), but it dies when tries to initialize Win32k and the video part (the Windows Desktop). Unfortunately, since there isn't BOOTVID, BSoDs don't work and there isn't way to tell what is happening without attaching a WinDBG session to the PC.

Maybe you can get a little insight enabling a kernel or a full core dump in windows before attempting UEFI boot, and trying to retrieve the *.dmp file after each attempt to read it with WinDBG. Is the least you can do when the machine doesn't have any other means to be debugged.

[Beta12]

I still think the problem lies in the Video handling part.

Yes you are right - problem lies in the Video handling part. Finally, success I boot WinXP x64 on X220 in EFI without screen (without any video driver) - this post helped me:
Install Windows 7 at UEFI Graphics Output Protocol (GOP) hardware

What to do:

• uninstall graphics driver Intel HD Graphics (to prevent the autoinstallation of the driver after reboot, you need to find in which file oemx.inf was a graphics driver in C:\WINDOWS\Inf and delete it)
• change Start REG_DWORD to 4 two services - vga and VgaSave in regedit:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vga
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VgaSave
  and probably also in subkey ControlSet001
• enable Remote Desktop to possible connect from other PC:
  

X220 boot, on LCD screen a wallpaper with the message Starting Windows Vista is displayed but I hear Windows start sound and possible connect over Remote Desktop :


BCD file as before without changes. AIDA64 display correct info DMI, Motherboard etc. (in VMware DMI not work)

[Beta12]

I found a very interesting topic where users try to run Win7 x64 in EFI mode on Mac computers (Mac computers have an EFI firmware): Win7 x64 booting natively via EFI (no BIOS emulation)
If the graphics card is connected using a PCI bridge, then to start Win7 in EFI it is enough to change several PCI registers of the native PCI bridge in EFI Shell - I/O space and VGA enable:

Mac Mini Model 2011 have identical graphics card like ThinkPad X220 - Intel HD3000 and on this Mac users can not run Win7 x64 in EFI like I do WinXP x64 on X220 :
I see many of you solve this problem by setting the PCI Command register of the videocard to 7 and by setting the VGAE register of the corresponding parent PCI bridge to 8.

For my Mac Mini Model 2011 with integrated Intel HD3000 graphic card this does not work. First of all, the PCI command register of the videocard has already the value 7, so I do not need to set it again.

Secondly, the Video Card operates directly on PCI bus 0. So there is no PCI bridge in between the video card and bus 0.

[Beta12]

I found a way to run WinXP x64 in EFI mode with a working display on ThinkPad X220. It is possible using the driver:
Universal VESA/VBE Video Display Driver (for Windows NT Architecture)

Direct link: vbempk.zip - Release version beta 2015.01.01

Just install the driver from vbempk\VBE30\XPAMD64\PNP


Note! Before installation, the driver PNP vbemp.sys must be manually copied to WINDOWS\system32\drivers otherwise error:

Code: Select all

A service installation section in this INF is invalid.

3D functions do not work but it's better than a black screen or Remote Desktop

Please test and write if it worked.

[Beta12]

The system can be installed to be on the C: partition not D: e.g. 100MB + 5GB NTFS Active + rest NTFS. In setup Win7 from diskpart:

Code: Select all

	select disk 0
	clean
	create partition primary size=100
	create partition primary 5120
	active
	format fs=ntfs quick
	create partition primary
	format fs=ntfs quick

Now install WinXP on C: 5GB (Windows Setup recognizes partition 100MB as E:)
In running WinXP in legacy mode:

• format partition 100MB as FAT32 - Windows auto-assign letter e.g. E:
• copy boot files (ntldr, boot.ini, NTDETECT.COM) from C: to E: (FAT32)
• copy BCD and EFI files to appropriate locations on E: (FAT32)
• in BOOTICE delete assigned letter E: from FAT32 partition and Activate this partition
• install all drivers and video driver Universal VESA/VBE Video Display Driver

This is what the 500GB drive looks like divided into three partitions:


FAT32 partition with assigned letter U:


From now on you can use the Legacy or EFI mode.

By using bcfg in precompiled EFI Shell v2 you can also add the system loader entry to NVRAM:




The FAT32 partition can be mounted at any time by assigning a letter using BOOTICE.

[Beta12]

I created an account to share this with you. I think this is really interesting getting xp to boot using EFI

I am trying xp64 on hardware too (hp 6530b laptop that has an early EFI implementation) and I can get windows to start loading but it hangs on something I haven't figured yet with a black screen. booting in safemode shows the vista beta 2 loader loads past crcdisk.sys then hangs. I tired to boot with boot logging enabled but it doesn't get far enough to create a ntboot.log file.

I will continue experimenting

Have you tried to run WinXP x64 using EFI files with Windows Server Longhorn 2008 6.0.6001.16497 and a BCD file? Try to install the original graphics driver or VBEMP NT Project Universal VESA / VBE

[Beta12]

Note! Before installation, the driver PNP vbemp.sys must be manually copied to WINDOWS\system32\drivers otherwise error:

Code: Select all

A service installation section in this INF is invalid.

I found an error in the .INF file.
For a 64-bit driver it should be like this:

Code: Select all

[SourceDisksNames]
1 = %DiskId1%,,,""

For a 32-bit driver it should be like this:

Code: Select all

[SourceDisksNames.x86]
1 = %DiskId1%,,,""

Now you do not have to manually copy the .sys file.

[Beta12]

One more video to prove that WinXP x64 can be launched in UEFI:

[Beta12]

You can change the default Aurora bootscreen on your own, read this:
How change EFI boot screen Server 2008 Longhorn 6001.16497

for example like this:



xp64_winload_efi_mui.zip

Extract file winload.efi.mui to %windir%\system32\en-US

[dfawcus]

I've only just scanned through this thread now. While I can't give any info about EFI boot for XP, I can state that some versions of XP used BCD (rather than NTLDR) to boot.

A few years ago I bought an Advent NetBook, it came with XP Home which was there for a while before I installed Linux. In fiddling with the boot setup at the time (to preserve multi-OS boot), I found the XP startup was not using NTLDR.

So my first experience with the BCD stuff was trying to understand how to preserve it for multi boot when playing with that machine.

The machine was a 32bit Atom, used BIOS for boot, was MBR partitioned (with an "OS Recovery") partition, yet used BCD instead of NTLDR.

[Beta12]

The machine was a 32bit Atom, used BIOS for boot, was MBR partitioned (with an "OS Recovery") partition, yet used BCD instead of NTLDR.

BCD is a replacement for boot.ini and BOOTMGR is a replacement for NTLDR
WinXP x86 can be started using BCD + NTLDR or BCD + winload.exe
WinXP x64 can be started using BCD + winload.exe
WinXP x86 or x64 can be started in UEFI mode using BCD + winload.efi

winload.exe and winload.efi from Vista Beta

That's right - ADVENT laptops used BCD - see, for example, Advent 4211 user guide page 31:

[bc485003]

OK, the problem with the signatures solved

WinXP x64 boot in VMware 8 and in Oracle VM VirtualBox 5.2.18 using EFI files from Windows Server Longhorn 6001.16497, but only with the option Disable Driver Signature Enforcement. You do not need any .CAT files. To run WinXP x64, press F8 at startup time or add an option in the BCD file that always displays the Advanced Boot Options menu - DisplayAdvancedOptions:


...

What is the BCD editor that you're using here? It doesn't look like any of the others I've found, and it's running in XP which is a plus.

Thanks in advance!

[Beta12]

What is the BCD editor that you're using here? It doesn't look like any of the others I've found, and it's running in XP which is a plus.

Thanks in advance!

BOOTICE by Pauly e.g. version 1.3.2

[bc485003]

BOOTICE by Pauly e.g. version 1.3.2

Great, thank you very much. Now if only there were a "Can XP boot from eMMC?" thread with a solution as a good as the UEFI solution in this thread?

[Hyoenmadan86]

Did you try to test if you can run Intel Drivers in your X220 by using this UEFI VGAFix shim?
https://github.com/davidcie/VgaShim

Btw, i have done some testing with WinVista SP1 and newer Bootmgfw/Winload conbinations. Seems your fileset is the last one which can run XP64. SP1 and Server 2008 RTM combinations load kernel and drivers just fine, but then vmware vcpu gets disabled in middle of XP64 NT kernel early init phase, long before even kernel debugger gets enabled :-/. I will test if Bootmgr/Winload exe files can execute XP64 kernel succesfully... I have the feeling that some code gets disabled in normal retail releases.

[.NETLover3790]

As I understand it, all three 64-bit editions of Windows XP (64-bit Edition 2002, 64-bit Edition 2003, and x64) all support EFI. You can't run the IA64 version on your AMD64-based PC, but you can run the x64 version of Windows XP as long as your device drivers support it. Windows Vista, when it was known as "Longhorn", was also intended to support EFI, even in 32-bit editions (which as I understand 32-bit versions of XP and 2003 didn't support EFI). However, when UEFI supplanted EFI in 2005, Longhorn was redirected to use UEFI (understandably based on the EFI spec). While it originally used 32-bit UEFI as well as 64-bit, the 32-bit support was dropped because adoption of 32-bit systems with UEFI was low (as most people bought 64-bit systems later on that supported it, but used existing 32-bit systems that didn't, and even many later 32-bit systems didn't have UEFI). Vista and later ended up only supporting UEFI on 64-bit systems, and using the legacy BIOS interface on 32-bit ones.

I am genuinely surprised that Windows XP MCE 2005 supports EFI. My UEFI-capable laptop (albeit in legacy mode) runs MCE on a separate partition and I had no idea about any of this. I am curious as to why they implemented this and wonder if standard XP SP2/3 supports it, or if this was just a thing your OEM packed on the disc. Mine has SP3 slipstreamed, so I'm not sure.

The reason Macintosh computers traditionally won't run 64-bit versions of Windows targeting UEFI mode is because they don't use UEFI like modern Windows. They use EFI, which is different. EFI is old, UEFI is based on the last version of the EFI spec, which was from 2005 (I think), and UEFI is still being developed, unlike EFI. I know that the early 2012-model MacBook Pro still uses EFI, not sure about newer ones. What I know is since the Macs can do legacy boot, you can run Windows just targeting BIOS, but you can't run a UEFI-compatible OS on EFI hardware.

[MrBurgerKing]

As I understand it, all three 64-bit editions of Windows XP (64-bit Edition 2002, 64-bit Edition 2003, and x64) all support EFI.

They don't. Users are modding XP to get it working on EFI boot. Read the thread for more info.

(albeit in legacy mode) runs MCE on a separate partition and I had no idea about any of this. I am curious as to why they implemented this and wonder if standard XP SP2/3 supports it, or if this was just a thing your OEM packed on the disc. Mine has SP3 slipstreamed, so I'm not sure.

It doesn't. The screenshot posted at the beginning was from a MacRumors thread, and the original poster later realized those files were leftovers from a Vista Beta install and non functional.

The reason Macintosh computers traditionally won't run 64-bit versions of Windows targeting UEFI mode is because they don't use UEFI like modern Windows.

UEFI is the hardware's firmware. It isn't a part of Windows, instead Windows interfaces with the system's EFI.

They use EFI, which is different. EFI is old, UEFI is based on the last version of the EFI spec, which was from 2005 (I think), and UEFI is still being developed, unlike EFI. I know that the early 2012-model MacBook Pro still uses EFI, not sure about newer ones. What I know is since the Macs can do legacy boot, you can run Windows just targeting BIOS, but you can't run a UEFI-compatible OS on EFI hardware.

[/quote][/quote]
Most apple computers made after 2013 are UEFI compliant and Windows EFI-mode compatible. Previous models aren't but some can still install Windows in EFI mode. Windows does not necessarily require UEFI compliance to be compatible with a system's given EFI.

[Hyoenmadan86]

They don't. Users are modding XP to get it working on EFI boot. Read the thread for more info.

He means IA64 version. Windows IA64 version ofc supports EFI since the first day, as EFI firmware has been always mandatory in IA64 platforms (both Tru64/VAX and WindowsNT), and part of its design core... Just as ARC firmware was in NT RISC platforms.

Most apple computers made after 2013 are UEFI compliant and Windows EFI-mode compatible. Previous models aren't but some can still install Windows in EFI mode. Windows does not necessarily require UEFI compliance to be compatible with a system's given EFI.

Actually there is a better reason. Old Intel EFI Macs are EFI32 firmware driven systems, while Windows only offers UEFI32 loaders up to Win8 (except for betas ofc). You can't mix different binary bitness in UEFI architecture, so UEFI Windows support will not work in these older EFI32 platforms, at least not out-the-box.
Actually, the oldest Longhorn Beta Bootmgfw/Winldfw/Winload is Intel EFI compatible (both 32 and 64 bitness versions), so there are chances a 32bit Windows XP can boot natively in these old configurations paired with the 32bit version of these components, but these old efi windows loaders are extremely buggy, and there aren't available symbols for them so them can be debugged and diagnosed, so making them work is an extremely difficult task for a hardware is already rare to start with.

[MrBurgerKing]

He means IA64 version.

As I understand it, all three 64-bit editions of Windows XP (64-bit Edition 2002, 64-bit Edition 2003, and x64) all support EFI. You can't run the IA64 version on your AMD64-based PC, but you can run the x64 version of Windows XP as long as your device drivers support it. [...] I am genuinely surprised that Windows XP MCE 2005 supports EFI.

Last time I checked MCE was x86, not IA64.

Actually there is a better reason. Old Intel EFI Macs are EFI32 firmware driven systems, while Windows only offers UEFI64 loaders up to Win8 (except for betas ofc). You can't mix different binary bitness in UEFI architecture, so UEFI Windows support will not work in these older EFI32 platforms, at least not out-the-box.
Actually, the oldest Longhorn Beta Bootmgfw/Winldfw/Winload is Intel EFI compatible (both 32 and 64 bitness versions), so there are chances a 32bit Windows XP can boot natively in these old configurations paired with the 32bit version of these components, but these old efi windows loaders are extremely buggy, and there aren't available symbols for them so them can be debugged and diagnosed, so making them work is an extremely difficult task for a hardware is already rare to start with.

Some pre-2013 Core2 and all Core i series Macs are efi64, but not fully UEFI-compliant or Windows EFI-mode compatible. See https://everymac.com/mac-answers/snow-l ... -mode.html for details. Only a few pre-UEFI compliant Macs can boot Windows in EFI mode, and usually with audio issues.

[Beta12]

Did you try to test if you can run Intel Drivers in your X220 by using this UEFI VGAFix shim?
https://github.com/davidcie/VgaShim

I tested VgaShim but unfortunately it did not help
I also tried the bootvid.dll files from different versions of Windows and also did not help.
Interestingly, the bootvid.dll file from Vista Beta 6.0.5384.4 or Vista Business SP2 work with WinXP x64 but only in Legacy BIOS.

[Hyoenmadan86]

Well, I have done some new testing about the issue and this is what i've found so far...

Using VMWare Workstation 12 in a Win10 1803 Host.
Windows XP 64Bit SP2, tuned to boot from all the known working OS Loaders for XP64Bit: PCAT (BIOS) Bootmgr/Winload, UEFI Bootmgr/Winload and the built-in classic NTLoader. Bootmgr/Winload files were taken from the checked version of Windows Vista RTM. SP1 Vista version of the files and upwards will not work at all, with NTOSKrnl failing its execution very early in its initalization phase (before windows kernel debugger gets enabled), and disabling the VCpu in Vmware case. (Note: probably Beta12 files, which came from the Longhorn Server Beta, and ofc are newer than my Vista RTM files, are the last ones which are capable to boot successfully NTLoader based windows versions)

The results of the testing:

UEFI BootMgr/Winload: BSOD when NOGUIBOOT parameter directive isn't specified as we already know.
PCAT BootMgr/Winload: BSOD when NOGUIBOOT parameter directive isn't specified too. What is more, it fails in the same location, in the same way!! O_o (aka, BIOS vs UEFI seem to have nothing to do with the failure as we thought at first). See below for details.
Built-in XP64 NTLoader (Startrom.com + OSLoader.exe): Works fine with BootAnimation and all.

As i said, both UEFI and PCAT versions of Bootmgr/Winload make XP64 fail in the same location, in the same way. Stack text goes as following in both versions:

Code: Select all

fffffadf`e480efd8 fffff800`010d88ae : fffffadf`e480f701 fffff800`010da9bd 00000000`00000000 00000000`00000000 : nt!DbgBreakPointWithStatus
fffffadf`e480efe0 fffff800`010da4e8 : 00000000`00000004 fffffadf`e480f780 fffffadf`e480f701 00000000`00000050 : nt!KiBugCheckDebugBreak+0x1e
fffffadf`e480f040 fffff800`01041794 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeBugCheck2+0xba1
fffffadf`e480f670 fffff800`010b8904 : 00000000`00000050 fffff800`000c0b16 00000000`00000000 fffffadf`e480f780 : nt!KeBugCheckEx+0x104
fffffadf`e480f6b0 fffff800`01040259 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!MmAccessFault+0x9a0
fffffadf`e480f780 fffff800`0149564d : fffff800`0080e578 00000000`00000000 00000000`00000001 00000000`000000a0 : nt!KiPageFault+0x119
fffffadf`e480f910 fffff800`0148d047 : fffff800`014a7cd0 fffff800`014d85a1 fffff800`0080e578 fffffadf`e480f980 : hal!XmEmulateStream+0xfd
fffffadf`e480f960 fffffadf`e440c5cf : 756e6547`0000000b 00000000`00020000 00000000`00000000 00000000`000a0000 : hal!HalpBiosDisplayReset+0xa7
fffffadf`e480f9b0 fffff800`0141109b : fffffadf`e78fe701 fffff800`0080e578 00000000`00000000 00000000`00000000 : BOOTVID!VidInitialize+0x17f
fffffadf`e480fa10 fffff800`01410f0a : 00000000`00000000 fffffadf`e78fe7d0 fffffadf`e78fe7d0 00000000`00000001 : nt!InbvDriverInitialize+0x6b
fffffadf`e480fa50 fffff800`01246cc9 : 00000000`00000000 fffffadf`e78fe7d0 00000000`00000080 fffffadf`e78fe7d0 : nt!Phase1InitializationDiscard+0x2c7
fffffadf`e480fd40 fffff800`012b4e5e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!Phase1Initialization+0x9
fffffadf`e480fd70 fffff800`01044196 : fffff800`01177180 fffffadf`e78fe7d0 fffff800`0117b300 fffff800`0080e578 : nt!PspSystemThreadStartup+0x3e
fffffadf`e480fdd0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxStartSystemThread+0x16

Failure point: hal!XmEmulateStream+0xfd

I want to remark this only happens in xp-64 and win2k3-64. Bootanimation and video drivers which depend in Int10h interface work fine in 32bit versions, booted by NTLdr, or both UEFI and PCAT versions of BootMgr/Winload.

But... 32Bit versions don't use HAL BIOS emulator, but VDM Ke386CallBios and V86 HalpBiosCall (x86new emulated version of this one is named HalCallBios).

[Beta12]

Well, I have done some new testing about the issue and this is what i've found so far...

Thanks for the tests but it must be the fault of the Intel graphics driver because:

• Legacy BIOS + Standard VGA WinXP driver = OK
• Legacy BIOS + Intel driver = OK
• Legacy BIOS + VBEMP driver = OK
• UEFI + Standard VGA WinXP driver = PROBLEM
• UEFI + Intel driver = PROBLEM
• UEFI + VBEMP driver = OK