
Computer users of a certain age will remember BIOS as ubiquitous firmware that came loaded on PCs. It was the thing you saw briefly before your operating system loaded, and you could dig into the settings to change your computer's boot order, enable or disable some features, and more.
Most modern PCs ship with UEFI instead. But most also still have a "legacy BIOS" mode that allows you to use software or hardware that might not be fully compatible with UEFI.
In a few years that might not be an option anymore: Intel has announced plans to end support for legacy BIOS compatibility by 2020.
This most certainly affects many older operating systems - especially older hobby and alternative operating systems that were never updated with UEFI support.

This should only be a serious issue for 16-bit OSes or for bootloaders, as using multiboot (or more generally any bootloader that puts the machine into a known state regardless of UEFI/BIOS) the differences between UEFI and BIOS were largely abstracted from 32-bit and 64-bit OSes.
Hi,
It's not quite that simple.
There's a lot of backward compatibility built into the hardware itself - things like the PIT chip (replaced by HPET years ago), the PIC chips (replaced by IO APICs years ago), "PS/2 emulation for USB devices" (and related support in USB controllers and USB keyboard/mouse to make it work), legacy PATA emulation modes in disk controllers, VGA (in the video card's registers, in the video card's ROM and "legacy IO port" ranges in PCI bridges), etc.
Once the BIOS is gone, there's no "backward compatibility" reason for all of this older junk to remain, so you can expect it all to disappear.
That sounds great at first ("Yay, no more A20 gate!") until you look at what's left and realise that it's a hideously over-engineered nightmare, with no way for beginner OS developers to gain the experience (on simpler/older things) that is necessary to cope with the complexity.
- Brendan
This may make emulators written in Javascript even more valuable in the future.
Think of Bellard's JSLinux ( https://bellard.org/jslinux/ ) or
V86 ( http://copy.sh/v86/ ).
And, there are even emulators for less common systems such as the Amiga ( http://creativejs.com/2012/12/html5-amiga-emulator/index.html ).
A bonus of having an emulator written in Javascript is that it can be run in a browser (or Node.js). Of course this makes it possible to have a virtual machine on a Chromebook in its default "User Mode".
Thanks to multiboot specification and Grub, most 64 bits OSes should be okay: http://wiki.osdev.org/Multiboot
I'm not sure about 32 bit ones, however it looks like 16 bit OSes will probably no longer be supported.
The only major open source OS I know in that category would be FreeDOS. The explicitly do not support UEFI http://wiki.freedos.org/wiki/index.php/UEFI . Even if they did, it would not help much, since most DOS programs require BIOS APIs to function. Even simple things like printing characters to text screen are sometime done thru BIOS calls.
I don't think anything short of emulation will allow them to continue to work.
They already did this for the Atom line of CPU's.
Even today's modern netbooks that are sold come with baked in 32 bit efi firmware that only support specific OS configurations, even if some models come with 4 GB of RAM or even higher.
Not even sure that Intel officially sells Atom CPU's these days, aside from OEM's.
Eh, you're spreading anti-MS hysteria ...and not a very new one. Same thing was said of Trusted Platform Module or Secure Boot, that they would prevent Linux / alternative OS on "MS" hardware ...and none of those predictions came to pass (in fact, TPM is used to probably greatest lenghts by Linux PCs - Chromebooks)
Problems with adding new features requiring disabling of older ones became evident about 15 years ago when AMD's high performance timer prevented use of the internal floppy controller. I hope the pure UEFI startup will make it easier to utilize all improvements to newer systems.
Good thing Haiku has UEFI support about 90% complete :-)
https://www.freelists.org/post/haiku-commits/haiku-hrev51183-srctool...