simon-git: putty (master): putty.git
Commits to Tartarus hosted VCS
tartarus-commits at lists.tartarus.org
Sat Jan 21 15:00:28 GMT 2017
TL;DR:
7ccc105 Do the Windows build in a subdirectory windows/build32.
504c00e Rename the 'x86' build output directory to 'w32'.
4b17025 Switch the main Windows build to Visual Studio 2015.
d9b05f8 Build 64-bit Windows binaries, alongside the 32-bit ones.
e6059f1 Build a set of Windows 32-bit 'legacy' binaries with VS2003.
faae648 Build an MSI installer for the new Win64 binaries.
5985bb7 Name the 64-bit MSI distinctively.
786d752 Comment that Inno Setup installer remains 32-bit only.
d039996 Remove 'putty -cleanup-during-uninstall' from legacy uninstaller.
27e58f8 Reinstate the ASLR and DEP linker flags on Windows.
23a9d56 Fix PE header of the VS2015 builds so they run on Windows XP.
960ad59 Add a 'strbuf' system, for building up a large string piece by piece.
7e14730 Include 'build info' in all --version text and About boxes.
5687a16 Make bob builds show the full source git commit hash in buildinfo.
be586d5 Show the git commit hash in local dev builds too.
19aefec Conditionalise the automake git-commit embedding.
Repository: https://git.tartarus.org/simon/putty.git
On the web: https://git.tartarus.org/?p=simon/putty.git
Branch updated: master
Committer: putty.git
Date: 2017-01-21 15:00:28
commit 7ccc105c81094011110297ef8dfeba9ba08ad023
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=7ccc105c81094011110297ef8dfeba9ba08ad023;hp=a76de8774bfcbbd54b6a0fa8d7815c6c0b20dfac
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:47 2017 +0000
Do the Windows build in a subdirectory windows/build32.
Uses the BUILDDIR mechanism I added to Makefile.vc in commit
d3db17f3e.
This change is purely internal to Buildscr, and shouldn't affect the
output of a build. It paves the way to have Buildscr run multiple
Windows builds using different compilers, by putting each one in a
different subdirectory so that their outputs don't collide.
Buildscr | 18 +++++++++---------
windows/installer.wxs | 12 ++++++------
windows/putty.iss | 12 ++++++------
3 files changed, 21 insertions(+), 21 deletions(-)
commit 504c00e4ad072873c0a27c05105aa35c4a452821
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=504c00e4ad072873c0a27c05105aa35c4a452821;hp=7ccc105c81094011110297ef8dfeba9ba08ad023
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:48 2017 +0000
Rename the 'x86' build output directory to 'w32'.
This change does affect the layout of the output build directory, and
will need corresponding website changes to avoid breaking links.
'x86' was a misnomer anyway, because it was really Windows-specific
rather than just x86-specific. Calling it 'w32' will make it look less
strange to add 'w64' alongside it.
Buildscr | 14 +++++++-------
sign.sh | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
commit 4b17025035f0a9e38959ca536eb4a9805902b269
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=4b17025035f0a9e38959ca536eb4a9805902b269;hp=504c00e4ad072873c0a27c05105aa35c4a452821
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:48 2017 +0000
Switch the main Windows build to Visual Studio 2015.
This is a big jump from the previous VS2003. It should add a little
performance (VS2015 is a better-optimising compiler), but mostly it's
groundwork for doing other useful things such as 64-bit builds and
security-related linker features.
The downside is reduced support for very old versions of Windows,
which I'll address shortly.
Buildscr | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
commit d9b05f8861ddb139f0345aafc02d9aaba59465f8
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=d9b05f8861ddb139f0345aafc02d9aaba59465f8;hp=4b17025035f0a9e38959ca536eb4a9805902b269
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:52 2017 +0000
Build 64-bit Windows binaries, alongside the 32-bit ones.
Now we've got VS2015 available (and thanks to a lot of 64-bit
cleanness fixing, in particular Tim Kosse's large patch series from
August 2015) we can do this fairly easily.
The new binaries are shipped in a 'w64' directory, alongside the
just-renamed 'w32'. There is no 64-bit installer (yet).
Buildscr | 7 +++++++
sign.sh | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
commit e6059f18d49410beaab5aa0679a7467ce021fdc1
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=e6059f18d49410beaab5aa0679a7467ce021fdc1;hp=d9b05f8861ddb139f0345aafc02d9aaba59465f8
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:52 2017 +0000
Build a set of Windows 32-bit 'legacy' binaries with VS2003.
The downside of moving to VS2015 is that its output won't run on very
old versions of Windows. It's not yet clear whether anyone still cares
about things before, say, Win2000 or WinXP, but since my build
environment still _has_ VS2003 available, it's easy enough to build
the extra set of binaries anyway just in case. (At least for now.)
The new binaries live in a build output directory 'w32old'. As with
w64, there is no installer for them; but unlike w64, I don't intend to
add one.
Buildscr | 11 ++++++++++-
sign.sh | 2 +-
2 files changed, 11 insertions(+), 2 deletions(-)
commit faae648475c84f64f2c1eaa49b863f6ff92fd5d5
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=faae648475c84f64f2c1eaa49b863f6ff92fd5d5;hp=e6059f18d49410beaab5aa0679a7467ce021fdc1
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:52 2017 +0000
Build an MSI installer for the new Win64 binaries.
The MSI format has a fixed field for target architecture, so there's
no way to build a single MSI that can decide at install time whether
to install 32-bit or 64-bit (or both). The best you can do along those
lines, apparently, is to have two MSI files plus a bootstrap .EXE that
decides which of them to run, and as far as I'm concerned that would
just reintroduce all the same risks and annoyances that made us want
to migrate away from .EXE installers anyway.
Buildscr | 17 ++++++----
sign.sh | 2 +-
windows/installer.wxs | 90 +++++++++++++++++++++++++++++++++++++--------------
3 files changed, 77 insertions(+), 32 deletions(-)
commit 5985bb7ea0afd73407bc894fd32633a4f0cadad4
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=5985bb7ea0afd73407bc894fd32633a4f0cadad4;hp=faae648475c84f64f2c1eaa49b863f6ff92fd5d5
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:52 2017 +0000
Name the 64-bit MSI distinctively.
The 32- and 64-bit installers may be distinguishable by their pathname
in the build output directory, but it's better to have their actual
filenames be different as well, so they don't collide in people's
download directories.
Buildscr | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
commit 786d7527576057795fc3a69d41108e7d44776813
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=786d7527576057795fc3a69d41108e7d44776813;hp=5985bb7ea0afd73407bc894fd32633a4f0cadad4
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:53 2017 +0000
Comment that Inno Setup installer remains 32-bit only.
Our Inno Setup installer is legacy as far as I'm concerned, so there's
no point in introducing a 64-bit version of it. 64-bit PuTTY users can
use the MSI from the start, and then there'll only ever have been one
kind of installer and they won't collide with one another.
Buildscr | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
commit d03999661619df7e15e962d889128d15c6733d88
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=d03999661619df7e15e962d889128d15c6733d88;hp=786d7527576057795fc3a69d41108e7d44776813
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:53 2017 +0000
Remove 'putty -cleanup-during-uninstall' from legacy uninstaller.
It's a bit conceptually incoherent anyway - if you're uninstalling
PuTTY _systemwide_ across a multi-user system, it doesn't really make
sense that you'd also want to wipe the saved sessions for the
individual user running the uninstaller.
Also, making this change to the Inno Setup uninstaller opens up a
nicer migration path to MSI for people doing large corporate rollouts:
they can upgrade to this version of the Inno Setup package, then do a
silent uninstall of it (which should now _actually_ be silent, since
this cleanup step was the thing that interrupted it otherwise) and
then a silent install of the MSI.
windows/putty.iss | 7 -------
1 file changed, 7 deletions(-)
commit 27e58f826f95056d6abc5820266bcdb9fdc7632c
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=27e58f826f95056d6abc5820266bcdb9fdc7632c;hp=d03999661619df7e15e962d889128d15c6733d88
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:53 2017 +0000
Reinstate the ASLR and DEP linker flags on Windows.
Originally added in commit 0014ffb70, and promptly reverted in
6bea4b250 when we realised that VS2003 didn't actually understand
them. But now we're building with VS2015, which does understand them,
it's actually useful to put them back in again.
Looking more closely, it turns out that VS2003 didn't actually _fail
to build_ if you passed these flags on the linker command line - it
just printed a warning and ignored them. (So there was no actual need
to revert the original change, except that it would have caused
confusion.) But that means I can add them unconditionally now, without
breaking even the legacy VS2003 build.
mkfiles.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
commit 23a9d5608c2c1bad56b14d6ec66b08f4c0401b5d
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=23a9d5608c2c1bad56b14d6ec66b08f4c0401b5d;hp=27e58f826f95056d6abc5820266bcdb9fdc7632c
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:53 2017 +0000
Fix PE header of the VS2015 builds so they run on Windows XP.
By default the VS2015 linker produces binaries with the minimum
version fields in the PE header set to 06.00, which causes XP not to
recognise them as valid binaries at all. But there's no other reason
VS2015-built binaries _can't_ run on versions of Windows as old as XP;
so here I add the link option to set those fields to 05.01 which makes
XP like them again.
This only applies to the 32-bit build, because the VS2015 64-bit
linker refuses to lower the min version field to under 06.00.
Buildscr | 6 ++++--
mkfiles.pl | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
commit 960ad594a313a91314a3984fc142bdfd11d136f5
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=960ad594a313a91314a3984fc142bdfd11d136f5;hp=23a9d5608c2c1bad56b14d6ec66b08f4c0401b5d
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:53 2017 +0000
Add a 'strbuf' system, for building up a large string piece by piece.
I'm faintly surprised I haven't needed this before. Basically it's an
allocating string formatter, like dupprintf, except that it
concatenates on to the end of a previous string. You instantiate a
strbuf, then repeatedly call strbuf_catf to append pieces of formatted
output to it, and then you can extract the whole string and free it
(separately or both in one step).
misc.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
misc.h | 7 ++++++
2 files changed, 72 insertions(+), 16 deletions(-)
commit 7e14730b83d2504a454ad5dfbfb4b4f8700f4dc5
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=7e14730b83d2504a454ad5dfbfb4b4f8700f4dc5;hp=960ad594a313a91314a3984fc142bdfd11d136f5
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:53 2017 +0000
Include 'build info' in all --version text and About boxes.
This shows the build platform (32- vs 64-bit in particular, and also
whether Unix GTK builds were compiled with or without the X11 pieces),
what compiler was used to build the binary, and any interesting build
options that might have been set on the make command line (especially,
but not limited to, the security-damaging ones like NO_SECURITY or
UNPROTECT). This will probably be useful all over the place, but in
particular it should allow the different Windows binaries to be told
apart!
Commits 21101c739 and 2eb952ca3 laid the groundwork for this, by
allowing the various About boxes to contain free text and also
ensuring they could be copied and pasted easily as part of a bug
report.
cmdgen.c | 4 +++-
misc.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++
misc.h | 2 ++
pscp.c | 4 +++-
psftp.c | 4 +++-
unix/gtkdlg.c | 5 +++--
unix/gtkmain.c | 5 ++++-
unix/unix.h | 11 ++++++++++
unix/uxpgnt.c | 4 +++-
unix/uxplink.c | 4 +++-
windows/pageant.rc | 8 +++----
windows/puttygen.rc | 8 +++----
windows/win_res.rc2 | 10 ++++-----
windows/windlg.c | 6 ++++--
windows/winpgen.c | 6 ++++--
windows/winpgnt.c | 6 ++++--
windows/winplink.c | 4 +++-
windows/winstuff.h | 2 ++
18 files changed, 127 insertions(+), 28 deletions(-)
commit 5687a16fc1b60345c76d4f5088edc41004a3529d
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=5687a16fc1b60345c76d4f5088edc41004a3529d;hp=7e14730b83d2504a454ad5dfbfb4b4f8700f4dc5
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:55:53 2017 +0000
Make bob builds show the full source git commit hash in buildinfo.
The Windows binaries, and both Windows and Unix source archives,
output from a bob build will now include the full SHA-1 of the source
git commit in their buildinfo (hence in all the About boxes and
command-line version output).
This will be occasionally useful to me at release time (there was that
one embarrassing incident where I managed not to notice that I'd made
a release build from entirely the wrong commit), but mostly, it just
seems like an obviously useful thing to put in a general buildinfo
section now that there is one.
Buildscr | 1 +
Recipe | 6 +++---
misc.c | 3 +++
version.c | 1 +
version.h | 1 +
5 files changed, 9 insertions(+), 3 deletions(-)
commit be586d53b0e503a00c72982667f8e8d11b1893fe
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=be586d53b0e503a00c72982667f8e8d11b1893fe;hp=5687a16fc1b60345c76d4f5088edc41004a3529d
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:57:31 2017 +0000
Show the git commit hash in local dev builds too.
This is perhaps the more useful end of the mechanism I added in the
previous commit: now, when a developer runs a configure+make build
from a git checkout (rather than from a bob-built source tarball), the
Makefile will automatically run 'git rev-parse HEAD' and embed the
result in the binaries.
So now when I want to deploy my own bleeding-edge code for day-to-day
use on my own machine, I can easily check whether I've done it right
(e.g. did I install to the right prefix?), and also easily check
whether any given PuTTY or pterm has been restarted since I rolled out
a new version.
In order to arrange this (and in particular to force version.o to be
rebuilt when _any_ source file changes), I've had to reintroduce some
of the slightly painful Makefile nastiness that I removed in 4d8782e74
when I retired the 'manifest' system, namely having version.o depend
on a file empty.h, which in turn is trivially rebuilt by a custom make
rule whose dependencies include $(allsources). That's a bit
unfortunate, but I think acceptable: the main horribleness of the
manifest system was not that part, but the actual _manifests_, which
were there to arrange that if you modified the sources in a
distribution tarball the binaries would automatically switch to
reporting themselves as local builds rather than the version baked
into the tarball. I haven't reintroduced that part of the system: if
you check out a given git commit, modify the checked-out sources, and
build the result, the Makefile won't make any inconvenient attempts to
detect that, and the resulting build will still announce itself as the
git commit you started from.
Recipe | 12 ++++++++++++
version.c | 4 ++++
version.h | 21 +++++++++++++++++++++
3 files changed, 37 insertions(+)
commit 19aefec3e8b33f12e6edbead1028c07b5f486ce0
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=19aefec3e8b33f12e6edbead1028c07b5f486ce0;hp=be586d53b0e503a00c72982667f8e8d11b1893fe
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Jan 21 14:57:31 2017 +0000
Conditionalise the automake git-commit embedding.
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).
Recipe | 6 ++++--
configure.ac | 12 ++++++++++++
2 files changed, 16 insertions(+), 2 deletions(-)
More information about the tartarus-commits
mailing list