of polishing to bring them to what I think should in principle be
release quality. Unlike the unfix.org patches themselves, this
checkin enables IPv6 by default; if you want to leave it out, you
have to build with COMPAT=-DNO_IPV6.
I have tested that this compiles on Visual C 7 (so the nightlies
_should_ acquire IPv6 support without missing a beat), but since I
don't have IPv6 set up myself I haven't actually tested that it
_works_. It still seems to make correct IPv4 connections, but that's
all I've been able to verify for myself. Further testing is needed.
[originally from svn r5047]
[this svn revision also touched putty-wishlist]
mid-session if we are not using SSHv1. I've done this by introducing
a generic `cfg_info' function which every back end can use to
communicate an int's worth of data to setup_config_box; in SSH
that's the protocol version in use, and in everything else it's
currently zero.
[originally from svn r5040]
[r5031 == d77102a8d5]
(which will gain more content anon).
Retire BUG_SSH2_DH_GEX and add a backwards-compatibility wart, since we never
did find a way of automatically detecting this alleged server bug, and in any
case there was only ever one report (<3D91F3B5.7030309@inwind.it>, FWIW).
Also generalise askcipher() to a new askalg() (thus touching all the
front-ends).
I've made some attempt to document what SSH key exchange is and why you care,
but it could use some review for clarity (and outright lies).
[originally from svn r5022]
comment when I unblock it in pty.c to reflect reality. Also I've
moved block_signal() out of pterm.c into signal.c, so I can
conveniently use it for unblocking SIGCHLD rather than having to
reinvent it in pty.c.
[originally from svn r5006]
pterm, which was breaking my bash job notification patch. This is
apparently not the case for xterm, so I've fiddled with it. Not
entirely sure _why_ it did this in the first place, but there we go.
[originally from svn r4997]
timing shakeup: just running `psftp' caused the net/stdin select
loop (on both Unix and Windows) to get confused at the lack of any
network connection and give up immediately. Should now be fixed.
[originally from svn r4993]
blink when the window doesn't have focus, we don't schedule blink
timers at that point either.
Infrastructure change: term->has_focus should now not be written
directly from outside terminal.c. Instead, use the function
term_set_focus, which will sort out the blink timers as well.
[originally from svn r4911]
which pretty much any module can call to request a call-back in the
future. So terminal.c can do its own handling of blinking, visual
bells and deferred screen updates, without having to rely on
term_update() being called 50 times a second (fixes: pterm-timer);
and ssh.c and telnet.c both invoke a new module pinger.c which takes
care of sending keepalives, so they get sent uniformly in all front
ends (fixes: plink-keepalives, unix-keepalives).
[originally from svn r4906]
[this svn revision also touched putty-wishlist]
- initialise blank mbstate_t using memset rather than an ad-hoc
initialiser.
- expand the OMIT_UTMP ifdefs to enclose a load of entire functions
that would generate `static function never called' warnings if
left as empty shells.
- couple of other fiddly things.
[originally from svn r4896]
before is would return success and the empty string. IMO this makes `-batch'
much more useful; before, utilities such as Plink in `-batch' mode would
attempt to plough on using empty strings for usernames, passwords, and so on.
[originally from svn r4832]
[originally from svn r4788]
[this svn revision also touched bmbm,caltrap,charset,enigma,filter,fonts,golem,grunge,halibut,html,lj,local,misc,polyhedra,putty-website,putty-wishlist,puzzles,pycee,sdlgames,svn-tools,timber,tweak]
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]
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]
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]
The active terminal screen is no longer an array of `unsigned long'
encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of
`termchar' structures, which currently have 32-bit Unicode and 32
attribute bits but which will probably expand further in future.
To prevent bloat of the memory footprint, I've introduced a mostly
RLE-like compression scheme for storing scrollback: each line is
compressed into a compact (but hard to modify) form when it moves
into the term->scrollback tree, and is temporarily decompressed when
the user wants to scroll back over it. My initial tests suggest that
this compression averages about 1/4 of the previous (32 bits per
character cell) data size in typical output, which means this is an
improvement even without counting the new ability to extend the
information stored in each character cell.
Another beneficial side effect is that the insane format in which
Unicode was passed to front ends through do_text() has now been
rendered sane.
Testing is incomplete; this _may_ still have instabilities. Windows
and Unix front ends both seem to work as far as I've looked, but I
haven't yet looked very hard. The Mac front end I've edited (it
seemed obvious how to change it) but I can't compile or test it.
As an immediate functional effect, the terminal emulator now
supports full 32-bit Unicode to whatever extent the host platform
allows it to. For example, if you output a 4-or-more-byte UTF-8
character in Unix pterm, it will not display it properly, but it
will correctly paste it back out in a UTF8_STRING selection. Windows
is more restricted, sadly.
[originally from svn r4609]
- new function platform_get_x_display() to find a sensible local display.
On Unix, the Gtk apps weren't taking account of --display when
determining where to send forwarded X traffic.
- explicitly document that leaving X display location blank in config tries
to do something sensible (and that it's now blank by default)
- don't override X11Display setting in plink, since that's more properly
done later
[originally from svn r4604]
and "plink user@host" differed in that the former attempted to load session
`host' while the latter didn't. Now both forms attempt to load a session.
Someone will probably complain, but hey.
[originally from svn r4485]
before "-load" is processed so that it doesn't clobber it.
I've also changed the semantics of "-load" slightly for PSCP, PSFTP,
and Plink: if it's specified at all, it overrides (disables) the
implicit loading of session details based on a supplied hostname
elsewhere (on the grounds that the user is more likely to want the
"-load" session than the implicit session). (PuTTY itself doesn't do
implicit loading at all, so I haven't changed it.)
This means that all the PuTTY tools' behaviour is now consistent iff
"-load" is specified (otherwise, some tools have implicit-session, and
others don't).
However, I've not documented this behaviour, as there's a good chance
it will be swept away if and when we get round to sorting out how we
deal with settings from multiple sources. It's intended as a "do
something sensible" change.
[originally from svn r4352]
No very good reason, but I've occasionally wanted to frob it to see if it
makes any difference to problems I'm having, and it was easy.
Tested that it does actually cause keepalives on Windows (with tcpdump);
should also work on Unix. Not implemented on Mac (does nothing), but then
neither is TCP_NODELAY.
Quite a big checkin, much of which is adding `keepalive' alongside `nodelay'
in network function calls.
[originally from svn r4309]
