hazard. I considered removing it completely, but I can't rule out
the possibility of an OS that actually takes security of its
terminal devices seriously, and which might be able to make sensible
and safe use of this feature.
[originally from svn r3103]
remember changes in COE so it knows whether to print a message, and
(b) once the session has already ended, Warn On Close should shut up.
[originally from svn r3102]
of PuTTY (terminal, backend, logctx etc) take a `void *' handle
passed to them from the frontend, and used as a context for all
their callbacks. Most of these point at the frontend structure
itself (on platforms where this is meaningful), except that the
handle passed to the backend has always pointed at the terminal
because from_backend() was implemented in terminal.c. This has
finally bitten Unix PuTTY, because both backend and logctx have
been passing their respective and very different frontend handles to
logevent(), so I've fixed it.
from_backend() is now a function supplied by the _frontend_ itself,
in all cases, and the frontend handle passed to backends must be the
same as that passed to everything else. What was from_backend() in
terminal.c is now called term_data(), and the typical implementation
of from_backend() in a GUI frontend will just extract the terminal
handle from the frontend structure and delegate to that.
This appears to work on Unix and Windows, but has most likely broken
the Mac build.
[originally from svn r3100]
the location of PuTTY's data storage mentioned in the manual section
about loading and storing sessions. This seems not unreasonable, so
I've put it there.
[originally from svn r3094]
contents, and doesn't automatically maintain scroll position at the
bottom when new entries are added while the list is open, but it's a
start.
[originally from svn r3087]
broken! We were expecting the peer address/port in the incoming
packet _before_ the connected address/port, which is just wrong. I
wonder how I managed to mess that up.
[originally from svn r3083]
position in GTK, so I can now implement the other half of -geometry
which I'd previously believed to be impossible in GTK. It's still
not perfect, because GTK apparently provides no way for us to get
hold of the X reparent event in order to support negative geometries
in a manner which takes account of the WM borders; but for positive
position it's at least an improvement on the previous version!
[originally from svn r3078]
particular, the config box uses it in place of the word `PuTTY',
which means mid-session reconfig in pterm will look less strange
once I implement it. Also, while I'm at it, I've personalised all
the dialog boxes and menu items and suchlike so that PuTTYtel
actually claims to be PuTTYtel rather than PuTTY.
[originally from svn r3074]
This isn't _quite_ right, since it uses a b/w dither everywhere, whereas
it should use grey on colour screens. That would involve mucking around
with DeviceLoop, though, and I'm not sure I can be bothered.
[originally from svn r3066]
former by simply removing it; the latter by adding an enumeration
function to libcharset.) This has had slight `const' repercussions
on cp_name() and cp_enumerate() which might break the Mac build.
[originally from svn r3064]
This menu is not yet fully populated, but it has an About box (yet
another licence location :-/ ) and supports the new configurable
specials menu (thus making Unix PuTTY do one tiny thing which
OpenSSH-in-a-pterm can't :-).
[originally from svn r3062]
supports SOCKS 4, SOCKS 4A and SOCKS 5 (well, actually IPv6 in SOCKS
5 isn't supported, but it'll be no difficulty once I actually get
round to it). Thanks to Chas Honton for his `stone soup' patch: I
didn't end up actually using any of his code, but it galvanised me
into doing it properly myself :-)
[originally from svn r3055]
`Special Command' menu, in which any backend can place its own list
of magical things the user might want to ask the backend to do. In
particular I've implemented the recently proposed "break" extension
in SSH2 using this mechanism.
NB this checkin slightly breaks the Mac build, since it needs to
provide at least a stub form of update_specials_menu().
[originally from svn r3054]
