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

[Skybuck Flying]

Hello,

After seeing a blog about a disk which could work on C64 and on MS-Dos I
asked the following three fun questions for you:

1. Is it possible to make a CD/DVD which would boot dos,linux,windows and
mac ?

This would probably involve a boot program which could switch so maybe it's
not so difficult to do...

So a little bit more difficult question:

2. Is it possible to make an auto run CD/DVD which would automatically play
in dos,linux,windows and mac ?

Finally the most difficult question:

3. Is it possible to make an executable which would work on dos, linux,
windows and mac ?

Bye,
Skybuck =D

 

[Jaelani]

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.

2. 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.

3. 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.

 

[Jaelani]

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

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.

 

[Jaelani]

5 years?  Try 26.  El Torito alone is 15 years old.

5 years. I mean since I bought my PC.

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

How bad is it?

 

[Jaelani]

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.

 

[Jeremy Linton]

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.

Maybe its my perspective, but, WOW, are you kidding? Openfirmware at a
1000ft level seems great, but it failed in one of its primary goals (to
allow cross platform card firmware). It quickly became a case of write
once, debug everywhere, or just write multiple copies due to
incompatibilities between implementations. This was in my view because
the standard wasn't specific enough in all the places that counted and
failed to account for real hardware interaction.

For example, there isn't a way to create an interrupt handler. So,
everything was polled, this quickly lead to a whole host of problems
from ethernet adapters that couldn't boot a system faster than 10MB/sec
to openfirmware prompts that dropped characters when large text buffers
were pasted over RS232 ports running at fast baud rates. (we could blame
some of this on lack of task switching and therefore processing
methodologies, but the result was the same).

IMHO openfirmware appears to work because 3rd party devices are
extremely rare on the computers that use openfirmware. This is the same
reason EFI even pretends to work.

I could go on about openfirmware but I won't.

<rant>

Frankly I'm firmly in the camp that can't quite figure out whats wrong
with PC BIOS. Sure, its got some seriously legacy issues, but from where
I stand it seems its only true failings are in places where the related
standards are complex/poorly defined and the quality of the
implementations aren't so good. IMHO the replacements all suffer from a
case of creating a complex mess which will only lead to more pain in a
time period shorter than BIOS has been around. Frankly, there seems a
lot of "Not Invented Here" happening because a truly KISS replacement
would probably look shockingly like BIOS.

Of course, then we wouldn't be able to throw away the last vestages of
(expired patent) hardware standards created by the XT/AT series.
Hardware standards which probably consume far less than 1% of the area
of a modern device. Trading that hardware instead, for a never ending
set of driver bugs, conflicts and a black hole of unknowns (due to
unpublished hardware specifications) which make it nearly impossible to
guarantee that you can actually get your PC to boot with a given
hardware configuration. Shit, I still have to use PS2 keyboards, RS-232
ports etc on my PC's. This is because when the crap hits the fan what
can I depend on to work when the kernel debugger pops? No, not the USB
keyboard stack, or the TCP/IP stack, but rather the lowly RS-232 port
which can be programmed with a half dozen assembly instructions and
works on every PC with an actual 8250 emulation mode. Hell, the 8042
based interface of the PS2 port (which actually works better in modern
computers due to S3 type power saving states than USB!) and CGA/MDA text
modes again just tend to work because the bugs were worked out 25 years
ago.

</rant>