# Windows for People Who Use It Every Day > What's actually underneath Windows - the NT kernel, drive letters and the real folder layout, services and the registry, and PowerShell - explained for someone who's used Windows for years but was never shown the manual. --- # Windows for People Who Use It Every Day You've used Windows for years. You install programs, you double-click icons, you've clicked "Yes" on a hundred of those darkening "Do you want to allow this app to make changes?" boxes without ever knowing what they were really asking. Nothing here is *hard* - you already know how to drive the car. This guide opens the hood and shows you the engine, so the next time something is weird, slow, or scary, you know where to look and why. We're not going to cover clicking around the desktop - you've got that. We're going to cover the parts nobody ever explained: what `C:\` really is and why your settings hide in a folder called `AppData`, what "Run as administrator" is actually doing, what all those background processes in Task Manager are, what the registry is (and why people whisper about it), and PowerShell - the modern shell that's genuinely worth learning. > ⏭️ **New to operating systems in general?** Read [What an Operating System Is](/guides/what-an-operating-system-is) first - it builds the kernel / user-space / process model that this whole guide leans on. We'll reference it but not re-teach it. ## How to read this - **Want a specific answer?** Jump straight to the phase: drive letters and folders are in [Phase 1](01-windows-under-the-hood.md), the registry is in [Phase 2](02-services-task-manager-registry.md), PowerShell is in [Phase 3](03-powershell-basics.md). - **Want it to finally make sense?** Read in order. Each phase assumes the mental model from the one before - by the end you'll be able to *reason* about Windows instead of memorizing where buttons are. ## The phases 1. **[Windows Under the Hood](01-windows-under-the-hood.md)** - the NT kernel, drive letters and the real folder layout (including `AppData`, the one everyone trips over), how "Run as administrator" maps to the OS permission model, and the plain list of ways Windows differs from Unix. 2. **[Services, Task Manager & the Registry](02-services-task-manager-registry.md)** - what services are and how they differ from apps, Task Manager in depth (Startup, Details, killing a process), and the registry explained for real - what it is, how it's organized, and ⚠️ how to touch it without breaking anything. 3. **[PowerShell Basics](03-powershell-basics.md)** - the big idea (commands pass *objects*, not text), the verb-noun cmdlet naming, piping objects, running a script, and the ⚠️ execution-policy gotcha that stops every beginner's first script. > Deliberately deferred to follow-up guides: deep NTFS internals and permissions/ACLs, the Windows Subsystem for Linux (WSL), Group Policy, and PowerShell scripting beyond the basics. This guide is about *understanding the machine you use daily* - not turning you into a Windows sysadmin in one sitting. --- # Windows Under the Hood Here's the reassuring truth: Windows is doing the exact same job every operating system does. A kernel in the middle, sharing the hardware among a crowd of programs, deciding who's allowed to do what. If that sentence is fuzzy, the [What an Operating System Is](/guides/what-an-operating-system-is) guide builds it from scratch - this phase assumes it and shows you what it looks like *wearing Windows clothes*. What trips people up isn't the model. It's the local dialect: drive letters, a folder layout that scatters your stuff across several places, a permission prompt that darkens the whole screen, and a few decisions Microsoft made decades ago that still shape everything. Let's translate. ## The NT kernel: the engine you never see **What it actually is.** At the center of Windows is a kernel called **NT** (the name is a holdover from "New Technology," Windows NT, 1993). Every version of Windows you've touched since Windows XP - including Windows 10 and 11 - runs on a descendant of that same NT kernel. It's the trusted core that talks to the CPU, the memory, and the disk, and enforces every rule about who can do what. 📝 **Terminology.** *NT kernel* = the core of Windows that manages the hardware and has full control of the machine. When people say "the Windows kernel," this is it. **Why this matters to you.** Everything you see - the desktop, File Explorer, the Settings app, your browser - runs *on top of* NT, in user space, asking it for anything that touches the disk or network. A crashed program rarely takes the whole machine down, because NT just cleans it up and moves on; a true hard lockup means the kernel itself is in trouble. 💡 **Key point.** "Windows" is two things wearing one name: the **NT kernel** (the real operating system) and the **desktop shell** (the Start menu, taskbar, File Explorer - the face you click on). When the taskbar freezes but music keeps playing, that's the face hanging while the kernel underneath is fine. ## Drive letters: `C:\` and friends **What it actually is.** A drive letter is Windows' name for a **volume** - a formatted area of storage the OS can read and write. `C:` is, by long convention, the drive Windows itself is installed on. Plug in a USB stick and it shows up as `D:` or `E:`; a second hard drive might be `D:`. The letters aren't magic - they're just labels the OS hands out. **Why people get this wrong.** People assume drive letters are physical - "C is my hard drive." Not quite. One physical disk can be split into several volumes (`C:` and `D:` on the same drive), and several disks can each get their own letter. The letter names a *volume*, not a piece of hardware. 📝 **Terminology.** *Volume* = a formatted, usable storage area with a filesystem on it. *Filesystem* = the scheme that organizes files and folders on a volume. Windows almost always uses **NTFS** (NT File System) for its main drive. **How this differs from Unix.** This is the first big fork from the macOS/Linux world. On Unix-like systems there are no drive letters at all - there's one single tree starting at `/` (the "root"), and extra disks get *mounted* into a folder inside that one tree. Windows keeps each volume as its own lettered tree: ```text WINDOWS UNIX (macOS / Linux) ───────────────────── ───────────────────── C:\ / ├── Windows\ ├── usr/ ├── Program Files\ ├── etc/ └── Users\ └── home/ D:\ ← a separate tree /mnt/usb ← the USB lives *inside* the one tree E:\ ← another separate tree ``` Neither is wrong - they're two answers to "how do we name more than one disk." Windows says "give each its own letter." Unix says "everything hangs off one root." ## The folder layout (and `AppData`, the one everyone trips over) Open `C:\` and you'll see a handful of folders that actually matter. Here's what each is *for*: ```text C:\ ├── Windows\ ← the OS itself: the kernel, drivers, system tools. Leave it alone. ├── Program Files\ ← installed apps (64-bit). One folder per app. ├── Program Files (x86)\ ← installed apps (older 32-bit). Yes, two folders. See below. ├── ProgramData\ ← app data shared by ALL users (licenses, shared databases). Hidden by default. └── Users\ └── you\ ← your home folder. Everything that's "yours" lives under here. ├── Desktop\, Documents\, Downloads\, Pictures\ … └── AppData\ ← your per-user app settings and data. Hidden by default. ← the famous one. ``` **Why there are two `Program Files` folders.** `Program Files` holds modern 64-bit apps; `Program Files (x86)` holds older 32-bit ones. Windows keeps them apart so a 32-bit and 64-bit version of the same thing don't collide. It's not a bug - it's Windows quietly running both worlds at once. The `x86` name refers to the old 32-bit Intel architecture. **Now, `AppData` - the folder that explains a hundred mysteries.** It's a *hidden* folder inside your home folder, and it's where applications stash your personal settings, caches, profiles, and save data. When you ask "where did my app save its config?" or "where are my game saves?" or "this program forgot all my settings after I reinstalled" - the answer is almost always somewhere in `AppData`. It has three sub-folders, and the difference is worth knowing: ```text C:\Users\you\AppData\ ├── Local\ ← machine-specific data. Big caches, this-PC-only settings. Does NOT roam. ├── LocalLow\ ← like Local, but for low-permission apps (e.g. stuff running in a browser sandbox). └── Roaming\ ← settings meant to follow you between PCs on a corporate network. Smaller, portable. ``` The split exists for a real reason: in a company, your `Roaming` profile can follow you when you log into a different computer, while `Local` (full of huge caches) stays put. On a home PC you'll mostly care about `Local` and `Roaming` being the two places apps hide things. **A real example.** You can jump straight there. In File Explorer's address bar, or anywhere a path is accepted, type `%AppData%`: ```console C:\Users\you> echo %AppData% C:\Users\you\AppData\Roaming ``` *What just happened:* `%AppData%` is an **environment variable** - a named shortcut Windows expands into a real path. It points at your `Roaming` folder. (There's a matching `%LocalAppData%` for the `Local` one.) This is why guides say "go to `%AppData%\SomeApp`" instead of spelling out `C:\Users\yourname\AppData\Roaming\SomeApp` - the variable works no matter what your username is. ⚠️ **Gotcha: AppData is hidden by default.** If you go looking in File Explorer and can't find `AppData`, it's not missing - it's a hidden folder. Turn on **View → Show → Hidden items**, or just paste `%AppData%` into the address bar and skip the hunt. This is the folder people mean when they swear an app "deleted all their settings" after an update - it didn't, they just never knew it existed. ## Processes and permissions: what "Run as administrator" really does You met user space and kernel space in the OS guide: untrusted programs run in user space and must ask the trusted kernel for anything powerful. Windows adds one more layer *within* user space, and it's the thing behind every "Do you want to allow this app to make changes?" box. **What it actually is.** Even when you're logged in as an administrator, your normal programs run with **limited** privileges - as if you were a standard user. This is on purpose. It means a random program (or some malware you clicked) can't quietly change system files just because *you* happen to be an admin. When a program genuinely needs elevated power - installing software into `Program Files`, editing `Windows\`, changing system settings - it has to *ask*, and you have to approve. That approval prompt is **UAC**. 📝 **Terminology.** *UAC* (User Account Control) = the Windows feature that keeps programs running with limited privileges and pops up a consent prompt when one needs to do something powerful. *Elevation* = the act of granting a program those higher privileges for the task. ```text Standard rights (default) Elevated rights ("as administrator") ───────────────────────── ──────────────────────────────────── • read most files • write into Program Files\ and Windows\ • write inside your own Users\ folder • install / uninstall software • run normal apps • change system-wide settings • CANNOT touch system folders • edit other users' data │ ▲ └────────── UAC prompt: "Allow changes?" ┘ you click Yes → the program is elevated for that task ``` **What it does in real life.** Right-click a program and choose **Run as administrator**, and Windows checks with you via the UAC prompt (the screen darkens to a "secure desktop" so a sneaky program can't fake your click). Approve it, and that program now runs on the powerful side of the line. **Why this saves you later.** Half of "it won't let me save here" and "the installer failed" problems are this. Saving into `C:\Program Files\...` and getting "Access denied"? That folder needs elevation, and your editor isn't elevated. A terminal command fails with a permissions error but works after you reopen the terminal as administrator? Same lesson - you're on the wrong side of the privilege boundary, not fighting a random glitch. ⚠️ **Gotcha: don't run everything as administrator "to be safe."** It's the opposite of safe. UAC's whole value is that your everyday programs *can't* wreck the system even if they misbehave. Run a thing elevated and you hand it the keys. Elevate only when a task genuinely needs it. ## How Windows really differs from Unix You'll hear "Windows is different from Mac/Linux." Here's the straight, concrete version of *how* - the differences that actually bite you, not vibes: | | Windows | Unix (macOS / Linux) | |---|---|---| | Path separator | backslash `\` - `C:\Users\you` | forward slash `/` - `/home/you` | | Where disks live | drive letters, each its own tree (`C:`, `D:`) | one tree from `/`; extra disks *mounted* in | | Runnable programs | a file ending in `.exe` (the extension marks it executable) | any file with the "executable" permission bit set | | File-type meaning | decided by the **extension** (`.txt`, `.exe`, `.jpg`) | extension is a hint; the permission bit decides "can run" | | Where settings live | the **registry** (a central database) + some files | plain-text config files (often in `/etc` and your home folder) | | Case sensitivity | `File.txt` and `file.txt` are the **same** file | usually **different** files | Two of these are worth a sentence more, because they're the ones that surprise people: - **`.exe` and extensions.** The file extension isn't just a label on Windows - it's how the OS decides what a file *is* and how to open it. Double-click `report.txt` and you get Notepad; rename it `report.exe` and Windows will try to *run* it. That's why hiding extensions is a security risk (`invoice.pdf.exe` looks like a PDF when extensions are hidden) and why Windows asks "are you sure?" when you change one. - **The registry instead of config files.** Deepest cultural difference of the bunch, and it gets its own section in [Phase 2](02-services-task-manager-registry.md). Short version: where a Unix program drops a text file to remember its settings, Windows often writes them into one giant, central database called the **registry** - powerful and fast, and why "just edit the config file" isn't always how you fix things here. 💡 **Key point.** None of these differences make Windows "weird" - they're just different design choices for the same problems. Drive letters vs. one root. Extension vs. permission bit. Central database vs. scattered text files. Once you can name the choice, the difference stops being friction and starts being something you can reason about. ## Recap 1. Windows runs on the **NT kernel** - the trusted core. The desktop, File Explorer, and your apps all run *on top of it* in user space. 2. **Drive letters** (`C:`, `D:`) each name a *volume*, not a physical disk; Unix instead hangs everything off one root `/`. 3. Apps live in **`Program Files`** (and `Program Files (x86)` for old 32-bit ones); *your* settings and data hide in **`AppData`** - a hidden folder with `Local`, `LocalLow`, and `Roaming` inside. 4. **UAC / "Run as administrator"** is your programs asking to cross from limited to elevated privileges - the source of most "access denied" mysteries. 5. Windows differs from Unix in real, nameable ways: **`\` vs `/`**, **drive letters vs one root**, **`.exe`/extensions vs the permission bit**, and **the registry vs config files**. Next, we'll watch the parts that run without you ever opening them - services - and meet the registry up close. --- # Services, Task Manager & the Registry Open Task Manager right now (`Ctrl + Shift + Esc`) and look at how many processes are running. You launched maybe five programs. So what are the other three hundred? This phase answers that - the invisible background programs called **services**, the tool that lets you watch and control all of it (**Task Manager**), and the central database where Windows and your apps keep their settings (**the registry**). This is the layer where "my PC is slow," "something starts on boot that I didn't ask for," and "a forum told me to edit the registry" all live. By the end you'll be able to look each of those in the eye. ## Services: the programs with no window **What it actually is.** A **service** is a program that runs in the background, usually with no window and no taskbar icon, often starting before you even log in. Your print spooler, Windows Update, the thing that keeps time synced, your antivirus, the database behind a local app - these are services. They're regular programs in the sense that the kernel runs them as processes; they're *different* from regular apps in how they live. 📝 **Terminology.** *Service* = a long-running background program managed by Windows' Service Control Manager, designed to run without a user interface and (often) without anyone logged in. **How services differ from regular apps.** The contrast is the clearest way to understand them: | | A regular app (Word, Chrome) | A service (Print Spooler, Windows Update) | |---|---|---| | Has a window? | yes - you interact with it | no - it works silently in the background | | Started by | you, when you double-click | Windows, often automatically at boot | | Needs you logged in? | yes | often no - runs before/without login | | Lives as long as | you keep it open | the machine is on (or until stopped) | | Managed by | you (open/close) | the Service Control Manager + Services app | **What it does in real life.** Services are *why your computer can do things while you're not looking* - receive a print job, install an update overnight, listen for incoming network connections. They're managed in their own console: press `Win + R`, type `services.msc`, and you'll see the full list with each service's status (Running / Stopped) and **Startup type** (Automatic, Manual, Disabled). **Why this saves you later.** When something runs on your machine with no window for it - a stuck print queue, a sync tool eating CPU, a leftover process from an app you uninstalled - "it's probably a service" is the right first guess, and `services.msc` is where you confirm and stop it. Be conservative: many services are load-bearing. Stop the print spooler, fine; disable things you don't recognize and you may break Windows. ## Task Manager, properly You've opened Task Manager to force-quit a frozen app. That's the tip of it. Three tabs turn it from a panic button into an instrument. ### The Processes tab - the overview The default tab groups everything into **Apps** (things with windows), **Background processes**, and **Windows processes**, with live CPU, Memory, Disk, and Network columns. This is your "what's hogging the machine right now" view. Click a column header to sort by it - sort by CPU to find the runaway, by Memory to find the hog. ```text Name CPU Memory Disk ───────────────────────────────────────────────────── ▸ Google Chrome (12) 14.2% 2,140 MB 0.1 MB/s ← an app, with 12 sub-processes ▸ Microsoft Word 0.3% 310 MB 0 MB/s Background processes Antimalware Service Exec… 8.1% 520 MB 3.4 MB/s ← a service, working in the background Print Spooler 0.0% 6 MB 0 MB/s ``` *What just happened:* Each row is a process the OS is running. The little triangle (▸) means a process has children grouped under it - Chrome runs one process per tab or so, which is why it sprawls. The "Background processes" group is largely your services from the section above, now visible as live, resource-using rows. ### The Startup apps tab - why your boot is slow **What it actually is.** A list of every program that launches itself automatically when you log in, each with an **Startup impact** rating (Low / Medium / High). This is the single most useful tab most people never open. **Why this saves you later.** Half of "my computer takes forever to start" is a pile of apps - updaters, chat clients, "helper" tools from things you installed once - that quietly added themselves here. You can right-click any of them and choose **Disable**, and it won't auto-launch next boot. (Disabling startup doesn't uninstall the program; you can still open it yourself when you want it.) ⚠️ **Gotcha:** "Disable" here only stops the program from *auto-starting*. It doesn't remove or break it. So you can safely disable things to speed up boot and turn them back on if you miss them - low risk, easily reversed. ### The Details tab - the precise view **What it actually is.** The unglamorous, powerful tab: a flat list of every process with its exact **PID** (process ID - the OS's unique number for it), the user account it's running as, CPU, and memory. No friendly grouping - just the truth. 📝 **Terminology.** *PID* = a unique number the OS assigns to each running process. Two copies of the same program get different PIDs. It's how you point at *one specific* process unambiguously. **Killing a process.** When an app is truly frozen - no window response, the "Apps" entry won't close - this is where you end it for real: ```text Details tab → right-click the process → End task (or: select it and press the End task button) ``` *What just happened:* You told the OS to terminate that process immediately. The kernel reclaims its memory and CPU and removes it from the list. Because it's the OS killing the process from outside, it works even when the program itself is too hung to respond to a normal "close." ⚠️ **Gotcha: ending a process is a hard kill, not a polite close.** The program gets no chance to save. Any unsaved work in it is gone. Use End task when an app is genuinely stuck - not as a normal way to quit, where the app's own "Save?" prompt protects you. 🪖 **War story.** Classic confusion: someone "closes" a heavy app from the Apps list, but it keeps eating CPU. The window closed; a background process of the same app didn't - the Details tab showed two entries with the same name and different PIDs, and ending the leftover one fixed it. ## The registry: Windows' central settings database This is the one people are scared of, and the fear comes entirely from not knowing what it is. Let's fix that. **What it actually is.** The **registry** is a single, central database where Windows and most Windows programs store their settings. Your desktop wallpaper, file-type associations (what opens a `.pdf`), installed-program info, per-user preferences, and a vast amount of system configuration all live here - in one organized store, instead of in thousands of scattered config files. 📝 **Terminology.** *Registry* = the hierarchical database Windows uses to hold configuration for the OS and applications. Think "a giant, system-wide settings file, but structured like a tree." **Why it exists (the design decision).** Early Windows used scattered `.ini` text files, like Unix's config-file approach in [Phase 1](01-windows-under-the-hood.md) - and it got messy: settings everywhere, no consistent format, slow to search. The registry was the fix: one fast, structured, queryable place for all of it. The trade-off is the obvious one - centralized and quick, but not human-friendly text you can open in Notepad, and no "just delete the bad config file" escape hatch when something goes wrong. **How it's organized.** Three nested concepts - and they map almost exactly onto folders, files, and the contents of files: ```mermaid flowchart TD Hive["HIVE (top-level root, like a drive)"] --> Key["KEY (a folder)"] Key --> SubKey["KEY (a sub-folder)"] SubKey --> Value1["VALUE: name → data (a setting = its value)"] SubKey --> Value2["VALUE: name → data"] ``` - **Hives** - the handful of top-level roots. The two you'll actually meet: - `HKEY_CURRENT_USER` (abbreviated **HKCU**) - settings for *you*, the logged-in user. - `HKEY_LOCAL_MACHINE` (abbreviated **HKLM**) - settings for the *whole machine*, all users. - **Keys** - folders inside a hive. They nest as deep as needed, e.g. `HKCU\Software\Microsoft\Windows\...`. - **Values** - the actual settings, living inside a key. Each value has a **name**, a **type** (a number, some text, a yes/no flag), and its **data**. 📝 **Terminology.** *Hive* = a top-level section of the registry (its own root). *Key* = a container, like a folder. *Value* = a single setting (name + type + data) stored inside a key. **A real example - seeing it without the GUI.** You don't have to open the scary editor to look. From a terminal, `reg query` reads a key: ```console C:\> reg query "HKCU\Control Panel\Desktop" /v Wallpaper HKEY_CURRENT_USER\Control Panel\Desktop Wallpaper REG_SZ C:\Users\you\AppData\Roaming\...\wallpaper.jpg ``` *What just happened:* You read one **value** named `Wallpaper`, of type `REG_SZ` (a text string), out of the key `Control Panel\Desktop` in your personal `HKCU` hive. Its data is the path to your current wallpaper image. That single line *is* "your desktop background setting" - and now you can see it's just a named entry in a database, not magic. **The editor.** The graphical tool is **Registry Editor** - press `Win + R`, type `regedit`. It shows the hives down the left like a folder tree, and the values of the selected key on the right. It looks exactly like the diagram above, made real. ⚠️ **Gotcha - the big one. Edit the registry carefully, and back up first.** There is no Recycle Bin for the registry and no "undo" after you close the editor. Some keys are load-bearing for Windows itself; a wrong edit or deletion can stop programs working or, rarely, stop Windows booting cleanly. The safety rules, every time: 1. **Only change what a trusted source told you to change**, exactly as written. Don't go exploring and "tidying up." 2. **Export a backup first.** In `regedit`, right-click the key you're about to touch → **Export** → save the `.reg` file. If it goes wrong, double-click that file to restore. 3. **Know that most things have a normal Settings UI.** If the Settings app or a program's own options can change it, do it *there* - the registry should be the last resort, not the first. 💡 **Key point.** The registry isn't dangerous because it's mysterious - it's an ordinary settings database (hives → keys → values). It earns respect for one concrete reason: **no undo and no Recycle Bin.** Back up the key, change only what you were told to, and it's a fine tool. ## Recap 1. **Services** are background programs with no window, started by Windows (often before login) - managed in `services.msc`. They're why your PC does things while you're not looking. 2. **Task Manager** is more than a force-quit button: **Processes** shows what's hogging resources, **Startup apps** shows what auto-launches (disable to speed up boot - fully reversible), **Details** gives every process its exact **PID** and lets you hard-kill a truly frozen one. 3. The **registry** is a central settings database, organized as **hives → keys → values** (a database that looks like folders/files). `HKCU` is your settings; `HKLM` is the machine's. 4. ⚠️ The registry has **no undo and no Recycle Bin** - so back up the key first (right-click → Export), change only what a trusted source specified, and prefer the normal Settings UI when it can do the job. Next, the genuinely fun part: PowerShell - a modern shell built on one surprising idea. --- # PowerShell Basics If you've used a terminal before - or read [The Terminal & Shell](/guides/the-terminal-and-shell) - you know a shell is a program that takes typed commands and runs them. PowerShell is Windows' modern shell, and it's genuinely worth learning. But here's the thing nobody tells you up front, and it changes everything about how you read it: **Most shells pass plain text between commands. PowerShell passes *objects*.** That one sentence is the whole personality of PowerShell. Grasp it first, and every weird-looking thing afterward - the `Verb-Noun` names, the way you can sort and filter so easily - stops being weird and starts being obvious. So let's build that idea before we type anything serious. > 📝 **Terminology.** *Shell* = the program that reads your typed commands and runs them (PowerShell, plus the older Command Prompt `cmd.exe`, are Windows' shells). *Cmdlet* (pronounced "command-let") = a built-in PowerShell command, like `Get-Process`. ## The big idea: objects, not text **What it actually is.** In a traditional shell, when one command's output feeds into the next, what flows between them is **text** - lines of characters. The second command has to *re-parse* that text (hunt for the right column, split on spaces) to get at the data. It works, but it's fiddly and fragile. PowerShell flows **objects** instead - structured things with named properties. When a cmdlet hands you a process, it's not a line of text that *says* "chrome 14% 2140MB"; it's an actual process object with a `.Name` property, a `.CPU` property, an `.Id` property. The next cmdlet can ask for `.CPU` directly. No parsing, no guessing which column is which. ```text TRADITIONAL SHELL (text) POWERSHELL (objects) ────────────────────────── ────────────────────────── command → "chrome 14% 2140MB" command → { Name="chrome", │ (a line of text) Id=8124, ▼ CPU=14.2, next command must SPLIT the text WorkingSet=2140MB } to find the number it wants │ (a real object) ▼ next command just asks for .CPU ``` **Why this is the whole game.** Because the data stays structured, you sort, filter, and select by *property name* with simple, readable commands instead of text-wrangling incantations. That's why PowerShell feels verbose at first, then suddenly feels powerful: you're manipulating data, not scraping text. 💡 **Key point.** Whenever you see a PowerShell command, ask "what *object* does this produce, and what properties does it have?" That question is the key to the entire shell. The display you see on screen is just a *printed view* of objects that are richer than what's shown. ## Cmdlets are named `Verb-Noun` **What it actually is.** Every built-in PowerShell command follows one naming pattern: a **verb**, a hyphen, and a **noun**. `Get-Process`. `Get-ChildItem`. `Stop-Process`. `Set-Location`. The verb says what you're doing; the noun says what you're doing it to. **Why this is a gift.** Once you know the pattern, you can *guess* commands instead of memorizing them. Want to see services? `Get-Service`. Stop one? `Stop-Service`. Start one? `Start-Service`. The verbs come from a small, standard list (`Get`, `Set`, `Start`, `Stop`, `New`, `Remove`, …), so the language is far more predictable than the cryptic short names of older shells. **A real example.** `Get-Process` produces process objects - and PowerShell prints them as a tidy table: ```powershell PS C:\> Get-Process NPM(K) PM(M) WS(M) CPU(s) Id SI ProcessName ------ ----- ----- ------ -- -- ----------- 28 18.45 52.10 4.31 8124 1 chrome 31 24.02 88.77 12.96 8456 1 chrome 12 2.10 6.44 0.20 1190 0 spoolsv 45 61.30 142.88 31.07 9032 1 Code ``` *What just happened:* `Get-Process` asked the OS for every running process and handed back one **object per process**. PowerShell printed a default table view of them - but each row is a full object with properties like `Id`, `ProcessName`, `CPU`, and `WS` (working set, i.e. memory in use). You're seeing the same processes Task Manager shows, as data you can now work with. (`SI` is the session; `0` is a service session, `1` is your login.) 📝 **Terminology.** *`Get-ChildItem`* is PowerShell's "list what's in this folder" cmdlet - the equivalent of the old `dir`. The noun "ChildItem" is general on purpose: it lists the *children* of wherever you are, whether that's files in a folder or - neatly - keys in the registry. ```powershell PS C:\Users\you> Get-ChildItem Directory: C:\Users\you Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 6/18/2026 9:14 AM Desktop d----- 6/19/2026 8:02 AM Documents d----- 6/17/2026 4:48 PM Downloads -a---- 6/15/2026 11:30 AM 14237 notes.txt ``` *What just happened:* `Get-ChildItem` listed the children of your home folder. The `d-----` rows are directories; `-a----` is a normal file (the `d` flag means directory, `a` means archive). Again - these aren't text lines, they're file/folder objects, each carrying `Name`, `Length`, `LastWriteTime`, and more. ## Piping objects from one cmdlet to the next This is where "objects, not text" pays off. The **pipe** `|` takes the objects coming out of one cmdlet and feeds them into the next. Because they're objects, the next cmdlet can act on their properties directly. **A real example - find your top memory hogs:** ```powershell PS C:\> Get-Process | Sort-Object WS -Descending | Select-Object -First 3 Name, Id, WS Name Id WS ---- -- -- chrome 8456 93057024 Code 9032 68891648 chrome 8124 54618112 ``` *What just happened:* Read it left to right as a sentence. `Get-Process` produced process objects; `Sort-Object WS -Descending` reordered them by the **`WS`** (memory) property, biggest first; `Select-Object -First 3 Name, Id, WS` kept the top three and showed only those three properties. At no point did anything parse text - each cmdlet reached straight into the objects' properties by name. *That's* the power the object pipeline buys you: a readable English-ish line does what would be a gnarly text-scraping script elsewhere. **Stopping a process from the pipeline.** Because objects carry their identity, you can pipe them straight into an action cmdlet: ```powershell PS C:\> Get-Process notepad | Stop-Process ``` *What just happened:* `Get-Process notepad` found the Notepad process **object(s)**, and the pipe handed them to `Stop-Process`, which terminated each one. You didn't have to look up and retype a PID - the object you found *is* the thing you stopped. (This is the same hard kill as Task Manager's "End task," so the same caution applies: unsaved work in that program is lost.) ⚠️ **Gotcha:** `Stop-Process` is a hard kill - no "save your work?" prompt. Be sure you've matched the right process before you pipe it into a stop. `Get-Process notepad` first, *look* at what came back, *then* stop it. ## Running a script - and the execution-policy gotcha A PowerShell script is a text file ending in `.ps1` - a saved list of the same commands you'd type. You run it by giving its path: ```powershell PS C:\Users\you> .\hello.ps1 ``` And here, on a fresh Windows machine, almost everyone hits the same wall the very first time: ```powershell PS C:\Users\you> .\hello.ps1 .\hello.ps1 : File C:\Users\you\hello.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170. + CategoryInfo : SecurityError: (:) [], PSSecurityException + FullyQualifiedErrorId : UnauthorizedAccess ``` *What just happened:* This is **not** a bug, and your script is fine. Windows ships with an **execution policy** that blocks running script files by default - a deliberate safety setting so a downloaded `.ps1` can't silently run itself. PowerShell is refusing to execute the file, and politely telling you why. 📝 **Terminology.** *Execution policy* = a PowerShell safety setting that controls whether (and which) script files are allowed to run. It is a *speed bump, not a security boundary* - Microsoft is explicit that it's meant to prevent accidental script runs, not to stop a determined attacker. **The fix - for your own account, deliberately:** ```powershell PS C:\> Set-ExecutionPolicy -Scope CurrentUser RemoteSigned ``` *What just happened:* You changed the policy for **your user account only** (`-Scope CurrentUser`, so you don't need admin rights and you don't change it for everyone). `RemoteSigned` means: scripts *you* wrote locally can run, but scripts *downloaded from the internet* must be digitally signed by a trusted publisher first. That's the sensible middle ground - your own scripts work, random downloads don't get a free pass. ⚠️ **Gotcha - don't reach for `Unrestricted` or `Bypass` to "make the error go away."** Those turn the safety off entirely and let *any* script, including ones you downloaded without thinking, run unchallenged. `RemoteSigned` for `CurrentUser` is the standard, safe choice. If a tutorial tells you to set `Bypass` machine-wide, that's a flag to slow down and understand what you're being asked to disable. 🪖 **War story.** Every Windows developer has watched a colleague paste a script, hit that red "running scripts is disabled" wall, and conclude "PowerShell is broken." It isn't - it's a safety setting doing its job, and now a 30-minute confused detour is a 10-second `Set-ExecutionPolicy`. ## Where to go from here You now have the load-bearing idea: PowerShell moves **objects**, named **`Verb-Noun`**, **piped** from one to the next. Three habits will carry you a long way: - When stuck on what a command is called, guess the `Verb-Noun` - or run `Get-Command *process*` to search. - When you want to know what an object can do, pipe it into `Get-Member` (`Get-Process | Get-Member`) to list its properties and methods. - When you want to read a cmdlet's manual, `Get-Help Get-Process` (the help system is itself just more cmdlets). Deeper scripting - variables, loops, functions, error handling, writing real automation - is its own guide. But the daily wins (find a hog, stop a stuck process, list a folder, run a trusted script) are all yours now. ## Recap 1. PowerShell's defining idea: commands pass **objects** (structured data with named properties), not plain text - so you work with data instead of scraping it. 2. Built-in commands are **cmdlets**, named **`Verb-Noun`** (`Get-Process`, `Get-ChildItem`, `Stop-Process`) - predictable enough to guess. 3. The **pipe `|`** passes objects from one cmdlet to the next, which is why `Get-Process | Sort-Object WS | Select-Object -First 3` reads like a sentence and needs no text parsing. 4. Scripts are `.ps1` files; the first run usually hits the **execution policy** block. ⚠️ Fix it deliberately with `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` - not by turning the safety off entirely. > ⏭️ **Where next.** For the shell concepts underneath all this (what a prompt, a path, and a pipe really are), see [The Terminal & Shell](/guides/the-terminal-and-shell). To compare how the *other* big OSes do the same jobs, see [macOS Under the Hood](/guides/macos-under-the-hood) and the foundation in [What an Operating System Is](/guides/what-an-operating-system-is).