> ## Documentation Index > Fetch the complete documentation index at: https://siriusbar.net/llms.txt > Use this file to discover all available pages before exploring further. # Phase 2 — The Windows Filesystem Layout > Reading the C: drive tree with Unix habits: System32, Program Files, Users, AppData, and the backwards SysWOW64. In Phase 1 we learned to talk to a Windows box. Now we walk its filesystem. The directory tree is where I build my first map of any OS, so let me map `C:\` onto what I already know. ## There is no single `/` In Linux, everything hangs off one root, `/`, and every disk, partition, and network share is mounted somewhere inside that single tree. Windows does not start there. Each volume gets its own letter and its own root: `C:\`, `D:\`, and so on. `C:` is just the common letter for the boot drive. That is the first mapping that breaks. There is no global `/` that contains everything; there are several roots living side by side. > When I go looking for "the root", I should ask "the root of which volume?". `C:\` is the closest thing to `/`, but only for that one disk. ## The directories that matter in `C:\` Walking `C:\`, most top-level directories have a rough equivalent to something I already know. * `C:\Windows`: the operating system itself lives here — much of what I would scatter across `/boot`, `/lib`, and parts of `/usr`. (Your note said "not so sure" here, and that is fair — we fix it precisely below.) * `C:\Program Files`: installed 64-bit applications, closest to `/opt` or `/usr/local`. * `C:\Program Files (x86)`: the same idea, but only for 32-bit applications on a 64-bit system. * `C:\ProgramData`: machine-wide application data, hidden by default. Think `/var/lib` plus a little system-wide `/etc`. * `C:\PerfLogs`: Windows performance logs, empty by default — a narrow slice of `/var/log`. * `C:\Users`: the `/home` of Windows. One detail on the `Program Files` split: on a 32-bit system, `Program Files` holds the 32-bit (and historically 16-bit) applications. On a 64-bit system, 64-bit applications go to `Program Files` and 32-bit ones are pushed into `Program Files (x86)`. The architecture decides where an installer drops its files. ## `System32` holds the kernel, and `SysWOW64` lies to you This is the part that genuinely surprised me, and it answers the "not so sure" in the notes. `C:\Windows` is the OS container, but the binaries and libraries that actually make it run sit in `C:\Windows\System32`. This is the real `/bin` + `/lib` + `/sbin` of Windows: system executables, the bulk of the `DLL`s, and even the kernel image `ntoskrnl.exe`. It is also the heart of the default `PATH`. So when the note said "Windows holds the OS files", it is more precise to say `C:\Windows` is the house and `System32` is where the load-bearing walls are. Now the trap. On a 64-bit Windows: * `System32` holds the **64-bit** binaries. * `SysWOW64` holds the **32-bit** binaries. Yes, that is backwards, and it is worth a double take. `WOW64` means "Windows 32-bit **on** Windows 64-bit", the compatibility layer that lets old 32-bit programs run. The "32" and "64" in those folder names describe history, not the bitness of what is inside. There is also a legacy `System` folder, a leftover from the 16-bit era, that we can mostly ignore on modern systems. > If I am reversing a binary and I see it loading DLLs out of `SysWOW64`, that is a 32-bit process on a 64-bit OS. The folder name is the opposite of the hint I would expect, so I read it carefully. ## `Users`, `Default`, and the `/etc/skel` moment `C:\Users` is `/home`. Two entries inside it map cleanly onto things I already know: * `Public`: a shared directory every user can reach, and it is shared to the network as well. Closest to a shared `/srv` or a world-readable share. * `Default`: the template a new user profile is copied from. This is exactly `/etc/skel` — the skeleton that seeds a fresh home directory. That `Default` = `/etc/skel` mapping is one of the cleanest in the whole series. ## `AppData`: where the dotfiles went On Linux my per-user state lives in dotfiles and `~/.config`, `~/.local`, `~/.cache`. Windows collects that per-user application data under `C:\Users\\AppData`, and splits it by how portable the data is: * `Roaming`: machine-independent data that can follow the user between machines (on a domain, it roams with the profile). Closest to the config I would happily sync through dotfiles. * `Local`: machine-specific data that does not roam — caches and state tied to this one box. Closest to `~/.cache`. This is also where an application keeps its private libraries (`DLL`s) when it does not install them system-wide. ## `WinSxS`: the answer to DLL hell One directory has no clean Unix twin: `C:\Windows\WinSxS`, the Windows component store ("side-by-side"). It keeps copies of Windows components, updates, and service packs — including multiple versions of the same component at once. I rarely keep several versions of a shared library installed on purpose; `WinSxS` exists precisely so different programs can bind to the exact component version they need. ## Exploring it the Linux way The muscle memory transfers more than expected: ```text theme={null} dir ≈ ls (dir /a shows hidden entries, closer to ls -la) tree ≈ tree ``` > So my first move on a new Windows box is the same reflex as always: stand at `C:\`, `dir` to see the top level, and `tree` a directory I care about. The layout is different, but the instinct of "build the map first" still works. With the map in hand, Phase 3 looks at the filesystems under these directories and who is actually allowed to touch each file.