No version of DOS can boot on bare metal on a UEFI-only computer.

[RaymiiOrg]

Are you aware of methods to achieve this anyway? (Without CSM).

Like an emulation layer, Linux, CSM-on-a-stick, an RTOS with bios emulattion, etc?

[lproven]

Not directly, no.

There are, as I understand it, 2 issues:

• DOS calls the BIOS for much of its (tiny) functionality. So it needs a BIOS to be present. UEFI does not present a BIOS interface.
• UEFI expects a protect-mode payload of (occasionally 32-bit, but mostly) 64-bit code. DOS starts and runs in Real Mode. UEFI cannot handle that.

I can imagine 2 ways around this.

VMs

You could run a tiny kernel that starts in (probably) 64-bit mode and runs a single Intel VT VM, and it could provide a soft-loaded BIOS. This is how VirtualBox, VMware, etc. work today. There is a FOSS BIOS that could be used, SeaBIOS.

Using Linux this is broadly how the HP option, available on some models, of setting your OS to "FreeDOS" works. It is actually Debian with FreeDOS in a VM.

An all-FOSS version of that is entirely doable, but it will need a Linux boot volume, filesystem, etc. It might be possible to embed this entirely in the UEFI ESP; OneFileLinux does this, and I have written about it.

However, this would not be able to re-flash BIOSes, access hardware like sound cards, etc.

I think it would be useful to some people for some things. Essentially an extremely cut down Linux distro that can just run DOS VMs. A free, cross-platform version of HP's "DOS" boot option.

Even more interesting would be if it could have some very simple windowing system, so that it could run VGA-mode DOS apps (640*480 pixels in 16 colours) in tiled or overlapping windows, without the bulk of X11 or Wayland. Maybe Microwindows could do it? Maybe TWIN could be adapted?

A smart DOS memory manager

In the 20th century, pre-Win95, the way that DOS memory managers such as QEMM worked was like this (according to my distant and poor understanding):

1. DOS booted in Real Mode, it loaded QEMM;
2. QEMM reset the 386 CPU into protect mode
3. QEMM then rearranged the RAM mapping RAM into vacant parts of the DOS upper memory area that were not in use by ROM or I/O ports.
4. QEMM then started a single Real Mode VM and returned control to DOS running in that.
5. Now DOS had more RAM between 640kB but below 1024kB, and could load TSRs into that.
6. This saved base or conventional memory allowing the user to run bigger apps.

At least one formerly-commercial memory manager is now FOSS: 386Max.

My imagined idea is this:

1. Adapt 386Max to load on its own as a UEFI payload
2. One it loads it maps RAM and creates that DOS VM the same way as before
3. Then in a reversal of the current mode of operation, 386Max loads DOS into the VM, along with SeaBIOS mapped into the VM.
4. Since we now have at least 2 FOSS DOS kernels, FreeDOS and SvarDOS, the kernel could actually be provided along with the memory manager and if necessary modified for this purpose.

I have no idea if it is viable but it does not sound impossible to me.

[RaymiiOrg]

Well this is way to much of a coincidence. This was posted to lobste.rs just now: https://github.com/FlyGoat/csmwrap

[lproven]

This was posted to lobste.rs just now: https://github.com/FlyGoat/csmwrap

Yes, I saw it and came to post it. :-)

It also links to an earlier effort:

https://gitlab.com/tkchia/muefircate-deleted-22918542