So far, FlashBoot can make Windows 7 x64 ISO on VirtualBox, therefore the EFI files are 64 bit. If you want, you can use the Windows 7 x86 (or 32 bit) ISO to create a new patched ISO using FlashBoot and using windows vista or windows 8 EFI files.
@UsefulAGKHelper I have already collected various files for possible UEFI boot. I will add your bootmgfw.efi file replacement option in future too. Everthing is ready and in-place. Only untested on real HW. But patched bootmgrfw seems like great addition instead of using AnaPA driver integrated. EDIT: I have already added these files replacement for upcoming version v1.6
The reason why I provided the FlashBoot EFI files is that VgaShim/UefiSeven gives me the "Unable to unlock VGA ROM memory at C0000, aborting" error, FlashBoot on the other hand boots in my case but at low fps on the VM (the fps FlashBoot provided to me is so low that I have to maximize the window to change the frame, especially on the cursor, visually not very usable, that problem goes away with the VBox Guest Additions, but it's not a universal generic driver). P.s. I use a UEFI Class 3 Laptop, therefore that's why I prefer an EFI INT10 emulator. If you included the FlashBoot EFI files as a separate option, UefiSeven/VgaShim EFI files as another option, then it's great. [EDIT: The reason why Vga/Shim/UefiSeven gave me the C0000 error was because the segment was occupied when I used FlashBoot to boot on real UEFI Class 3 hardware because It is designed to lock the C0000 Int10h segment and persists after restart. Just so you know, if you try to use FlashBoot and VirtualBox together through XP2ESD setup on UEFI mode, you would have to deal with the low fps from FlashBoot unless VgaShim/UefiSeven is suggested, or unless you and your friends try to patch the existing FlashBoot (bootmgfw.efi) file to fix the low fps problem on VirtualBox. NOTE: Use this advice only if you use VgaShim/UefiSeven and want to clear the C0000 segment so VgaShim/UefiSeven can use it again. If you don't use VgaShim/UefiSeven, skip these steps. To make UefiSeven work again on pure UEFI Class 3 (without C0000), I had to refresh the C0000 segment. This advice is only for UEFI Class 3 VgaShim/UefiSeven users' hardware to empty the hex memory C0000 segment (don't do this on UEFI Class 2 Hardware with CSM enabled, it will erase the Int10h VESA Video handler). To check the C0000 segment on UEFI computer, do the following on UEFI shell (if there's content, it means that an Int10h emulator (either CSM Int10h Legacy ROM or OVMF Int10h fakevesa) was used on the computer and the pc didn't clean it up yet): 1. mem C0000 On UEFI class 3, the hex C0000 segment would be usually empty (Int10h is absent or was tampered with code from another fakevesa emulator if GOP also exists). To confirm that CSM is truly disabled and to check the existence of GOP, do the following on the UEFI shell: 1. drivers If it mentions in the video driver's name "GOP", then you have pure EFI without fakevesa. On VirtualBox/Vmware instead of GOP, you would get something like "VirtualBox VGA", "VirtualBox SVGA", and "Vmware SVGA", meaning that it's not pure EFI and partially uses fakevesa to make up for the lack of GOP support. On UEFI class 3, do the following on UEFI Shell (or another memory address hex editor) to clean up C0000 on UEFI shell but this is just for UefiSeven: 1. hexedit -m C0000 20000 2. Set all values to 00. A real UEFI class 3 hardware (or pure EFI with CSM disabled) will have GOP present and C0000 empty, which is why a virtual machine such as VirtualBox/Vmware isn't pure EFI because they use an incomplete version of fakevesa that only supports GOP output for the display because the programs don't support the real GOP yet. Btw, I also want to remind you that the display driver of FlashBoot EFI works terrible on VirtualBox (has low fps, that's why I wanted to suggest you gradually patch It over time so it can also be usable on VirtualBox), while on real hardware it works pretty well. Sorry for providing a lot of information, but I just wanted to give some helpful advice. If there's even more stuff coming soon on XP2ESD 1.6, then I wish you good luck building it, I can wait.]
I've tested disk/partmgr with GPT partition and XP is able to see it. I still need to do a write test to a >2TB HDD and see if it is stable. Disk is formatted using gparted with proper alignment. Any reason for adding crcdisk? I have not seen that for XP/GPT before.
@George King Speaking of drivers, is there a package of daniel_k's universal x64 Sysprep mass storage drivers that you have that is required to boot Windows XP 64 on modern hardware? If you do have it, would you mind linking the drivers so we can test them to see if they work even if they are incomplete? Even tho it's great that you recommended @daniel_k 's drivers, they would work great for Windows XP 32 bit but they are incompatible with XP 64 bit.
Today news: 1) OOBE for all languages still needs to be modded - should be done in few days 2) XP2ESD v1.6 can run under XP host - but it's really limited and result is much different compared to images builded under Windows 7 host. This needs to be investigated after public release - it will be great if we can manage in under XP / 2003 with same result as 7 or newer 3) Whole topic needs rewrite a lot as 1.5.6 vs. 1.6 is like XP SP1 vs. SP3 If everything goes as expected in my life, then you can see release in less than 2 weeks
That's wonderful, I can't wait! I wonder if x64 ACPI drivers package for x64 XP/2003 is included in XP2ESD in order to avoid ACPI A5 BSOD?
Yes, there is also one new x64 ACPI 2.0 (v2) compiled from same sources as new x86 ACPI 2.0 (v4). Currently many BSOD scenarios are fixed (of course not all, but much more than before)
@UsefulAGKHelper I have compiled ACPI 2.0 v5.1.2600.7777.4 for XP SP3 and 5.2.3790.7777.4 for Server 2003 / XP SP2 x64. These new drivers are now default ones. I think now we can boot XP2ESD images on more machines than ever as it really works on most newer motherboards