OSDev.org

rdos wrote:When you boot an operating system not built on PE or ELF flat binaries of the right bitness, the UEFI loader (and GRUB) is just creating problems with no benefits. First, I both need a 64-bit and a 32-bit EFI, and the 64-bit EFI needs to switch back to 32-bit protected mode in order to be compatible. Then I need to turn-off paging as this is setup in a different way in the OS. Basically, leaving control in 64-bit "flat paged mode" has no benefits at all for me. I'd rather be in real mode instead.

Leaving control in real mode has no benefits either. You still need to set up the CPU mostly from scratch either way.

You've forgotten the part where UEFI (and GRUB) can parse filesystems, which makes loading files from the disk much easier.

rdos wrote:It's still faster than writing 4 bytes per pixel times 8 pixels wide times 19 lines per character. I mean, a typical "hobby" OS will not have a native graphics driver, rather relies on LFB.

Update only the parts of the screen that change, and set the LFB to use write combining.

rdos wrote:A typical console needs to output the right ASCII characters otherwise, it is be broken. After all, text-mode apps assume they can draw boxes and similar. You also need to emulate the blinking cursor by regularly updating the LFB.

A typical console needs to output the right Unicode characters; otherwise, it's broken. What good are box drawing characters when I need to simultaneously display text in English, Arabic, and Chinese?

Octocontrabass wrote: You've forgotten the part where UEFI (and GRUB) can parse filesystems, which makes loading files from the disk much easier.

Yes, and that's the buggy part. I managed to find one way to do with that works on at least 3 different UEFIs. The problem is, if you don't read files like Windows or Linux does, then there is no guarantee that it will work since it is basically untested.

Octocontrabass wrote: A typical console needs to output the right Unicode characters; otherwise, it's broken. What good are box drawing characters when I need to simultaneously display text in English, Arabic, and Chinese?

I think that is a different type of console from the one running legacy-coded apps. You cannot both have unicode support and support for box drawing, since the unicode extensions overlap the box characters. Also, text mode apps that use unicode will not work on the real text mode console.

rdos wrote:The problem is, if you don't read files like Windows or Linux does, then there is no guarantee that it will work since it is basically untested.

The same is true of BIOS functions.

rdos wrote:You cannot both have unicode support and support for box drawing, since the unicode extensions overlap the box characters.

Unicode has the exact same box drawing characters. The code points are different, but it's not difficult to come up with a wrapper that will translate the output from legacy programs into Unicode.

rdos wrote:Also, text mode apps that use unicode will not work on the real text mode console.

EGA and VGA text mode has hardware support for displaying 512 unique characters at a time, and those characters can be reprogrammed at any time. Displaying text in multiple languages is well within the realm of possibility, although you'll have to be clever when 512 characters isn't enough.

Octocontrabass wrote:

rdos wrote:You cannot both have unicode support and support for box drawing, since the unicode extensions overlap the box characters.

Unicode has the exact same box drawing characters. The code points are different, but it's not difficult to come up with a wrapper that will translate the output from legacy programs into Unicode.

At the moment, the text console is used with some old programs (like an editor) that use the old ASCII standard. Other than that, programs are in English, so don't need unicode. The programs that have UIs don't use the text console, rather run in graphics mode both on EFI and BIOS and use UTF-8. The emulator on UEFI uses a fixed 8x19 font (that is ASCII mapped), so works naturally with the old ASCII standard and not with UTF-8. That way, the text console works the same both on a real text mode and on UEFI emulated console.

Still, I do like the new EFI designed mode that has an emulated console and fixed resolution, so I might merge them eventually, but I need to be backwards compatible as my company has some 500 terminals running on hardware that only boot with BIOS. Also, on older hardware the graphics is too slow for an emulated console.

Octocontrabass wrote:

rdos wrote:Also, text mode apps that use unicode will not work on the real text mode console.

EGA and VGA text mode has hardware support for displaying 512 unique characters at a time, and those characters can be reprogrammed at any time. Displaying text in multiple languages is well within the realm of possibility, although you'll have to be clever when 512 characters isn't enough.

That's more of a curiosity.

rdos wrote:Other than that, programs are in English, so don't need unicode.

The world is becoming increasingly global. By explicitly refusing to support internationalization, you're limiting the potential user base of your OS.

rdos wrote:Still, I do like the new EFI designed mode that has an emulated console and fixed resolution, so I might merge them eventually, but I need to be backwards compatible as my company has some 500 terminals running on hardware that only boot with BIOS.

The EFI text console is a boot service, not a run-time service. You can't use it from within an OS.

rdos wrote:Also, on older hardware the graphics is too slow for an emulated console.

Have you tried my earlier suggestion? (Updating only parts of the framebuffer that change, and using write-combining.)

rdos wrote:

Octocontrabass wrote:512 unique characters at a time

That's more of a curiosity.

So is RDOS.

Octocontrabass wrote:

rdos wrote:Other than that, programs are in English, so don't need unicode.

The world is becoming increasingly global. By explicitly refusing to support internationalization, you're limiting the potential user base of your OS.

End users will not use the console. It's for programmers and developers only, and internationalization in that area is not interesting.

Octocontrabass wrote:

rdos wrote:Still, I do like the new EFI designed mode that has an emulated console and fixed resolution, so I might merge them eventually, but I need to be backwards compatible as my company has some 500 terminals running on hardware that only boot with BIOS.

The EFI text console is a boot service, not a run-time service. You can't use it from within an OS.

The LFB is a run-time service. You combine that with a table for 19x8 fixed fonts mapped for ASCII. Not so hard to do, and this is needed in order to create crash screens and debug screens. When the OS is up, you use TrueType fonts instead, but that is not the console.

Hi,

rdos wrote:End users will not use the console. It's for programmers and developers only, and internationalization in that area is not interesting.

You should rather rethink this.

There may be text files that are not plain ASCII. How do you display them in the console? Same for filenames displayed using "ls", "dir", or whatever the command for listing a directory is.

Text mode is limited in other ways too. What if a programmer wants to run a console application in something bigger than 80x25? How does your console allow that? What if this console application is designed to use bold/italic/underlined text?

Also, are you sure a programmer will like to see a 80x25 console that uses an aliased font that makes his eyes hurt?


Regards,
glauxosdever

glauxosdever wrote: There may be text files that are not plain ASCII. How do you display them in the console? Same for filenames displayed using "ls", "dir", or whatever the command for listing a directory is.

If you edit them, you can display them in hex, but there is no convenient way to show them as UTF-8 or similar.

OTOH, the shell is just a program that normally runs in a text-console. It can be exchanged with something else, like something that uses a graphics mode and TrueType fonts. The shell is not built-into the OS. It's just another user app. You might even build a shell that partly has a command prompt, party a file browser and possibly other things as well.

I have rebuilt the console device in the EFI-version so it can be shared between processes (it was a bad design to tie the console to a process which required a lot of work to fix). Also, a process now may use only part of the visible console. I'm back-porting this to the BIOS / VESA version as well so BIOS boots also can share consoles and spawn processes in the same console. I might even add a mode to the BIOS version that emulates text mode with the highest available video-mode, much like EFI works, and never switches video-mode at run-time.

glauxosdever wrote: Text mode is limited in other ways too. What if a programmer wants to run a console application in something bigger than 80x25? How does your console allow that? What if this console application is designed to use bold/italic/underlined text?

Also, are you sure a programmer will like to see a 80x25 console that uses an aliased font that makes his eyes hurt?

The application can ask for the console size, and adapt to that if it wishes. It cannot change it though.

Hi,

rdos wrote:

glauxosdever wrote: There may be text files that are not plain ASCII. How do you display them in the console? Same for filenames displayed using "ls", "dir", or whatever the command for listing a directory is.

If you edit them, you can display them in hex, but there is no convenient way to show them as UTF-8 or similar.

So the user will have to decode the multibyte sequences himself? I don't think that's very usable. Could easily be fixed with not using a text mode in the first place.

rdos wrote:The shell is not built-into the OS. It's just another user app.

Then why should it even be allowed to change video modes? The need for that however can easily be avoided by shifting the console to use its own designated window, instead of using a text mode in the first place.

rdos wrote:The application can ask for the console size, and adapt to that if it wishes. It cannot change it though.

Could easily be done by shifting the console to use its own designated window, and then resizing it. However, you will have to not use a text mode in the first place.


Regards,
glauxosdever

glauxosdever wrote:Then why should it even be allowed to change video modes? The need for that however can easily be avoided by shifting the console to use its own designated window, instead of using a text mode in the first place.

I'm not a fan of windowed designs, so I never implemented this in RDOS. Rather, RDOS uses different views / consoles that run in full-screen mode. Typically, an app has its own console, and will not compete with other apps in a windowed design. The keyboard has reserved short-cuts (CTRL + funktion key) to switch between consoles. So the shell typically runs in a console, and can even run in more than one console. When a new app it started, it can be detached, and then runs in a new console (in the shell, this is done by using the @ character before the command). That's also why different consoles can run in different video modes (at least in the BIOS version). So a tool to display an JPEG image might setup the most suitable resolution that matches the picture size.

The terminal app we have developed runs full screen in its own console. It sets a fixed resolution (typically 640x480 or 800x600), and runs using a widget class library. When it is deployed, a loader application also runs in its own console (in text mode), but is invisible since there is no keyboard that can be used to switch consoles. The kernel debugger also typically is always running, and it also runs in its own console and is invisible unless you know how to switch to it.

glauxosdever wrote:Could easily be done by shifting the console to use its own designated window, and then resizing it. However, you will have to not use a text mode in the first place.

I have no plans to develop a windowed GUI. If I do, it will be another user app that runs special apps, or runs console apps by limiting their consoles.