'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]
Should be no significant change in behaviour.
(Well, entering usernames containing commas on Plink's command line will be
a little harder now.)
[originally from svn r7628]
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]
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]
- 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]
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]
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]
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]
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]
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]
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]
practically trivial to put all the pieces together and create a
working prototype of Unix PuTTY! It's missing a lot of things -
notably GUI request boxes for host keys and logfiles and so forth,
the Event Log, mid-session reconfiguration, session loading and
saving, sensible population of the character sets drop-down list and
probably other fiddly little things too - but it will put up a
config box and then create a GUI window containing an SSH connection
to the host you specified, so it's _basically_ there. Woo!
[originally from svn r3020]
