For certain ways of writing the BIOS - you can have the BIOS immediately enter 32/64-bit flat addressing mode (as if you were a 32/64-bit kernel) and then drop back to 16-bit mode when you're done if you need to do a legacy MBR boot. I think this is how coreboot/libreboot/linuxboot/etc. and Tianocore/EDK2 work.

Can you use Tianocore as your BIOS for VirtualBox the way that you can use it (in the form of OVMF) for qemu?

How is SeaBIOS built?

And even writing some 16-bit code using gcc is not impossible too. The problem is that it lacks support for things like near and far pointers.

Without near and far pointers, it is hopeless to write non-trivial programs for 16 bit DOS.

Sure. My argument is that unless you're interested in retrocomputing (which is a cool field, but not the field VirtualBox is in) you shouldn't be writing non-trivial 16-bit programs at all any more - VirtualBox doesn't even support emulating any 16-bit-only CPUs. You should be writing 32-bit programs with a tiny bit of 16-bit code on each end (either in assembly or in trivial C) to switch from 16-bit to 32-bit mode and back. Since you only need the BIOS for a very small amount of time to support a bootloader loading itself, the slowness of switching modes at each interrupt will hardly be your limiting factor (especially given that you're in a VM).

This has the advantage that you don't need any new compiler to build your program, neither OpenWatcom or Digital Mars. (Nothing against the Digital Mars compiler! I just think that it isn't the right engineering direction for VirtualBox to depend on retrocomputing.)

Though it is worth mention that the runtime code that implements BIOS services (INT 10h, 11h, 12h, 13h, etc...) for the most part can't switch to protected mode without breaking compatibility.

You're in an emulator - you don't have to switch to protected mode within the emulation, you can instead exit the VM and do the work outside the emulation. The caller within the emulation won't notice unless it's trying to single-step the BIOS code (and why would they do that?).

Edit: unless the code within the emulator is trying to run the BIOS within an emulator of its own. Turtles all the way down...

>Edit: unless the code within the emulator is trying to run the BIOS within an emulator of its own. Turtles all the way down...

Common with the VGA BIOS BTW.

SeaBIOS is doing a reasonable job at that

but there is also the VGA BIOS.

Do you even need a VGA BIOS in an emulator? It's an emulator - just write to segment B800 or wherever and have the host-side process just watch that page of memory.

Again, qemu works fine without a retrocomputing compiler. Is VirtualBox doing something that prevents it from taking whatever approach qemu uses? (qemu even has the cool thing where "-curses" will cause it to copy segment B800 as text to your host-side terminal emulator and avoid rendering graphics at all.)

What I am talking about is things like this: https://mail.coreboot.org/pipermail/seabios/2015-April/00902...

And even for things like BIOS they can be useful, and that is what I am most interested in.