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
Isn’t that where virtualisation comes in? I doubt Qemu will be removing virtual BIOS support anytime soon.
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.
Bit of a shame really.. feels like loosing a loved pet and all you’re left with are memories.
In theory somebody could take an Open Source (or suitably licensed) BIOS and wrap it into something that EUFI could load, and then use that to bootstrap your way into the BIOS-using OS.
Note that I haven’t given this any real thought at all so may be making it all up.
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.
So modern PCs won’t be “compatible” anymore.
No, but I expect my modern PC to have a simple and easy way to boot any software I am willing to write for it.
Right now what Microsoft is aiming for is a way to prevent people/organizations developing their own software that boots the hardware to do what they want.
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)
Not at first no, but give it a couple more years and we’ll see.
And it’s not like you can take some control of your machine back either, because some hardware requires you to have the MS keys present in the UEFI keychain.
Edit:
On a side note, is it possible to edit the tittle? Some quotation marks get really screwed up in there.
Edited 2017-11-21 11:08 UTC
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…
Long time PC user. I think this is a welcome change. There will always be ways to emulate DOS, et.al.