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 haven't investigated this very closely, but it's not clear to me
that this would be useful for anything except Cygwin. I've used
Windows telnetds, and they look to me as if they're working in a
fundamentally different way from a Unix telnetd. When you issue a
command that scrolls the screen a lot, it seems to get
redrawn from the server end rather than scrolled - as if
the server had its own image of what the console screen ought to
look like and was running something like
reproduce that image on the client side.
This leads me to conjecture that Windows's equivalent of a pty works
Windows will still do the terminal emulation itself, and all you can
do is read the results off a rectangular screen buffer and transfer
them to an output device. So there would be no scope, in this model,
for PuTTY to supply superior terminal emulation.
The alternative to that, of course, would be to ignore Windows's pty equivalent (whatever it is) and run the application in an ordinary pair of pipes instead. But this doesn't seem to work very well for the ordinary Windows Command Prompt utility: if you do that, you lose the command-line editing and recall which the console device provides.
As far as I can tell (and this is still all deductions based on observation, and might be wrong), the Cygwin library takes a completely different approach: the first Cygwin program you run in a Windows console will turn part of itself into a terminal emulator, create some pipes, and run the rest of the program in those pipes. If the program spawns other programs, they are passed the same pipes, and all terminal emulation is done by whichever program was first to get hold of the real console device. So in this model, PuTTY could contribute: it could run (say) Cygwin bash in a pair of pipes, and apply its own terminal emulation to the data it received from bash. However, there's still the question of what it would do about local line editing (which Unix utilities would still want to enable sometimes). I suspect Cygwin has a means of dealing with this, which a hypothetical local-PuTTY would have to implement.
In summary: I believe Windows does not supply an interface at the right level to make it sensibly possible to run a Command Prompt inside PuTTY's terminal emulator. I believe it would be possible in theory, but quite fiddly, to turn PuTTY into a local xterm-alike for the use of Cygwin programs only; but this is significantly less useful than the original goal of making it a generic replacement for the Command Prompt window. So unless anyone can correct my deductions above, I don't think this has a sufficiently high benefit-to-effort ratio to be worth doing.
A workaround is of course to run an SSH (or telnet) server on your Windows box.
Mark Edgar has created
PuTTYcyg (link on Links page),
which allows PuTTY to act as a terminal for
Cygwin (with the aid of a helper
application linked against Cygwin).
(further discussion in
This certainly looks believable enough for the moment. What I'd _like_ to do is to set up a more general mechanism for having PuTTY monitor Windows file descriptors as well as network sockets. This would be useful for supporting the OpenSSH-like ProxyCommand function (for example running PuTTY over a secondary Plink), and for talking to serial ports; and it would _also_ be an interesting alternative approach to your problem, since we could arrange to run (something like) cthelper with a group of pipes rather than local network connections. If we were to do this, it would open up two or three possible avenues of implementation for your feature: (a) cthelper works roughly as it now does, with two data channels from PuTTY to it so that data and screen resizes can be separated. They could now be pipes rather than network sockets, but this would still require an extra back end in PuTTY. (b) If cthelper were to speak (a reasonably small subset of) the Telnet protocol on its stdin/stdout, then it might be possible to do this _without_ any modifications to PuTTY once I implement proxy commands: you would supply `cthelper' as a proxy command, and select Telnet as the protocol (the host and port would then become unimportant). Then cthelper could separate the incoming Telnet stream into screen resize events and data, perform minimal Telnet encoding on the data it sent back, and your code could be completely independent of changes to mine. (c) I'd also quite like to implement a DLL plugin interface; I've been wanting to do this for a while but recently there have been some slightly more immediate reasons for wanting it. It would obviously be good to have DLL plugins be able to add extra back ends, so possibly that would be a good approach. For the moment, though, yours looks entirely workable and I'll have to give it a try...
Audit trail for this wish.