Part 1 drew SWTOS — a microkernel with no MMU, where addresses are addresses and isolation is a discipline rather than a mechanism. This is the same viewer, the same data contract and the same array-language middle layer, pointed at a system with all the machinery SWTOS does without.

MesaOS is a 64-bit hybrid kernel: a physical frame allocator, a virtual memory manager, a higher-half direct map, a kernel heap, and ELF programs running in Ring 3 behind a real privilege boundary. What is drawn here is its memory layout — kernel sections, loaded modules, bootloader requests and sparse allocations, laid out as 512 KiB blobs with the empty space summarized rather than drawn.

Resource Link
MesaOS (upstream) crackanimad0r/MesaOS
MesaOS (my fork) softwarewrighter/MesaOS
How it works Made Visible #1
Comments Discord

MesaOS

Three views of the MesaOS memory layout: kernel sections in place, the same space with a region highlighted, and recolored by kind
MesaOS: sparse 512 KiB blobs with logarithmic summaries --- kernel sections, modules and bootloader requests, classified the same way.

MesaOS is the conventional one, and that is why it belongs here. It is somebody else’s work — I am running a fork of it. A 64-bit hybrid kernel with a physical frame allocator, a virtual memory manager, a higher-half direct map, a kernel heap, and ELF programs running in Ring 3 behind a real privilege boundary. Textbook architecture, the kind SWTOS deliberately is not.

xclock running as a Ring 3 ELF program under MesaOS, its second hand sweeping
An ELF program in Ring 3, drawing. Capture from my fork.

Which makes it the useful second case. SWTOS has no MMU at all — addresses are addresses, and isolation is a discipline rather than a mechanism. MesaOS has exactly the machinery SWTOS does without: frames, mappings, and a distinction between what is physically there and what a process is allowed to see. The same picture has to mean something in both.

A note on the name. MesaOS is what the upstream project is called, and the name is well and truly spoken for: mesaos.com belongs to an active restaurant point-of-sale product, and it is in use elsewhere besides. So neither the upstream project nor my fork is necessarily keeping it. If you go searching for MesaOS and find yourself reading about kitchen printers, you have not taken a wrong turn — and if either repository has been renamed by the time you read this, that is why.

Nothing in the visualizer changed

That is the part worth sitting with. The renderer has no idea what a page table is. It received the same columnar description any producer emits — spaces, region kinds, owners, offsets, lengths — and MesaOS filled it with its own vocabulary: kernel sections, modules, bootloader requests, sparse blobs. Part 1 has the format and the reasoning behind it.

The region names are data. limine_requests means nothing to the visualizer, and it does not need to — it needs a color for it, and the palette covers the union of what the producers emit.