Code Wrangling at its Best
In Chapter 6, the kernel heap still depended on low identity-mapped physical pages. That worked as a bootstrap step, but it tied the heap to the first 16 MiB of RAM. In Chapter 7, we added a real VMM and proved that the kernel can map and unmap pages anywhere the page tables allow. That
Continue Reading “Chapter 8 – Moving the Heap onto Virtual Memory”
In Chapter 5 we enabled paging, but only with a fixed identity map: In Chapter 6 we built a heap, but it still had an important weakness: because only the first 16 MiB were identity-mapped. Now we fix the architectural problem. This chapter adds a small virtual memory manager, or VMM: This lets the kernel
Continue Reading “Chapter 7 — A Real Virtual Memory Mapping Layer”
In Chapter 5, we enabled paging with a simple identity map: That gave us a working paged kernel, but not yet a comfortable way to allocate variable-sized objects. The physical memory manager gives us whole pages: But kernel code usually needs smaller objects: So this chapter builds the first kernel heap. We will keep it
Continue Reading “Chapter 6 — Building the First Kernel Heap”
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
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”
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”
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”
One of GAMBAS’s biggest advantages is its fully integrated development environment (IDE), which resembles VB6 and offers an easy-to-use graphical interface. This makes creating forms, handling events, and connecting to databases significantly faster than using more complex frameworks.
Continue Reading “Why GAMBAS BASIC Deserves a Place in Your Development Toolbox”
Introduction As an electronics enthusiast with over 50 years of experience, I’ve had the privilege of witnessing the dramatic evolution of computing systems. From the early days of 4 and 8-bit machines with minimal RAM to today’s powerful 64-bit computers with terabytes of storage, the progress has been nothing short of extraordinary. The same transformative
Continue Reading “Developing an Open Hardware Device Programmer”
OOP is Not What You Think It Is
Object-Oriented Programming (OOP) has become one of the most popular paradigms in modern software development, yet it’s often misunderstood. When most people hear “OOP,” they think of classes, inheritance, and the rigid hierarchy of objects—features that languages like C++ and Java have made standard. But this wasn’t the original vision.
The roots of OOP lie in the groundbreaking work of Alan Kay, who introduced the world to the concept in the 1970s through the creation of Smalltalk. For Kay, OOP wasn’t about objects in the way we think of them today—it was about message passing, a way for software components to communicate seamlessly without getting bogged down by the internal structure. In this vision, objects were secondary to the messages they exchanged, which encouraged flexibility, modularity, and dynamic behavior.
Smalltalk: A Different Kind of OOP
Smalltalk wasn’t just a programming language—it was a philosophy. Unlike C++ and other modern OOP languages that focus on complex class hierarchies, Smalltalk treated objects as living entities capable of sending and receiving messages. This idea of message passing was central, allowing objects to respond in ways that weren’t strictly predefined. The focus was on behavior over structure, encouraging experimentation and evolution within a system.
Smalltalk’s version of OOP was lightweight, adaptable, and far less rigid than what we see today. Alan Kay’s emphasis was on how objects collaborate rather than how they inherit from one another. This made systems designed in Smalltalk inherently more flexible, allowing for changes without the fear of breaking the underlying architecture—a stark contrast to the tightly coupled systems often seen in C++-based projects.
What Went Wrong: The Rise of Modern OOP
As languages like C++ gained popularity, the industry’s perception of OOP began to shift. Object-Oriented Programming became synonymous with class-based design, encapsulation, and inheritance. Message passing was sidelined in favor of method invocation, where functions are called directly on objects, leading to more rigid and complex systems.
The shift from Smalltalk’s dynamic message-passing model to the static class structures of C++ marked a fundamental change in how we build software. It wasn’t long before terms like polymorphism, encapsulation, and inheritance became the buzzwords of OOP, but the simplicity and elegance of Kay’s original ideas were lost in the process. Modern OOP became more about managing structure than about fostering communication between entities.
Recent Comments