зеркало из https://github.com/github/putty.git
eac66b0281
This lays further groundwork for the OS X GTK3 port, which is going to have to deal with multiple sessions sharing the same process. gtkwin.c was a bit too monolithic for this, since it included some process-global runtime state (timers, toplevel callbacks), some process startup stuff (gtk_init, gtk_main, argv processing) and some per-session-window stuff. The per-session stuff remains in gtkwin.c, with the top-level function now being new_session_window() taking a Conf. The new gtkmain.c contains the outer skeleton of pt_main(), handling argv processing and one-off startup stuff like setlocale; and the new gtkcomm.c contains the pieces of PuTTY infrastructure like timers and uxsel that are shared between multiple sessions rather than reinstantiated per session, which have been rewritten to use global variables rather than fields in 'inst' (since it's now clear to me that they'll have to apply to all the insts in existence at once). There are still some lurking assumptions of one-session-per-process, e.g. the use of gtk_main_quit when a session finishes, and the fact that the config box insists on running as a separate invocation of gtk_main so that one session's preliminary config box can't coexist with another session already active. But this should make it possible to at least write an OS X app good enough to start testing with, even if it doesn't get everything quite right yet. This change is almost entirely rearranging existing code, so it shouldn't be seriously destabilising. But two noticeable actual changes have happened, both pleasantly simplifying: Firstly, the global-variables rewrite of gtkcomm.c has allowed the post_main edifice to become a great deal simpler. Most of its complexity was about remembering what 'inst' it had to call back to, and in fact the right answer is that it shouldn't be calling back to one at all. So now the post_main() called by gtkdlg.c has become the same function as the old inst_post_main() that actually did the work, instead of the two having to be connected by a piece of ugly plumbing. Secondly, a piece of code that's vanished completely in this refactoring is the temporary blocking of SIGCHLD around most of the session setup code. This turns out to have been introduced in 2002, _before_ I switched to using the intra-process signal pipe strategy for SIGCHLD handling in 2003. So I now expect that we should be robust in any case against receiving SIGCHLD at an inconvenient moment, and hence there's no need to block it. |
||
|---|---|---|
| charset | ||
| contrib | ||
| doc | ||
| icons | ||
| macosx | ||
| testdata | ||
| unix | ||
| windows | ||
| .gitignore | ||
| Buildscr | ||
| Buildscr.cv | ||
| CHECKLST.txt | ||
| LATEST.VER | ||
| LICENCE | ||
| README | ||
| Recipe | ||
| be_all.c | ||
| be_all_s.c | ||
| be_misc.c | ||
| be_none.c | ||
| be_nos_s.c | ||
| be_nossh.c | ||
| be_ssh.c | ||
| callback.c | ||
| cmdgen.c | ||
| cmdline.c | ||
| conf.c | ||
| config.c | ||
| configure.ac | ||
| cproxy.c | ||
| dialog.c | ||
| dialog.h | ||
| errsock.c | ||
| fuzzterm.c | ||
| import.c | ||
| int64.c | ||
| int64.h | ||
| ldisc.c | ||
| ldisc.h | ||
| ldiscucs.c | ||
| licence.pl | ||
| logging.c | ||
| minibidi.c | ||
| misc.c | ||
| misc.h | ||
| miscucs.c | ||
| mkauto.sh | ||
| mkfiles.pl | ||
| mksrcarc.sh | ||
| mkunxarc.sh | ||
| network.h | ||
| nocproxy.c | ||
| nogss.c | ||
| noprint.c | ||
| noshare.c | ||
| noterm.c | ||
| notiming.c | ||
| pageant.c | ||
| pageant.h | ||
| pgssapi.c | ||
| pgssapi.h | ||
| pinger.c | ||
| portfwd.c | ||
| pproxy.c | ||
| proxy.c | ||
| proxy.h | ||
| pscp.c | ||
| psftp.c | ||
| psftp.h | ||
| putty.h | ||
| puttymem.h | ||
| puttyps.h | ||
| raw.c | ||
| release.pl | ||
| resource.h | ||
| rlogin.c | ||
| sercfg.c | ||
| settings.c | ||
| sftp.c | ||
| sftp.h | ||
| sign.sh | ||
| ssh.c | ||
| ssh.h | ||
| sshaes.c | ||
| ssharcf.c | ||
| sshbcrypt.c | ||
| sshblowf.c | ||
| sshblowf.h | ||
| sshbn.c | ||
| sshbn.h | ||
| sshccp.c | ||
| sshcrc.c | ||
| sshcrcda.c | ||
| sshdes.c | ||
| sshdh.c | ||
| sshdss.c | ||
| sshdssg.c | ||
| sshecc.c | ||
| sshecdsag.c | ||
| sshgss.h | ||
| sshgssc.c | ||
| sshgssc.h | ||
| sshmd5.c | ||
| sshnogss.c | ||
| sshprime.c | ||
| sshpubk.c | ||
| sshrand.c | ||
| sshrsa.c | ||
| sshrsag.c | ||
| sshsh256.c | ||
| sshsh512.c | ||
| sshsha.c | ||
| sshshare.c | ||
| sshzlib.c | ||
| storage.h | ||
| telnet.c | ||
| terminal.c | ||
| terminal.h | ||
| testback.c | ||
| testbn.c | ||
| time.c | ||
| timing.c | ||
| tree234.c | ||
| tree234.h | ||
| version.c | ||
| version.h | ||
| wcwidth.c | ||
| wildcard.c | ||
| x11fwd.c | ||
README
This is the README for the source archive of PuTTY, a free Win32
and Unix Telnet and SSH client.
If you want to rebuild PuTTY from source, we provide a variety of
Makefiles and equivalents. (If you have fetched the source from
Git, you'll have to generate the Makefiles yourself -- see
below.)
There are various compile-time directives that you can use to
disable or modify certain features; it may be necessary to do this
in some environments. They are documented in `Recipe', and in
comments in many of the generated Makefiles.
For building on Windows:
- windows/Makefile.vc is for command-line builds on MS Visual C++
systems. Change into the `windows' subdirectory and type `nmake
-f Makefile.vc' to build all the PuTTY binaries.
Last time we checked, PuTTY built with vanilla VC7, or VC6 with
an up-to-date Platform SDK. (It might still be possible to build
with vanilla VC6, but you'll certainly have to remove some
functionality with directives such as NO_IPV6.)
(We've also had reports of success building with the
OpenWatcom compiler -- www.openwatcom.org -- using Makefile.vc
with `wmake -ms -f makefile.vc' and NO_MULTIMON, although we
haven't tried this ourselves. Version 1.3 is reported to work.)
- Inside the windows/MSVC subdirectory are MS Visual Studio project
files for doing GUI-based builds of the various PuTTY utilities.
These have been tested on Visual Studio 6.
You should be able to build each PuTTY utility by loading the
corresponding .dsp file in Visual Studio. For example,
MSVC/putty/putty.dsp builds PuTTY itself, MSVC/plink/plink.dsp
builds Plink, and so on.
- windows/Makefile.bor is for the Borland C compiler. Type `make -f
Makefile.bor' while in the `windows' subdirectory to build all
the PuTTY binaries.
- windows/Makefile.cyg is for Cygwin / MinGW installations. Type
`make -f Makefile.cyg' while in the `windows' subdirectory to
build all the PuTTY binaries.
You'll probably need quite a recent version of the w32api package.
Note that by default the multiple monitor and HTML Help support are
excluded from the Cygwin build, since at the time of writing Cygwin
doesn't include the necessary headers.
- windows/Makefile.lcc is for lcc-win32. Type `make -f
Makefile.lcc' while in the `windows' subdirectory. (You will
probably need to specify COMPAT=-DNO_MULTIMON.)
- Inside the windows/DEVCPP subdirectory are Dev-C++ project
files for doing GUI-based builds of the various PuTTY utilities.
The PuTTY team actively use Makefile.vc (with VC7) and Makefile.cyg
(with mingw32), so we'll probably notice problems with those
toolchains fairly quickly. Please report any problems with the other
toolchains mentioned above.
For building on Unix:
- unix/configure is for Unix and GTK. If you don't have GTK, you
should still be able to build the command-line utilities (PSCP,
PSFTP, Plink, PuTTYgen) using this script. To use it, change into
the `unix' subdirectory, run `./configure' and then `make'. Or you
can do the same in the top-level directory (we provide a little
wrapper that invokes configure one level down), which is more like
a normal Unix source archive but doesn't do so well at keeping the
per-platform stuff in each platform's subdirectory; it's up to you.
Note that Unix PuTTY has mostly only been tested on Linux so far;
portability problems such as BSD-style ptys or different header file
requirements are expected.
- unix/Makefile.gtk and unix/Makefile.ux are for non-autoconfigured
builds. These makefiles expect you to change into the `unix'
subdirectory, then run `make -f Makefile.gtk' or `make -f
Makefile.ux' respectively. Makefile.gtk builds all the programs but
relies on Gtk, whereas Makefile.ux builds only the command-line
utilities and has no Gtk dependence.
- For the graphical utilities, any of Gtk+-1.2, Gtk+-2.0, and Gtk+-3.0
should be supported. If you have more than one installed, you can
manually specify which one you want by giving the option
'--with-gtk=N' to the configure script where N is 1, 2, or 3.
(The default is the newest available, of course.) In the absence
of any Gtk version, the configure script will automatically
construct a Makefile which builds only the command-line utilities;
you can manually create this condition by giving configure the
option '--without-gtk'.
- pterm would like to be setuid or setgid, as appropriate, to permit
it to write records of user logins to /var/run/utmp and
/var/log/wtmp. (Of course it will not use this privilege for
anything else, and in particular it will drop all privileges before
starting up complex subsystems like GTK.) By default the makefile
will not attempt to add privileges to the pterm executable at 'make
install' time, but you can ask it to do so by running configure
with the option '--enable-setuid=USER' or '--enable-setgid=GROUP'.
- The Unix Makefiles have an `install' target. Note that by default
it tries to install `man' pages; if you have fetched the source via
Git then you will need to have built these using Halibut
first - see below.
- It's also possible to build the Windows version of PuTTY to run
on Unix by using Winelib. To do this, change to the `windows'
directory and run `make -f Makefile.cyg CC=winegcc RC=wrc'.
All of the Makefiles are generated automatically from the file
`Recipe' by the Perl script `mkfiles.pl' (except for the Unix one,
which is generated by the `configure' script; mkfiles.pl only
generates the input to automake). Additions and corrections to Recipe,
mkfiles.pl and/or configure.ac are much more useful than additions and
corrections to the actual Makefiles, Makefile.am or Makefile.in.
The Unix `configure' script and its various requirements are generated
by the shell script `mkauto.sh', which requires GNU Autoconf, GNU
Automake, and Gtk; if you've got the source from Git rather
than using one of our source snapshots, you'll need to run this
yourself. The input file to Automake is generated by mkfiles.pl along
with all the rest of the makefiles, so you will need to run mkfiles.pl
and then mkauto.sh.
Documentation (in various formats including Windows Help and Unix
`man' pages) is built from the Halibut (`.but') files in the `doc'
subdirectory using `doc/Makefile'. If you aren't using one of our
source snapshots, you'll need to do this yourself. Halibut can be
found at <http://www.chiark.greenend.org.uk/~sgtatham/halibut/>.
The PuTTY home web site is
http://www.chiark.greenend.org.uk/~sgtatham/putty/
If you want to send bug reports or feature requests, please read the
Feedback section of the web site before doing so. Sending one-line
reports saying `it doesn't work' will waste your time as much as
ours.
See the file LICENCE for the licence conditions.