Code Wrangling at its Best
In Chapter 4, we built the first memory-management layer: Now we add the next layer: paging. Paging lets the CPU translate a virtual address into a physical address through page tables. In 32-bit x86 paging without PAE, a virtual address is split into a page-directory index, page-table index, and page offset; page directories and page
Before we add paging, a heap, processes, filesystems, or user programs, the kernel must answer a basic question: Which physical 4 KiB pages of RAM are safe for me to use? Right now, our kernel can boot, print text, catch CPU exceptions, and receive timer/keyboard interrupts. But it still cannot safely allocate memory. This chapter
Continue Reading “Chapter 4 — Reading the Memory Map and Building a Physical Page Allocator”
In Chapter 2 we taught the CPU how to call our code when something goes wrong: Now we will teach the machine how to call our code when hardware wants attention: This is the first step toward a living kernel. A timer interrupt eventually gives us scheduling. Keyboard input eventually gives us a kernel monitor
Continue Reading “Chapter 3 — Hardware Interrupts: PIC, PIT Timer, and Keyboard Input”
In Chapter 1, we got control of the machine: Now we need something more important than printing text: we need the CPU to call our code when something goes wrong. Right now, if the kernel executes an invalid instruction, divides by zero, touches unmapped memory later, or faults during setup, the machine may reset, hang,
Continue Reading “Chapter 2 — GDT, IDT, and Surviving Your First Kernel Crash”
Today, we are beginning a new article series: “Writing a Linux-Style Operating System From Scratch.” In this series, we will walk step by step through the process of creating our own operating system from the ground up. Many operating system tutorials stop shortly after the system boots and prints a simple message on the screen.
Continue Reading “Writing a Linux-style Operating System From Scratch”
Together, these tools allow us to assemble, compile, link, inspect, and transform kernel binaries without using the host operating system’s normal compiler target.
Every major shift in computing has triggered the same fear: “Is this the end of developers as we know them?” When compilers replaced handwritten machine code, some thought assembly programmers were finished. When high-level languages emerged, others predicted the death of low-level expertise. When frameworks abstracted enormous amounts of boilerplate, people claimed “anyone can build
In today’s developer landscape, many programmers—both new and seasoned—cling to a single coding paradigm as the “one true way,” dismissing others like object-oriented, functional, or event-driven programming as bloated or misguided. But real engineering maturity comes from knowing why each paradigm exists and when to use it. The most successful developers choose their tools based on risk, scalability, and maintainability—not ideology. This article explores why the refusal to evolve beyond one style limits growth, risks project failure, and ignores decades of hard-earned lessons in software design.
There’s a real disconnect between the code that’s visible and the veteran status that’s claimed. This discrepancy isn’t trivial
Continue Reading “The Pirate Software Paradox: What Happens When Influence Outpaces Skill”
Call me a control freak. But after decades in software development, I’ve learned to be cautious, especially when it comes to building systems on top of third-party APIs. While APIs can offer short-term acceleration, they often introduce long-term fragility that you can’t control. Why Relying on 3rd Party APIs Is Risky Using third-party APIs might
Recent Comments