Multi-Boot, Multi-Autorun, Multi-Executable for dos,linux,windows,mac ?

1. The CD-ROM El-Torito specification itself is capable of multi- booting in order to present a way to decide which one to boot. So multi-booter software such as SYSLINUX or GRUB is optional. Of course, assuming that the PC BIOS support El-Torito specification fully. Some BIOS only shows the first one. Like mine, which is a 5 years old PC.

1. If the Autorun feature is present and is not disabled in the OS, then yes. CD-ROMs supports multiple file-systems. e.g. ISO & UDF (all OS), ISO-RockRidge (UNIX/Linux) or HFS+ (Mac). We can have those three file-systems in one CD for the same files. The required Autorun files however, might be file-system specific, depending on how they work.

2. This has never been proven (nice idea BTW), but IMO, it's "partially" possible. Never tried it myself. I know that a DOS & Window can reside in one executable file. But when adding Linux/Mac into the scene, it might requires additional files. For Linux & Mac, I don't think that's possible since both use the same executable header but the fields are interpreted differently.

Skybuck Fly> Hello,

Relying on the PC BIOS to behave properly when it comes to El Torito is foolish at best. This is particularly damning when it comes to dealing with systems afflicted with EFI, since they *rely* on this feature to be able to multiboot with BIOS. In practice, it is broken on both. This pretty much rules Mac out of the equation (since Macs use EFI -- pretty much the only non-Itanic platform which does.)

However, excluding Mac, modern El Torito bootloaders (like my own Syslinux/ISOLINUX) can do this in software and thus don't rely on the BIOS.

-hpa

S.

Can't argue with that (so much for 5 years of BIOS technology). Multi- platform bootable CD is not a well supported method anyway.

It would be interesting when Linux in BIOS become widely used. :)

From everything I've seen, it's going from bad to much worse.

-hpa

How bad is it?

It's another case of "let's throw the baby out with the bathwater" syndrome. The BIOS is ugly, but all evidence is that LinuxBIOS/Coreboot, EFI, etc. all create the same class of problems just without the long established common ground.

BIOS has been successful not because it is a good standard (it has been declared obsolete at least since the IBM AT, in 1986) but because it is (a) ubiquitous, (b) fairly minimal, (c) sufficient (just barely). EFI fails (a) and (b), although Intel is trying to fix (a) by ramming it down everyones' throats; LinuxBIOS/Coreboot fails (a) and (c).

-hpa

What about that OpenBIOS? Though, I'm not sure about the details or even the exact goal of the project. IMO, it's probably jut another clone of the classic PC BIOS. But it should open a new way for BIOS development. e.g. increased memory capacity (assuming the motherboard can handle it) in order to allow better code and create a new kind of BIOS. Something like Mac BIOS perhaps? I mean, something really different.

Well, the Mac "BIOS" is EFI. Really different, and not in a good way.

I have a bit of a soft spot for OpenFirmware; it is relatively simple and has been tested for a long time, but it is not widely used in the x86 world and even where it is it has some issues.

OpenBIOS seems to have stalled out, but there is a "legacy BIOS payload", based on BochsBIOS, for Coreboot, which makes an interesting combination.

-hpa