Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

274
Visualizações
How are low-level graphical interfaces programmed?

Recently, I have been experimenting with things like arch Linux and this raised a few questions. I constantly see the use of graphics in very low level parts of an OS(things like the GRUB or almost all boot menus). Some of these even feature images. I can also see graphical manipulation in things like the "pacman" command, where the loading bar will change with out disturbing the text above it. Another example would be a program like cfdisk. I would just like to know how these types of features are programmed?

Edit: By this I mean what system calls are used to make this possible?

Boot menu

over 4 years ago · Santiago Trujillo
2 Respostas
Responde à pergunta

0

This kind of thing was very common in MSDOS back when I was learning to code. There were a set of basic hardware screen modes that could be accessed through simple assembly instructions.

For those supporting ASCII character sets, it was possible to modify the actual glyph images for the characters in memory. Each available character was a simple bitmap, which could be modified in memory to look however you want.

For example, in colour screen modes (e.g. CGA, EGA), the text could be rendered via a specific memory area where one byte specified the character and the other byte specified a colour (foreground and background as 4-bits each for EGA). You just write the values in there and they show on screen. If you had modified your character table, then the modified characters would show.

I can't believe I remembered this just now, but the memory address A000 is apparently burned into my brain. You can read more at https://en.wikipedia.org/wiki/Enhanced_Graphics_Adapter

Of course, there are higher screen modes that support writing actual pixels, and that's how we used to write games. Famously the 320x200 VGA mode was super easy and fast to get "realistic" and smooth animated graphics in mind-blowing 256 colours without worrying about bit planes or anything.

And this is essentially what's happening at the low level. BIOS support for these forgotten graphics modes has existed for a very long time, but modern hardware has abstracted us away from such modes and we now tend to communicate directly with graphics cards via a driver or OS abstractions.

over 4 years ago · Santiago Trujillo Relatório

0

I learned quite a bit on how to initialise and operate on low-level direct memory access graphics modes from the venerable Fractint (original ran on DOS). All the goodies are in a file called video.asm. In addition to EGA/VESA et. al., it also handled some of the available graphics cards at the time, like Hercules.

They chose X server to port it to linux as XFractint. Much of the original look and feel and spirit of the application remains the same. This is probably a good and safe way to start with.

For lower level may be try SVGAlib (I haven't tried this). Most of the Linux low-level graphics from kernel seems to be using VESA BIOS Extensions.

over 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda