OSDev.org

Hi,

mallard wrote:If you want to dismiss all mainstream OSs as "retarded" then that's fine. I believe that all software is "bad" in some way or another, just to varying degrees.

I only dismissed Linux. OS X never made this mistake, and while Windows did make the mistake they've fixed it since.

mallard wrote:

Brendan wrote: You won't even be able to determine (reliably) what sort of firmware exists; and won't know if VBE is available or not.

Read the real-mode IVT. If entry 10h is a valid entry and pointing to a readable memory address, it's probably valid. If, by chance, it's pointing to readable memory that doesn't contain a video BIOS then when when you try to run it with an x86 emulator or V86 mode process, it will fault in some way, almost certainly pretty quickly. If that happens, you can note it in a configuration file somewhere and don't attempt it in future. VBE availability detected.

Sure, "probably valid", and "by chance", and "lets do something that's almost certainly undefined behaviour and hope we're lucky and it crashes quickly". None of this is close to "acceptable reliability" - it's a dodgy hack that will backfire.

Please note that for an OS to work properly, many separate/unrelated things all have to work properly at the same time - if video works but multi-CPU fails then the OS doesn't work; if video and multi-CPU work but USB fails then the OS doesn't work; etc. If you're willing to accept "works 95% of the time in theory" for each of those separate/unrelated things, then you will end up with "works 90% of the time in practice" (due to bugs, etc) instead. When an OS relies on 2 separate/unrelated things that work 90% of the time in practice, then the chance of both things working is only 81%; and when the OS relies on 10 things that work 90% of the time the chance of all 10 things working is only 35%. For "acceptable" you want the OS as a whole to work 90% of the time or better (see note), which means that when there's 10 separate/unrelated things each of those things must work 99% of the time in practice; which means you can't afford to risk anything less than "works 100% of the time in theory".

Note: There's been many surveys done on customer experience and they all end up with different statistics. However, in general, the rule of thumb is that happy customers will only tell a few people that something was good, and unhappy customers will tell about 10 times as many people that something is bad. This means that if your OS only works on 90% of your computers then 50% of people will hear its bad and 50% will hear it's good.

mallard wrote:The multiboot structure tells you all you need to know if you're planning to use a bootloader-configured framebuffer. You don't need to know if you've got VBE or GOP.

Yes, multi-boot is designed to support setting up a video mode during boot (like it should).

mallard wrote:

Brendan wrote:Wrong. You can make educated guesses and prepare for foreseeable future hardware differences; including "class 3 UEFI", including systems where PCI bridges aren't configured to route "legacy VGA accesses" to any of the video cards, including systems with insanely high resolutions ("10240 * 5760"? Sure, why not), including things like (e.g) 3D VR headsets, including 1024-bit AVX, including systems with more than 256 CPUs, etc.

So you've built an OS that supports all these things then? Or surely, you know someone who has? Some of those ideas will have no difficulty being supported by current OSs (e.g. "insanely high" screen resolutions; mainstream OSs have DPI scaling already). For others, we don't even know what the OS/hardware interfaces will look like (e.g. >256-way SMP), so it's impossible to support them. You can design with the possibility in mind, but that's about it.

These things are all easy to support. If you were designing an OS in 1990 then failing to take these things into account would've been fine (as they all would've been extremely difficult to foresee back then); but if you're designing an OS now you'd be a fool to ignore them.

Note: Intel released the x2APIC spec (the key piece needed to support more than 255 CPUs) in 2006; and when designing your OS's video API it's easy to make sure its suitable for 3D VR headsets (without knowing exact details of any hardware interface because that only effects the device driver and not the rest of the OS).

mallard wrote:VBE and BIOS support isn't going away for the "foreseeable" future. It inevitably will, of course, and I'll design with that possibility in mind, but while the support is there, I may as well use it.

You've already admitted that it's gone away on Apple hardware; and now you're trying to tell me it won't go away?

Do you honestly think it makes any sense to say that something is inevitable but can't be foreseen? The only question is "when" (and the only answer is "starting several years ago").

mallard wrote:

Brendan wrote:The sad part is that all of these people (and you) are too stupid to understand the difference between "works" and "only works for me for now".

In the long-term, there is no difference. What "works" currently will eventually not work, no matter how good you are future-proofing. Better to design for what you have and what you can see on the horizon than spend enormous time and effort designing something "future proof" that inevitably ends up being proved not so.

The difference is "worked well for 20+ years" vs. "constantly fixing design mistakes that could've easily have been avoided when they were made". Note that using a little foresight reduces the amount of work (slightly more work in the beginning, but a lot less in total).

mallard wrote:

Brendan wrote:you've completely failed to explain why an OS would be so poorly designed that it needs to switch video modes after boot without a native driver.

We covered that ages ago. The "without a native driver" scenarios are exactly the same as the "with a native driver" scenarios, except that the user is using hardware that you haven't been able to build a native driver for. (Personally, I'm hoping that some initiative like CDI will result in a decent range of ready-made OS-neutral device drivers being available to hobbyists).

Some "without a native driver" scenarios are different (e.g. only needing to change video modes for a 3D accelerated game that ceases to matter when there's no 3D acceleration), and for the remainder VBE doesn't work for most of them anyway (no support for rotated video modes, likely poor support for the monitor's native resolution, no support for multi-monitor, no support for detecting monitor insertion/removal, etc).

A device driver is something that fills the gap between the interface provided by hardware and the abstraction/interface the OS wants. Different OSs typically have different abstractions/interfaces; so the words "OS neutral device drivers" are self-contradictory.


Cheers,

Brendan

Hi,

Combuster wrote:What's an important part of the problem is that many native graphics drivers are heavily dependent on the presence of the Video BIOS.

The thing here is that graphics hardware is not unique. It was common practice for a manufacturer to distribute a chip, have a licensor put that chip on a board, have him add a ISA/PCI*/AGP/... connector of his choice, memory modules of his choice, and clocks of his choice. This would then get reselled under the brand vendot's product line and you had to be really careful about what it really was because names were pretty distracting. This practice has well continued into the modern generation, although it became more obvious to ask for either a radeon or nvidia, and the brand name came second place in importance.

When PCI was first introduced it took hardware manufacturers a few generations to get it right; and there are ancient PCI video cards that are (literally) ISA cards slapped onto a PCI interface. The same happens for any new technology - it takes a little while for pre-existing solutions to catch up. This includes the introduction of UEFI (e.g. it took Microsoft one generation of their OS to get it "mostly working" and one more generation to get it "working properly").

Combuster wrote:Regardless, you had many chips with the same PCI ID - if it had one - and what happened afterwards is that the remainder of the configuration was stored at a fixed address. This would tell the driver the RAM, clock and DAC properties it needed to reconfigure the clocks to provide stable graphics output on non-VGA resolutions. This has the unfortunate consequence that drivers have to depend on the firmware to provide part of their configuration, and for any pre-EFI images, this is the legacy video ROM.

This practice is known to continue into the latest NVidia series of video cards.

The consequence is obvious: drivers depend on the legacy BIOS being loaded because they would be unable to configure the video card otherwise. This gives a whole slew of backwards compatibility issues for drivers that aren't aware that the firmware might not be present at all times, and probably a significant part of the reason why firmware is consistently loaded at the "usual" address.

For well designed OSs, the native video driver does not depend on legacy/VBE interfaces. This has nothing to do with UEFI and goes all the way back to the introduction of PCI (and the ability to have 2 or more video cards in a computer; where both can't be using "legacy VGA IO ports, etc" at the same time). I even remember tables from around that time (it's still online!) listing which PCI video cards can be used in "multi-video card" systems and which can't (due to things like the "ISA device slapped on a PCI interface" problem).

Note that this does not exclude things like ATI/AMD's "AtomBIOS", where the ROM is used to make things easier for the driver (especially when there are multiple licensed vendors providing different variations), where the legacy/VBE interface is not used.


Cheers,

Brendan

Brendan wrote: You've already admitted that it's gone away on Apple hardware; and now you're trying to tell me it won't go away?

I don't consider Apple hardware to be an "ordinary" PC. "Ordinary" PCs will need to supporrt pre-8 versions of Windows (and other OSs) for some time. That means that VBE support will be available on "ordinary" PCs for the forseeable future. Also, all current Apple hardware has support for BIOS boot, including VBE support. An EFI bootloader such as "rEFInd" can be used to "convert" them into "class 2" systems where VBE is available on EFI boot. So, even on Apple hardware, the support hasn't completely "gone away". If it ever does "completely" go away on ordinary PCs, third-party, "generic" CSM modules will likely fill the gap (some are already available, e.g. SeaBIOS).

Brendan wrote: Some "without a native driver" scenarios are different (e.g. only needing to change video modes for a 3D accelerated game that ceases to matter when there's no 3D acceleration), and for the remainder VBE doesn't work for most of them anyway (no support for rotated video modes, likely poor support for the monitor's native resolution, no support for multi-monitor, no support for detecting monitor insertion/removal, etc).

I never mentioned 3D acceleration in any of my posts. That's your scenario, not mine. "Rotated" video modes can be trivially supported in software, requiring no support in VBE. On the majority of hardware, VBE defaults to "mirrored" mode if multiple monitors in use. Of course, there's no way to detect the resolutions supported by the "second" monitor, so you have to ask the user. If you're asking the user to set a resolution, making them reboot to test each possibility isn't a good user experience.

All I'm saying is that VBE support is available, even with UEFI boot, on the vast majority of hardware. There is a method to detect it with at least 90% accuracy (The chance of there being a valid IVT that points to valid memory that doesn't contain a video BIOS is very small. You can even reject addresses outside of the 0xC0000+ range and not "lose" support for any known hardware.) For the other <10%, an extra boot parameter (to disable the VBE probe) is all that's needed at most. If it's available, and there are no better options (native drivers) then you may as well use it. If it isn't, by all means fall back to a bootloader-configured framebuffer.

Hi,

mallard wrote:All I'm saying is that VBE support is available, even with UEFI boot, on the vast majority of hardware. There is a method to detect it with at least 90% accuracy (The chance of there being a valid IVT that points to valid memory that doesn't contain a video BIOS is very small. You can even reject addresses outside of the 0xC0000+ range and not "lose" support for any known hardware.) For the other <10%, an extra boot parameter (to disable the VBE probe) is all that's needed at most. If it's available, and there are no better options (native drivers) then you may as well use it. If it isn't, by all means fall back to a bootloader-configured framebuffer.

And all I'm saying is that; assuming we're talking about a new well designed OS (without backward compatiblity concerns, and with things like resolution independence); when every PC had VBE it wasn't really worth the hassle of bothering with VBE after boot (and that using it during boot was a "good enough" fallback for systems without native drivers); and now UEFI is here and the hassle of bothering with VBE after boot is far greater, it's gone from "not really worth bothering with" to "incredibly stupid".


Cheers,

Brendan