system menu, but expand from 256 entries to 1024 as there seems to be plenty
of space.
Also remove a couple of unused IDM_* constants.
[originally from svn r4733]
submenu were going up in steps of 16, I've changed to steps of 1, thus
increasing the possible number of sessions from ~256 to 4096, since a
recent report seemed to indicate that the previous limit might not be
enough for someone (!)
I can't find any documentation that puts an upper limit on the number of
menu items, and it seems to work on Win98, which is where I'd expect it to
break if anywhere.
Also a number of other tweaks to this code.
[originally from svn r4731]
Also, I'm pretty sure that adding a source address to a remote SSH-2 forwarding
can never have worked, since we added an address string to the packet twice in
that case. OpenSSH 3.4p1 certainly doesn't like it (`Server has disabled port
forwarding' debug message). Fixed (and OpenSSH is happier now).
[originally from svn r4727]
mechanics means that each SSH-2 remote tunnel will sfree() something
random and thus have a chance of crashing or doing something else
bad, although it won't otherwise affect execution. Introduced in
1.319 [r4529] (some of my improved diagnostics). One day I'll make a
checkin to ssh.c without forgetting about the coroutines...
[originally from svn r4725]
[r4529 == 27193c4bf0]
fixing `vuln-ssh2-debug', by missing out a field. In most cases
(always_display = 0) we would log a zero-length or truncated message.
(Also add a prototype for ssh2_pkt_getbool().)
[originally from svn r4718]
This is mainly intended to make the documentation suitable for including in
distributions such as the Debian package, but won't be amiss on the web site
docs. It will look a bit out of place in the .HLP, but never mind.
[originally from svn r4690]
- change click-by-click advice on modifying saved sessions
- add `Restart Session' as another reason you might not want to close the
window on exit; other tweaks to this language
- mention Shift-Backspace action
- the window resizing configuration documentation was completely out of
date; rewrite
- add a note about Default Bold Background since it's caused confusion
- "remote terminal" -> "remote system" in terminal-type doc
[originally from svn r4686]
- soften language around changing-username-during-login section; with SSH-2
this is a misfeature of implementations rather than the protocol itself
- tweak new-host-key dialog text
[originally from svn r4681]
variables. It was no longer true (given that we support them in SSH-2 now),
and the new situation was probably too complex to explain in an introductory
chapter. And the utility of setting them seems to be marginal these days given
the lack of server support.
[originally from svn r4679]
middle of a PDF. So here's a modification to sshzlib.c which enables
it to be compiled into a standalone Zlib decoder if you define
ZLIB_STANDALONE. As an added bonus, it (both standalone and in
PuTTY) also validates the Zlib header, just to make sure someone
hasn't defined a new compression format.
[originally from svn r4657]
(in the Windows version), and hopefully to clarify distinction between line
charset and local font, which has occasionally foxed me.
Cross-reference the Translation panel reference section from the intro
section in using.but and mention line-drawing characters there also.
[originally from svn r4654]
This is disgustingly huge because old versions of OpenSSH got the message
format wrong, so we have to infer which format is in use. Tested with
Debian stable OpenSSH (3.4p1), with `uint32' packet, and lshd, which uses
the correct `string' packet, and also let me test "core dumped" and the
explanatory message.
[originally from svn r4653]
of the SSH servers I conveniently have access to (Debian stable OpenSSH --
3.4p1 -- and lshd) seem to take a blind bit of notice, but the channel
requests look fine to me in the packet log.
I've included all the signals explicitly defined by
draft-ietf-secsh-connect-19, but I've put the more obscure ones in a submenu
of the specials menu; there's therefore been some minor upheaval to support
such submenus.
[originally from svn r4652]
down. (A side effect of fixing this is that ssh->mainchain is set to NULL
when it closes, which might avoid other sorts of trouble.)
While we're here, don't bother offering SSH1_MSG_IGNORE if we believe the
remote will barf on it.
[originally from svn r4650]
the same window (Windows version only).
Policy change: it's now the backend's responsibility to call
update_specials_menu() at the start of a session (or whenever it feels ready),
if it has any special commands. Otherwise the menu won't be displayed.
[originally from svn r4649]
http://www.cl.cam.ac.uk/~mgk25/unicode.html#activate
feels strongly that it should be easy to make _all_ your
applications work in UTF-8 mode, without having to remember a switch
for each one. Every application should simply note a UTF-8 locale
setting and switch into UTF-8 mode automatically.
Therefore, for the Unix port only, there's now a checkbox, enabled
by default, which causes the drop-down Translation box to be
overridden if the locale indicates UTF-8. Anyone who doesn't like
this, or doesn't like MGK, is welcome to turn it straight back off.
I'm not _completely_ convinced by MGK's argument myself; for
xterm/pterm to do _useful_ UTF-8 you also need to specify a decently
Unicode-capable font, and there's no way _that_ can be automagically
done on noticing a locale setting. But it's a de facto standard
(i.e. xterm does it :-) so I might as well at least be _able_ to
support it.
[originally from svn r4648]
into the Connection panel, and implemented support for the SSH2
"env" request. (I haven't yet found a server which accepts this
request, so although I've visually checked the packet log and it
looks OK, I haven't yet been able to do a full end-to-end test.)
Also, the `pty' backend reads this data and does a series of
`putenv' commands before launching the shell or application.
This is mostly because in last week's UTF-8 faffings I got
thoroughly sick of typing `export LANG=en_GB.UTF-8' every time I
started a new testing pterm, and it suddenly occurred to me that
this would be precisely the sort of thing you'd want to have pterm
set up for you, particularly since you can configure it alongside
the translation settings and so you can ensure they match up
properly.
[originally from svn r4645]
the scrollback if you then leak away all the memory you saved!) One
of the leaks - by far the bigger of the two - was in my temporary
diagnostic function cc_check(), which is particularly embarrassing :-)
[originally from svn r4638]
was checking whether lattr == LATTR_NORM, where it should have been
checking (lattr & LATTR_MODE) to mask off LATTR_WRAPPED et al.
[originally from svn r4627]
XXX-REMOVE-BEFORE-RELEASE tag, since they're performance-intensive.
And now that I'm reasonably confident of remembering to remove them
before the next release, I feel less guilty about adding them willy-
nilly all over the place, so I've shoved in a couple more for now :-)
[originally from svn r4624]
PuTTY source for the word XXX-REMOVE-BEFORE-RELEASE, and not release
until I've got rid of all of them. Hence, here's an addition to the
release checklist which will remind me to do so.
I don't want this mechanism to seriously inhibit a release by being
a placeholder for a large piece of work we might never get round to.
It should be used only in cases where it's _simple_ to change the
offending code: for example, a performance-impacting diagnostic
might be invaluable while testing nightly snapshots but wouldn't
want to slow down everyone's next release, and it's easy to get rid
of on release day.
[originally from svn r4623]
array of each `termline' structure now contains optional additional
entries after the normal number of columns, which are used to chain
a linked list of combining characters off any primary termchar that
needs it. This means we support arbitrarily many combining
characters per cell (unlike xterm's hard limit of 2).
Cut and paste works correctly (selecting a character cell containing
multiple code points causes all those code points to be cut and
pasted). Display works by simply overlaying all the relevant
characters on top of one another; this is good enough for Unix
(xterm does the same thing), and mostly seems OK for Windows except
that the Windows Unicode fonts have a nasty habit of not containing
most of the combining characters and thus overlaying an
unknown-code-point box on your perfectly good base glyph.
I had no idea how to add support in the Mac do_text(), so I've
simply stuck in an assertion that will trigger the first time a
combining character is displayed, and hopefully this will bite
someone with the clue to fix it.
[originally from svn r4622]
PuTTY / Plink not to run a remote shell/command at all. Supported in
the GUI configuration and via the (OpenSSH-like) -N command-line
option.
No effort is currently made to arrange `nice' UI properties. If you
do this in GUI PuTTY, a full-size terminal window will still be
created, and will sit there with almost nothing in it throughout
your session. If you do it in Plink, Plink will not accept any kind
of request to terminate gracefully; you'll have to ^C or kill it.
Nonetheless, even this little will be useful to some people...
[originally from svn r4614]
Jacob Nevins
Simon Tatham