Hi everyone!<p>As a bit of a gag, I’ve made a graphical IRC Client that runs entirely in the UEFI preboot environment. It features completely overdone features such as TrueType fonts, a cursor, and GUI decorations.<p>I first started this project as I was getting a bit tired building a from-scratch GPS receiver, and wanted to make something relatively quick and lighthearted. As tends to happen, this took a fair bit longer than I anticipated at the outset!<p>A fair chunk of that time was spent on the visualisations in the post showing how scroll views are modelled and how they’re rendered to a static viewport. I really hope you enjoy them!<p>When I first began wanting to "stuff something in UEFI that really shouldn’t be in UEFI", my first instinct was a Twitter client. As it turns out, someone has already done a great job making this by using UEFI’s HTTP protocol! I therefore decided that whatever I made shouldn’t use HTTP at all, because that’s taken. I went with IRC since it sits on top of TCP and has the same social media feel that doesn’t belong anywhere near a preboot environment.
I love this!<p>I think it also emphasizes the complexity and capability of software that underlies the systems most people think about. I think it is a common misconception that your OS is the "lowest level" of the software stack, but in actuality, there is this firmware-ish code that truly owns your system. Sometimes it does a job and goes away, other times stays running the whole time your system is up, transparent even to the OS.<p>Sometimes, the attitude people have about this is along the lines of... "who cares, its just low level code to get my devices running, nothing serious can happen down there".<p>But knowing that you can get a whole IRC client down there doesn't make it too hard to imagine all the other nefarious things that could go on.
> “Why”? What kind of question is “why”?<p>This is the spirit I come to HN for. Thank you for sharing.<p>> The most frightening realization hit me: there wasn't any reason behind what I'd done. I mean, I knew why I'd done it - I just did it because it would be fun. But I knew they would ask, "Why the hell did you do this?" and if I didn't have a good enough reason, they would probably throw me into a mental institution." -- Boyd Rice
> <i>I told a friend I was making a joke project, then explained it. She said she wasn’t sure when to laugh. I’m not so sure either.</i><p>Don't sell yourself short. There's a botnet C&C client project here!<p>OK the UI is a bit funny. :)
This is super cool. Had no idea UEFI APIs were so readily-available and well-documented. Awesome work! Out of curiosity, what was the dev cycle like? I assume you were running the thing in a VM. Did you have to "boot up" every time you wanted to run the client?
Nice! I would like to someday finish writing an OS for my IRC bot that is still running.<p>Maybe the most useless comment but: that non-linear mouse movement (aka acceleration) is the very first thing I turn off when I boot up a new OS. It literally hurts my hand somehow. For example linearmouse is free for Mac. For Windows you can just turn off acceleration. For Linux its easy, obviously.<p>Using mouse acceleration stops you from learning to map a distance traveled by the mouse to a distance on the screen. I do think its more efficient in the long run without it. Something I learned to do from gamers, and something I think all gamers still do for a good reason.
> “Why”? What kind of question is “why”?<p>Because low-level applications like this were promised when UEFI was introduced, that's why. UEFI's creators went even as far as to dream of replacing the Linux-based Internet-only mini-OSes of some vendors which could be accessed by pressing a certain key during boot (though I don't remember what they were called).
Nice writeup! This reminds me of the barebox bootloader April fools two years back, which will connect you to #barebox, when all other boot targets fail[1]. :-)<p>The focus there was on adding TCP support to barebox though and it lacks your nice GUI elements. Only interface was CLI (which can be drawn on top of EFI GOP when barebox is built as EFI payload).<p>[1]: <a href="https://lore.barebox.org/barebox/20220401145902.GF4351@tellis.lin.mbt.kalray.eu/" rel="nofollow">https://lore.barebox.org/barebox/20220401145902.GF4351@telli...</a>
This instantly made me think of a recent video by the Cathode Ray Dude, talking about HP's 'email client' (read: Outlook Plugin) "QuickLook" which was a shipped product implemented this way: <a href="https://www.youtube.com/watch?v=ssob-7sGVWs" rel="nofollow">https://www.youtube.com/watch?v=ssob-7sGVWs</a> (also goes into some even weirder stuff they did).<p>This does the hard bit of networking that QuickLook skipped though.
I can't but think about some music related applications that would benefit from a bare metal environment that boots very quickly and doesn't contain unnecessary bloat, for example a synthesizer (just like MiniDexed for the Raspberry Pi, but not limited to FM), and a effect processor that interfaces with an external pedal board, for guitars, bass etc. Both would require also support for audio cards, although most recent mainboards certainly have decent converters.
As always, the relevant xkcd: <a href="https://xkcd.com/1782/" rel="nofollow">https://xkcd.com/1782/</a><p>I understand that BIOS had limitations but I still think that UEFI is way too much.
> Each time we draw a bit of graphical content to a scroll view, we first allocate the tiles necessary to display the corresponding visual area.<p>I get the intent here, to avoid the issue of not knowing how large a buffer to allocate for your scroll view in the first place. But doesn't this still use way too much memory? Especially for something like an irc client, the scroll view will only grow as the program is used longer, and as such the number of tiles of rendered content will also only grow. You'll of course need to keep the textual history in memory, but that's <i>far</i> smaller than the rendered screen contents.<p>Proper GUI toolkits (disclaimer: I have worked with few, and only a little at that) handle this, I think, by not considering the scroll view a canvas to draw stuff on, but instead a thing that you can place <i>widgets</i> on. Each widget has access to some data that allows it to re-draw its graphical content at some position on-screen, and the scroll view forgets rendered content far outside the visible area, and asks widgets to re-draw their content whenever they get scrolled onto the screen again.<p>Of course, you could expect requests for even more over-engineering ;)<p>Cool stuff! As someone else mentioned, you missed April 1st.
This would be even better if it were a chat interface to ChatGPT so you could ask it troubleshooting questions next time your machine won't boot into OS.