Adding Packages to an already installed Nano Server instance, is a really an interesting question.

I can think about adding :
– WSA packages : https://github.com/yarnpkg/yarn/issues/3999
– Windows Nano Server packages shipped by Microsoft on Windows Server 2016 ISO.

https://mehic.se/2017/02/02/how-to-implement-packages-roles-and-features-on-nano-server/
https://www.javydekoning.com/fixing-signature-nanoserverpackage-cat-not-match-hash/

Create you own edition according to fit your specific needs and nothing more than a really basic sustainable principle in 2023!

Thanks for commenting on! I actually did try busybox-w32 but wasn’t too impressed. Commands worked but vi and line editing didn’t. I wasn’t aware of the environment variable. I will try that if it works I will update the article of course or maybe slap a new one. Again thanks for pointing this out!

The current release of busybox-w32 appears to work in nanoserver. At least, the BusyBox testsuite gives results in the same ballpark as on proper Windows systems.

It needs an environment variable to be set for correct console emulation (from PowerShell: $env:BB_SKIP_ANSI_EMULATION=0) then just run ‘busybox sh -l’ to get a BusyBox shell. No further set up is needed.

Yeah this was actually quite disappointing. Everybody was so hyped about Nano and a lot of vendors were making software more compatible with it. I seen a few pilot deployments on Nano. Then it just died all out of the sudden. I would like to learn the internal story some day. Do people really prefer regular server core over nano? Or do they run it with full desktop experience and tiles showing random websites around the web? Do people really run Windows containers? And even if they do, doesn’t it make sense to use more full featured base image than nano for regular apps? All of this stuff is backward and really doesn’t make any sense to me.

https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2016-nano-server-installation-option

Normal servers are supported for 10 years; this one was supported for less than two. Trying to install updates after 2018, including servicing stack updates, fails claiming they’re inapplicable.

I’m actually curious if any Microsoft product was supported for less time.

OK, this link is still up, might want to mirror: https://mega.co.nz/#!VwQnkRJC!RtLwdzo-hD_PN3M5emzylAGL3Hcxr4ia9edrU9ZbDhs

As far as fixing the console, it’s not exactly a video driver. The “normal” console goes via condrv.sys, which generates events that are pumped by a usermode conhost.exe which turns around and calls GDI to render things. Here, condrv appears basically in tact, but messages are pumped by conkbd.dll which is hosted in csrss.exe (everything old is new again!) I’m sure you’re right that it’d be possible to replace this sucker with a “better” version that can display a cursor or background colors without horking.

However, that’s only one layer. The other strange thing in Nano is that kernel32.dll isn’t fully there – parts of it are, and some exports that have existed since Windows NT 4.0 are just gone. Yori happens to work because it’s designed to run on NT 3.1 so it’s trying to degrade gracefully when things are missing, but the missing things here are just a bit strange. For example, the normal console manages aliases which are exposed via AddConsoleAlias et al. Those exports are gone. So even if conkbd.dll were replaced with something that implemented them, there’s no way for applications to access that functionality without adding back the missing exports into kernel32.

Something that really gave me Win95 flashbacks is ENABLE_WRAP_AT_EOL_OUTPUT . By default this is on, and conkbd doesn’t support it being turned off. Win9x was similar, so sdir (which ran on Win95 once) has to count to see if a line is long enough to trigger an implicit line wrap, and if not generate one explicitly. More, which is newer, just turned this off so it can display a line and move to the next line unconditionally. But on condrv, this moves by two lines, not one. So I need to port all of the sdir crap into more so it works correctly.

Anyway, here are fixes so far:
* Don’t display the current directory via VT sequences since conkbd just displays it as text.
* Use 7-bit ascii line drawing by default in sdir and libwin (aka edit, co, history.)
* A cut down palette for libwin. I’m using yellow for selection, green for titles. This makes edit usable, but somebody more artistic than me could do better.
* Accelerator characters are always highlighted since pressing “Alt” by itself doesn’t trigger a keypress from conkbd.

Changes that I think would be good:
* Do something with the cursor, but all options suck. Conkbd is effectively not displaying the character the cursor is on. I can do that too but use a giant yellow block or something, but without a background color, keeping the character displayed is only possible by changing the foreground color only, which is lame.
* Yedit should detect the lack of clipboard and always disable those options. Somewhat later, it should build its own single process fallback clipboard.
* Fix Yori (shell) selection color, similar to libwin. This is hard to invoke without a mouse, but it’s still there.
* Ymore line wrapping issue mentioned above.
* Ypm could fall back to winhttp when wininet is not available. It looks like the instructions for Nano include an extra switch to generate an image with OEM drivers, which seems like something I should use to have networking support.
* Yshutdn should fall back to something when user32’s shutdown is gone.

There’s probably a lot more, but as of now things kind of work. Here’s what yedit looks like:
http://www.malsmith.net/edit/nano.png

To use Yori instead of Powershell:
reg add “HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon” /v Shell /t REG_SZ /d “C:\Yori\OneYori.exe” /f

Thanks for a quick response! Wow if you could replace PS with Yori shell and make YEdit work a little better that would make a pretty awesome and useable OS! I’m also thinking that perhaps instead of working around quirks of the default console a better video driver could be build?

I ignored this when it was launched because it seemed like a big contradiction to say “compact Windows image” and then say “which uses Powershell and .NET for administration.” That was before Yori, and now it seems like a good time to revisit and see if the potential of Nano can really be fulfilled. Replacing Powershell with Yori as a boot shell enabled it to boot on 128Mb RAM. I need to do some trial-and-error to see what services can be disabled – most of them are network related and I don’t have an operational network so it looks like a lot of them can go.

It has plenty of quirks and loose edges. It has winhttp.dll but not wininet.dll, which is what ypm was using for updates. It doesn’t have user32.dll which makes sense given it’s trying to be GUI-less and user32 contains a lot of Window handling code, but it also contains things like clipboard code or even the simplest way to reboot and shutdown. The terminal appears to have VT support, but doesn’t implement everything and Yori by default spews the current directory to the console (it’s trying to hint to Terminal where it is but Nano doesn’t know what to do with that.) And I really need to figure out how to debug the thing, given it doesn’t have an operating network – use kd for everything?

In terms of reverse video, it looks like the foreground color can be set to anything but the background color must be black. That breaks a whole pile of things, like the cursor (as you mentioned.) I think what I need to do with YEdit is create a central color table system, so rather than controls specifying their colors they query from a system palette. From there, it needs to detect display capabilities and fall back to something primitive. It’s not just the menus that are off – the dialogs are unusable, the status bar is hidden, the scroll bar is busted, etc.

In more amusing news, it has 8.3 names enabled. So here we are with a 64-bit only edition, no 32 bit support let alone 16 bit support, and DOS compatibility lives on.