The windows console host (conhost) provides the “UI” for nano server. Even on desktop Windows, it’s built with support for running without a window manager. The rendering engine is named “wddmcon” and it lives in our repository at [1]; it’s pretty much the most barebones console renderer we have. Reverse video and most color support were obviously[2] never implemented… even though I would have liked to spend engineering effort on it. The decision predates me, but I suspect it’s because they weren’t necessary for local validation.
Wddmcon eventually evolved into the rendering engine used in Windows Terminal[3]; it’s still not very good[4], but it works in conhost as well. Eventually, we can bring those changes or whatever future rendering engine we write back to wddmcon.
It has a sister renderer, “bgfxcon”. Bgfxcon renders text to the blue screen/boot graphics driver in the event that WDDM is unavailable.
If you manage to open multiple (full-screen) console sessions, you can flip between them using Alt-Tab. This service is provided by the “console I/O server”, a CSRSS component available only on Nano Server that mimics some of the user32 things conhost needs, such as keyboard input. It also handles brokering us a WDDM or BGFX handle on startup. Unfortunately, that one’s closed-source… not because it should be, but because disentangling the build process for a component that lives in CSRSS wasn’t on our critical path.
Note: this article appears to be talking about Nano Server as an a traditional OS. Microsoft has abandoned[1] that approach and is instead only offering Nano Server as a container image[2]. Compared to more conventional Windows images whose size are measured in gigabytes, the Nano Server docker images take ~120MB to pull and ~300MB of disk space.
Server Core or Hyper-V Server still contains quite some GUI dependencies. Things like task manager, Notepad (different between versions), and a basic file picker for applications. A floating console window appears and even wallpapers applied via SysInternals are supported.
A good thing too, because the driver installation tools from Dell for instance depend on these.
I think it was relatvely recently still possible to get HyperV minimal hypervisor (it was also one of the use cases for NanoServer, essentially minimal HyperV + tiny layer of userspace)
I had hoped that Nano Server would make it's way onto the Raspberry Pi (natively), but that never happened. Instead Microsoft offered up Windows IoT, which is a horribly slow beast with a convoluted management workflow, and practically useless for any real-world application (and also restricted by licencing to keep it out of reach from hobbyists).
> But that's "Best Practice" will all Windows systems ;)
Reminds me of back in 1999 or so, when me and a colleague was installing some additional workstations for a small company, about 20-30 employees. While there, the local IT guy asked us to take a look at the domain controller as it had been a bit sluggish and acting up lately. As customary for small shops, the domain controller also handled e-mail and was a print server.
The domain controller ran NT4, and as one usually does we started by firing up Task Manager to see what was running. There we noticed the CPU graph, which showed the uptime: 849 days...
We were so amazed the thing ran at all we almost didn't want to reboot it.
By default, Microsoft now pitch Windows Server as 'GUI-less', with an option to install it with the added 'desktop experience' if you need a GUI. The GUI-less version used to be 'Server Core' but that name has been dropped now it's the default option.
It's not really text mode though; you get a floating PowerShell window on a plain wallpaper after login. From there it's all PowerShell commands to configure and manage the server (or you do it remotely via the Server Manager GUI). Some limited built in tools work locally with their GUIs, but not many due to missing .NET framework components and Shell (aka desktop) hooks.
Ish. Problem is it is neither as text only as Nano Server nor as well supporter as Windows Server: Without Desktop Experience, there's only a handful of server roles a Windows Server can do. Only some Microsoft server roles work without desktop, and almost no third party ones do.
If Microsoft released a "Windows 11 No Bullshit Edition" with like 1/100th the telemetry, no un-uninstallable bundled software, no ads, no spyware, and no dark patterns to herd you into cloud login, I'd pay extra for it and it might cause me to take another look at X64 laptops with Ryzen chips in them instead of my M1 Mac.
As it stands Linux desktops have too many issues and Windows is loaded with crap, so I am stuck on Mac as the best option.
The windows console host (conhost) provides the “UI” for nano server. Even on desktop Windows, it’s built with support for running without a window manager. The rendering engine is named “wddmcon” and it lives in our repository at [1]; it’s pretty much the most barebones console renderer we have. Reverse video and most color support were obviously[2] never implemented… even though I would have liked to spend engineering effort on it. The decision predates me, but I suspect it’s because they weren’t necessary for local validation.
Wddmcon eventually evolved into the rendering engine used in Windows Terminal[3]; it’s still not very good[4], but it works in conhost as well. Eventually, we can bring those changes or whatever future rendering engine we write back to wddmcon.
It has a sister renderer, “bgfxcon”. Bgfxcon renders text to the blue screen/boot graphics driver in the event that WDDM is unavailable.
If you manage to open multiple (full-screen) console sessions, you can flip between them using Alt-Tab. This service is provided by the “console I/O server”, a CSRSS component available only on Nano Server that mimics some of the user32 things conhost needs, such as keyboard input. It also handles brokering us a WDDM or BGFX handle on startup. Unfortunately, that one’s closed-source… not because it should be, but because disentangling the build process for a component that lives in CSRSS wasn’t on our critical path.
[1]: https://github.com/microsoft/terminal/tree/main/src/renderer...
[2]: which the article has already called out!
[3]: https://github.com/microsoft/terminal/tree/main/src/renderer...
[4]: https://github.com/microsoft/terminal/issues/10362