[michaelmadell]

…s bootloader, so that the setup runs at better resolutions than 800x600/1024x768 where buttons may be off screen

I have seen on numerous systems that the windows setup on most windows versions (Consumer and Server) will have buttons either cut of partially or entirely, relying on ALT combos to navigate.

In the recent windows 11 iso's, you may be able to see the "Previous Version of Setup" after pressing ALT+N 2 times, this will give a more accessible screen, but some automations don't function with this setup screen.

The fixes applied in this PR query the UEFI GOP Driver for the highest possible resolution, then set it before handing off to the windows setup screen, allowing setup to inherit this higher resolution.

I have tested on systems where this issue has and hasn't been present, all with success.

Looking at the code, this hopefully will not cause any issues with any other systems/OSs

[michaelmadell]

Ah, I see I mis-spelled SizeOfInfo as SizeOFInfo in boot.c 🤦

[pbatard]

Thanks for the PR. Don't worry about the Visual Studio builds breaking as it's just a matter of updating Visual Studio, which I will do very soon, so please hold of on updating your PR until I do so. On the other hand, the Linux gcc with EDK2 is something that needs fixing, but it looks like you found the issue already.

While I definitely want to apply this PR, it's probably going to be a while before I do so, because, since the 2011 KEK used by Microsoft to sign bootloaders for Secure Boot expired on 2026.06.27, the next release of UEFI:NTFS will have to be signed with the new 2023 Secure Boot credentials, and I estimate that it'll probably be a year or so before we can rely on most people to have properly transitioned to supporting that certificate.

Which means that I will most likely not be updating UEFI:NTFS in Rufus for quite a while, and therefore, I will keep this PR on the backburner...

[pbatard]

Okay, I've updated the solution files for VS2026, which means that if you rebase on latest and fix the EDK2 issue, then I expect all GitHub Actions to work.

Also, if you can live with a 2023-signed UEFI:NTFS that is not part of Rufus, I may try to publish a release with your patch sooner (say around September). But again, at this stage, even though I would very much like to have your fix there, I am not planning to update UEFI:NTFS in Rufus for about another year (unless of course a major issue needs to be addressed).

[michaelmadell]

It's up to you when it gets implemented.

For the time being, i have found a workaround for customers to use to get better resolutions, may lead to me creating a stripped down version of rufus, and working out how to do the third-party signing process, but that wouldn't be for a while.

We've been fighting some fires with the 2011 cert internally aswell, so know the pain, but were working more on the windows side than third party.

I see this as a QOL fix for other users, so as you say, implement when there is something more pressing to implement on the UEFI:NTFS front.