Encounters
Windows Internals ⚬𓂃｜_encounter｜ENC｜20261013192254-00-•
Quite a lot is known. Windows is proprietary in the sense that you can’t read or rebuild the source, but Microsoft publishes far more about its internals than people tend to assume, and a large community has filled in the rest.
How we know what we know
The canonical reference is the book *Windows Internals* (Russinovich, Solomon, Ionescu, Yosifovich, now in its 7th edition). It’s written with Microsoft’s cooperation and access to source, and it goes deep into the scheduler, memory manager, I/O system, security model, and more. Russinovich also wrote the Sysinternals tools (Process Explorer, Process Monitor, etc.), which Microsoft later acquired. Those tools let you watch much of the machinery live.
Microsoft also publishes debug symbols for nearly every system binary on a public symbol server. With WinDbg you can see internal function names and many kernel data structures by name, which makes reverse engineering far easier than for a truly closed system. The Driver Kit documentation covers a large part of the kernel’s interfaces, because third-party drivers need them.
Beyond that, there are several other sources:
- Academic source access: the Windows Research Kernel was a licensed release of much of the Server 2003 kernel source for universities.
- Leaks: several have happened over the years (NT 4/2000, and a big XP-era one in 2020).
- Independent reverse engineering: researchers like Geoff Chappell have documented undocumented APIs in detail, and security research regularly dissects obscure components.
- Reimplementations: Wine and ReactOS have to reimplement Windows behavior faithfully, so they are themselves a kind of documentation.
The real gaps are in finer details: exact heuristics, newer or niche components, and internals that change between builds.
How the paradigms differ from Unix
A useful starting point is that NT wasn’t descended from Unix at all. Dave Cutler’s team came from DEC's VMS, and that lineage shows everywhere.
“Everything is an object,” not ”everything is a file.” Unix funnels most things through file descriptors and a filesystem namespace1. NT has an Object Manager: processes, threads, files, events, mutexes, registry keys, and memory sections are all kernel objects. They live in their own hierarchical namespace, you access them through handles, and each one carries a security descriptor. Drive letters like
C:are really just symbolic links in that object namespace pointing to something like\Device\HarddiskVolume3.The stable interface is the library, not the syscall. On Linux, the syscall interface is the sacred ABI that must never break. On Windows, system call numbers change between builds and are deliberately undocumented. The contract2 is the Win32 API in DLLs like kernel32.dll, which sits on top of a thinner "Native API" in ntdll.dll. NT was originally designed so that Win32, OS/2, and POSIX could all be “personalities” layered over one kernel. Win32 won, but the layering remains.
Process creation. Unix creates processes with `fork()` (clone the current process) followed by `exec()` (replace it with a new program). Windows has no fork. `CreateProcess` builds a new process from scratch with a large set of parameters. This is a big part of why Cygwin, which emulates fork, is slow. On Windows, threads were first-class from day one, and a process is essentially a container of resources that threads run in.
Command lines. On Unix, the shell splits arguments and hands the program an array. On Windows, a program receives one raw command-line string and parses it itself, usually by C runtime convention. That’s the source of endless quoting weirdness.
I/O is asynchronous at its core. Every I/O request in the NT kernel is an I/O Request Packet (IRP) passed down a stack of layered drivers, which filter drivers can intercept. Completion is inherently asynchronous, and I/O completion ports became the standard for high-performance servers. The model is “tell me when it’s done.” Unix traditionally used a readiness model (“tell me when I can read without blocking,” via select/epoll). Linux’s newer io_uring is partly a move toward the completion style.
Security. Unix started with user/group/other permission bits and a special root user. NT has access control lists on every object, identities as security IDs (SIDs), and per-process access tokens holding a set of granular privileges. Newer layers like integrity levels and sandboxing sit on top. Linux has since added ACLs, capabilities3, and SELinux, but NT started from the richer model.
Configuration. Unix mostly uses text files in `/etc` and dotfiles. Windows uses the registry, a hierarchical database managed by the kernel and stored in binary "hive" files.
IPC and composition. Unix culture composes small programs via text streams and pipes, and uses signals for asynchronous notification. Windows has no real equivalent of signals; it uses events, waits, and asynchronous procedure calls. Its composition model is APIs and COM, a binary component-object system that underlies huge swaths of Windows, from the shell to DirectX. PowerShell reflects this by passing structured .NET objects through pipelines4 instead of text.
Drivers and the GUI. Windows keeps a stable driver model so third-party drivers survive across versions, which is roughly the opposite of Linux’s policy of in-tree drivers with no stable internal kernel API. The windowing system also lives partly in the kernel (win32k.sys5, moved there in NT 4 for performance). Classic Unix put the GUI in an ordinary user-space program, the X server.
In broad strokes: Unix favors a small number of simple, general abstractions (files, processes, text) and lets you compose them. NT favors a richer, more formally engineered set of abstractions (typed objects, ACLs, asynchronous packets, component interfaces) behind a stable library layer. Each philosophy’s strengths are roughly the other’s pain points.
Source: Claude ○˒
(echo_:: @ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ)
(echo:: @ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ ᯤ)Link to original Footnotes