C. T.

(thank you for reissuing the question)

The simple answer is that UEFI and BIOS are not the same kind of thing, and modern PCs are not supposed to run "baremetal" software like the booter apps we used back in the 80s. Are they capable of it? Sure, in theory, but it's a bad idea, and you are not really supposed to do it.

It was expected in 1981, and 88, and to some extent still in 92 even, that end user programmers would write software that talked directly to the BIOS, assuming they didn't go even further and just talk to hardware directly. An enormous amount of software used the BIOS to some extent, but as far as I know, no modern application is ever expected or allowed to talk to UEFI. As a result, it has not tried to keep up with the complexity of modern computing.

If you read the first page of the UEFI spec, it says that it is an interface between firmware and the operating system. In other words, it is assumed you will have an OS.

UEFI offers a couple products to the OS: help getting the system started, info about hardware inventory, and a few other low-level things - but otherwise it trusts the OS to handle all the Real Work. To help with boot, it has mechanisms to take input from the user and put high resolution images on the screen, so that things like boot selectors can work even if the OS hasn't had time to load a graphics driver yet. But it still expects the OS to take over at some point. It's just offering the bare essentials for that very brief period between power-on and the OS loading its own drivers, at which point it will assume the responsibility of drawing graphics, taking input, and everything else.

So, while UEFI offers the GOP for basic graphics, they're basic. Like, yeah, it seems impressive that it can put your screen in 1920x1080 mode and draw 24 bit color to it, but only in comparison to the 80x25 textmode that we put up with way, way, way longer than we needed to. By the early 90s PCs just had VGA graphics, and that's why vendors eventually started shipping motherboards with BIOS' that put a 640x480 image on the screen during boot, all the way back in... 96? Maybe earlier? Graphics support just became normal.

So, by the time UEFI was implemented, it was just a given that a computer could display 1024x768 or even higher resolutions, and that you had a monitor that could tell the machine which modes it supported. Thus, when they wrote the Graphics Output Protocol they took that as a given, and now "high" resolutions and color depth are assumptions. But that's it, that's as far as they went - you get graphics, but nobody ever said they would be FAST. GOP is slow as molasses, and it'll never get any faster because it's completely unoptimized, because it doesn't need to be optimized, because UEFI is a pre boot environment, where you just don't have any need for fast graphics.

Something like a memory tester or other system diagnostic fits into the concept of a "pre boot environment" because it's part of the process of getting your machine ready to run an OS. You wouldn't really think of your machine as having "booted" if it's sitting in memtest. And partly that's because it has so little functionality - memtest doesn't touch your filesystems, it doesn't try to bring up your network card or speak 3D to your GPU. It has very little interactivity; it does one thing, and it's a thing that fits cleanly inside a singletasking environment with no guardrails.

See, if memtest, running as an EFI app, were to make one tiny mistake and write a single byte into the wrong part of memory, the system would crash, and that's the best outcome. It could be worse - it could overwrite its own code, for instance, altering a loop so that it now writes to even more undesired places in memory, and slowly corrupting the entire system until... who knows what happens. Anything. So memtest has to be perfect in a way that software just hasn't needed to be for decades. Nobody wants an app to crash, but... how many have been sold in enormous quantity that did crash, regularly? Lots, but they get away with it because of the memory protection in modern operating systems. You can't act like that if you're running on bare metal though.

One of the most sophisticated apps I can imagine fitting the bill would be gparted. It's still a tool for getting your PC to a bootable (OS-ified) state, but it's also very simpleminded. It does one thing: It edits GPTs and MBRs on attached mass storage devices. Since modern mass storage controllers all speak UEFI, I think you could make an EFI partition editor that makes sense.

The problem with something like a media player is that it does not do one thing, it does a billion. It needs to draw video to the screen at high frame rates, so GOP is right out. It needs sound, which UEFI doesn't support. It needs to speak to the DVD drive, including special commands for things like querying the current region; UEFI may understand optical drives as mass storage, but it probably offers nothing like that. And you need codecs, and you need crypto.

You can't get 60fps video out of a Geforce card without using a full-fat driver. This does not exist for UEFI, and never will; you could try to write it yourself, but take one look at the neverending nightmare of nvidia support on linux. You are also going to have to write your own sound driver, since nobody makes that for UEFI. Both will need to be specific to whatever chip is in whatever machine you're shipping on. You will need an ATAPI driver that understands DVD commands, and nobody makes that.

There are almost certainly no MPEG2 libraries for UEFI, and unquestionably no DVD decrypting libraries, and you are not writing either one yourself.

But then there's Linux. A breathtaking achievement, because any person (or corporation) can simply pluck a distro off the vine and get phenomenal functionality. You get sound drivers for just about everything, support for almost every intel graphics chip and most ATI/Nvidia hardware (after a fashion), universal optical drive support, FOSS or commercial versions of every video codec, and you can license a DVD library for linux on any imaginable architecture from x86-64 to MIPS. It all self-detects and self-configures, and all without writing a single line of code - and there's no risk. It's a protected mode OS, you can trust the kernel and drivers to be mature, and if the DVD player you licensed from Intervideo is buggy, the worst it's going to do is hang the machine.

QuickLook was not much of a hack, but that doesn't mean it was a good idea. I don't know what would happen if you triggered a bug in it; it could scribble all over chunks of the UEFI itself, and then what would happen? Could it corrupt your filesystem because you opened an email with a weird high Unicode character in it? I have no reason to think it couldn't.

As far as "more complex diagnostics", that too I think gets into problems due to the enormous variety of computer hardware. Memtest should be built in to everything and I don't know why it isn't; but beyond that there isn't a lot of hardware for which diagnostic tools are generally productive, except for your GPU which again requires custom and up to date drivers for those diagnostics to even make sense. At which point, well, why not just do it from an operating system.

And as much as I wish computers had a built-in shell that would let me jump into my local file systems and edit my boot config even if I don't have a live USB drive, it's still just pushing way too hard against the limitations of UEFI I think. You can develop applications for it as a side effect of it being a very rich preboot environment, but very rapidly you just end up finding yourself reinventing wheels that took decades to get where they are anyway.

Modern computers use operating systems for good reason; they're basically enormous condoms for your software that have been put through countless millions of puncture tests. So even if it's a quickie (start), wrap that sticky.