GUI & windowing

Everything in this level so far — the loader, the DLL search, ntdll.dll — happens before a program shows anything on screen at all. This chapter starts the part most people would actually call "using Windows": windows, menus, drawing, input. It's also the part almost everyone touches every day and almost nobody has mapped correctly, because "Explorer," "the desktop," and "a window" are three genuinely different things that happen to look related.

Three nested containers, not one

The structure is a set of nested objects, each one narrower than the last:

1. A session is created when a user logs on (or when a service like Remote Desktop needs its own isolated environment). Windows has run non-interactive Session 0 for services since Vista, specifically so that a compromised or malfunctioning service can't draw UI on, or read input from, the interactive user's session — a security boundary as much as a UI one.
2. A window station is a securable container inside a session, holding one or more desktops plus shared resources: the clipboard and the atom table (a shared string-interning table used for window class names). The interactive session's window station is conventionally named Winsta0.
3. A desktop is a logical display and input surface inside a window station. Ordinary Explorer/app windows live on the Default desktop; the secure logon and UAC-consent UI live on a completely separate Winlogon desktop, precisely so that no ordinary application running on Default can see or interact with it.

Only one desktop within a window station is ever the input desktop at a time — the one actually receiving keyboard and mouse events and being rendered to the display.

Then, within a desktop: windows and drawing resources

Once you're inside a desktop, two parallel object families do the actual work:

• USER objects represent interactive elements and state: windows, menus, cursors, hooks, accelerator tables. Anything the user can click, focus, or receive input through is a USER object.
• GDI objects represent drawing resources: device contexts, brushes, pens, fonts, bitmaps. Anything that produces pixels is a GDI object.

A single visible window is, underneath, a USER object referencing a device context, which itself references several GDI objects for whatever it's currently drawing. Windows enforces per-process and per-session quotas on both families specifically so a single buggy or malicious process can't exhaust GUI resources for the entire session.

Why this explains a specific, common experience

The clearest illustration of why this layering exists is something almost every Windows user has seen: pressing Ctrl+Alt+Del, or getting a UAC consent prompt, and the screen visibly "switching" to a different, dimmed environment where only that one dialog responds.

That's not a rendering effect — it's an actual desktop switch. Windows changes which desktop is the input desktop, from Default to a secure one, runs the prompt there in isolation, and switches back once you respond. Window stations & desktops walks through this exact sequence and the security reasoning behind it in detail, with an animated walkthrough.

A common mistake

The most common misconception is treating "the desktop" as synonymous with "the shell" (Explorer) or with "the GUI system" as a whole. Explorer is just one ordinary Win32 application running on the Default desktop — it happens to be the one responsible for the taskbar and file browsing, but it has no special access to window-station or desktop internals beyond what any other app on the same desktop has. If Explorer crashes, the desktop, window station, and every other running app's windows are completely unaffected; Windows just restarts the shell process.

Where this connects

• Window stations & desktops goes deeper on the container objects introduced here, including the secure-desktop switch.
• USER & GDI objects goes deeper on what actually lives inside a desktop.
• CSRSS, Win32k, and session UI plumbing explains the user-mode-and-kernel-mode split underneath all of this — the parts of "the GUI" that aren't Win32k the graphics engine, but CSRSS the session infrastructure.