bufchain_add() now allocates at most one new granule. Granules still
have a minimum size, so small adds still get coalesced.
The main practical consequence of this is that PSCP and PSFTP now
generate 4K SSH packets rather than 512-byte ones. Also, the compiled
code (on my Ubuntu box) is fractionally smaller.
[originally from svn r9602]
by sending most of the initial SSH_MSG_CHANNEL_REQUEST messages before
waiting for any replies. The initial version of this code was a clever
thing with a two-pass loop, but that got hairy so I went for the simpler
approach of separating the request and reply code and having flags to
keep track of which requests have been sent.
[originally from svn r9599]
winadj@putty.projects.tartarus.org request. Not currently enabled
automatically, but should be usable as a manual workaround.
[originally from svn r9592]
zero but does it in such a way that over-clever compilers hopefully
won't helpfully optimise the call away if you do it just before
freeing something or letting it go out of scope. Use this for
(hopefully) every memset whose job is to destroy sensitive data that
might otherwise be left lying around in the process's memory.
[originally from svn r9586]
having just noticed that Makefile.gtk had it and this one doesn't. (Of
course, this being autoconf, we can easily enough make it conditional
on the compiler actually being gcc.)
[originally from svn r9583]
compile warning ('left-hand operand of comma expression has no
effect'), which of course becomes fatal under -Werror.
(This would have been instantly noticeable to people compiling with
the old-fashioned Makefile.gtk, which does include -Wall -Werror, but
those of us using the new autoconf makefile hadn't noticed.)
[originally from svn r9582]
platform manner, but which nothing ever called. It thus served only to
trap up the unwary. The live function key handling code lives in the
frontends, i.e. window.c on Windows and gtkwin.c on Unix.
[originally from svn r9579]
and the argument list contains only one string, try again by passing
that single string to "$SHELL -c" to be parsed as a shell command.
This matches xterm's behaviour (as of xterm 261, at least), and means
in practice that users can do _either_ of 'pterm -e some command' and
'pterm -e "some command"'.
(A quick survey suggests that the majority of X terminal programs agree
with pterm's old behaviour of only supporting '-e some command',
except that gnome-terminal only supports the other behaviour and xterm
supports both. With that disagreement, I think supporting both is
probably the sensible thing.)
[originally from svn r9575]
piece of keyboard handling: if Num Lock is on, numeric keypad keys are
eaten by the IM, so we must avoid passing them to the IM in the first
place if we're in any non-default numeric keypad mode (application or
Nethack).
This is a grubby way to do it, but the more obvious approach of just
moving the Nethack and app-keypad if statements up to above the IM
call doesn't work because those statements depend on the generic
Alt-prefix handling that happens just _below_ the IM call. So instead
I just repeat the list of keystrokes and modes in an if statement
conditionalising the IM call.
[originally from svn r9573]
[r9567 == 7fc8db15b2]
FXP_READDIR on an empty directory by returning a zero-length list of
filenames, instead of the more common response of a list containing
just "." and "..". Stop PSFTP failing an assertion when that happens.
[originally from svn r9569]
a GtkIMMulticontext and having that filter most keypresses. I think
I've got this right so that it doesn't break any previous deliberate
keyboard-handling behaviour that's now _after_ the 'if (filter
keypress) return' statement.
[originally from svn r9567]
unconditionally set the telnet state to SEENCR regardless of whether
we have actually seen a CR, and as a result sending a NUL through
PuTTY (via Ctrl-Space or whatever) does not work. Must have arisen
through some kind of really weird cut-and-paste error!
[originally from svn r9545]
The previous platform-dependent ifdefs, switching between a system
which tried to cope with spurious callbacks (which I'd observed on
Windows) and one which tried to cope with system clock jumps (which
can happen on Unix, if you use gettimeofday) have been completely
removed, and replaced with a much simpler approach which just copes
with system clock jumps by triggering any timers immediately.
None of the resulting effects should be catastrophic (the worst thing
might be the waste of CPU in a spurious rekey, but as long as the
system clock isn't jumping around _all_ the time that's hardly
critical) and in any case the Unix port has had a long-standing oddity
involving occasional lockups if pterm or PuTTY runs for too long,
which hopefully this should replace with a much less bad failure mode.
And the code is much simpler, which is not to be sneezed at.
[originally from svn r9528]
sequence: since init_fonts sets up ucsdata based on the available
Windows fonts, we should call it before passing ucsdata to term_init.
[originally from svn r9527]
calling back->unthrottle), we should immediately call
ssh_process_queued_incoming_data to handle the SSH packets that have
been saved for later functioning while we were throttled. Otherwise,
they'll sit there unhandled until the next call to ssh_gotdata, which
might not be for ages if the server thinks it's waiting for us.
[originally from svn r9523]
forwarded X connection. (I somehow forgot to do this in r9364, despite
making the identical change in portfwd.c.)
[originally from svn r9470]
[r9364 == 49927f6c4d]
the offset horizontal line characters in the VT100 line-drawing set
(o,p,r,s), so that no trace of it - and hence no pointless performance
hit - is compiled into the cross-platform modules on non-Windows
platforms.
[originally from svn r9467]
will not even initialise sbstring[0], so we shouldn't even look at it
let alone depend on it to tell us the desired character was absent.
[originally from svn r9465]
logevent(), which temporarily turn off the raw mode we've put stderr
into, so that they don't get called if the log_eventlog() call between
them is not _actually_ going to write to stderr.
Fixes a bug in which, if you define a Unix PuTTY saved session which
uses 'plink -nc' as a local proxy command and then run PuTTY
backgrounded from the shell with that session loaded, the subprocess
Plink would get SIGTTOU when it tried to muck about with stderr and
the whole thing would grind to a halt. I'm prepared to consider that
acceptable if Plink _really_ wants to write on standard error, but if
it doesn't, it should just carry on working in the background!
[originally from svn r9462]
interpretation with some analysis done on it. The script will do its
own tracking of the set of open channels and their states, and its
output is in a one-line-per-packet format such that every distinct
channel has a unique identifier in it which should make it easy to
grep out all lines relating to that channel. The script also matches
up {CHANNEL,REQUEST}_{SUCCESS,FAILURE} to the requests that caused
them, by tracking a queue of requests in each direction per channel
and for global requests. Command-line options permit generating a
final dump of all channels ever known to the script and their various
ids and final state, and also dumping out the data transferred over
each channel in each direction.
Output is not complete, in the sense that some parameters in some
messages (e.g. pixel sizes in window-size specifications) are
deliberately omitted due to being boring, and the entire contents of
some messages (e.g. KEXINIT) are omitted because I haven't yet seen
any purpose in decoding them. Filling them in might be a useful thing,
although I'm inclined to think that the default should still be to
show only the potentially interesting stuff (e.g. still not pixel
sizes!) and enable the rest using a -v option.
Hopefully this should do a lot of the legwork in debugging issues in
which a channel mysteriously remains partially open and prevents PuTTY
closing.
[originally from svn r9457]
duplicate the strings they pass to gtk_entry_set_text. I was already
doing that in dlg_editbox_set, but forgot to add the same code when I
revamped FontSpec and Filename to contain dynamically allocated
strings (r9314 and r9316 respectively). This fixes a bug where, on
some versions of GTK (but apparently not up-to-date versions), loading
a saved session causes gibberish to appear in file-selector edit boxes
accompanied by a valgrind error.
[originally from svn r9456]
[r9314 == 9c75fe9a3f]
[r9316 == 62cbc7dc0b]
wonky because I'd used the subkey for the red component in four places
where I should have used the green/blue subkeys instead. Thanks to
Martin Kletzander for spotting it.
[originally from svn r9449]
[r9214 == a1f3b7a358]
bidi_char from wchar_t to unsigned int, but omitted to similarly
adjust the parameter to doMirror which is passed a pointer to that
field.
[originally from svn r9426]
[r9409 == 053d2ba6d1]
which text pasted into the terminal is preceded and followed by
special function-key-like escape sequences ESC[200~ and ESC[201~ so
that the application can identify it and treat it specially (e.g.
disabling auto-indent-same-as-previous-line in text editors). Enabled
and disabled by ESC[?2004h and ESC[?2004l, and of course off by
default.
[originally from svn r9412]
UTF-16 support. High Unicode characters in the terminal are now
converted back into surrogates during copy and draw operations, and
the Windows drawing code takes account of that when splitting up the
UTF-16 string for display. Meanwhile, accidental uses of wchar_t have
been replaced with 32-bit integers in parts of the cross-platform code
which were expecting not to have to deal with UTF-16.
[originally from svn r9409]
