Around a year ago I needed to learn assembly to understand a particular piece of code in the kernel. Though I would have loved to spend years reading books about it, I knew the most practical approach—the one that didn’t require years and would let me get back to that piece of code in the kernel before I grow old—was to learn how to write, and subsequently read, assembly through a simple project. I wanted something simple.
Todo apps seem to be every YouTube-web-dev-course’s favourite. I think it’s a waste of time. It’s something that’s been done before a million times, there’s no innovation and there’s nothing new to learn. I believe you are far better off building something you or someone else you know would use. Nobody is going to use the todo app I built either but hey, do as I say, not as I do. This project is purely for educational purposes (and to poke fun at todo app projects).
If it’s not clear yet, this blog will be explaining how to write your very own todo app in GNU x86_64 assembly and walking you through how I did it. I was quite ambitious at the start; I planned to write the entire frontend from scratch in assembly, but a little research showed that to be the opposite of practical. You’d have to write calls to a display server like X11 to help create, manage and draw on windows. X11 will write it to the framebuffer, which is the internal byte representation of your screen at any given moment. You can also write to the framebuffer yourself (if you’re insane) and make your frontend without using any display servers. Checkout this blog post for more information on framebuffers and how you can manipulate them: link.
I, in my limited lifespan, used a simpler approach. Hijack the browser to be your frontend. The browser lets you render HTML, and all it needs is the right response for its requests. So my frontend is…an HTTP server? Well, the entire program is an HTTP server. The way it works requires you to know a little about browsers and how websites are shown. The URL you enter is an identifier for a server somewhere on the internet. This identifier allows your browser to ask this server for resources. HTTP is a way of asking for these resources. A webpage is basically just an HTML page (with it’s CSS and JS) that the server has and the browser asks for via a GET request. The server can choose how to respond to whatever requests it gets and typically, it just sends over the HTML files when asked for it. Once the browser has its hands on the HTML, it can uses it’s internal rendering engine to show the content on the screen.
What this means, is that I can write my frontend in HTML, CSS and JS, have a server running that hosts my application and let the user interact with it through the browser. This isn’t the most user friendly experience, but thankfully we don’t have to worry about our non-existent userbase. If you preferred to write to the framebuffer or use display manager protocols, you’ll have to wait for the next blogs for the next steps (though I’m sure you can figure everything out by yourself) because the rest of this blog will be how to host your own web server using assembly.
First, you need to understand the structure of an assembly program.