Why is WinPE called an operating system?

Solution 1:

It's not a separate OS, however, it is still an OS. WinPE is just a trimmed down version of Windows – it doesn't show a login screen, doesn't have a taskbar, just directly runs Setup.exe instead, but it nevertheless boots a full OS (the regular Windows kernel, drivers, etc).

So the point of calling it "an OS" isn't to brand it as something completely separate, but rather to indicate that it is not "just the setup wizard". WinPE is Windows, so it is not fundamentally limited to running just Setup – it is only configured to do so.

For example, there's the standard Cmd.exe hidden behind Shift+F10, it comes with many standard tools like Diskpart or Regedit, you can use it as a mostly functional OS. (In the days of Windows XP, you could even run Solitaire or Minesweeper to play while installing.) In fact Microsoft even publish tools for creating your own custom WinPE builds, with your favourite recovery tools included.

In the Linux world, things work exactly the same way. When you boot a Linux CD or USB stick, it just boots a specially prepared Linux distro from a read-only image, but it's still just a Linux distro – the same kernel runs the same init system and starts mostly the same services.

(In particular, if it's branded as a Live CD, it's usually nearly indistinguishable from a full installation, while Install variants tend to be more specialized and trimmed down.)

It is also the same with BSDs, Solaris, and even OpenVMS – when you boot the installer, everything happens in a minified version of the actual OS that you're installing. Nobody writes the whole installer from scratch on bare metal if they can use pre-existing tools (especially pre-existing drivers, as the installer needs to access your disks, your filesystems, etc).

Solution 2:

WinPE is Windows. It’s analogous to how Debian is a specific distribution of Linux. WinPE is one of a handful of ‘distributions’ of Windows, alongside the Xbox One system software (Windows 10 with a custom 10-foot UI, with the games actually running in Hyper-V VMs with a minimalist OS kernel), Windows IoT (a specialized variant designed for embedded systems), and a handful of others.

WinPE itself provides a (near) full Windows environment, it just boots to something other than the usual login screen and graphical shell. You can even configure it to do any number of other things. The company I used to work at had a customized WinPE CD for system recovery purposes that booted to a PowerShell session with all the tools we normally used to repair a system.

Linux, BSD, and most other modern operating systems handle things similarly for their installation processes, the installation environment is a largely complete system by itself. Depending on the exact OS and distribution, it may default to a ‘live’ environment where you have to run the installer manually (Alpine Linux, Arch Linux, and most source-based distributions do this), or it may just boot directly to the installer (Debian, OpenSUSE and NetBSD do this).

Obviously, since these are using the standard OS kernel of the system they’re installing, there is an operating system involved, you just don’t usually see it directly (of course, it could be argued that you don’t see the Linux kernel or NT kernel directly either in most cases during normal usage of a Linux or Windows system).

This approach is taken largely because writing the installer like a regular application has a number of benefits:

• Because it uses the same drivers that the installed system will, you significantly reduce the risk of problems with storage devices or filesystems. This, by itself, eliminates a whole class of potential problems without requiring almost any engineering work.
• It completely avoids the need to write custom graphics routines if you want a graphical installer (if you’ve never done any embedded or systems-level software development this probably does not sound like a significant benefit, but trust me, it’s huge).
• Regular applications are exponentially easier to debug than bare-metal stuff. It is possible with good VM tooling to debug a bare-metal application much more easily than used to be the case, but it’s still exponentially easier to just use your regular debugger.
• If things are designed correctly, it allows users to bootstrap additional installs from an existing install without needing installation media. You can actually do this on many Linux distributions pretty easily, though it’s rather tricky on Windows (it’s doable, but you can't readily leverage the default setup program, and there are a huge number of limitations involved).