Skip to main content
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 DLLs, 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\<name>\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 (DLLs) 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:
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.