What you describe used to be very common: https://en.wikipedia.org/wiki/PC_booter

The problem comes when you need to use any kind of hardware, all the drivers would have to be part of your app. The "unikernel" concept however does some version of this: loads a kernel which only supports the minimal amount of functionality and drivers needed and with only a single address space for a single app.

Historically this was more tractable because driver code was much simpler and there was a lot of cloning/emulation of "legacy" hardware interfaces (a lot of this is still present on PC, despite vendors' desire to get rid of it). Typically either the hardware capabilities were fundamentally narrower in scope than modern hardware or the hardware had its own controller (sometimes with more raw power than the host CPU...) that implemented an abstract interface. A bare-metal VGA driver for a single mode is no more than a few dozen lines of code, whereas a modern GPU driver stack literally has an optimizing compiler built into it.

This is standard "embedded" system programming for lower-end MCUs. "Unikernels" use the same concept to create standalone bootable binaries(linked with reqd. OS modules) to run directly either on HW or on a VM Hypervisor.

See "IncludeOS" for one representative example.

Yes, the ASM overkill was a mistake of my youth :-) https://github.com/cirosantilli/x86-bare-metal-examples/tree...

Besides what everyone is commenting on, this is how Amiga, Atari ST and most console games used to be done.

So a Unikernel with your program?

you're describing any number of embedded systems, including the Arduino runtime - load up an Arduino app and you have your dream come true :-)