v86

[Brendan]

Hi,

Here's a "mostly complete" summary of the BIOS's device support:

DISK IO:

• Disk IO for floppy and hard disk. This mostly works most of the time. In some cases it doesn't work - for example, if you've got 2 different SCSI cards then the ROMs in both the SCSI cards "fight" and you can expect one to lose.
• Disk IO for CD-ROM. This mostly only works if you've booted from CD-ROM (but even when you have booted from CD-ROM it may only work for one CD-ROM when there's 2 or more). If you didn't boot from CD-ROM most BIOSs won't provide any CD-ROM support (but in theory you might be lucky for some BIOSs).
• Disk IO for USB devices. This mostly only works if you've booted from a USB device (but even when you have booted from a USB device it may only work for one when there's 2 or more). If you didn't boot from USB most BIOSs won't provide any support.

COMMUNICATION DEVICES:

• Network cards. This mostly only works if you've booted from network (but even when you have booted from network it only works for one network card when there's 2 or more). If you didn't boot from network there is no support.
• Serial ports and parallel ports. These are supported by the BIOS, but the BIOS services are virtually unusable. The problem is that the BIOS uses polling (no input/output buffering or IRQs) which causes data loss if you have to do anything with the data you've received due to the (potentially) high number of "bytes per second".
• Modems (including data, voice and fax). No support (beyond unusable serial port support).

INPUT DEVICES:

• PS/2 keyboard. This should work (but I do have one computer here where the BIOS doesn't support it); but only when the keyboard layout is "US QWERTY" (which mostly means that it is supported but doesn't work for most people).
• PS/2 mouse. Not supported (there are no services like "int 0x16" provided for mouse).
• USB keyboard. This may or may not be supported by BIOS (depends on how old the BIOS is); but if it is supported it doesn't work for most people ("US QWERTY" only).
• USB mouse. Not supported (there are no services like "int 0x16" provided for mouse).
• All other input devices (touchpad, touchscreen, trackball, joystick, bar-code scanner, etc). Not supported.
• Sound cards (recording digitized sound). Not supported.
• Cameras (recording video or just taking pictures). Not supported.
• Scanners. Not supported.

OUTPUT DEVICES:

• Video cards. Sort of supported, but only one. Poor control over video modes (e.g. normally you can't even set the video mode to suit the monitor's native resolution, and the monitor's EDID is typically ignored so it's a pain in the neck just making sure a video mode is usable). No support for anything else (2D/3D acceleration, hardware pointer, MPEG decoder, etc). Note: There was a "VESA VBE/AF" specification designed to try to provide support for some things (hardware pointer, polygons), but nobody ever implemented it
• Braille displays. No support. For some, you can sort of make them work by throwing ASCII at the serial port.
• "PC speaker". The BIOS sort of supports this a little bit (usually you can ask the BIOS to print an ASCII bell character and get a beep). There's no control over pitch/frequency or duration.
• Sound cards (playback of digitized sound or midi). Not supported. Note: There was a "VESA VBE/AI" specification designed to try to provide support for some things, but like a lot of VESA's standards nobody ever implemented it
• Printers. No support. For old printers that connect to parallel port or serial port, you can sort of make them work sometimes by throwing ASCII at the parallel/serial port (no graphics, no colour, no page layout control, etc).

OTHER/MISC:

• Timer. There's support for "ticks since midnight", but this is very low precision (55 ms) and can have problems each day at midnight. It doesn't support delays (e.g. put the computer into a power saving state for some amount of time).
• Time and date. This is supported, but it has the same problems as the RTC (you can't know which time zone and daylight savings support is a complete disaster). If you want both the time and date, then it's racey (e.g. there's no "get time and date" so you have to be careful near midnight and need to get the date, then time, then get the date again).
• IRQ controllers. The PIC is supported sort of. No support for IO APIC, MSI, etc.
• Memory. Almost no support for memory above 0x00100000, except for a "Copy Extended Memory" function. Ironically this function is so hard to use that it's easier (and more reliable) to do it yourself.
• Other CPUs. Not supported (everything is "boot CPU only", and there isn't even any "tell other CPU to execute foo" service).
• A20. Usually supported by BIOS (but it's best to have fall-back "do it yourself" code in case BIOS doesn't support it).
• PCI. Minimal support for reading/writing to PCI configuration space (but it's easier to do it yourself).
• Any sort of hot-plug (e.g. including inserting/removing PS/2 devices, and USB devices if the BIOS happens to actually support any USB devices). Not supported.
• Power management. Minimal support (mostly just "self protection" rather than actual power management).

Note: The hardware itself is typically capable of doing many things at the same time - e.g. the hardware could be loading data from disk, while sending packets to network, while transferring graphics data to display memory, while playing sound, while scanning a document, while printing a document, etc; and while all this is happening the CPU/s are all still free to calculate the millionth digit of PI (or anything else). Because the BIOS services are "synchronous" you can only do one thing at a time (e.g. reading from disk and nothing else, or sending a packet to network and nothing else, etc). For this reason; even if you're writing a single-tasking OS for real mode; you shouldn't use the BIOS services (even if it actually does support the device/s you're using).


Cheers,

Brendan

[kohlrak]

Hi,

Here's a "mostly complete" summary of the BIOS's device support:

DISK IO:

• Disk IO for floppy and hard disk. This mostly works most of the time. In some cases it doesn't work - for example, if you've got 2 different SCSI cards then the ROMs in both the SCSI cards "fight" and you can expect one to lose.
• Disk IO for CD-ROM. This mostly only works if you've booted from CD-ROM (but even when you have booted from CD-ROM it may only work for one CD-ROM when there's 2 or more). If you didn't boot from CD-ROM most BIOSs won't provide any CD-ROM support (but in theory you might be lucky for some BIOSs).
• Disk IO for USB devices. This mostly only works if you've booted from a USB device (but even when you have booted from a USB device it may only work for one when there's 2 or more). If you didn't boot from USB most BIOSs won't provide any support.

COMMUNICATION DEVICES:

• Network cards. This mostly only works if you've booted from network (but even when you have booted from network it only works for one network card when there's 2 or more). If you didn't boot from network there is no support.
• Serial ports and parallel ports. These are supported by the BIOS, but the BIOS services are virtually unusable. The problem is that the BIOS uses polling (no input/output buffering or IRQs) which causes data loss if you have to do anything with the data you've received due to the (potentially) high number of "bytes per second".
• Modems (including data, voice and fax). No support (beyond unusable serial port support).

INPUT DEVICES:

• PS/2 keyboard. This should work (but I do have one computer here where the BIOS doesn't support it); but only when the keyboard layout is "US QWERTY" (which mostly means that it is supported but doesn't work for most people).
• PS/2 mouse. Not supported (there are no services like "int 0x16" provided for mouse).
• USB keyboard. This may or may not be supported by BIOS (depends on how old the BIOS is); but if it is supported it doesn't work for most people ("US QWERTY" only).
• USB mouse. Not supported (there are no services like "int 0x16" provided for mouse).
• All other input devices (touchpad, touchscreen, trackball, joystick, bar-code scanner, etc). Not supported.
• Sound cards (recording digitized sound). Not supported.
• Cameras (recording video or just taking pictures). Not supported.
• Scanners. Not supported.

OUTPUT DEVICES:

• Video cards. Sort of supported, but only one. Poor control over video modes (e.g. normally you can't even set the video mode to suit the monitor's native resolution, and the monitor's EDID is typically ignored so it's a pain in the neck just making sure a video mode is usable). No support for anything else (2D/3D acceleration, hardware pointer, MPEG decoder, etc). Note: There was a "VESA VBE/AF" specification designed to try to provide support for some things (hardware pointer, polygons), but nobody ever implemented it
• Braille displays. No support. For some, you can sort of make them work by throwing ASCII at the serial port.
• "PC speaker". The BIOS sort of supports this a little bit (usually you can ask the BIOS to print an ASCII bell character and get a beep). There's no control over pitch/frequency or duration.
• Sound cards (playback of digitized sound or midi). Not supported. Note: There was a "VESA VBE/AI" specification designed to try to provide support for some things, but like a lot of VESA's standards nobody ever implemented it
• Printers. No support. For old printers that connect to parallel port or serial port, you can sort of make them work sometimes by throwing ASCII at the parallel/serial port (no graphics, no colour, no page layout control, etc).

OTHER/MISC:

• Timer. There's support for "ticks since midnight", but this is very low precision (55 ms) and can have problems each day at midnight. It doesn't support delays (e.g. put the computer into a power saving state for some amount of time).
• Time and date. This is supported, but it has the same problems as the RTC (you can't know which time zone and daylight savings support is a complete disaster). If you want both the time and date, then it's racey (e.g. there's no "get time and date" so you have to be careful near midnight and need to get the date, then time, then get the date again).
• IRQ controllers. The PIC is supported sort of. No support for IO APIC, MSI, etc.
• Memory. Almost no support for memory above 0x00100000, except for a "Copy Extended Memory" function. Ironically this function is so hard to use that it's easier (and more reliable) to do it yourself.
• Other CPUs. Not supported (everything is "boot CPU only", and there isn't even any "tell other CPU to execute foo" service).
• A20. Usually supported by BIOS (but it's best to have fall-back "do it yourself" code in case BIOS doesn't support it).
• PCI. Minimal support for reading/writing to PCI configuration space (but it's easier to do it yourself).
• Any sort of hot-plug (e.g. including inserting/removing PS/2 devices, and USB devices if the BIOS happens to actually support any USB devices). Not supported.
• Power management. Minimal support (mostly just "self protection" rather than actual power management).

Note: The hardware itself is typically capable of doing many things at the same time - e.g. the hardware could be loading data from disk, while sending packets to network, while transferring graphics data to display memory, while playing sound, while scanning a document, while printing a document, etc; and while all this is happening the CPU/s are all still free to calculate the millionth digit of PI (or anything else). Because the BIOS services are "synchronous" you can only do one thing at a time (e.g. reading from disk and nothing else, or sending a packet to network and nothing else, etc). For this reason; even if you're writing a single-tasking OS for real mode; you shouldn't use the BIOS services (even if it actually does support the device/s you're using).


Cheers,

Brendan

Sounds much better.

Anyway, for anyone who needs the solution to my original problem: despite being able to go from 16bit real mode to 32bit pmode directly, to do a far return back to real mode, the cs register must be using a 16bit pmode selector. It appears that it has an effect on the pushw instruction. If it's 32bit, it'll align the pushw to 32bits anyway (just puts 0s in for padding to keep the stack aligned).

EDIT: Oh, and i made a serious mistake with my interrupt descriptor table entry for real mode, if you know what you're doing you should see it right away.

[rdos]

That changes things a lot. In this case (in protected mode most of the time) there's only 4 sane options:

1. Your OS takes control of the hardware; and therefore has no reason to use any real mode/BIOS code.
2. The BIOS remains in control of the hardware; and your protected mode code frequently switches back to real mode to do "nothing" (e.g. a few NOP instructions) to give the BIOS a chance to handle pending IRQs (and you have a "switch to real mode and do BIOS function then switch back to protected mode" routine).
3. The BIOS remains in control of the hardware; but you install your own protected mode IRQ handlers that switch back to real mode and pass control to the BIOS's original IRQ handlers (and you have a "switch to real mode and do BIOS function then switch back to protected mode" routine).
4. The BIOS remains in control of the hardware; and you use virtual8086 to run the BIOS's real mode IRQ handlers (and you have a "switch to real mode and do BIOS function then switch back to protected mode" routine)

Most OSs use the first option, but that means having device drivers, etc. For the remaining options, option #2 is a little dodgy (e.g. can't handle NMI) and is a pain to use (I've used it in boot code, and you need to sprinkle "do nothing" calls everywhere and never know if you've got enough or too many). Option #4 is a complicated - I wouldn't use virtual8086 mode unless you're intending to run applications designed for real mode (e.g. DOS applications running under a 32-bit OS, like Win9x).

Option #3 is a little tricky, but relatively easy. It's probably the best option for your case.

I don't think option #4 is overly complicated. Not on a modern processor that supports VME. By enabling VME, the requirements for handing IF from v86-mode disappears. The kernel needs to install protected mode IRQs that by default switches to v86 mode and handles them there. There is no need to switch to real mode when using v86 mode, and it provides by far the best interrupt performance of the options. Switching to real mode is accomplished by iretd, with a frame containing a 1 in the V86 bit + the extra segment registers on the stack. Switching back can be done by invalid instruction or similar, or possibly an interrupt that has RPL=0.

[Combuster]

Switching to real mode is accomplished by iretd, with a frame containing a 1 in the V86 bit

Protected mode, v8086 submode, thank you

[Brendan]

Hi,

I don't think option #4 is overly complicated. Not on a modern processor that supports VME. By enabling VME, the requirements for handing IF from v86-mode disappears. The kernel needs to install protected mode IRQs that by default switches to v86 mode and handles them there. There is no need to switch to real mode when using v86 mode, and it provides by far the best interrupt performance of the options. Switching to real mode is accomplished by iretd, with a frame containing a 1 in the V86 bit + the extra segment registers on the stack. Switching back can be done by invalid instruction or similar, or possibly an interrupt that has RPL=0.

The main problem with virtual8086 mode is that some BIOS code (things like network boot ROMs designed to support both real mode and protected mode interfaces) may use protected mode internally. The end result of this is that your code has to emulate "virtual protected mode within virtual8086 mode" until the BIOS/ROM code disables protected mode again, or your code crashes/panics.

Note: In my opinion any BIOS/ROM code that attempts to enable protected mode is wrong and broken. Sadly "wrong and broken" BIOS/ROM code does exist, and (from the end user's perspective) it's your fault if your OS crashes (regardless of what the underlying cause actually is).


Cheers,

Brendan

[kohlrak]

Hi,

I don't think option #4 is overly complicated. Not on a modern processor that supports VME. By enabling VME, the requirements for handing IF from v86-mode disappears. The kernel needs to install protected mode IRQs that by default switches to v86 mode and handles them there. There is no need to switch to real mode when using v86 mode, and it provides by far the best interrupt performance of the options. Switching to real mode is accomplished by iretd, with a frame containing a 1 in the V86 bit + the extra segment registers on the stack. Switching back can be done by invalid instruction or similar, or possibly an interrupt that has RPL=0.

The main problem with virtual8086 mode is that some BIOS code (things like network boot ROMs designed to support both real mode and protected mode interfaces) may use protected mode internally. The end result of this is that your code has to emulate "virtual protected mode within virtual8086 mode" until the BIOS/ROM code disables protected mode again, or your code crashes/panics.

Note: In my opinion any BIOS/ROM code that attempts to enable protected mode is wrong and broken. Sadly "wrong and broken" BIOS/ROM code does exist, and (from the end user's perspective) it's your fault if your OS crashes (regardless of what the underlying cause actually is).


Cheers,

Brendan

That's why you do a "this-determines-your-computer's-compatibility-with-my-OS test." Slap filling the test on there with the ram requirements and things like that. Once the thing works, if someone buys new hardware that makes the bios crash the thing, then the user will blame the hardware.

I don't think option #4 is overly complicated. Not on a modern processor that supports VME. By enabling VME, the requirements for handing IF from v86-mode disappears. The kernel needs to install protected mode IRQs that by default switches to v86 mode and handles them there. There is no need to switch to real mode when using v86 mode, and it provides by far the best interrupt performance of the options. Switching to real mode is accomplished by iretd, with a frame containing a 1 in the V86 bit + the extra segment registers on the stack. Switching back can be done by invalid instruction or similar, or possibly an interrupt that has RPL=0.

My problem with this is that you have an extra layer of complexity if you want to also implement your own exception handlers.

[rdos]

Hi,

I don't think option #4 is overly complicated. Not on a modern processor that supports VME. By enabling VME, the requirements for handing IF from v86-mode disappears. The kernel needs to install protected mode IRQs that by default switches to v86 mode and handles them there. There is no need to switch to real mode when using v86 mode, and it provides by far the best interrupt performance of the options. Switching to real mode is accomplished by iretd, with a frame containing a 1 in the V86 bit + the extra segment registers on the stack. Switching back can be done by invalid instruction or similar, or possibly an interrupt that has RPL=0.

The main problem with virtual8086 mode is that some BIOS code (things like network boot ROMs designed to support both real mode and protected mode interfaces) may use protected mode internally. The end result of this is that your code has to emulate "virtual protected mode within virtual8086 mode" until the BIOS/ROM code disables protected mode again, or your code crashes/panics.

Note: In my opinion any BIOS/ROM code that attempts to enable protected mode is wrong and broken. Sadly "wrong and broken" BIOS/ROM code does exist, and (from the end user's perspective) it's your fault if your OS crashes (regardless of what the underlying cause actually is).

I don't know about disc access and other types of BIOS accesses, but in my experience no BIOS switches video-mode by entering protected mode. That's because my v86 monitor doesn't support this, and it still works on all machines I've tested on (which is quite a few at the moment).

[bluemoon]

How about UEFI -> BIOS stub? I can imagine it's totally natural for the future BIOS stub being a wrapper for UEFI which runs in protected mode or long mode.

[Brendan]

Hi,

The main problem with virtual8086 mode is that some BIOS code (things like network boot ROMs designed to support both real mode and protected mode interfaces) may use protected mode internally. The end result of this is that your code has to emulate "virtual protected mode within virtual8086 mode" until the BIOS/ROM code disables protected mode again, or your code crashes/panics.

Note: In my opinion any BIOS/ROM code that attempts to enable protected mode is wrong and broken. Sadly "wrong and broken" BIOS/ROM code does exist, and (from the end user's perspective) it's your fault if your OS crashes (regardless of what the underlying cause actually is).

That's why you do a "this-determines-your-computer's-compatibility-with-my-OS test." Slap filling the test on there with the ram requirements and things like that. Once the thing works, if someone buys new hardware that makes the bios crash the thing, then the user will blame the hardware.

There's no difference between a "this-determines-your-computer's-compatibility-with-my-OS test" and a "this-determines-my-OS's-compatibility-with-your-computer test". Of course if the test boots from CD (with no network support provided by BIOS) and the OS boots from network (with no CD support provided by BIOS), then the test isn't going to detect problems caused by the network card's ROM (and any problems with the CD support that are detected are going to be irrelevant).

My problem with this is that you have an extra layer of complexity if you want to also implement your own exception handlers.

Just a minor note - yesterday I implemented "option #3" (protected mode; with interrupt handlers that switch to real mode, call the BIOS interrupt handler then return to protected mode). It took about 5 hours to do; including a silly/test boot loader and the ability to determine if an interrupt was caused by an exception (because most BIOSs don't support exceptions properly - e.g. they go into an "infinite IRQ 5" loop when there's a general protection fault). I was planning on adding "BSOD code" to display the details of exceptions and then maybe releasing it somewhere today (e.g. "announcements" forum) as a demo/example; but today is completely borked and I'm not sure I'll be able to do much in the next few days.


Cheers,

Brendan

[Brendan]

Hi,

How about UEFI -> BIOS stub? I can imagine it's totally natural for the future BIOS stub being a wrapper for UEFI which runs in protected mode or long mode.

Once hardware (rather than merely firmware) has fully adopted UEFI, this won't work; because the hardware that a "stub BIOS" would rely on (like PIC, PIT, PS/2, the old memory map, etc) will cease to exist.

A better idea would be the reverse - a "BIOS -> UEFI stub" that emulates UEFI on old BIOS systems to allow a modern "UEFI only" OS to boot.


Cheers,

Brendan

[kohlrak]

There's no difference between a "this-determines-your-computer's-compatibility-with-my-OS test" and a "this-determines-my-OS's-compatibility-with-your-computer test".

There is, and it's called "marketing." Notice things come with a "made for windows" sticker on it? This isn't to make microsoft happy. Not to say that any amount of marketing will make any of our OSes sound much better, but you can be pretty convincing if you're not afraid to be winded (or to have writers cramp).

Of course if the test boots from CD (with no network support provided by BIOS) and the OS boots from network (with no CD support provided by BIOS), then the test isn't going to detect problems caused by the network card's ROM (and any problems with the CD support that are detected are going to be irrelevant).

That is why you make controlled tests.

Just a minor note - yesterday I implemented "option #3" (protected mode; with interrupt handlers that switch to real mode, call the BIOS interrupt handler then return to protected mode). It took about 5 hours to do; including a silly/test boot loader and the ability to determine if an interrupt was caused by an exception (because most BIOSs don't support exceptions properly - e.g. they go into an "infinite IRQ 5" loop when there's a general protection fault). I was planning on adding "BSOD code" to display the details of exceptions and then maybe releasing it somewhere today (e.g. "announcements" forum) as a demo/example; but today is completely borked and I'm not sure I'll be able to do much in the next few days.

I know the feeling. This is why i want to spend the least amount of time in the BIOS (that and it reduces the complexity for the learner). Since my primary support is going to be Floppy/HDD/USB-emulated-hdd, i don't have to worry about the said cd problem or network problem. What i'm going to do is write a program that does everything that relies on the bios for my kernel, then check it, and if the user sees a space ship flying through stars, it's good to go and odds are their bios won't be a problem.

IMO, the x86 arch is just full of all these old and not so good standards that allowed room for all the BS. As such, the arch is a pure mess of bad setups. After this kernel's done and the lessons are written, i'm moving onto thumb mode ARMs and arms up to v8 (i might have to look for a new arch when it hits v8 [i think the charm of arm is the lack of standards {standards are good, so long as they're good standards}, but many systems have open docs]).

Once hardware (rather than merely firmware) has fully adopted UEFI, this won't work; because the hardware that a "stub BIOS" would rely on (like PIC, PIT, PS/2, the old memory map, etc) will cease to exist.

If UEFI wasn't so scary (system lock downs, even if you own it), I would say that it's a good thing. UEFI sounds great except for the fact that it's a good avenue for OEM level DRM. And i think everyone here knows that means Windows or MacOSX or it doesn't boot. Look at hardware drivers.

A better idea would be the reverse - a "BIOS -> UEFI stub" that emulates UEFI on old BIOS systems to allow a modern "UEFI only" OS to boot.

Doesn't sell enough. When the time comes to switch, they make more money having you buying new computers than upgrading old ones.

[Brendan]

Hi,

There's no difference between a "this-determines-your-computer's-compatibility-with-my-OS test" and a "this-determines-my-OS's-compatibility-with-your-computer test".

There is, and it's called "marketing." Notice things come with a "made for windows" sticker on it? This isn't to make microsoft happy. Not to say that any amount of marketing will make any of our OSes sound much better, but you can be pretty convincing if you're not afraid to be winded (or to have writers cramp).

Microsoft actually matters to consumers, and if a piece of hardware doesn't work in Windows then the average consumer is much more likely to blame the hardware. You are not Microsoft; and the end user will be blaming you (especially if the hardware works correctly in Windows and other OSs).

Of course if the test boots from CD (with no network support provided by BIOS) and the OS boots from network (with no CD support provided by BIOS), then the test isn't going to detect problems caused by the network card's ROM (and any problems with the CD support that are detected are going to be irrelevant).

This is why i want to spend the least amount of time in the BIOS (that and it reduces the complexity for the learner). Since my primary support is going to be Floppy/HDD/USB-emulated-hdd, i don't have to worry about the said cd problem or network problem.

So you'll have to worry about "USB emulated HDD" instead of worrying about CD support or network support? That changes everything - your OS can fail (even when the "does-this-OS-suck test" passes) for a slightly different reason!

IMO, the x86 arch is just full of all these old and not so good standards that allowed room for all the BS. As such, the arch is a pure mess of bad setups. After this kernel's done and the lessons are written, i'm moving onto thumb mode ARMs and arms up to v8 (i might have to look for a new arch when it hits v8 [i think the charm of arm is the lack of standards {standards are good, so long as they're good standards}, but many systems have open docs]).

The BIOS is only intended to be enough to get an OS booted. You think the 80x86 is full of old and not so good standards because you're trying to use the BIOS for more than just booting (e.g. using it as "drivers" after boot, instead of writing your own good drivers). I think ARM will be good for you - there are no standards (not even old/bad ones) and you will be forced to write your own drivers, and will begin to learn how to do things right.

Once hardware (rather than merely firmware) has fully adopted UEFI, this won't work; because the hardware that a "stub BIOS" would rely on (like PIC, PIT, PS/2, the old memory map, etc) will cease to exist.

If UEFI wasn't so scary (system lock downs, even if you own it), I would say that it's a good thing. UEFI sounds great except for the fact that it's a good avenue for OEM level DRM. And i think everyone here knows that means Windows or MacOSX or it doesn't boot. Look at hardware drivers.

The lock-down/DRM issue was over-hyped and is solved already. Of course ARM is different - hardware manufacturers have been locking ARM systems down for a lot longer and there are no work-arounds. Hopefully, Microsoft will force UEFI onto ARM systems (to get around the "no standards" problem) and we'll be able to use the existing "UEFI work-arounds" on ARM instead of having no option at all.

A better idea would be the reverse - a "BIOS -> UEFI stub" that emulates UEFI on old BIOS systems to allow a modern "UEFI only" OS to boot.

Doesn't sell enough. When the time comes to switch, they make more money having you buying new computers than upgrading old ones.

So you're agreeing that future of an OS that uses BIOS instead of good/native drivers is limited?


Cheers,

Brendan

[rdos]

Hi,

How about UEFI -> BIOS stub? I can imagine it's totally natural for the future BIOS stub being a wrapper for UEFI which runs in protected mode or long mode.

Once hardware (rather than merely firmware) has fully adopted UEFI, this won't work; because the hardware that a "stub BIOS" would rely on (like PIC, PIT, PS/2, the old memory map, etc) will cease to exist.

A better idea would be the reverse - a "BIOS -> UEFI stub" that emulates UEFI on old BIOS systems to allow a modern "UEFI only" OS to boot.

Yes, there are such systems. Many new UEFI-capable BIOSes seems to emulate UEFI on top of BIOS. That way, the computer can still run older OSes designed without UEFI-support. I'm sure that these computers will at some point be replaced by computers that have no BIOS support, but only UEFI support. It doesn't make much sense to emulate BIOS on top of UEFI. Especially since most OSes that uses BIOS from V86-mode doesn't support the BIOS switching mode anyway.

[kohlrak]

Microsoft actually matters to consumers, and if a piece of hardware doesn't work in Windows then the average consumer is much more likely to blame the hardware. You are not Microsoft; and the end user will be blaming you (especially if the hardware works correctly in Windows and other OSs).

Microsoft matters to consumers because of marketing. If microsoft changed it's name, it wouldn't matter. Marketing is the key to everything.

So you'll have to worry about "USB emulated HDD" instead of worrying about CD support or network support? That changes everything - your OS can fail (even when the "does-this-OS-suck test" passes) for a slightly different reason!

Primary loader is USB. Odds are it'll be tested on USB before floppy or hd, due to the saving mechanism: it'll assume it owns he whole HD. Official support will be for USB, not floopy or HDD: it's just convenient that it happens to work for them, too.

The BIOS is only intended to be enough to get an OS booted. You think the 80x86 is full of old and not so good standards because you're trying to use the BIOS for more than just booting (e.g. using it as "drivers" after boot, instead of writing your own good drivers). I think ARM will be good for you - there are no standards (not even old/bad ones) and you will be forced to write your own drivers, and will begin to learn how to do things right.

It's alot more than just the standards set by the BIOS. Look at the GDT and the IDT and A20, just for examples in the processor family itself.

The nice thing about ARM will be that there will be open hardware (for the dev platforms) that give us documentation. The hardware is consistent to specific boards, so we do not have to poll for everything and look for identifiers that might very well be fake or broken. Driver development doesn't bother me: having to conform to an x number of standards that i can't even test my code against does, especially when said standards might not even be in use anymore. And then you have closed hardware that you can't even support. Frankly, it's a mess.

The lock-down/DRM issue was over-hyped and is solved already. Of course ARM is different - hardware manufacturers have been locking ARM systems down for a lot longer and there are no work-arounds. Hopefully, Microsoft will force UEFI onto ARM systems (to get around the "no standards" problem) and we'll be able to use the existing "UEFI work-arounds" on ARM instead of having no option at all.

It may be solved for now, but will it remain that way? What when they argue that theirs is the only OS that anyone wants to run? MS will not do anything that promotes competition: history shows them not to be the heros (UEFI is getting put on ARMs, it's just not requiring the option for disabling secure boot). My migration to ARM has nothing to do with OSes to compete with the big 3, so much as OSes to interface hardware (perhaps for manufacturing or making new systems for other purposes). Let's face it, the big 3 most likely will not be challenged by anyone here. There is a future, however, for systems that are not for facebook and all that stuff. For all that, most people are happy where they're at and the existing OSes will do, despite all the problems (people would rather live with the problems than deal with them, so let them keep it that way). Instead, if you want your OS to be used by more than just you, you have to come up with a different purpose for it. And heaven knows, there are *ALOT* of needs out there that are just aching to be fulfilled.

So you're agreeing that future of an OS that uses BIOS instead of good/native drivers is limited?

You have to be a fool to not see that, but only for the x86. UEFI is, in itself, just a new look at a BIOS standard. Thinking of i as x86 BIOS being reinvented to drop old standards, but to implement them for now so people can run their legacy software.

[FallenAvatar]

Microsoft actually matters to consumers, and if a piece of hardware doesn't work in Windows then the average consumer is much more likely to blame the hardware. You are not Microsoft; and the end user will be blaming you (especially if the hardware works correctly in Windows and other OSs).

Microsoft matters to consumers because of marketing. If microsoft changed it's name, it wouldn't matter. Marketing is the key to everything.

Right, too bad no one here considers marketing until after they have something to market..... (Why is this brought up???)

The BIOS is only intended to be enough to get an OS booted. You think the 80x86 is full of old and not so good standards because you're trying to use the BIOS for more than just booting (e.g. using it as "drivers" after boot, instead of writing your own good drivers). I think ARM will be good for you - there are no standards (not even old/bad ones) and you will be forced to write your own drivers, and will begin to learn how to do things right.

It's alot more than just the standards set by the BIOS. Look at the GDT and the IDT and A20, just for examples in the processor family itself.

The nice thing about ARM will be that there will be open hardware (for the dev platforms) that give us documentation. The hardware is consistent to specific boards, so we do not have to poll for everything and look for identifiers that might very well be fake or broken. Driver development doesn't bother me: having to conform to an x number of standards that i can't even test my code against does, especially when said standards might not even be in use anymore. And then you have closed hardware that you can't even support. Frankly, it's a mess.

So you prefer an arch that does not cater to the end user? (On ARM you still have to care about differet devices, look at the HTC Evo vs. the HTC One+, there is a gigantic difference in hardware. But because you are targeting ARM you don't have to query the hardware to figure out what you have to deal with.......wait.....)

The lock-down/DRM issue was over-hyped and is solved already. Of course ARM is different - hardware manufacturers have been locking ARM systems down for a lot longer and there are no work-arounds. Hopefully, Microsoft will force UEFI onto ARM systems (to get around the "no standards" problem) and we'll be able to use the existing "UEFI work-arounds" on ARM instead of having no option at all.

It may be solved for now, but will it remain that way? What when they argue that theirs is the only OS that anyone wants to run? MS will not do anything that promotes competition: history shows them not to be the heros (UEFI is getting put on ARMs, it's just not requiring the option for disabling secure boot). My migration to ARM has nothing to do with OSes to compete with the big 3, so much as OSes to interface hardware (perhaps for manufacturing or making new systems for other purposes). Let's face it, the big 3 most likely will not be challenged by anyone here.

That's very close minded, and insulting. (Not to say that I am going to write the next killer OS) But that no one from here could be the next Linus (Assuming you are refering to linux.)

There is a future, however, for systems that are not for facebook and all that stuff.

What else would you use a computer for? (I can think of many reasons.....namely gaming, the market Valve has on lock espicially with their linux port of Steam. What is your idea of another use {that other systems don't cover}?)

For all that, most people are happy where they're at and the existing OSes will do, despite all the problems (people would rather live with the problems than deal with them, so let them keep it that way). Instead, if you want your OS to be used by more than just you, you have to come up with a different purpose for it. And heaven knows, there are *ALOT* of needs out there that are just aching to be fulfilled.

Do tell...

So you're agreeing that future of an OS that uses BIOS instead of good/native drivers is limited?

You have to be a fool to not see that, but only for the x86. UEFI is, in itself, just a new look at a BIOS standard. Thinking of i as x86 BIOS being reinvented to drop old standards, but to implement them for now so people can run their legacy software.

UEFI offers much more standardization of boot level services. And given that, and what you said, why the heck are you asking about how to drop back to Real Mode???

- Monk