Some still-supported Linux distributions (Debian jessie and Ubuntu 14.04
at least) still use GCC 4, where C99 isn't the default.
For autoconf, we do it the autotools way. For the standalone Makefiles,
we go for -std=gnu99 rather than c99, to avoid trouble with fdopen().
Unlike the traditional Unix SSH server organisation, the SFTP server
is built into the same process as all the rest of the code. sesschan.c
spots a subsystem request for "sftp", and responds to it by
instantiating an SftpServer object and swapping out its own vtable for
one that talks to it.
(I rather like the idea of an object swapping its own vtable for a
different one in the middle of its lifetime! This is one of those
tricks that would be absurdly hard to implement in a 'proper' OO
language, but when you're doing vtables by hand in C, it's no more
difficult than any other piece of ordinary pointer manipulation. As
long as the methods in both vtables expect the same physical structure
layout, it doesn't cause a problem.)
The SftpServer object doesn't deal directly with SFTP packet formats;
it implements the SFTP server logic in a more abstract way, by having
a vtable method for each SFTP request type with an appropriate
parameter list. It sends its replies by calling methods in another
vtable called SftpReplyBuilder, which in the normal case will write an
SFTP reply packet to send back to the client. So SftpServer can focus
more or less completely on the details of a particular filesystem API
- and hence, the implementation I've got lives in the unix source
directory, and works directly with file descriptors and struct stat
and the like.
(One purpose of this abstraction layer is that I may well want to
write a second dummy implementation, for test-suite purposes, with
completely controllable behaviour, and now I have a handy place to
plug it in in place of the live filesystem.)
In between sesschan's parsing of the byte stream into SFTP packets and
the SftpServer object, there's a layer in the new file sftpserver.c
which does the actual packet decoding and encoding: each request
packet is passed to that, which pulls the fields out of the request
packet and calls the appropriate method of SftpServer. It also
provides the default SftpReplyBuilder which makes the output packet.
I've moved some code out of the previous SFTP client implementation -
basic packet construction code, and in particular the BinarySink/
BinarySource marshalling fuinction for fxp_attrs - into sftpcommon.c,
so that the two directions can share as much as possible.
Every time I do my standard re-test against all three major versions
of GTK, I have to annoyingly remember that the GTK1 headers contain
code that depends on the old gcc language standard, and manually add
this flag on the configure command line. Time to put it where it
belongs, in configure.ac so I don't have to remember it again.
This arranges that the mechanism from the previous commit
automatically turns itself on and off depending on whether a .git
directory even exists (so it won't try to do anything in distribution
tarballs), and also arranges that it can be manually turned off by a
configure option (in case someone who _is_ building from a git
checkout finds it inconvenient for some reason I haven't thought of,
which seems quite plausible to me).
This commit adds two .plist files, which go in the app bundles; two
.bundle files, which are input to gtk-mac-bundler and explain to it
how to _create_ the bundles; and a piece of manual addition to
Makefile.am that actually runs gtk-mac-bundler after building the
gtkapp.c based binaries and the OSX launcher. The latter is
conditionalised on configuring --with-quartz (unlike the binaries
themselves, which you can build on other platforms too, though they
won't do much that's useful).
Today I've gone through the whole GTK front end, doing a manual test
of every piece of code that I either remembered having had to fiddle
with for GTK3, or suddenly realised I _should_ have fiddled with. I've
fixed all the bugs arising from that exercise; and what with that, the
fact that the new Cairo image surface strategy makes server-side font
handling _faster_ in GTK3 than in GTK2, and the fact that GTK3 also
supports the shiny new smooth scrolling system for touchpads, I
suddenly think that the GTK3 build is now at least as good as GTK2.
So I've switched the configure script over to picking it by default if
it can, and I've also removed the 'unfinished and experimental'
warning if you select it. I for one will now start using GTK3 PuTTY
and pterm for my day-to-day work.
Using GTK to run on OS X is going to require several workarounds and
behaviour tweaks to be enabled at various points in the code, and it's
already getting cumbersome to remember what they all are to put on the
command line. Here's a central #define (OSX_GTK) that enables them all
in one go, and a configure option (--with-quartz) that sets it.
As part of this commit, I've also rearranged the #include order in the
GTK source files, so that they include unix.h (which now might be
where NOT_X_WINDOWS gets defined) before they test NOT_X_WINDOWS to
decide whether to include X11 headers.
After the last few commits, we now compile cleanly against GTK3 even
without -Wno-deprecated-declarations, so let's turn the default
warnings back on to ensure we don't regress that.
After the last few changes, the whole codebase now compiles and links
successfully against GTK3, and I can run an experimental pterm. The
config box and font selector look ugly, but the basics all seem to
work.
In order to compile at all, I had to manually bodge in the extra
compile flag -Wno-deprecated-declarations. My plan is to fix all the
uses of deprecated things, and then remove that flag.
I've made GTK3 the second choice, after GTK2 but before GTK1. GTK2 is
the only GTK version that produces a completely sensible build (partly
because the GTK3 port is visibly unfinished, and mostly because its
server-side font handling is just too slow), so it remains the first
choice.
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.
Previously, 'configure' and its assorted machinery lived in the 'unix'
subdir, because that seemed like a clean place to keep it given that
all the other per-platform Makefiles live in their platform
directories. However, this never sat all that happily with autotools,
and even less so now that it likes to have object file pathnames
parallel source file pathnames: if you have Makefile.am refer to
source files outside its subdir as "../terminal.c" and enable
subdir-objects then any out-of-tree build calls the corresponding
object file "../terminal.o" and so your build products mostly end up
at the directory above your build dir! And as of autotools 1.14 my
previous compensatory bodge of prefixing every source file path in
Makefile.am with "$(srcdir)" has stopped working too.
So I'm giving in to necessity, and changing policy by moving the
configure machinery up to the top level of the source tree where
autotools will be less confused by it. This should not be taken as any
indication of the primacy of the Unix port, only of the recalcitrance
of autotools.
Whereas before we had a trivial script called 'configure' at the top
level that invoked unix/configure to effectively do an 'out-of-tree
build' (for make purposes) at the top level of the source tree, we now
have a similar script in unix/configure. So this _should_ make very
little difference: people who were previously running configure from
the top level should still be able to, and likewise people who were
running it from the unix subdir.
[originally from svn r10141]
