How detect if WinXP boot in EFI or BIOS?

[Beta12]

I need an application running on WinXP x86 and/or x64, which will detect if the system started in EFI mode. I tested AIDA64 but this reports that UEFI Boot - No:


msinfo32.exe from WinVista, 7, 8 or 10 not work in XP

[Windows Thunderstruck]

I think only the Intel Itanium version of Windows XP supported EFI out of the box, because EFI wasn't really a thing back in the early 2000s.

EFI wasn't really a thing used in booting Windows until Windows Vista x64 SP1.

[MrBurgerKing]

They got XP working on UEFI somehow, check out the glorious megathread:https://www.betaarchive.com/forum/viewt ... 77#p435277
But yeah, because it wasn't supported I don't think any tools would display properly.
HWINFO also shows boot type, you could always give that a try.

[Beta12]

They got XP working on UEFI somehow, check out the glorious megathread:https://www.betaarchive.com/forum/viewt ... 77#p435277

MrBurgerKing - "They got" - It's me got

I think only the Intel Itanium version of Windows XP supported EFI out of the box, because EFI wasn't really a thing back in the early 2000s.

EFI wasn't really a thing used in booting Windows until Windows Vista x64 SP1.

No, Vista or Server Longhorn 2008 support EFI boot and AIDA64 displays correctly UEFI Boot - Yes regardless of whether the partition is GPT or MBR. I did an EFI test in VMware - I installed Win2008 Longhorn in EFI mode on GPT:


In the second virtual machine I installed WinVista Longhorn in BIOS on MBR, copied EFI files to the appropriate locations, switched the machine to EFI. Now Vista boot and AIDA64 correctly displays the information:


I do not know how AIDA64 detects UEFI but certainly not by checking if the partition is GPT

[Windows Thunderstruck]

I know that booting off EFI on a GPT partition on 64 bit Windows Vista was actually meant for the original release. (before SP1), but it was apparently delayed because of a lack of supported hardware during Vista's beta phase. So actual support was introduced in SP1.

Beta12, I wonder if you can test this EFI and GPT thing on a later build, (eg 5472, 5600, 5744 or 5840?).

[Beta12]

Beta12, I wonder if you can test this EFI and GPT thing on a later build, (eg 5472, 5600, 5744 or 5840?).

Yet Longhorn Server2008 6001.16497 is later build (this is SP1)


AIDA64 displays ok UEFI Boot - Yes on GPT - look on my screenshot in previous (edited) post.

[Windows Thunderstruck]

Beta12, I wonder if you can test this EFI and GPT thing on a later build, (eg 5472, 5600, 5744 or 5840?).

Yet Longhorn Server2008 6001.16497 is later build AIDA64 displays ok UEFI Boot - Yes on GPT - look on my screenshot in previous (edited) post.

I am asking if it is possible with EFI and GPT from the start, as you did on Longhorn Server 6001.16497.

Is this EFI and GPT configuration possible on later client builds, like 5472, 5600, 5744 and 5840 from the start instead of starting with BIOS and MBR?

[Beta12]

And I was asking if it was possible with EFI and GPT from the start, as you did on Longhorn Server 6001.16497.

Vista 5384.4 have EFI files but does not start with a DVD in EFI mode.

But it does not matter. The topic is how to detect if the system is running in EFI mode. WinXP x64 system can not be installed in EFI mode (at least for now I do not know how). You must install it in Legacy mode, copy EFI files and switch firmware to EFI.

[Windows Thunderstruck]

Hmm, by copying EFI files from a Vista or Server 2008 pre-release to boot up XP x64 on EFI?

Probably not without some heavy modification, as shown on that megathread: https://www.betaarchive.com/forum/viewt ... 77#p435277

[Beta12]

Hmm, by copying EFI files from a Vista or Server 2008 pre-release to boot up XP x64 on EFI?

Probably not without some heavy tweaking, as shown on that megathread: https://www.betaarchive.com/forum/viewt ... 77#p435277

Oh my God - the next one that refers to my post - more than half of the posts in this megathread is mine

Yes, just copy a few files and create the appropriate BCD file - this is not "heavy tweaking"

Please read the whole "megathread" carefully.

[Windows Thunderstruck]

A particuliar point of interest:

One of the posts in the megathread mentions 5219 32-bit having a winload.efi and it used boot.ini in bootmgr instead of BCD.

And that it worked to actually boot up XP, even with SP3.

[condor.07]

but there is no Windows XP with UEFI boot
the video posted shows absolutely nothing !!!
they are forced mod with Windows Vista files
Windows support in UEFI mode starts with Windows Vista (Server 2008)
Before UEFI existed only for macOS

[Beta12]

I kinda want to test this out, please give me some clear directions on how to do this in VMWare.

No problem - check PM

the video posted shows absolutely nothing !!!

Which video?

[AlphaBeta]

but there is no Windows XP with UEFI boot
the video posted shows absolutely nothing !!!
they are forced mod with Windows Vista files
Windows support in UEFI mode starts with Windows Vista (Server 2008)
Before UEFI existed only for macOS

And who even claims that Windows XP supported UEFI? As far as I know, some members of this forum have successfully transplanted the Windows Vista boot manager to XP and used it to boot XP in UEFI mode. There even is a link to that thread in previous posts; you would have seen it if you had read them before posting.

[Pwned]

You can try this console-based app that I made: https://cdn.discordapp.com/attachments/ ... isefi2.exe

Will it work?

EDIT: Someone removed the file I uploaded to the BetaArchive Discord. So I reuploaded it to anonfiles instead:
https://anonfiles.com/T3G392kdb6/isefi2_exe

[Beta12]

Unfortunately, it detects as a BIOS

I threw file in the hex editor and it looks like it uses windows files: kernel32.dll, msvcrt.dll and function: GetFirmwareEnvironmentVariableW but WinXP x64 does not support EFI.

The application would have to be able to use EFI Runtime Services directly without using Windows files. I found something like that: Runtime Services function call wrappers:

Code: Select all

	GET_TIME,
	SET_TIME,
	GET_WAKEUP_TIME,
	SET_WAKEUP_TIME,
	GET_VARIABLE,
	GET_NEXT_VARIABLE,
	SET_VARIABLE,
	QUERY_VARIABLE_INFO,
	GET_NEXT_HIGH_MONO_COUNT,
	UPDATE_CAPSULE,
	QUERY_CAPSULE_CAPS,

[Pwned]

Unfortunately, it detects as a BIOS

I threw file in the hex editor and it looks like it uses windows files: kernel32.dll, msvcrt.dll and function: GetFirmwareEnvironmentVariableW but WinXP x64 does not support EFI.

The application would have to be able to use EFI Runtime Services directly without using Windows files. I found something like that: Runtime Services function call wrappers:

Code: Select all

	GET_TIME,
	SET_TIME,
	GET_WAKEUP_TIME,
	SET_WAKEUP_TIME,
	GET_VARIABLE,
	GET_NEXT_VARIABLE,
	SET_VARIABLE,
	QUERY_VARIABLE_INFO,
	GET_NEXT_HIGH_MONO_COUNT,
	UPDATE_CAPSULE,
	QUERY_CAPSULE_CAPS,

I'm not sure if it's possible to do that without using kernel-mode privileges (.sys), but maybe it's possible. I'll try it sometime soon.

[d3vi1]

I'm not sure if it's possible to do that without using kernel-mode privileges (.sys), but maybe it's possible. I'll try it sometime soon.

It shouldn't be possible at all because you're missing the pointers to the runtime services. On Macs booting in CSM based BootCamp, Apple introduced an SMBIOS table with pointers to the RunTime Services table (struct). But that is Mac specific. The only way to do it otherwise is to look for the signature (0x56524553544e5552) in all the memory until you find it, but that is very complicated if you don't have access to the memory maps.

If you have the pointer and are in ring0 (kernel-land), you should be able to run them, otherwise there's no chance. Generally, after you call ExitBootServices and SetVirtualAddressMap you should save a copy of those pointers (converted with ConvertPointer() ) somewhere. In the Windows design it's the HAL that should do that because the HAL is the one that implements HalQueryEnvironmentVariableInfoEx, HalSetEnvironmentVariableEx. In older Windows NT releases that emulated the ARC BIOS you had HalGetEnvironmentVariable and HalSetEnvironmentVariable for the same purpose. The variables used by osloader.exe were created at runtime by the ARC emulator (NTLDR) from boot.ini.

[Beta12]

.

Maybe you're right, but I'm interested in one thing - why does not the graphics driver work if we run WinXP in EFI mode?

All other drivers work - Ethernet, Wifi, Sound, USB etc.

[Beta12]

The best proof that WinXP x64 starts in UEFI is a manual launch of the loader from the EFI Shell level or add a position to NVRAM eg. using bcfg tool:
Boot UEFI WinXP x64

[Hyoenmadan86]

Maybe you're right, but I'm interested in one thing - why does not the graphics driver work if we run WinXP in EFI mode?

All other drivers work - Ethernet, Wifi, Sound, USB etc.

Because Video drivers use Legacy Bios services in WinXP at initialization time, even in x86-64 (That's what HAL x86new built-in BIOS emulator is for). To understand how it works you have to check VIDEOPRT and XPDM architecture and notes in ROM code16 and Int10 videorom query services. Even in Win7 WDDM version there aren't provisions for Video Drivers to work in an CSM-free UEFI environment. First version which provides a different mechanism from BIOS dependent VIDEOPRT/VGAPNP is win8.

Other Drivers don't have such limitations and that's them aren't affected. This small project explains a bit better even if wasn't made with winxp in mind.

[Beta12]

Because Video drivers use Legacy Bios services in WinXP at initialization time, even in x86-64 (That's what HAL x86new built-in BIOS emulator is for). To understand how it works you have to check VIDEOPRT and XPDM architecture and notes in ROM code16 and Int10 videorom query services. Even in Win7 WDDM version there aren't provisions for Video Drivers to work in an CSM-free UEFI environment. First version which provides a different mechanism from BIOS dependent VIDEOPRT/VGAPNP is win8.

I ran on X220 Debian amd64 in EFI mode and the dmidecode command shows that the INT10 video services are supported:

Code: Select all

BIOS Information
	Vendor: LENOVO
	Version: 8DET76WW (1.46 )
	Release Date: 06/21/2018
	Address: 0xE0000
	Runtime Size: 128 kB
	ROM Size: 8192 kB
	Characteristics:
		PCI is supported
		PNP is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		3.5"/720 kB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
	BIOS Revision: 1.46
	Firmware Revision: 1.24

Debian is running in EFI:

Code: Select all

Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@debian:~# ls /sys/firmware
acpi  efi  memmap

root@debian:~# efibootmgr
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 000A,000C,001A,0007,0008,0009,000B,000D,000E,000F,0010,0011,0012,0013,0000,0001,0002
Boot0000* EFI Shell BCFG
Boot0001* EFI Shell Normal
Boot0002* iPXE EFI
Boot0006  Boot Menu
Boot0007* USB FDD
Boot0008* ATAPI CD0
Boot0009* ATA HDD2
Boot000A* ATA HDD0
Boot000B* ATA HDD1
Boot000C* USB HDD
Boot000D* PCI LAN
Boot000E* ATAPI CD1
Boot000F* ATAPI CD2
Boot0010  Other CD
Boot0011* ATA HDD3
Boot0012* ATA HDD4
Boot0013  Other HDD
Boot0014* IDER BOOT CDROM
Boot0015* IDER BOOT Floppy
Boot0016* ATA HDD
Boot0017* ATAPI CD:
Boot0018* PCI LAN
Boot0019  Setup
Boot001A* USB CD
Boot001B  Diagnostic Splash Screen
Boot001C  Startup Interrupt Menu
Boot001D  ME Configuration Menu
Boot001E  Rescue and Recovery

So the Intel HD3000 driver for WinXP x64 does not use INT10 ??? - I do not think so.

Standard VGA driver use INT10 but not work in EFI
Intel HD3000 driver probably use INT10 but not work in EFI
AnaPa VBE Miniport VBE30 (VESA BIOS Extension) based on Standard VGA driver - use INT10 and work on EFI:
For proper operation my driver expects that your video card's BIOS is 100%-compatible with VESA Video BIOS extensions specification. Nowadays there are many video cards that don't fully supports INT10 interface, which is provided by VESA/VBE standard (See VBE FAQ below for details).

It's probably not about INT10 and the problem why Intel HD3000 driver not work in EFI should be looked elsewhere.

[Beta12]

I probably found a solution. Legacy bios works in real mode and UEFI bios works in protected mode. WinXP after running from legacy bios creates a key in the registry called RealModeIrqRoutingTable in:

Code: Select all

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\MultifunctionAdapter\0

but when we run it from UEFI then there is no such key in the registry. I wrote scripts checking the presence of the key in the registry: is_EFI_legacy.zip:


Scripts work only in WinXP and probably in Vista.
On Win7 and newer it doesn't work because in Legacy mode there is no RealModeIrqRoutingTable key in the registry.

[Beta12]

Unfortunately, my is_EFI_Leagcy scripts are not good proof that WinXP was launched under UEFI.
If I run WinXP under legacy bios using winload.exe, there is no RealModeIrqRoutingTable key in the registry, just like when running under UEFI with winload.efi

Yes, winload.exe and winload.efi are run in Protected mode but winload.exe is for legacy bios and winload.efi is for UEFI bios.

Debugging Early Boot Stages of Windows

Boot Processes

Here are boot processes of BIOS based Windows XP and Windows 7 systems. I will discuss each stage except for BIOS (POST) and Ntoskrnl.exe.

Boot Process (XP)
BIOS (POST) -> MBR -> VBR -> Ntldr (Real-Mode) -> Ntldr (Protected-Mode) -> Ntoskrnl.exe

Boot Process (Windows 7)
BIOS (POST) -> MBR -> VBR -> Bootmgr (Real-Mode) -> Bootmgr (Protected-Mode) -> Winload.exe -> Ntoskrnl.exe

If we run WinXP using ntldr then the IRQ routing table is present in the registry.

If we run WinXP using winload .exe or .efi then the IRQ routing table is not present in the registry.

My scripts can be used to detect if WinXP was started using ntldr or winload so it should be named is_ntldr_winload:

[Beta12]

Very good proof that WinXP SP2 64-bit works under pure UEFI:
In pure UEFI mode, no the PCI Option ROM's and no legacy various tables, e.g. E820 or MP - just run the RW-Everything tool:

WinXP SP2 64-bit on pure UEFI:



WinXP SP2 64-bit on legacy bios: