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.