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]
(list boxes are particularly conspicuously absent), it has no event
handling at all, and it isn't in any way integrated into pterm - you
have to build it specially using the test stubs in gtkdlg.c. But
what there is so far seems to work plausibly well, so it's a start.
Rather than browbeat the existing GTK container/layout widgets into
doing what I wanted, I decided to implement two subclasses of
GtkContainer myself, which implement precisely the layout model
assumed by the config box specification; this has the rather cool
consequence that the box can be resized and will maintain the same
layout at all times that it would have had if initially created at
that size.
[originally from svn r2931]
opaque to all platform-independent modules and only handled within
per-platform code. `Filename' is there because the Mac has a magic
way to store filenames (though currently this checkin doesn't
support it!); `FontSpec' is there so that all the auxiliary stuff
such as font height and charset and so on which is needed under
Windows but not Unix can be kept where it belongs, and so that I can
have a hope in hell of dealing with a font chooser in the forthcoming
cross-platform config box code, and best of all it gets the horrid
font height wart out of settings.c and into the Windows code where
it should be.
The Mac part of this checkin is a bunch of random guesses which will
probably not quite compile, but which look roughly right to me.
Sorry if I screwed it up, Ben :-)
[originally from svn r2765]
holdout static I hadn't noticed; unicode.c had one too; and a large
number of statics that were perfectly OK due to being constants have
been made `const', with assorted `const' repercussions all over the
place. I now declare `remove-statics' to be fixed.
[originally from svn r2594]
just done this the very simple way - bundle all the globals into a
data structure and pass pointers around. One particularly ugly wart
is that wc_to_mb now takes a pointer to this structure as an
argument (optional, may be NULL, and unused in any Unicode layer
that's even marginally less of a mess than the Windows one). I do
need to do this properly at some point, but for now this should just
about be adequate. As usual, the Mac port has not been updated.
[originally from svn r2592]
relevant bits of it passed in to init_ucs(). (Actually I pass in all
of it in the Windows version, since it's a bit hairy in there.)
[originally from svn r2565]
we're going to be a security program, we can at least make a token
effort to use the most secure local X auth available! And I'm still
half-tempted to see if I can support it for remote X servers too...
[originally from svn r2537]
font whose encoding comes up as CS_NONE - but this is also true for
iso10646-1 fonts, since libcharset doesn't support wide-character
encodings! Hence UTF-8 cut and paste was enabled in ordinary modes,
but disabled in UTF-8 mode, which was a bit embarrassing. Now we
have a dedicated flag variable indicating direct-to-font mode.
[originally from svn r2425]
know what that encoding actually is, we can do our best to support
additional charsets (VT100 linedrawing, SCO ACS, UTF-8 mode) using
the available characters; if we don't, we fall back to a mode where
we disable all Unicode cut-and-paste and assume any Unicode
character is undisplayable.
[originally from svn r2413]
does UTF-8 copy and paste (falling back to normal strings if
necessary), it understands X font encodings and translates things
accordingly so that if you have a Unicode font you can ask for
virtually any single-byte encoding and get it (Mac-Roman pterm,
anyone?), and so on. There's work left to be done (wide fonts for
CJK spring to mind), but I reckon this is a pretty good start.
[originally from svn r2395]
