Welcome to mirrors.uni-ruse.bg, a free service hosted by the University of Ruse

PuTTY wish win-command-prompt

PuTTY wish win-command-prompt

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

summary: Ability to backend on to a Windows command interpreter
class: wish: This is a request for an enhancement.
difficulty: mayhem: Probably impossible
priority: low: We aren't sure whether to fix this or not.

Lots of people ask whether PuTTY would be able to act as a front end for Windows command interpreters (Command Prompt, bash, etc), in place of the not-very-pleasant standard console window.

I (SGT) have done some experimental work in this direction, but it doesn't look promising, since Windows's interface to its console devices is fundamentally different in nature from Unix's system of terminals and pseudo-terminals.

Unix programs communicate with their terminal via a serialised stream of data in which literal text to be written to the screen is intermixed with control codes to do operations such as positioning the cursor, clearing the screen, and setting the colour. This architecture makes it very natural and simple to put a network connection in between the terminal application and the software or hardware which is converting that serialised data stream into a rectangular view of a terminal window; Unix supports this by providing "pseudo-terminal" devices, which look and behave just like an ordinary Unix terminal from the point of view of the applications running in them, but which pass the data stream to another application which can interpret it itself. Unix programs such as xterm, and also network servers such as sshd, all work by using these pseudo-terminal devices to retrieve the stream of terminal data. In sshd's case, the data is then passed on to a remote network client such as PuTTY, which receives that stream of terminal data and interprets all the control codes so as to display the literal text into its window as those codes instruct it.

By contrast, Windows's console device is much more geared to direct access via the Windows API: there are API functions to ask Windows to read or write out the contents of a console's rectangular screen buffer, to change the colour, and so on. Windows has no analogue of Unix's pseudo-terminal device: there is no convenient way to create something that looks like a Windows console to its client application but passes all requests on to another application which can decide how to answer them.

(This is a slight oversimplification. Unix does include one or two terminal operations which are not serialised into the usual data stream but are instead performed by direct Unix API calls, such as resizing the window. However, in such cases Unix is careful to provide an out-of-band mechanism for applications using pseudo-terminals to arrange correct handling of the operation.)

It is just about possible (though extremely fiddly) to construct an application which instantiates a Windows console as a hidden window, and uses the same console API used by applications running in the console to read out its screen buffer and transfer that into the PuTTY window. This would give a window that had the look and feel of PuTTY (and, in particular, PuTTY's cut and paste interface), but running a Windows command prompt inside it. I have an experimental branch of the PuTTY code base (last touched in 2009) which attempts this.

However, it's not of production quality and probably never will be. Many things go subtly wrong when you attempt this sort of hackery, and handling of errors and exceptional cases is often very hard to get right. For example, it's extremely hard to arrange that if the PuTTY managing the invisible console window crashes, all processes using the console are cleaned up correctly. It's also hard to get GUI processes started from the invisible console not to be invisible themselves. Also, important keystrokes like Ctrl-C are difficult to pass through properly to the underlying console.

On the other hand, making PuTTY behave like a local terminal window for Cygwin processes in particular is a much more feasible piece of work, since Cygwin carefully emulates the Unix-like terminal model which PuTTY already understands, so all that PuTTY has to do is to arrange to be able to talk to that emulation. See cygwin-terminal-window for thoughts on this.


If you want to comment on this web site, see the Feedback page.
Audit trail for this wish.
(last revision of this bug record was at 2017-04-28 16:52:45 +0100)

Contact us:mirrors@uni-ruse.bg

Developed and supported by the Centre for Information and Computing Technologies

ipv6 ready