software may collect information about you and your use of the software, and send that to Microsoft.
...and judging from the other comment here, it appears to be nothing more than a kernel and a command prompt, yet the download is nearly 340MB. Did they strip out everything else, but still leave the spyware in?
I would expect it to have some extra functionality not usually baked into the kernel to be extra careful (and note) when a device works, but not quite obeys the protocols it should. Microsoft used to have "checked builds" (IIRC) that validated API call parameters. It was slower, but it would slap your hand instead of crashing when you asked it to do something stupid.
Also, if it's a hardware validation tool, I'd expect it to be able to collect and send all sorts of telemetry back to Microsoft. They are also interested in whether the device you are validating works correctly.
> it appears to be nothing more than a kernel and a command prompt, yet the download is nearly 340MB
That's honestly not that bad for a base system. FWIW, Arch's minimal install is ~600mb, and that's with a kernel + coreutils + drivers + userland utilities. This must be a really minimal tool.
Windows hasn’t had a text mode since Windows 2000. And even before that, the Windows NT text mode only served the purpose of bringing up a system before the graphics drivers were available, and was accordingly bare-bones and mostly unsupported. The GUI is an intrinsic part of the OS, baked into the kernel and core system libraries, not something bolted onto it like on most other operating systems you’re used to. I know it’s hard for *nix people to fully understand, because you think of the command line as the “real” interface to Linux, but on Windows, the real interface is the GUI.
Pre-OSX MacOS was also GUI only, and didn’t even come with any command line interface at all.
Windows NT (at least up to 7, but probably all versions) does have a text console that serves basically the same purpose as in Unix systems. It's where stuff printed with NtDisplayString goes. See Autochk (boot-time disk check) and other native NT applications which used it (e.g. boot-time defragmenters).
Also up to XP the setup disk contained a "recovery console" that also used the native NT console, and ran something very close to cmd (if not cmd itself?). It's really just probably due to some fancy compatibility reason that they decided to enable the GUI even when you'd only need the NT console.
More recent versions of Windows also contain the recovery console. I've certainly used it a few times in Win10 & Win8 (had to "fix" my partition tables on a clean Win10 install from Win8). It's not a full-screen terminal like you'd expect if you were "booting to a CLI". It's a windowed terminal sans explorer.exe. It's decently buried in the recovery options, but it's there.
About the same as the command prompt on the setup media.
Where you can run NOTEPAD.EXE and it pops up with the mouse support and you can edit and copy files as text, plus have a bit of GUI browsing in the file system while you are at it.
Actually, on most other operating systems since the adoption of Xerox's ideas, the GUI is part of the OS, unless we are talking about UNIX as you well put it, and the few surviving mainframes/micro-computers.
Makes some amount of sense to do it this way, since that probably means you get things like adjusting the font size or launching accessibility tools bundled in with the graphical frontend + conhost instance. Otherwise that stuff would have to be reimplemented for a 'true console only' mode
If you don't want to implement a console (that is fair) you can just use the console provided by the BIOS (the VGA console, as DOS did back in the days) or nowadays UEFI (as for example GRUB or even Linux if you don't load a graphics driver does). BIOS/UEFI have the primitives necessary to read/write to the console so you can just use them.
A text-only console is useful in a lot of situations, for example when the graphics driver doesn't work or crashes (in that situations in Windows you have to reboot or start in recovery mode, while on Linux you can open a text console and with the CLI fix the issue or restart the graphics server). It would also be useful to boot computers without a GPU, by exposing the text console trough a serial port, another thing that you can do in Linux, most embedded devices, such as routers, doesn't have any GPU but a serial port used for the console access (of course only for recovery and debugging, since otherwise you connect trough SSH).
By the way the question is not only for hardware that doesn't have the GPU, but also for containers/VM. If you drop the requirement of a GPU it would be far easier and lightweight to virtualize Windows, since you don't have to virtualize any graphics hardware at all but only the CPU. The text console would be provided by the virtualization program itself.
There's a handful of literal GUIs that load too, for instance, setting the date and time or using task manager. There's some literal GUI screens present... just not many.
Might be interesting to investigate what telemetry would or could be sent, but I’m assuming it’s just their usual feedback smileys that find their way into Microsoft’s beta UIs, and are presumably sent to an unmonitored ticketing system.
poorly monitored -- the vote up/down is typically used in internal performance metrics and when it dips too low, then someone analyses the feedback to see where they can improve the scores.
Some teams stay way more on top of the metric than others.
software may collect information about you and your use of the software, and send that to Microsoft.
...and judging from the other comment here, it appears to be nothing more than a kernel and a command prompt, yet the download is nearly 340MB. Did they strip out everything else, but still leave the spyware in?