Running a VBE Bios or VESA Bios?

[Brendan]

Hi,

It seems like you are right about the text output protocol. It seems to be a software construction where it is possible to emulate the whole thing. There is not even an specification of the buffer address or pixel organisation,

The text output protocol is a nice abstraction - it could be using any video mode, or sending the text over network or serial and not using video at all, or anything else.

But that doesn't invalidate my previous claims. The best video-mode to emulate text mode with is 640x350, which gives 8x14 cells.

The best way to eat your own feces is with a spoon (after you boil it). Would I create a restaurant that sells feces? Of course not. The same applies to text mode - the best way to emulate text mode is irrelevant because nobody sane wants it in the first place (no bold/italic, no anti-aliasing, no font sizes, no proportional fonts and no internationalisation) and any OS that actually uses text mode (or emulates text mode) is doing a disservice to its users.

No; the typical use of applications is whatever the user feels like (full screen, in a window, tiled, spread across multiple monitors, minimised, etc). Your code is designed by a fool, so you're attempting to pretend that users want code designed by a fool (despite a huge amount of evidence to the contrary).

You forgot one. On multiple virtual full screens with fast switching. That means you don't need to move or resize windows, and also don't need the window frame which is ugly and uses screen space.

Erm. My monitors can take up to one second of "black screen" to figure out what video mode the video card has switched to before they display anything after a video mode switch. Your idea of "fast switching" is painfully slow and ugly for the user. Also note that the user ends up with the monitors native resolution regardless; because the monitors have to do their own (lower quality) image scaling when the video mode is wrong.

Basically, resolution independence prevents "poor quality graphics that are slow and ugly for the user". It also removes a lot of hassle for application developers (who don't need to care about video modes, video resolutions and pixel formats when video is done right). Like most of your arguments, it seems like the main reason you want video mode switching after boot is because you're too lazy to do your job properly.


Cheers,

Brendan

[rdos]

Also: You can reliably use VBE on UEFI systems, if the card supports it (probable for non-integrated solutions or systems with a compatibility support module) provided you use it the same way people use it on non-x86 systems: By creating a "Virtual Real-Mode Machine" with a sufficiently fleshed out BIOS implementation, then performing the standard option ROM initialization steps in it. If implemented right, the card will correctly hook the VBE interrupts, at which point you can use it by invoking VBE interrupts inside said emulator. You might want to steal the implementations of various BIOS functions from the Bochs BIOS as experimentally needed (e.g. quite clearly you need not support disk I/O).

The option ROM should successfully re-initialize the device into VGA compatibility text mode (after all, this is necessary to support warm boots), i.e., into a mode which the VESA BIOS can support.

This is a good point, and an excellent migration path to UEFI. Although I think you are wrong about needing an emulator (V86 mode should work), and the "BIOS" image you use must not access standard PC-hardware, otherwise you will be in big trouble. I think it would be no big problem to scan for the video adapter in the 0xC0000 to 0xCFFFF area, and then initialize it so it hooks the correct interrupts. I'm not sure how much of BIOS emulation would be required other than the things that are emulated already.

Then I can boot with UEFI, discard their video-mode, and use VBE as usual. It would probably take a while before most machines no longer have a VESA BIOS. Much longer than the disappearance of the legacy BIOS.

[rdos]

The text output protocol is a nice abstraction - it could be using any video mode, or sending the text over network or serial and not using video at all, or anything else.

It's useless as it is a boot-service only.

The best way to eat your own feces is with a spoon (after you boil it). Would I create a restaurant that sells feces? Of course not. The same applies to text mode - the best way to emulate text mode is irrelevant because nobody sane wants it in the first place (no bold/italic, no anti-aliasing, no font sizes, no proportional fonts and no internationalisation) and any OS that actually uses text mode (or emulates text mode) is doing a disservice to its users.

The command shell shouldn't be internationalized, but instead should run in english only. Applications, of course, should not be done in text-mode (unless they print something simple), but with an GUI (but not within Windows). This actually is the concept on mobile phones as well. They have no Windows. Everything runs full-screen.

As an example of the superiority of the command shell, consider listing all ACPI devices. In the Windows GUI, you can do this in a very awkward way, looking device-for-device, with a single parameter displayed at a time. Of course, you cannot print a full device-list to a file. At the RDOS command shell you simply do:

dev >dev.txt

or

pci >pci.txt (to get a full PCI device list)

or

usb >usb.txt (to get a full USB device list)

Erm. My monitors can take up to one second of "black screen" to figure out what video mode the video card has switched to before they display anything after a video mode switch.

Then you are using an old monitor. Modern LCD monitors no longer take a long time to switch video mode.

Basically, resolution independence prevents "poor quality graphics that are slow and ugly for the user". It also removes a lot of hassle for application developers (who don't need to care about video modes, video resolutions and pixel formats when video is done right). Like most of your arguments, it seems like the main reason you want video mode switching after boot is because you're too lazy to do your job properly.

No, I'm not locking my users into a Windowed GUI, but rather let them develop in whatever video-mode they prefer, with and without typical GUI functionality. You are the one that locks your end user into a dated windowing concept that modern portable devices has abandoned.

[rdos]

Support for the idea that Windows (even 64-bit versions) uses it's own ROM BIOS to switch video modes: http://www.geoffchappell.com/studies/wi ... i/x86bios/

Bochs Bios: http://bochs.sourceforge.net/cgi-bin/to ... lxr/source

Unfortunately, the Bochs BIOS is a mess of C and assembly in some odd syntax. OTOH, could be useful to extract the things needed. For instance, it contains the int 0x15 emulation, and code for scanning for video adapters.

[Griwes]

Plot twist - modern smartphones do use multiple windows at once - look at for example galaxy notes and their pop-up S-note windows or at their multitasking features.

[dozniak]

Then you are using an old monitor. Modern LCD monitors no longer take a long time to switch video mode.

What about a TV connected to the computer? Is my 2011 SONY TV too old?

[Brendan]

Hi,

Also: You can reliably use VBE on UEFI systems, if the card supports it (probable for non-integrated solutions or systems with a compatibility support module) provided you use it the same way people use it on non-x86 systems: By creating a "Virtual Real-Mode Machine" with a sufficiently fleshed out BIOS implementation, then performing the standard option ROM initialization steps in it. If implemented right, the card will correctly hook the VBE interrupts, at which point you can use it by invoking VBE interrupts inside said emulator. You might want to steal the implementations of various BIOS functions from the Bochs BIOS as experimentally needed (e.g. quite clearly you need not support disk I/O).

The option ROM should successfully re-initialize the device into VGA compatibility text mode (after all, this is necessary to support warm boots), i.e., into a mode which the VESA BIOS can support.

For pure UEFI, the goal is to have a "UEFI driver" in the video card's ROM (using either native 80x86 code or portable "EFI byte code"). Except for "compatibility with obsolete BIOS" there is no need for VBE to exist in the video card at all and no need for a "UEFI only" system to have a chipset that supports any of the legacy VGA IO port and display memory window forwarding that VGA/VBE requires. The industry is still making a transition from "BIOS" to "BIOS+UEFI" to "pure UEFI" so ugly hacks to force obsolete stuff like VBE to work are sadly still possible, but there is no guarantee that it will work in future (and no guarantee that it will actually work in 100% of 80x86 UEFI systems today for that matter).

It's only a matter of time before someone at Intel decides that they can streamline the next "CPUs plus GPUs/video plus most of the chipset" chip intended for Windows tablets (or notebooks or phones or whatever) by ripping out a butt-load of unnecessary/deprecated bloat.

Then I can boot with UEFI, discard their video-mode, and use VBE as usual. It would probably take a while before most machines no longer have a VESA BIOS. Much longer than the disappearance of the legacy BIOS.

It will take a while. When it finally does happen you're screwed and will need to rewrite parts of your OS and all of your applications because you were too stupid to listen now, and I suspect that the cost of fixing your design failure after it's too late will be too high to be economically viable and all your customers will shift to QNX or Linux or something else instead.

Of course I really don't care what happens to RDOS. What I do care about is you encouraging beginners to follow your path towards inevitable doom. It's hard enough weaning beginners off of the BIOS without you doing your best to sabotage their work before they've really begun.

The text output protocol is a nice abstraction - it could be using any video mode, or sending the text over network or serial and not using video at all, or anything else.

It's useless as it is a boot-service only.

If you're writing an OS then you need to provide code to "operate the system", and therefore you only need to use something like UEFI's text output protocol during boot. If you're only writing a "UEFI application" (that doesn't take control of the hardware and only pretends to be an OS) then you shouldn't be calling the "exit boot services" function and can continue using UEFI's text output protocol. Either way you shouldn't care that it's a boot-service only.

As an example of the superiority of the command shell, consider listing all ACPI devices. In the Windows GUI, you can do this in a very awkward way, looking device-for-device, with a single parameter displayed at a time. Of course, you cannot print a full device-list to a file. At the RDOS command shell you simply do:

Is this a joke? As an example of the superiority of the GUI, consider playing Crysis in a window. In the Windows GUI you do a few mouse clicks. To do this in RDOS's command shell you...?

Users don't care about listing all ACPI devices. Normal users care about browsing the web, watching videos, writing letters in WYSIWYG editors and calculating their budget. System administrators don't want to use command line either - they want nice graphical tools with context sensitive help and visual cues. Programmers also don't want to use command line (most most hide or automate it using scripts and/or IDEs just get rid of it).

The only people that use command line are people that don't have a choice because the OS sucks and lacks graphical tools to do the job. This includes people that use command line applications for scripting (because sadly a lot of graphical OSs like Windows and Ubuntu still don't support good scripting for graphical applications).

Of course I'm not interested in reviving crap that other OSs have almost entirely abandoned - it's much more practical to learn by their mistakes and avoid wasting time bothering with command line (and providing modern graphical tools and a suitable scripting language instead).

Erm. My monitors can take up to one second of "black screen" to figure out what video mode the video card has switched to before they display anything after a video mode switch.

Then you are using an old monitor. Modern LCD monitors no longer take a long time to switch video mode.

Ironically, the fastest switching monitor I have is about 8 years old (and it's smaller cheap/crappy thing). It's the newest monitor (about 2 years old) that takes the longest.

Basically, resolution independence prevents "poor quality graphics that are slow and ugly for the user". It also removes a lot of hassle for application developers (who don't need to care about video modes, video resolutions and pixel formats when video is done right). Like most of your arguments, it seems like the main reason you want video mode switching after boot is because you're too lazy to do your job properly.

No, I'm not locking my users into a Windowed GUI, but rather let them develop in whatever video-mode they prefer, with and without typical GUI functionality. You are the one that locks your end user into a dated windowing concept that modern portable devices has abandoned.

You're mixing 2 completely separate things together. You can have a windowed GUI without resolution independence; and you can have "full screen only" with resolution independence (or any other combination of with/without).

For windowing, almost all systems that support windowing also support full screen applications, so you lose nothing by providing support for windowing and you have no sane/valid reason to avoid it (although this doesn't necessarily apply to only windowing - there are other ways, like tiling, which may work as well for users).

For resolution independence, we've talked about this before and I know we'll never agree. Your problem is that you have existing code, so fixing the graphics API ends up being too much work for your specific case, and you're not interested in how things should be. My problem is that I only care about how things should be and I don't care about your specific case.


Cheers,

Brendan

[Combuster]

Of course I really don't care what happens to RDOS. What I do care about is you encouraging beginners to follow your path towards inevitable doom. It's hard enough weaning beginners off of the BIOS without you doing your best to sabotage their work before they've really begun.

QFT.

Can we get rid of this spamlist of lies and rdos' permanent need to hijack other people's threads?

[rdos]

Of course I really don't care what happens to RDOS. What I do care about is you encouraging beginners to follow your path towards inevitable doom. It's hard enough weaning beginners off of the BIOS without you doing your best to sabotage their work before they've really begun.

QFT.

Can we get rid of this spamlist of lies and rdos' permanent need to hijack other people's threads?

I think this is highly ontopic. I'm suggesting solutions that nobody else have thought of or believes in. The other posters just have given up to the specifying team of UEFI, which ironically is Microsoft among others.

[rdos]

Plot twist - modern smartphones do use multiple windows at once - look at for example galaxy notes and their pop-up S-note windows or at their multitasking features.

Pop-ups are not Windows.

[rdos]

It will take a while. When it finally does happen you're screwed and will need to rewrite parts of your OS and all of your applications because you were too stupid to listen now, and I suspect that the cost of fixing your design failure after it's too late will be too high to be economically viable and all your customers will shift to QNX or Linux or something else instead.

I find that unlikely. We have four people working on RDOS right now, and they think it is a very good system to work with. RDOS will probably be in 2,000 more installations within one or two years.

Of course I really don't care what happens to RDOS. What I do care about is you encouraging beginners to follow your path towards inevitable doom. It's hard enough weaning beginners off of the BIOS without you doing your best to sabotage their work before they've really begun.

No, you don't believe in the adaptation way of working on OSes. As soon as some design feature is broken, you start a new project. My idea is to first support VBE while booting with UEFI, then provlde the graphical emulations of text-mode, and finally support legacy-free PCs. That is a process which will work without much problems. Making the switch directly to legacy-free PCs is a big hassle which will take a long time to achieve.

Users don't care about listing all ACPI devices. Normal users care about browsing the web, watching videos, writing letters in WYSIWYG editors and calculating their budget. System administrators don't want to use command line either - they want nice graphical tools with context sensitive help and visual cues. Programmers also don't want to use command line (most most hide or automate it using scripts and/or IDEs just get rid of it).

RDOS is not targeted at normal users. You should know that by now.

You're mixing 2 completely separate things together. You can have a windowed GUI without resolution independence; and you can have "full screen only" with resolution independence (or any other combination of with/without).

Not true. Coordinate transformations takes time, and so does rescaling images. For best performance, images should be in the right resolution, and for simplicity, the coordinates of widgets should be as well. Also, you forget that our applications are not made for running on any PC, they are designed for a very specific embedded board where we know exactly which screen resolutions are supported.

[PearOs]

Of course I really don't care what happens to RDOS. What I do care about is you encouraging beginners to follow your path towards inevitable doom. It's hard enough weaning beginners off of the BIOS without you doing your best to sabotage their work before they've really begun.

QFT.

Can we get rid of this spamlist of lies and rdos' permanent need to hijack other people's threads?

Hahaha yeah... My thread has been high jacked but oh well.

[Brendan]

Hi,

Of course I really don't care what happens to RDOS. What I do care about is you encouraging beginners to follow your path towards inevitable doom. It's hard enough weaning beginners off of the BIOS without you doing your best to sabotage their work before they've really begun.

No, you don't believe in the adaptation way of working on OSes. As soon as some design feature is broken, you start a new project. My idea is to first support VBE while booting with UEFI, then provlde the graphical emulations of text-mode, and finally support legacy-free PCs. That is a process which will work without much problems. Making the switch directly to legacy-free PCs is a big hassle which will take a long time to achieve.

I believe in doing it right the first time (in the hope of avoiding the need to adapt later). For RDOS it's already too late, but who cares? We're meant to be helping PearOS here (not RDOS), and for PearOS it's not too late to avoid design flaws.

Users don't care about listing all ACPI devices. Normal users care about browsing the web, watching videos, writing letters in WYSIWYG editors and calculating their budget. System administrators don't want to use command line either - they want nice graphical tools with context sensitive help and visual cues. Programmers also don't want to use command line (most most hide or automate it using scripts and/or IDEs just get rid of it).

RDOS is not targeted at normal users. You should know that by now.

I don't know what type/s of users PearOS is targeted at; but I don't think it matters too much - no users of any type really want command line if they can avoid it. For RDOS (which is irrelevant) I'm sceptical that (e.g.) banks would want command line for their automatic teller machines, or that service stations would want command line fuel pumps, but perhaps I'm wrong.

You're mixing 2 completely separate things together. You can have a windowed GUI without resolution independence; and you can have "full screen only" with resolution independence (or any other combination of with/without).

Not true.

It's true that it's possible to have a windowed GUI without resolution independence (e.g. ancient versions of Windows did this). It's also true that you can have "full screen only" with resolution independence (e.g. it'd be quite possible to implement this on top of an X server instead of more sane/windowing GUIs like KDE and Gnome). Windowing systems with resolution independence are also possible (most recent OSs do this); and it's also possible to have "full screen only" without resolution independence (DOS was like that). Basically, not only are all these combinations possible there's also existing software that proves they're possible. Because it's true that all combinations are possible, it's true that windowing systems and resolution independence are separate things.

Coordinate transformations takes time, and so does rescaling images. For best performance, images should be in the right resolution, and for simplicity, the coordinates of widgets should be as well. Also, you forget that our applications are not made for running on any PC, they are designed for a very specific embedded board where we know exactly which screen resolutions are supported.

Coordinate transformations take very little time (the overhead of matrix multiplication/s is virtually nothing compared to the cost of actually drawing things, especially if the code to draw things doesn't suck and does do things like anti-aliasing). Scaling fixed resolution images only has to be done once (from then on you can display the previously scaled version) so the overhead of this isn't very important. Despite this, scaling images can be done quickly enough that the user won't notice if it's scaled every time its used for no reason.

For best image quality you need to draw the graphics for whatever the monitor's native resolution happens to be (to avoid scaling in software or by the monitor itself afterwards); and application developers can't know in advance what all the user's different monitor's native resolutions will be. Failing to provide resolution independence just means that good applications have to implement their own internal resolution independence, and that most applications (where the developer couldn't be bothered) are bad applications that end up providing worse image quality (and other problems, like "stretched" images because some moron forgot to take into account different aspect ratios).

Also, you forget that nobody cares about RDOS, and that I'm talking "in general" (and not talking about any specific OS). I'm almost certain that PearOS will not be running applications designed for RDOS.


Cheers,

Brendan

[Griwes]

Plot twist - modern smartphones do use multiple windows at once - look at for example galaxy notes and their pop-up S-note windows or at their multitasking features.

Pop-ups are not Windows.

You clearly have no clue about what I am talking about. Sure, pop-up windows are not Windows, because Windows is an operating system by Microsoft. And pop-up windows are windows, by the very definition. I can have a snote window floating over my maximised Chrome window and it works just fine.

You just fail to understand that "single foreground window" limitation of some of modern mobile devices may come from OS dumbness, small screen size or CPU and/or GPU to weak to power full windowing system, not because windowing systems are broken (which they aren't ).

[PearOs]

Hi,

Of course I really don't care what happens to RDOS. What I do care about is you encouraging beginners to follow your path towards inevitable doom. It's hard enough weaning beginners off of the BIOS without you doing your best to sabotage their work before they've really begun.

No, you don't believe in the adaptation way of working on OSes. As soon as some design feature is broken, you start a new project. My idea is to first support VBE while booting with UEFI, then provlde the graphical emulations of text-mode, and finally support legacy-free PCs. That is a process which will work without much problems. Making the switch directly to legacy-free PCs is a big hassle which will take a long time to achieve.

I believe in doing it right the first time (in the hope of avoiding the need to adapt later). For RDOS it's already too late, but who cares? We're meant to be helping PearOS here (not RDOS), and for PearOS it's not too late to avoid design flaws.

Users don't care about listing all ACPI devices. Normal users care about browsing the web, watching videos, writing letters in WYSIWYG editors and calculating their budget. System administrators don't want to use command line either - they want nice graphical tools with context sensitive help and visual cues. Programmers also don't want to use command line (most most hide or automate it using scripts and/or IDEs just get rid of it).

RDOS is not targeted at normal users. You should know that by now.

I don't know what type/s of users PearOS is targeted at; but I don't think it matters too much - no users of any type really want command line if they can avoid it. For RDOS (which is irrelevant) I'm sceptical that (e.g.) banks would want command line for their automatic teller machines, or that service stations would want command line fuel pumps, but perhaps I'm wrong.

You're mixing 2 completely separate things together. You can have a windowed GUI without resolution independence; and you can have "full screen only" with resolution independence (or any other combination of with/without).

Not true.

It's true that it's possible to have a windowed GUI without resolution independence (e.g. ancient versions of Windows did this). It's also true that you can have "full screen only" with resolution independence (e.g. it'd be quite possible to implement this on top of an X server instead of more sane/windowing GUIs like KDE and Gnome). Windowing systems with resolution independence are also possible (most recent OSs do this); and it's also possible to have "full screen only" without resolution independence (DOS was like that). Basically, not only are all these combinations possible there's also existing software that proves they're possible. Because it's true that all combinations are possible, it's true that windowing systems and resolution independence are separate things.

Coordinate transformations takes time, and so does rescaling images. For best performance, images should be in the right resolution, and for simplicity, the coordinates of widgets should be as well. Also, you forget that our applications are not made for running on any PC, they are designed for a very specific embedded board where we know exactly which screen resolutions are supported.

Coordinate transformations take very little time (the overhead of matrix multiplication/s is virtually nothing compared to the cost of actually drawing things, especially if the code to draw things doesn't suck and does do things like anti-aliasing). Scaling fixed resolution images only has to be done once (from then on you can display the previously scaled version) so the overhead of this isn't very important. Despite this, scaling images can be done quickly enough that the user won't notice if it's scaled every time its used for no reason.

For best image quality you need to draw the graphics for whatever the monitor's native resolution happens to be (to avoid scaling in software or by the monitor itself afterwards); and application developers can't know in advance what all the user's different monitor's native resolutions will be. Failing to provide resolution independence just means that good applications have to implement their own internal resolution independence, and that most applications (where the developer couldn't be bothered) are bad applications that end up providing worse image quality (and other problems, like "stretched" images because some moron forgot to take into account different aspect ratios).

Also, you forget that nobody cares about RDOS, and that I'm talking "in general" (and not talking about any specific OS). I'm almost certain that PearOS will not be running applications designed for RDOS.


Cheers,

Brendan

Well said Brendan, I appreciate that. PearOs won't probably be running any other Os's software for a long while. My own applications that will run on PearOs are quite different because they are their own format and executable. Mainly because I wrote a C# compiler and have been using that so I have to write using an API to write applications. It works but a little messy at times. As far as VBE goes, I am currently working on porting a C++ Real Mode emulator to C# so that I can use it in my system but I will let you guys know when I run into trouble.

Thanks for all the help guys,

Matt