Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am often frustrated with the Windows' console host application, especially how clumsily the clipboard works, no-automatic-width issues etc. I would like to know if there is a way to replace the default console host conhost.exe with a custom one and where could I find more information on the interfaces I would have to implement if I were to write my own.

I am not looking just for an alternative console, I already use xterm from CygWin. I am looking for information on how to replace Windows' default console window host.

share|improve this question
add comment

migrated from serverfault.com Apr 16 '12 at 23:43

This question came from our site for professional system and network administrators.

4 Answers

up vote 5 down vote accepted
+100

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

share|improve this answer
1  
While all of them are nice consoles, none of them actually replace or interface with conhost.exe, so programs are NOT launched in them by default. –  Tibor Apr 19 '12 at 7:55
    
See my edit above. –  harrymc Apr 19 '12 at 8:17
    
How about console EXEs? –  Tibor Apr 19 '12 at 8:25
    
Question unclear. –  harrymc Apr 19 '12 at 8:34
1  
They are NOT affected by cmd.exe. cmd is only a shell, a command-line processor. The visual console window is controlled by a whole different subsystem i.e. csrss.exe on pre-Vista ane csrss.exe-spawned conhost.exe processes on Windows 7/Windows 2008 –  Tibor Apr 19 '12 at 9:13
show 5 more comments

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.

share|improve this answer
add comment

I would recommend installing either PowerShell, which is Microsoft's version of a unix terminal intended for scripting, piping, etc. or the Microsoft Services for Unix (once known as SFU) which is actually an entire Posix subsystem for Windows, operating directly on top of the kernel (i.e. alongside WIN32 and the Windows API, not on top of it. again, i.e. it is not emulated it's basically Unix) and will let you use any (well, most) of the *nix technologies and shells. It's a real shame Services for Unix has not gained more traction.

share|improve this answer
    
I used PowerShell, but this has nothing to do with the console host on Windows. IIRC, PowerShell uses the same console host with all its limitations (the only difference is the blue background). Furthermore I would like to change the console host for all console applications, not just for my shell of choice. –  Tibor Apr 18 '12 at 23:21
    
Yep. SFU will do exactly what you want, but then again, it replaces a whole lot more than conhost.exe –  Mahmoud Al-Qudsi Apr 19 '12 at 1:04
    
I was using CygWin and the xterm/bash that came with it is great, I use it all the time. I do still have console applications that are written for Win32 and they run in the default console host, if I don't run them from bash. I would like to know if it is possible to replace this windws component. –  Tibor Apr 19 '12 at 6:16
add comment

As others have said, it appears that one can't just replace the console host as such. There is another project that uses tricks to hide the conhost UI and show its own that hasn't been mentioned yet: ConEmu.

Not being a full replacement of conhost, you have to run the target program through ConEmu in order for this to have effect. Simply running a console program via the Run window will still show the conhost UI.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.