// the one-minute version
Windows 10 is the book's second great case study — a modern commercial OS built on the same concepts as Linux but with different choices. Its kernel uses a layered, hybrid design (a small kernel plus a larger "executive"), schedules threads (not processes) by priority, manages memory with demand-paged virtual memory, stores files in the journaling NTFS, and enforces security with per-object access control. Same ideas, different design — that's the point of comparing it with Linux.
Windows runs on more desktops than anything else, and it's built from the exact concepts in this book — but it makes different design calls than Linux. Putting the two side by side is the best way to see that these concepts are principles, not one fixed implementation.
01 Design goals
Windows was designed for security, reliability, compatibility (run decades of old software), performance, portability across hardware, and extensibility. Backward compatibility is unusually central — a huge amount of Windows's complexity exists to keep old applications working on new versions, a very different priority from Linux's.
02 Layered, hybrid architecture
Windows uses a layered/hybrid structure. At the bottom, the Hardware Abstraction Layer (HAL) hides hardware differences. Above it sits a small kernel (scheduling, interrupts, low-level sync). On top is the larger executive — the bulk of OS services. Around it, user-mode subsystems present APIs (like Win32) to applications.
HAL
Hides hardware specifics so the rest of the OS is portable across machines.
Kernel
Small core: thread scheduling, interrupt handling, basic synchronization.
Executive
The big service layer: process manager, memory manager, I/O manager, security reference monitor, object manager.
Subsystems
User-mode environments (like the Win32 API) presenting the OS to applications.
03 Processes and threads
As throughout the book, the thread is the unit Windows schedules; a process is a container of threads plus an address space and resources. Windows is heavily multithreaded internally, which is why threading (Chapter 4) is so central to its design. It also supports lightweight fibers and thread pools for high-concurrency servers.
04 Scheduling
Windows uses priority-based, preemptive scheduling with 32 priority levels (0–31). The highest-priority ready thread runs; equal-priority threads share via round robin. It applies priority boosts to threads that just completed I/O or own the foreground window, then lets the priority decay — a practical blend of the priority and round-robin ideas from Chapter 5 that keeps the interface responsive.
05 Memory management
Windows implements demand-paged virtual memory (Chapters 9–10): each process gets a large private virtual address space, mapped to physical frames via page tables, with pages brought in on demand and evicted under pressure. It tracks each process's working set to keep its active pages resident and avoid thrashing — exactly Chapter 10's model — and uses a standby/modified page list as a second-chance buffer before pages are reused.
06 NTFS: the file system
Windows stores files in NTFS, a modern journaling file system. It journals metadata for fast crash recovery (Chapter 15), supports large volumes and files, per-file permissions via access control lists (Chapter 17), compression, and encryption (EFS). Its central structure, the Master File Table (MFT), records every file — conceptually like the inode table, but a file's small data can even live inside its MFT record.
07 Security
Security is built deep into Windows. Every securable object (file, process, registry key) has a security descriptor with an ACL (Chapter 17) listing who may do what. A security reference monitor in the executive checks every access against these. User accounts carry access tokens with their privileges, and features like User Account Control implement least-privilege ideas concretely by separating standard and administrator rights.
08 Why two case studies
Linux and Windows bookend the course on purpose. They prove the concepts are universal — every one appears in both — while the differing designs show there's no single correct OS, only trade-offs chosen for different goals. If you can see the same scheduler, pager, and file-system ideas under two very different surfaces, you've understood the subject.
common catches & gotchas
- Windows is hybrid, not microkernel — It has a small-core structure but runs the executive in kernel space for speed. Calling it a pure microkernel is wrong.
- Threads, not processes, are scheduled — Like most modern systems, the schedulable unit is the thread; the process is just a container. Easy to misstate.
- 32 priority levels with boosts — Windows scheduling isn't pure priority — it boosts then decays priorities for responsiveness. The dynamic behavior matters.
- NTFS journals metadata — Like ext4, NTFS journals metadata for fast recovery; that protects structure, not necessarily the newest file contents.
- Compatibility drives complexity — Much of Windows's size exists to run old software. Its design choices only make sense with backward compatibility as a top goal.
09 Questions students actually ask
Is Windows monolithic or microkernel?
Hybrid. It has a small kernel and separated executive components (a microkernel-style structure) but runs most of them in kernel space for performance, like a monolith. A pragmatic blend rather than either pure design.
Does Windows schedule processes or threads?
Threads. The thread is the schedulable unit; a process is a container holding threads plus an address space and resources. Windows uses priority-based preemptive scheduling across 32 priority levels, with boosts for responsiveness.
What makes NTFS modern?
It journals metadata for fast crash recovery, supports large files and volumes, and provides per-file access control lists, compression, and encryption. Its Master File Table records all files, playing a role like the inode table in UNIX.
Why study both Linux and Windows?
To show the concepts are universal — both implement threads, paging, journaling file systems, and ACLs — while their different designs prove there's no single right OS, only trade-offs chosen for different goals like openness versus backward compatibility.
What is the object manager in Windows?
An executive component that treats nearly everything — files, processes, events, registry keys — as a uniform kernel object with a handle and a security descriptor, giving consistent naming, lifetime, and access control across very different resources.
10 Key takeaways
- Windows 10 is the book's commercial case study — same concepts, different choices than Linux.
- It uses a layered/hybrid design: HAL, small kernel, large executive, subsystems, object manager.
- The thread is the scheduled unit; scheduling is priority-based preemptive (32 levels) with boosts.
- Memory is demand-paged virtual memory with per-process working sets.
- NTFS journals metadata and enforces per-file ACLs via the MFT.
- Security is pervasive: every object has a security descriptor checked by a reference monitor.
- Comparing it with Linux shows the concepts are universal; only the trade-offs differ.
11 Wrapping up
That closes the companion. From "why an OS exists" in Chapter 1 to two full real systems here, every chapter was a facet of the same two jobs — manage the resources, guard the machine. You now have the whole map. Head back to the chapter index to revisit any topic.