Alternative console host for Windows 7/Windows Server 2008

Below are some nice console-replacements products that are more user-friendly than cmd.

As commented below, since Windows 7, all these shells are just an interface to conhost.exe, even powershell. For details, read What is conhost.exe and Why Is It Running.

Therefore, the consoles below only replace the default visual interface to conhost which is the one exhibited by cmd, and are only useful when directly invoked as programs. They cannot be indirectly invoked, as when a console-executable such as diskpart is run, since this will invoke conhost, and conhost has its own I/O interface and API.

Here is what Microsoft says in Windows 7 / Windows Server 2008 R2: Console Host :

ConHost represents a permanent change in the way that console application I/O is handled. There is no registry key or group policy setting that can force Windows to revert back to “legacy mode” console behavior.

The conclusion is that if you wish to replace the console in a deeper way than replacing the cmd interface, then this is not possible. Microsoft has chosen this design as a security measure, and will not go back.

The only way I can think of changing the way conhost is behaving is to set a global system hook on the conhost API. I don't know at all if this is possible and nobody has done it up till now (or if they did they are not telling). I also don't believe that Microsoft will let you replace such a crucially important system file as conhost.exe by a hacked version.

If replacing cmd is required, which resides in system32\cmd.exe, one needs to take ownership of the file and then rename it (cmd1.exe?), rename the console-replacement exe to cmd.exe and copy to system32 together with all the files it needs for it to work. This might cause problems if the replacement console does not support all the parameters that cmd does.

Another approach that works for .bat files, is to associate the new console with them. For this one needs to edit the registry key HKEY_CLASSES_ROOT\batfile\shell\open\command. See this article for some details.

Here is the list of consoles :

ColorConsole
FireCMD
PowerCmd
GS.EXE
PyCmd

There are programs like Console that wrap around cmd.exe and can probably give you what you're looking for, but I haven't seen anything that full on replaces the console system. AFAIK, most of these kinds of projects simply redirect stdin/stdout/stderr and then wrap a more common GUI around cmd.exe, hiding the actual console window in the background.

Microsoft has released their conhost.exe source code (https://github.com/microsoft/terminal).

The console host code in this repository is the actual source from which the conhost.exe in Windows itself is built.

So now you have the opportunity to replace the default conhost.exe with your own Console Host in Windows 10. In fact, I have already made such an attempt and achieved success (https://github.com/microsoft/terminal/issues/1817).

Then Microsoft said that the source code of OpenConsole comes from conhost.exe, then can we replace conhost.exe directly with OpenConsole.exe? This way we get a better default console host.

I tried it and it works well. Although OpenConsole is packaged as a UWP application, OpenConsole.exe is actually a normal Win32 window program that can be run by double-clicking its exe. You can find it from terminal\bin\x64\Release\OpenConsole.exe if you done a x64 release build.

Then, go to C:\Windows\System32, right-click conhost.exe, "Properties", and edit the permission list to give the current user the "Full Control" permission.

Then, rename conhost.exe to conhost-old.exe and copy OpenConsole.exe to here and rename it to conhost.exe.

Open any console application (powershell, wsl, ...) and enjoy your new console.

It is also possible to port OpenConsole source code to Windows 7. Also, because you have the source code, you can add any features you want.

In addition, Microsoft also introduced the Windows Pseudo Console API in Windows 10, allowing developers to develop third-party terminal applications more elegantly (Yes, it is implemented via conhost.exe and should be included in the code released by Microsoft).

https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/

Here are the things that conhost.exe is actually responsible for:

(From https://devblogs.microsoft.com/commandline/windows-command-line-inside-the-windows-console/)

The core components of the Console consist of the following (from the bottom-up):

• ConDrv.sys – Kernel-Mode driver

  • Provides a high-performance communications channel between Console and any connected Command-Line apps
  • Ferries IO Control (IOCTL) messages back and forth between Command-Line apps and the Console they’re “attached” to
  • Console IOCTL messages contain
    • Data representing requests to execute API calls against the Console instance
    • Text sent from the Console to the Command-Line app

• ConHost.exe – Win32 GUI app:

  • ConHost Core – the Console’s internals and plumbing

    • API Server: Converts IOCTL messages received from Command-Line app(s) into API calls, and sends text records from Console to Command-Line app
    • API: Implements the Win32 Console API & logic behind all the operations that the Console can be asked to perform
    • Input Buffer: Stores keyboard and mouse event records generated by user input
    • VT Parser: If enabled, parses VT sequences from text, extracts any found from text, and generates equivalent API calls instead
    • Output Buffer: Stores the text displayed on the Console’s display. Essentially a 2D array of CHAR_INFO structs which contain each cell’s character data & attributes (more on the buffer below)
    • Other: Not included in the diagram above include settings infrastructure storing/retrieving values from registry and/or shortcut files etc.

  • Console UX App Services – the Console UX & UI layer

    • Manages the layout, size, position, etc. of the Console window on-screen
    • Displays and handles settings UI, etc.
    • Pumps the Windows message queue, handles Windows messages, and translates user input into key and mouse event records, storing them in the Input Buffer