Home |
Licence |
FAQ |
Docs |
Download |
Keys |
Links
Mirrors |
Updates |
Feedback |
Changes |
Wishlist |
Team
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.
Audit trail for this wish.