NanaRun: runtime environment customisation for Windows, built on MinSudo and SynthRdp

Two finished components under an unfinished umbrella

NanaRun is described as an application runtime environment customization utility, and the project is organised as a set of components with their own development status.

MinSudo and SynthRdp are marked as done. NanaEAM, NanaKit, NanaRun (Console) and NanaRun (SDK) are not. The readme is a checklist rather than a feature list, which tells you that this repository is a container for several tools at different stages, and that only two of them are ready to use today.

That framing matters for an adopter, because the name on the release and the components you can actually use are not the same thing. The three most recent releases are all previews of NanaRun 1.0: NanaRun 1.0 Preview 3 at version 1.0.92.0 on 2024-08-01, Preview 2 at 1.0.18.0 on 2022-06-03, and Preview 1 at 1.0.5.0 on 2022-05-21.

The jump in version numbers between Preview 1 and Preview 2, and again to Preview 3, is large, and the repository is not archived with the last push on 2026-10-11, so the console and SDK pieces are being worked on even though they are not finished.

The tree reflects the split. Alongside the MinSudo, SynthRdp and NanaRun directories there are RunAsSvc and VirtualSmb, plus a Tools directory, a Documents directory, a NanaRun.IconResource directory, a solution file, a global.json, and the BuildAllTargets and BuildInstallers scripts for producing the whole set.

The audience is Windows developers and administrators who need specific runtime behaviours that the platform does not provide out of the box, and who would rather use a focused tool than a full application virtualisation layer.

MinSudo elevates a command without inventing a service or an IPC channel

MinSudo is a lightweight POSIX-style Sudo implementation for Windows. It makes user possible to use elevated console apps in non-elevated consoles.

The interesting part is how it refuses to do the dangerous thing. For safety, the implementation uses the UAC for elevation and doesn't support credential cache. It also doesn't use homemade Windows service and any IPC infrastructures.

That is a deliberate design constraint rather than an omission. The usual way to build a Windows sudo is to install a service that runs as SYSTEM, have the client talk to it over a named pipe, and let the service start the elevated process. That design gives you credential caching, and it also gives whoever can reach the pipe a path to SYSTEM. By routing elevation through UAC instead, MinSudo accepts the price of no credential cache in exchange for not running its own privileged service and not inventing its own IPC.

The usage is a single command with a set of switches:

Format: MinSudo [Options] Command

Options:

  --NoLogo, -NoL
    Suppress copyright message.

  --Verbose, -V
    Show detailed information.

  --WorkDir=[Path], -WD=[Path]
    Set working directory.

  --System, -S
    Run as System instead of Administrator.

The two identity switches are the unusual ones. --System, -S runs as System instead of Administrator, and --TrustedInstaller, -TI runs as TrustedInstaller instead of Administrator. Those are the two built-in Windows identities that ordinary administration does not give you, and they are what makes the tool useful for system maintenance tasks where Administrator is not enough.

The option syntax allows Windows or POSIX style, case insensitively

The command line handling in MinSudo is one of those small decisions that save real time, and it is worth describing because it is the kind of detail that decides whether a tool gets used.

All command options are case-insensitive. You can use the "/" or "--" override "-" and use the "=" override ":" in the command line parameters. For example, "/Option:Value" and "-Option=Value" are equivalent.

That equivalence is what allows a single command line to be pasted into cmd.exe, PowerShell and a POSIX style shell without editing. The slash form is native to Windows, the dash form is what you would expect from a Unix tool, and the colon and equals forms are the PowerShell conventions. Supporting all of them means you can copy the same invocation across environments, which matters for a tool whose whole purpose is to be invoked from wherever you happen to be.

Two other behaviours are documented. MinSudo will execute "cmd.exe" if you don't specify another command, which makes a bare invocation useful rather than an error. And the example given in the readme is the canonical case:

  If you want to run "whoami /all" as elevated in the non-elevated Console, and
  you don't want to show version information of MinSudo.
  > MinSudo --NoLogo whoami /all

So a command that would normally fail with a not-elevated error becomes a normal command line with a prefix. That is the whole user story, and it is a narrow one, which is why the tool is small.

The remaining switches are --Privileinor -P to enable all privileges, --Version for version information, and the help switches /?, -H, --Help.

SynthRdp makes Enhanced Session work for guests that cannot do it

SynthRdp is a Hyper-V Enhanced Session Proxy Service for Windows, which can redirect RDP over VMBus pipe to any RDP over TCP socket, because the Hyper-V Enhanced Session is actually the RDP connection over the VMBus pipe.

That single sentence explains both features it offers. It can make Hyper-V virtual machines with Windows 8 and earlier guest operating systems support Hyper-V Enhanced Session mode. And it can act as a proxy service to make Hyper-V virtual machines with non-Windows guest operating systems support Hyper-V Enhanced Session mode.

The reason the proxy works is that the Enhanced Session is not a separate protocol. It is ordinary RDP tunnelled over a virtual machine bus pipe rather than over TCP, and the pipe path needs a guest-side component that understands it. Windows 8 and earlier do not have that component, and non-Windows guests obviously do not. SynthRdp sits in the guest, accepts the VMBus pipe connection, and forwards it over a normal RDP socket to the host.

The quick start is short. You move SynthRdp.exe into the System32 folder of the virtual machine that needs it, with the platform of SynthRdp.exe matching the guest operating system, open an elevated Command Prompt, and run the install and configuration commands:

  SynthRdp Install
  SynthRdp Config Set DisableRemoteDesktop False
  SynthRdp Config Set EnableUserAuthentication False
  SynthRdp Config Set DisableBlankPassword False

The service is then managed with the Install, Uninstall, Start, Stop commands, and Config List or Config Set for its settings.

The SynthRdp configuration keys trade security for connectivity

The configuration keys are where the tool asks you to make a security decision, and the readme is refreshingly explicit about it.

DisableRemoteDesktop set to False enables the remote desktop for this virtual machine, and the default is True. The reason given is that Remote Desktop is necessary for the Hyper-V Enhanced Session because it is actually the RDP connection over the VMBus pipe.

EnableUserAuthentication set to False allows connections without Network Level Authentication. The default is True, and setting it to False is necessary for using the Hyper-V Enhanced Session via the SynthRdp service.

DisableBlankPassword set to False enables the usage of logging on this virtual machine as the account with the blank password via remote desktop. The default is True, and the readme says that setting this option to False will make you use the Hyper-V Enhanced Session via the SynthRdp service happier, but compromise the security. That is the most direct warning in the documentation.

Two further keys extend the scope. OverrideSystemImplementation set to True makes the guest use SynthRdp on Windows 8.1, Server 2012 R2 or later guests that already have built-in Enhanced Session support, and you need to reboot the virtual machine for the change. ServerHost sets the server host for the remote desktop connection, defaulting to 127.0.0.1, and ServerPort sets the port, defaulting to 3389.

So the configuration that the quick start applies, disabling remote desktop, NLA and blank password logging, is a coherent set rather than three unrelated switches. Each one removes a check that would otherwise reject the connection arriving over the VMBus pipe.

The readme's own advice is to use SynthRdp to connect to Windows Vista or later guests for decent user experiences.

Where this set of tools is the wrong answer

There are clear boundaries, and the first one is that the umbrella is mostly unfinished.

Only MinSudo and SynthRdp are marked as complete. NanaEAM, NanaKit, and the Console and SDK variants of NanaRun are not, and the three most recent releases are all NanaRun 1.0 previews, meaning the product the repository is named after is the part that is not finished. If you are evaluating NanaRun the application, there is nothing to evaluate yet, and the release numbers will not tell you that from a glance.

The second is the security posture of the SynthRdp configuration. The documented path to a working Enhanced Session involves turning off Remote Desktop, Network Level Authentication and blank password logging in the guest. That is a real weakening of the guest's security posture, and the readme says so. If the guest holds anything that matters, the trade may not be worth the smoother console.

The third is that MinSudo does not cache credentials, by design. If your workflow elevates repeatedly in a loop, every invocation goes through a UAC prompt, and there is no way around that within the tool. A service-based approach would remove the prompt, and that is exactly what this tool declines to be.

The fourth is platform coverage. MinSudo supports Windows Vista RTM or later, and SynthRdp supports Windows XP RTM or later, both on x86 in 32-bit and 64-bit and on ARM 64-bit. The XP floor for SynthRdp is striking, since it means the component is expected to run inside quite old guests, but the ARM support is x86 Windows on ARM, which is a specific configuration rather than native ARM64 Windows.

And the fifth is the alternative you should consider before installing either. If what you want is a working sudo on Windows, there are other implementations with different trade-offs around credential caching and service use. If what you want is a console for a Linux guest in Hyper-V, the issue is that the guest does not have an Enhanced Session capable component, and a proxy is one answer while a plain RDP connection with the same resolution and no clipboard integration is another.

How the two components relate to each other

It is worth asking what a runtime environment customization utility means here, because the two finished pieces solve problems that look unrelated until you put them next to each other.

MinSudo is about elevation inside a Windows session. SynthRdp is about the boundary between a virtual machine and its host. Both are about making a Windows runtime behave in a way it does not by default, and both are deliberately narrow.

The two also have different system requirements, which is the clearest signal that they are independent tools. MinSudo supports Windows Vista RTM (Build 6000.16386) or later, and SynthRdp supports Windows XP RTM (Build 2600) or later. Both support x86 in 32-bit and 64-bit and ARM 64-bit.

The build system in the tree reflects that composition. There is a NanaRun.slnx solution, a Directory.Build.props for shared MSBuild properties, BuildAllTargets.cmd and BuildAllTargets.proj for building the whole set of components, and BuildInstallers.cmd for producing the installers. The global.json pins the toolchain version for the C++ projects, and a .editorconfig governs formatting.

The RunAsSvc and VirtualSmb directories in the tree are the parts you would look at next to understand the direction of the project, since they are not in the component checklist and not documented in the readme excerpt. The Documents directory and the Tools directory suggest the project carries its own build helpers rather than relying entirely on Visual Studio.

The licensing is a custom one that GitHub cannot classify, with the terms in the License.md file, and the copyright line in that file runs from 2013 to 2026.

Editorial conclusion

Adopt MinSudo if you need to launch elevated console commands from a non-elevated shell without a homegrown service, and adopt SynthRdp if you run Hyper-V guests that need the Enhanced Session experience. Do not adopt the umbrella as a whole, because three of its five listed components, NanaEAM, NanaKit and the console and SDK variants of NanaRun, are not marked as done. Verify first the guest operating system version you need, since the two components have different floors, Windows Vista for MinSudo and Windows XP for SynthRdp, and read the SynthRdp configuration warnings before you disable the security settings it asks you to change.

Frequently asked questions

Official sources

1. Issues
2. M2Team/NanaRun on GitHub
3. README
4. Releases