DEV Community

Cover image for Day 4: What's Actually Running Under Windows
Aditya Raj
Aditya Raj

Posted on Originally published at omegaabot.hashnode.dev

Day 4: What's Actually Running Under Windows

25-07-2026

What I Did

Completed two rooms in Module 3 (Operating Systems Basics): Operating Systems: Introduction, then Windows Basics, which applies those same concepts to a real Windows Server 2019 environment.

What I Learned

The biggest shift from Operating Systems: Introduction was realizing the OS isn't just the desktop I see when I turn a computer on — it's the manager sitting between every application and the actual hardware, deciding who gets CPU time, RAM, and file access. The airport analogy made this click: applications are airlines competing for runway time, and the OS is air traffic control making sure they don't all grab the same resources at once.

The other big piece was kernel space versus user space. Regular applications run in a restricted user space and can't just reach out and touch hardware directly — they make a system call and let the kernel handle it. That's not just an organizational detail, it's a security boundary. Permissions, process isolation, and user accounts are already security mechanisms before any extra security tool ever gets installed.

Windows Basics took all of that and made it concrete. The Desktop, Start Menu, and File Explorer stopped feeling like separate, unrelated tools and started looking like different interfaces to that same underlying OS. Opening a folder through File Explorer and knowing its actual path (C:\Users\Administrator\Desktop...) made the connection between what I click and where the data actually lives feel real for the first time. Account type mattered too — being logged in as Administrator explained exactly why I could install software and change system configuration without hitting permission walls.

The clearest cybersecurity moment was the Windows Security custom scan. Scanning a folder, watching it detect a test file (EICAR), and quarantining it turned "endpoint protection" from an abstract term into an actual workflow: scan, detect, classify, investigate, quarantine.

Problems and How I Solved Them

In Operating Systems: Introduction, kernel space vs user space needed a second look — it's easy to misread as "kernel = the OS, user space = the human user," which isn't quite right. Reframing user space as the restricted execution environment for applications, not a literal "user's space," fixed that.

In Windows Basics, two things needed sorting out. Windows Settings vs Control Panel look like they do the same job, since Windows has been gradually moving functionality from the older Control Panel into the newer Settings app — so the overlap is real, not a misunderstanding on my part. Windows Security vs Windows Defender Firewall also needed separating: Windows Security is the broader dashboard, and the firewall is just one specific control inside it, not a competing product.

Visuals

The OS sitting between applications and hardware:

Flowchart showing User, Applications, Operating System, and Hardware stacked in order, each depending on the one below it

The Windows Security scan workflow from the lab:

Flowchart of a custom antivirus scan: target folder scanned, threat detected, classified as severe, then quarantined

What's Next

Linux CLI Basics and Windows CLI Basics to round out Module 3, moving from GUI-based navigation into the command line directly.

Top comments (0)