Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

273
Views
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 answers
Answer question

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 Report

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 Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!