GTK 2 has deprecated it and provided no replacement; a bug tracker
entry I found on the subject suggested that it was functionality that
didn't really belong in GTK, and glib ought to provide a replacement
instead, which would be a perfectly fine thing to suggest if they had
waited for glib to get round to doing so *before* throwing out a
function people were actually using. Sigh.
Anyway, it turns out that subsidiary invocations of gtk_main() don't
happen inside GTK as far as I can see, so all I need to do is to make
sure my own invocations of gtk_main() are followed by a cleanup
function which runs any quit functions that I've registered.
That was the last deprecated GTK function, so we now build cleanly
with -DGTK_DISABLE_DEPRECATED. (But, as mentioned a couple of commits
ago, we still don't build with -DGDK_DISABLE_DEPRECATED, because that
has migrating to Cairo drawing as a prerequisite.)
When anyone connects to a PuTTY tool's listening socket - whether it's
a user of a local->remote port forwarding, a connection-sharing
downstream or a client of Pageant - we'd like to log as much
information as we can find out about where the connection came from.
To that end, I've implemented a function sk_peer_info() in the socket
abstraction, which returns a freeform text string as best it can (or
NULL, if it can't get anything at all) describing the thing at the
other end of the connection. For TCP connections, this is done using
getpeername() to get an IP address and port in the obvious way; for
Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some
moderately hairy autoconfery) to get the pid and owner of the peer. I
haven't implemented anything for Windows named pipes, but I will if I
hear of anything useful.
Having found a lot of unfixed constness issues in recent development,
I thought perhaps it was time to get proactive, so I compiled the
whole codebase with -Wwrite-strings. That turned up a huge load of
const problems, which I've fixed in this commit: the Unix build now
goes cleanly through with -Wwrite-strings, and the Windows build is as
close as I could get it (there are some lingering issues due to
occasional Windows API functions like AcquireCredentialsHandle not
having the right constness).
Notable fallout beyond the purely mechanical changing of types:
- the stuff saved by cmdline_save_param() is now explicitly
dupstr()ed, and freed in cmdline_run_saved.
- I couldn't make both string arguments to cmdline_process_param()
const, because it intentionally writes to one of them in the case
where it's the argument to -pw (in the vain hope of being at least
slightly friendly to 'ps'), so elsewhere I had to temporarily
dupstr() something for the sake of passing it to that function
- I had to invent a silly parallel version of const_cmp() so I could
pass const string literals in to lookup functions.
- stripslashes() in pscp.c and psftp.c has the annoying strchr nature
The mechanism for constructing a new connection-type Socket when a
listening one receives an incoming connection previously worked by
passing a platform-specific 'OSSocket' type to the plug_accepting
function, which would then call sk_register to wrap it with a proper
Socket instance. This is less flexible than ideal, because it presumes
that only one kind of OS object might ever need to be turned into a
Socket. So I've replaced OSSocket throughout the code base with a pair
of parameters consisting of a function pointer and a context such that
passing the latter to the former returns the appropriate Socket; this
will permit different classes of listening Socket to pass different
function pointers.
In deference to the reality that OSSockets tend to be small integers
or pointer-sized OS handles, I've made the context parameter an
int/pointer union that can hold either of those directly, rather than
the usual approach of making it a plain 'void *' and requiring a
context structure to be dynamically allocated every time.
[originally from svn r10068]
Again, I've removed the special-purpose ad-hockery from the assorted
front end message loops that dealt with deferred handling of socket
errors, and instead uxnet.c and winnet.c arrange that for themselves
by calling the new general top-level callback mechanism.
[originally from svn r10023]
that the user really ought to know but that are not actually fatal to
continued operation of PuTTY or a single network connection.
[originally from svn r9932]
and returns its error message as a string, instead of actually
printing it on standard error and exiting. Now we can preserve the
previous error behaviour when we get a nonexistent font name at
startup time, but no longer rudely terminate in mid-session if the
user configures a bogus font name in Change Settings.
[originally from svn r9745]
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]
remembered to do before! Also some related fixes, such as that after
we do so we should immediately stop selecting on the socket in
question.
[originally from svn r9363]
allocated type.
The main reason for this is to stop it from taking up a fixed large
amount of space in every 'struct value' subunion in conf.c, although
that makes little difference so far because Filename is still doing
the same thing (and is therefore next on my list). However, the
removal of its arbitrary length limit is not to be sneezed at.
[originally from svn r9314]
'Config' in putty.h, which stores all PuTTY's settings and includes an
arbitrary length limit on every single one of those settings which is
stored in string form. In place of it is 'Conf', an opaque data type
everywhere outside the new file conf.c, which stores a list of (key,
value) pairs in which every key contains an integer identifying a
configuration setting, and for some of those integers the key also
contains extra parts (so that, for instance, CONF_environmt is a
string-to-string mapping). Everywhere that a Config was previously
used, a Conf is now; everywhere there was a Config structure copy,
conf_copy() is called; every lookup, adjustment, load and save
operation on a Config has been rewritten; and there's a mechanism for
serialising a Conf into a binary blob and back for use with Duplicate
Session.
User-visible effects of this change _should_ be minimal, though I
don't doubt I've introduced one or two bugs here and there which will
eventually be found. The _intended_ visible effects of this change are
that all arbitrary limits on configuration strings and lists (e.g.
limit on number of port forwardings) should now disappear; that list
boxes in the configuration will now be displayed in a sorted order
rather than the arbitrary order in which they were added to the list
(since the underlying data structure is now a sorted tree234 rather
than an ad-hoc comma-separated string); and one more specific change,
which is that local and dynamic port forwardings on the same port
number are now mutually exclusive in the configuration (putting 'D' in
the key rather than the value was a mistake in the first place).
One other reorganisation as a result of this is that I've moved all
the dialog.c standard handlers (dlg_stdeditbox_handler and friends)
out into config.c, because I can't really justify calling them generic
any more. When they took a pointer to an arbitrary structure type and
the offset of a field within that structure, they were independent of
whether that structure was a Config or something completely different,
but now they really do expect to talk to a Conf, which can _only_ be
used for PuTTY configuration, so I've renamed them all things like
conf_editbox_handler and moved them out of the nominally independent
dialog-box management module into the PuTTY-specific config.c.
[originally from svn r9214]
are now loaded from standard locations (system32 for SSPI, the
registry-stored MIT KfW install location for KfW) rather than using
the risky default DLL search path; I've therefore also added an
option to manually specify a GSS DLL we haven't heard of (which
should in principle Just Work provided it supports proper GSS-API as
specified in the RFC). The same option exists on Unix too, because
it seemed like too useful an idea to reserve to Windows. In
addition, GSSAPI is now documented, and also (unfortunately) its GUI
configuration has been moved out into a sub-subpanel on the grounds
that it was too big to fit in Auth.
[originally from svn r9003]
reorganises the GSSAPI support so that it handles alternative
implementations of the GSS-API. In particular, this means PuTTY can
now talk to MIT Kerberos for Windows instead of being limited to
SSPI. I don't know for sure whether further tweaking will be needed
(to the UI, most likely, or to automatic selection of credentials),
but testing reports suggest it's now at least worth committing to
trunk to get it more widely tested.
[originally from svn r8952]
void *, and hence eliminate a few casts. The Windows definition is
unchanged, but I daresay I've managed to stop it compiling nonetheless.
[originally from svn r8359]
ourselves, but on Unix then assumed it was compatible with the system's
gss_buffer_desc, which wasn't the case on LP64 systems. Now, on Unix
we make Ssh_gss_buf into an alias for gss_buffer_desc, though we keep
something similar to the existing behaviour on Windows. This requires
renaming a couple of the fields in Ssh_gss_buf, and hence fixing all
the references.
Tested on Linux (MIT Kerberos) and Solaris. Compiled on NetBSD (Heimdal).
Not tested on Windows because neither mingw32 nor winegcc worked out of the
box for me. I think the Windows changes are all syntactic, though, so
if this compiles it should work no worse than before.
[originally from svn r8326]
simply specifying a hostname on the command line -- this would bring up the
config dialog. Use a slightly more sophisticated notion of whether the user
meant to launch a session.
[originally from svn r7321]
[r7265 == 5d76e00dac]
takes a third argument which is TRUE if the file is being opened for
writing and wants to be created in such a way that it's readable
only to the owner. This is used when saving private keys.
While I'm here, I also use this option when writing session logs, on
the general principle that they probably contain _something_
sensitive.
The new argument is only supported on Unix, for the moment. (I think
writing owner-accessible-only files is the default on Windows.)
[originally from svn r7084]
I own has both an X display and a working serial port) I have been
unable to give this the full testing it deserves; I've managed to
demonstrate the basic functionality of Unix Plink talking to a
serial port, but I haven't been able to test the GTK front end. I
have no reason to think it will fail, but I'll be more comfortable
once somebody has actually tested it.
[originally from svn r6822]
rather than relying on the user to edit the Makefile. Makefile.gtk
still works as well as it ever did, but now we get a Makefile.in alongside
it. mkunxarc.sh now relies on autoconf and friends to build the configure
script for the Unix source distribution.
[originally from svn r5673]
in question vary per OS: on Windows the problem is that WM_TIMER
sometimes goes off too early, so that GetTickCount() is right and
the callback time is wrong, whereas on Unix the problem is that my
GETTICKCOUNT implementation comes from the system clock which means
it can change suddenly and non-monotonically if the sysadmin is
messing about (meaning that the timing of callbacks from GTK or
select timeouts is _more_ likely to be right than GETTICKCOUNT).
This checkin provides band-aid workarounds for both problems, which
aren't pretty but ought to at least prevent catastrophic assertion
failure.
[originally from svn r5556]
* Make sk_getxdmdata() return an arbitrary string rather than two integers.
This better matches the spec, even if the current version always returns
six bytes
* On Unix, for PF_UNIX sockets, return a counter rather than a constant along
with the PID. This should allow multiple clients to connect within one
second, and is what Xlib does.
* On Unix, interpret AF_INET6 addresses like Xlib does, returning the
embedded IPv4 address for v4-mapped addresses, and six bytes of zeroes
otherwise. The latter is silly, but if I'm going to do anything more sane
I need to check that X servers won't reject it.
[originally from svn r5219]
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]
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]
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]
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]
... here's a Unix port of PSFTP. Woo. (Oddly PSCP looks to be
somewhat harder; there's more Windows code interleaved than there
was in PSFTP.)
[originally from svn r3419]
ptrs and ints of different size and -Werror makes this serious).
The GTK bits are done by Colin's patch to use GINT_TO_POINTER
(thanks); the uxnet bits are done by cleaning up the rest of the
code. In particular, network.h now typedefs `OSSocket' to be a type
capable of holding whatever the OS's socket data type is that
underlies our socket abstraction. Individual platforms can make this
typedef themselves if they define OSSOCKET_DEFINED to prevent
network.h redoing it; so the Unix OSSocket is now int. Default is
still void *, so other platforms should be unaffected.
[originally from svn r3171]
Euro-supporting font with a Euro-enabled X key map will now actually
generate a Euro character rather than shrugging and doing nothing.
[originally from svn r3151]
had to move another of its values out into wincfg.c - paradoxically,
this was the `font has X encoding' option! (Because the Unix font
handling code expects to be able to tell for _itself_ whether it has
a font with X-encoded line drawing glyphs.)
[originally from svn r3145]
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]
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]
think it's now actually usable as a day-to-day SSH client, even if
things like the Event Log are still missing. So I call that a decent
lunch hour's work :-)
[originally from svn r3034]
being able to be a PuTTY as well as a pterm. In the process I've
also moved icky things like actually reading from the pty fd and
printing the `terminated on signal' messages into pty.c where they
obviously should have been in the first place. Also there's been one
interesting repercussion in the terminal code: terminal.c's
from_backend now calls term_out() directly rather than expecting the
front end to call it afterwards. This has had the entertaining side
effect of fixing a Windows-specific bug whereby activity in a port
forwarding through a PuTTY with a blinking cursor caused the cursor
to blink to ON (!!!!). So, a surprisingly far-reaching checkin as it
turns out...
[originally from svn r3017]
functionality that deal with selectable fds in general. The idea is
that pty.c will stop passing its fd straight to pterm.c and hand it
to this module instead, and pterm.c will start requesting a general
list of fds from this module rather than expecting a single one from
pty.c, with the ultimate aim of pterm.c being able to form the basis
of a Unix PuTTY as well as pterm proper.
[originally from svn r3015]
Unix-specific config items; moved a stray Windows-specific config
item (scrollbar-in-fullscreen) out into wincfg.c to stop it
appearing on Unix; continued updates to gtkdlg.c. I now believe the
GTK config box looks basically correct (modulo minor cosmetic issues
and keyboard accelerators). Next step, add the event handling so
it's actually functional.
[originally from svn r2933]
