constructed it it won't be deleted again by 'make clean'. The effect
is that not only does this work (as r9288 arranged),
./configure; make plink
but these work too:
./configure; make; make clean; make plink
./configure; make; make distclean; ./configure; make plink
[originally from svn r9290]
[r9288 == a4424bfd85]
makefile) as a side effect of running mkfiles.pl.
The automake docs observe that the BUILT_SOURCES list is only
automatically built by plain 'make' or 'make all' or a couple of other
targets, so the sequence './configure && make plink' from a freshly
unpacked tar file would previously fail for lack of empty.h.
If empty.h had important _content_ that needed to be built at compile
time, of course, I wouldn't be able to fix it like this; but since the
only important thing is the timestamp, I can just make sure it already
exists at the time of first build.
[originally from svn r9288]
nonstandard port number when loading a saved session.
Occurs because those tools include be_none.c which defines no entries
in backends[] at all, as a result of which settings.c doesn't
recognise the word 'ssh' in the saved session's protocol field and
instead sets the protocol to something idiotic - which _then_ means
that when pscp.c forces the protocol to PROT_SSH, it also resets the
port number as it would when overriding a saved session specifying a
protocol other than SSH.
The immediate solution is to define a new be_ssh.c citing only
ssh_backend, and include that in the SSH-only tools. However, I wonder
if a better approach (perhaps when I redesign session loading and
saving) would be not to be so clever, and just have all the tools
contain a complete list of known protocol names for purposes of
understanding what's in the saved session data, and complain if you
try to use one they don't know how to actually speak.
[originally from svn r9254]
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
'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]
icon, even if the program isn't running at the time, to be presented
with an application-defined collection of helpful links). The current
jump list is updated every time a saved session is loaded, and shows
the last few launchable saved sessions (i.e. not those like Default
Settings) that were loaded. Also, if Pageant or PuTTYgen or both is in
the same directory as the PuTTY binary, the jump list will present
links to launch those too.
Based on a patch sent last year by Daniel B. Roy, though it's barely
recognisable any more...
[originally from svn r9046]
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]
strings more rigorously, and then we look up the local X authority
data in .Xauthority _ourself_ rather than delegating to an external
xauth program. This is (negligibly) more efficient on Unix, assuming
I haven't got it wrong in some subtle way, but its major benefit is
that we can now support X authority lookups on Windows as well
provided the user points us at an appropriate X authority file in
the standard format. A new Windows-specific config option has been
added for this purpose.
[originally from svn r8305]
explicitly deals with GdkFont out into a new module, behind a
polymorphic interface (done by ad-hoc explicit vtable management in
C). This should allow me to drop in a Pango font handling module in
parallel with the existing one, meaning that GTK2 PuTTY will be able
to seamlessly switch between X11 server-side fonts and Pango client-
side ones as the user chooses, or even use a mixture of the two
(e.g. an X11 font for narrow characters and a Pango one for wide
characters, or vice versa).
In the process, incidentally, I got to the bottom of the `weird bug'
mentioned in the old do_text_internal(). It's not a bug in
gdk_draw_text_wc() as I had thought: it's simply that GdkWChar is a
32-bit type rather than a 16-bit one, so no wonder you have to
specify twice the length to find all the characters in the string!
However, there _is_ a bug in GTK2's gdk_draw_text_wc(), which causes
it to strip off everything above the low byte of each GdkWChar,
sigh. Solution to both problems is to use an array of the underlying
Xlib type XChar2b instead, and pass it to gdk_draw_text() cast to
gchar *. Grotty, but it works. (And it'll become significantly less
grotty if and when we have to stop using the GDK font handling
wrappers in favour of going direct to Xlib.)
[originally from svn r7933]
it'll let you see an identifier (SHGFP_TYPE_CURRENT) referenced since r7082.
(Actually, you need a pretty recent w32api before it's there at all.)
Morally, this should be defined for all toolchains, not just MinGW/Cygwin, but I'll leave that to people who have those toolchains.
<http://msdn2.microsoft.com/en-us/library/aa383745.aspx>
Also add some other comments on our use of this API (since it's a horrible one
that I suspect will come back and haunt us...)
[originally from svn r7087]
[r7082 == dbbd6eb5ec]
[this svn revision also touched putty-wishlist]
custom Panels container widget for the PuTTY config box, since the
perfectly standard GtkNotebook does the same job. Hence, let's
remove Panels completely in favour of doing it the proper way.
[originally from svn r7034]
since even the latest version of w32api (3.6) shows no sign of HTMLHelp
support.
(This touches mkfiles.pl because that's where the details of what Cygwin
doesn't support are kept currently. This may be deliberate, so I haven't
changed it.)
[originally from svn r7032]
r7000. I was probably half asleep. Actually, it's completely
unnecessary to bind to it at link time, because we load it at run
time in order to continue working as before on Win95. So I'm
removing it again.
[originally from svn r7030]
[r7000 == 1dac1bc911]
and various calls to WinHelp() have been centralised into a new file
winhelp.c, which in turn has been modified to detect a .CHM file as
well as .HLP and select between them as appropriate. It explicitly
tries to load HHCTRL.OCX and use GetProcAddress, meaning that it
_should_ still work correctly on pre-HTML-Help platforms, falling
gracefully back to WinHelp, but although I tested this by
temporarily renaming my own HHCTRL.OCX I haven't yet been able to
test it on a real HTML-Help-free platform.
Also in this checkin: a new .but file and docs makefile changes to
make it convenient to build the sources for a .CHM. As yet, owing to
limitations of Halibut's CHM support, I'm not able to write a .CHM
directly, more's the pity.
[originally from svn r7000]
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]
in place of making a network connection. This has involved a couple
of minor infrastructure changes:
- New dlg_label_change() function in the dialog.h interface, which
alters the label on a control. Only used, at present, to switch
the Host Name and Port boxes into Serial Line and Speed, which
means that any platform not implementing serial connections (i.e.
currently all but Windows) does not need to actually do anything
in this function. Yet.
- New small piece of infrastructure: cfg_launchable() determines
whether a Config structure describes a session ready to be
launched. This was previously determined by seeing if it had a
non-empty host name, but it has to check the serial line as well
so there's a centralised function for it. I haven't gone through
all front ends and arranged for this function to be used
everywhere it needs to be; so far I've only checked Windows.
- Similarly, cfg_dest() returns the destination of a connection
(host name or serial line) in a text format suitable for putting
into messages such as `Unable to connect to %s'.
[originally from svn r6815]
thread-based approach to stdin and stdout, wraps it in a halfway
sensible API, and makes it a globally available service across all
network tools.
There is no direct functionality enhancement from this checkin:
winplink.c now talks to the new API instead of doing it all
internally, but does nothing different as a result.
However, this should lay the groundwork for several diverse pieces
of work in future: pipe-based ProxyCommand on Windows, a serial port
back end, and (hopefully) a pipe-based means of communicating with
Pageant, which should have sensible blocking behaviour and hence
permit asynchronous agent requests and decrypt-on-demand.
[originally from svn r6797]
a VERSIONINFO resource. The versioning scheme is described in
windows/version.rc2.
Some .rc files are now #included in others. In order to keep MSVC
project files working, these have been renamed to .rc2; there may exist
a better solution.
(This checkin also includes the documentation tweak missing from r6367.)
Testing performed:
- MinGW (cross-compiler): works
- VC nmake: works (tested with VC6)
- VC project files: builds with VERSIONINFO resource (no VER variable though)
- Borland: an old version of this patch was tested with it and more or
less worked, except that some of the VERSIONINFO strings were apparently
not terminated properly. Not attempted to work around this.
- LCC: not tested. Some fixes are in there from the last time we tried
this, but then the build ultimately failed and I haven't tried this
since that was fixed.
- Dev-C++: untested. (Haven't done anything special.)
- Unix Gtk/autoconf Makefiles work as before.
[originally from svn r6374]
[r6367 == f86ad059db]
[this svn revision also touched putty-wishlist]
patched OpenSSH server. This is controlled by the same user settings
as diffie-hellman-group-exchange-sha1, which may not be optimal, especially
given that they're both referred to as dh-gex-sha1 in saved sessions.
[originally from svn r6272]
diffie-hellman-group-exchange-sha256, which the last DHGEX draft defined.
Code lifted from Simon's "crypto" directory, with changes to make it look
more like sshsh512.c.
[originally from svn r6252]
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]
written a script which would generate the various graphical
components of the PuTTY icon suite at any given resolution and then
used that to generate the OS X icon as well as all the others, but I
can always do that later; this'll do for now.
[originally from svn r5487]
with the Unix port and layering a Cocoa GUI on top. The basics all
work: there's a configuration panel and a terminal window, the
timing interface works and the select interface functions. The same
application can run both SSH (or other network) connections and
local pty sessions, and multiple sessions in the same process are
fully supported.
However, it's horribly unfinished in a wide variety of other ways;
anyone interested is invited to read README.OSX and wince at the
length and content of its `unfinished' list.
[originally from svn r5308]
in which case pterm will be installed setgid that, or to define
UTMP_USER in which case it will be installed setuid that. If you
define neither, it will be installed without any set-id bits as
before.
[originally from svn r5093]
Ben Harris
Simon Tatham
Jacob Nevins
Owen Dunn