In the early days (before everyone started cloning the IBM PC) replacing IO.SYS was indeed how MS-DOS was ported to other platforms, and so I suppose in theory that could work. However:

• UEFI, unlike BIOS, separates the boot phase from the runtime phase and provides far less functionality in the runtime phase. To get functionality comparable to BIOS I expect this DOS port would need to remain in the boot phase for its entire runtime.
• Since UEFI expects calls to be made in protected mode while the BIOS API is real mode, this compatibility layer would presumably need to keep switching into protected mode each time the BIOS is called, which is amusing because that’s the opposite of the typical arrangement where DPMI was used to call the real mode API from protected mode in various software.
• Because most of the commercial success of MS-DOS etc were on IBM PC clones rather than the early systems that relied on the IO.SYS abstraction layer, there’s not much extant DOS software that solely targets the DOS API. Some expects to call directly into the IBM ROM BIOS, and lots bypass even that layer and talk directly to legacy hardware devices that might not exist on a pure-UEFI system without a BIOS compatibility layer, so it’s not clear to me that there would be much software that would run on this hypothetical FreeDOS port to the UEFI API.

Honestly, if I were trying to do something like this I’d probably shoot for a very minimal Linux image that boots directly into something like QEMU/KVM running directly against the Linux framebuffer/KMS API, since the kernel would then presumably provide drivers for the real hardware (instead of using the more limited drivers in the UEFI firmware) and QEMU can already emulate various legacy hardware that software of the DOS era tends to expect to directly communicate with.

Of course, that’s not nearly as satisfying a solution as running directly as a UEFI application! I’m just concerned that UEFI isn’t really designed to provide equivalent services to IBM-style BIOS, so it would be an uphill struggle.

Indeed, I was thinking about OSes like DOS that use the BIOS API even at runtime, for tasks like accessing disks.

As you say, Linux is built for the same world that UEFI was built for, where the firmware is mostly used only to boot the system and for low-level stuff like power management. In that case, the “boot services” in UEFI help to get the kernel loaded and then that takes over most of the hardware interactions. Linux uses BIOS in the same limited way it uses UEFI.

But the IO.SYS in DOS (on IBM PC-compatible platforms, at least) is effectively a wrapper around the BIOS interrupts, and applications running under DOS also expect to be able to interact with BIOS directly sometimes, so I think to do what was asked would mean the OS effectively running inside the UEFI “boot services” environment, rather than the usual approach of the UEFI application only dealing with early boot and then transferring control fully to the OS.

(UEFI does have a legacy compatibility layer that I’ve been ignoring for the sake of this discussion because it’s something normally built in to your firmware rather than something you can add yourself. But it is technically possible for a BIOS implementation to run in that environment. I don’t think it’s possible for a normal UEFI application to use that facility, but I might be wrong about that.)

OSes that expect BIOS have some expectations that would be hard to meet in the UEFI application execution environment: BIOS ROM at a specific memory address, processor in real mode, and probably expecting to find some other legacy hardware even though that’s not strictly a BIOS thing.

Maybe you could use the CPU’s virtualization features to implement a low-level virtual machine with a BIOS implementation in it, launched directly from the UEFI environment, but would the entire OS then be running in that VM? 🤔

The more I thought about the interior references part the more questions I had! For example:

• The actual characters in a String belong to a dynamic memory allocation rather than to the String object itself, so the lifetime of &str references into there is “until any operation that might change the size of the allocation”. Since that level of detail doesn’t seem visible to to the type system even with the discussed addition, I guess it would reduce just to disallowing any mutable reference to the string so that its content cannot possibly move to a new allocation while the internal references are live. 🤔
• I also thought about the idea that a reference whose lifetime is related to another field in the same object could be represented as an offset from the object’s address rather than an absolute pointer and then generate relative accesses when dereferencing, but that would mean that the referents would need to always live inside the object itself, and not in a dynamic allocation as would be the case for &str into a String.

So, with all of that said, I’d love to read an article with more details on that part!