Permalink
Browse files

Merged Changes From PuTTY 0.70

- Merged upstream changes from PuTTY 0.70
- Added proper Visual Studio version detection for the About box
- Built binaries for PuTTY CAC 0.70
  • Loading branch information...
NoMoreFood committed Jul 8, 2017
1 parent 64e740e commit 37bbd0d6d309ac7bf353126c4e0b981c152e1069
Showing with 994 additions and 764 deletions.
  1. +33 −47 Buildscr
  2. +64 −42 CHECKLST.txt
  3. +1 −1 LATEST.VER
  4. +3 −3 README
  5. BIN binaries/puttycac-0.69u1-installer.msi
  6. BIN binaries/puttycac-0.70-installer.msi
  7. BIN binaries/puttycac-64bit-0.69u1-installer.msi
  8. BIN binaries/puttycac-64bit-0.70-installer.msi
  9. +54 −54 binaries/puttycac-hash.txt
  10. BIN binaries/x64/pageant.exe
  11. BIN binaries/x64/plink.exe
  12. BIN binaries/x64/pscp.exe
  13. BIN binaries/x64/psftp.exe
  14. BIN binaries/x64/putty.exe
  15. BIN binaries/x64/puttygen.exe
  16. BIN binaries/x64/puttytel.exe
  17. BIN binaries/x64/testbn.exe
  18. BIN binaries/x86/pageant.exe
  19. BIN binaries/x86/plink.exe
  20. BIN binaries/x86/pscp.exe
  21. BIN binaries/x86/psftp.exe
  22. BIN binaries/x86/putty.exe
  23. BIN binaries/x86/puttygen.exe
  24. BIN binaries/x86/puttytel.exe
  25. BIN binaries/x86/testbn.exe
  26. +2 −2 charset/utf8.c
  27. +1 −1 config.c
  28. +1 −1 configure.ac
  29. +1 −1 contrib/cygtermd/README
  30. +4 −6 doc/Makefile
  31. +7 −1 doc/blurb.but
  32. +0 −22 doc/chm.but
  33. +16 −15 doc/config.but
  34. +9 −9 doc/errors.but
  35. +9 −87 doc/faq.but
  36. +9 −9 doc/feedback.but
  37. +1 −3 doc/index.but
  38. +1 −1 doc/man-pl.but
  39. +1 −1 doc/man-pscp.but
  40. +1 −1 doc/man-psft.but
  41. +1 −1 doc/man-ptel.but
  42. +1 −1 doc/man-putt.but
  43. +10 −10 doc/pgpkeys.but
  44. +1 −1 doc/plink.but
  45. +1 −1 doc/pscp.but
  46. +1 −1 doc/udp.but
  47. +2 −1 import.c
  48. +1 −1 minibidi.c
  49. +31 −7 misc.c
  50. +28 −2 mkfiles.pl
  51. +2 −2 network.h
  52. +2 −2 packager/build.cmd
  53. +8 −10 pageant.c
  54. +11 −15 portfwd.c
  55. +21 −20 proxy.c
  56. +1 −1 pscp.c
  57. +8 −6 psftp.c
  58. +3 −5 raw.c
  59. +5 −2 release.pl
  60. +3 −5 rlogin.c
  61. +33 −10 sign.sh
  62. +48 −28 ssh.c
  63. +1 −1 sshpubk.c
  64. +11 −14 sshshare.c
  65. +3 −5 telnet.c
  66. +1 −1 terminal.c
  67. +1 −1 tree234.c
  68. +6 −6 unix/gtkwin.c
  69. +4 −1 unix/osxlaunch.c
  70. +2 −2 unix/unix.h
  71. +3 −4 unix/uxagentc.c
  72. +11 −13 unix/uxnet.c
  73. +3 −4 unix/uxpgnt.c
  74. +3 −5 unix/uxplink.c
  75. +6 −9 unix/uxproxy.c
  76. +4 −9 unix/uxpty.c
  77. +2 −4 unix/uxsel.c
  78. +5 −7 unix/uxser.c
  79. +4 −4 version.h
  80. +305 −68 wcwidth.c
  81. +45 −45 windows/README-msi.txt
  82. +39 −39 windows/README.txt
  83. +2 −2 windows/installer.wxs
  84. +5 −5 windows/putty.iss
  85. BIN windows/website.url
  86. +5 −5 windows/win_res.rc2
  87. +8 −1 windows/wincapi.c
  88. +1 −1 windows/windlg.c
  89. +3 −2 windows/window.c
  90. +12 −9 windows/winhsock.c
  91. +5 −3 windows/winmisc.c
  92. +25 −21 windows/winnet.c
  93. +1 −1 windows/winpgen.c
  94. +1 −1 windows/winpgnt.c
  95. +4 −7 windows/winplink.c
  96. +13 −8 windows/winprint.c
  97. +0 −2 windows/winsftp.c
  98. +4 −3 windows/winstuff.h
  99. +6 −12 x11fwd.c
View
@@ -35,7 +35,7 @@ module putty
ifeq "$(RELEASE)" "" set Ndate $(!builddate)
ifneq "$(Ndate)" "" in . do echo $(Ndate) | perl -pe 's/(....)(..)(..)/$$1-$$2-$$3/' > date
ifneq "$(Ndate)" "" read Date date
set Epoch 16280 # update this at every release
set Epoch 16351 # update this at every release
ifneq "$(Ndate)" "" in . do echo $(Ndate) | perl -ne 'use Time::Local; /(....)(..)(..)/ and print timegm(0,0,0,$$3,$$2-1,$$1) / 86400 - $(Epoch)' > days
ifneq "$(Ndate)" "" read Days days
@@ -139,8 +139,7 @@ ifneq "$(MAKEARGS)" "" set Makeargs $(Makeargs) $(MAKEARGS)
in putty do ./mksrcarc.sh
in putty do ./mkunxarc.sh '$(Autoconfver)' '$(Uxarcsuffix)' $(Docmakever)
in putty do perl mkfiles.pl
in putty/doc do make $(Docmakever) putty.hlp
in putty/doc do make $(Docmakever) chm
in putty/doc do make $(Docmakever) putty.hlp putty.chm
# Munge the installer script locally so that it reports the version
# we're really building.
@@ -157,50 +156,38 @@ in putty/icons do make
in putty do convert -size 164x312 'gradient:blue-white' -distort SRT -90 -swirl 180 \( -size 329x312 canvas:white \) +append \( icons/putty-48.png -geometry +28+24 \) -composite \( icons/pscp-48.png -geometry +88+96 \) -composite \( icons/puttygen-48.png -geometry +28+168 \) -composite \( icons/pageant-48.png -geometry +88+240 \) -composite windows/msidialog.bmp
in putty do convert -size 493x58 canvas:white \( icons/putty-48.png -geometry +440+5 \) -composite windows/msibanner.bmp
delegate windows
# Build the original binaries.
in putty/windows with visualstudio do/win mkdir buildold && nmake -f Makefile.vc BUILDDIR=buildold\ $(Makeargs) all cleantestprogs
# Build the VS2015 binaries. For the 32-bit ones, we set a subsystem
# version of 5.01, which allows the resulting files to still run on
# Windows XP.
in putty/windows with visualstudio2015_32bit do/win mkdir build32 && nmake -f Makefile.vc BUILDDIR=build32\ SUBSYSVER=,5.01 $(Makeargs) all cleantestprogs
in putty/windows with visualstudio2015_64bit do/win mkdir build64 && nmake -f Makefile.vc BUILDDIR=build64\ $(Makeargs) all cleantestprogs
# Code-sign the binaries, if the local bob config provides a script
# to do so. We assume here that the script accepts an -i option to
# provide a 'more info' URL, and an optional -n option to provide a
# program name, and that it can take multiple .exe filename
# arguments and sign them all in place.
ifneq "$(winsigncode)" "" in putty/windows do $(winsigncode) -i http://www.chiark.greenend.org.uk/~sgtatham/putty/ build*/*.exe
# Ignore exit code from hhc, in favour of seeing whether the .chm
# file was created. (Yuck; but hhc appears to return non-zero
# exit codes on whim.)
in putty/doc with htmlhelp do/win hhc putty.hhp & type putty.chm >nul
# Build a WiX MSI installer, for each of build32 and build64.
in putty/windows with wix do/win candle -arch x86 -dWin64=no -dBuilddir=build32\ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installer32.msi
in putty/windows with wix do/win candle -arch x64 -dWin64=yes -dBuilddir=build64\ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installer64.msi
# Build the old Inno Setup installer, for 32-bit only.
in putty/windows with innosetup do/win iscc putty.iss
# Sign the installers.
ifneq "$(winsigncode)" "" in putty/windows do $(winsigncode) -i http://www.chiark.greenend.org.uk/~sgtatham/putty/ -n "PuTTY Installer" installer32.msi installer64.msi Output/installer.exe
# Build the standard binaries, in both 32- and 64-bit flavours.
#
# For the 32-bit ones, we set a subsystem version of 5.01, which
# allows the resulting files to still run on Windows XP.
in putty/windows with clangcl32 do mkdir build32 && Platform=x86 make -f Makefile.clangcl BUILDDIR=build32/ SUBSYSVER=,5.01 $(Makeargs) all cleantestprogs
in putty/windows with clangcl64 do mkdir build64 && Platform=x64 make -f Makefile.clangcl BUILDDIR=build64/ $(Makeargs) all cleantestprogs
# Build the 'old' binaries, which should still run on all 32-bit
# versions of Windows back to Win95 (but not Win32s). These link
# against Visual Studio 2003 libraries (the more modern versions
# assume excessively modern Win32 API calls to be available), specify
# a subsystem version of 4.0, and compile with /arch:IA32 to prevent
# the use of modern CPU features like MMX which older machines also
# might not have.
in putty/windows with clangcl32_2003 do mkdir buildold && Platform=x86 make -f Makefile.clangcl BUILDDIR=buildold/ $(Makeargs) CCTARGET=i386-pc-windows-msvc13.0.0 SUBSYSVER=,4.0 EXTRA_windows=wincrt0.obj EXTRA_console=crt0.obj XFLAGS=/arch:IA32 all cleantestprogs
# Code-sign the Windows binaries, if the local bob config provides a
# script to do so in a cross-compiling way. We assume here that the
# script accepts an -i option to provide a 'more info' URL, an
# optional -n option to provide a program name, and an -N option to
# take the program name from an .exe's version resource, and that it
# can accept multiple .exe or .msi filename arguments and sign them
# all in place.
ifneq "$(cross_winsigncode)" "" in putty/windows do $(cross_winsigncode) -N -i https://www.chiark.greenend.org.uk/~sgtatham/putty/ build*/*.exe
# Build a WiX MSI installer, for each of build32 and build64.
in putty/windows with wixonlinux do candle -arch x86 -dWin64=no -dBuilddir=build32/ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installer32.msi -spdb
in putty/windows with wixonlinux do candle -arch x64 -dWin64=yes -dBuilddir=build64/ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installer64.msi -spdb
# Sign the Windows installers.
ifneq "$(cross_winsigncode)" "" in putty/windows do $(cross_winsigncode) -i https://www.chiark.greenend.org.uk/~sgtatham/putty/ -n "PuTTY Installer" installer32.msi installer64.msi
# Finished Windows builds.
return putty/windows/buildold/*.exe
return putty/windows/buildold/*.map
return putty/windows/build32/*.exe
return putty/windows/build32/*.map
return putty/windows/build64/*.exe
return putty/windows/build64/*.map
return putty/doc/putty.chm
return putty/windows/installer32.msi
return putty/windows/installer64.msi
return putty/windows/Output/installer.exe
enddelegate
in putty/doc do make mostlyclean
in putty/doc do make $(Docmakever)
in putty/windows/buildold do zip -k -j putty.zip `ls *.exe | grep -v puttytel` ../../doc/putty.chm ../../doc/putty.hlp ../../doc/putty.cnt
@@ -217,7 +204,6 @@ deliver putty/windows/build64/*.exe putty/w64/$@
deliver putty/windows/build64/putty.zip putty/w64/$@
deliver putty/windows/installer32.msi putty/w32/$(Ifilename32).msi
deliver putty/windows/installer64.msi putty/w64/$(Ifilename64).msi
deliver putty/windows/Output/installer.exe putty/w32/$(Ifilename32).exe
deliver putty/doc/puttydoc.zip putty/$@
deliver putty/doc/putty.chm putty/$@
deliver putty/doc/putty.hlp putty/$@
View
@@ -24,35 +24,38 @@ pre-releases on the website:
add a news announcement in components/news. (Previous naming
convention has been to name it in the form 'X.YZ-pre.mi'.)
Preparing to make a release
---------------------------
Things to do during the branch-stabilisation period:
Now that PuTTY is in git, a lot of the release preparation can be done
in advance, in local checkouts, and not pushed until the actual
process of _releasing_ it.
- Go through the source (including the documentation), and the
website, and review anything tagged with a comment containing the
word XXX-REVIEW-BEFORE-RELEASE. (Any such comments should state
clearly what needs to be done.)
To begin with, before dropping the tag, make sure everything is ready
for it:
- Do some testing of the Windows version with Minefield (you can
build a Minefield version using 'bob . XFLAGS=-DMINEFIELD'), and of
the Unix version with valgrind. In particular, any headline
features for the release should get a workout with memory checking
enabled!
- First of all, go through the source (including the documentation),
and the website, and review anything tagged with a comment
containing the word XXX-REVIEW-BEFORE-RELEASE.
(Any such comments should state clearly what needs to be done.)
Making a release candidate build
--------------------------------
- Also, do some testing of the Windows version with Minefield, and
of the Unix version with valgrind or efence or both. In
particular, any headline features for the release should get a
workout with memory checking enabled!
- Make a directory to hold all the release paraphernalia. I usually
call it ~/src/putty/X.YZ (where X.YZ will stand throughout for the
version number). In that directory, make a git clone of the PuTTY
repository, where you can make release-related commits and tags
tentatively, and keep them out of the way of any 'git push' you
might still be doing in other checkouts.
- Double-check that we have removed anything tagged with a comment
containing the words XXX-REMOVE-BEFORE-RELEASE or
XXX-REVIEW-BEFORE-RELEASE. ('git grep XXX-RE' should only show up
hits in this file itself.)
- Now update the version numbers and the transcripts in the docs, by
checking out the release branch and running
checking out the release branch in the release-specific checkout
and running
make distclean
./release.pl --version=X.YZ --setver
Then check that the resulting automated git commit has updated the
@@ -72,6 +75,42 @@ for it:
- If the release is on a branch (which I expect it generally will
be), merge that branch to master.
- Make a release-candidate build from the release tag, and put the
build.out and build.log dfiles somewhere safe. Normally I store
these in an adjacent directory, so I'll run a command like
bob -o ../X.YZ/build-X.YZ-rcN.out -l ../X.YZ/build-X.YZ-rcN.log -c X.YZ . RELEASE=X.YZ
This should generate a basically valid release directory as
`build-X.YZ-rcN.out/putty', and provide link maps and sign.sh
alongside that.
- Double-check in build-X.YZ-rcN.log that the release was built from
the right git commit.
- Make a preliminary gpg signature, but don't run the full release-
signing procedure. (We use the presence of a full set of GPG
signatures to distinguish _abandoned_ release candidates from the
one that ended up being the release.) In the 'build.X.YZ-rcN.out'
directory, run
sh sign.sh -r -p putty
and you should only have to enter the release key passphrase once,
which will generate a clearsigned file called
sha512sums-preliminary.gpg _outside_ the 'putty' subdirectory.
- For my own safety, make the release candidate build read-only.
chmod -R a-w build-X.YZ-rcN.out build-X.YZ-rcN.log
- Now do some checking of the release binaries, and pass them to the
rest of the team to do some as well. Do at least these things:
* make sure they basically work
* check they report the right version number
* if there's any easily observable behaviour difference between
the release branch and master, arrange to observe it
* test the Windows installer
* test the Unix source tarball.
Preparing to make the release
-----------------------------
- Write a release announcement (basically a summary of the changes
since the last release). Squirrel it away in
thyestes:src/putty-local/announce-<ver> in case it's needed again
@@ -96,33 +135,16 @@ for it:
branch (so that the wishlist mechanism can't automatically mark
them as fixed in the new release), add appropriate Fixed-in
headers for those.
* Add an entry to the @releases array in control/bugs2html.
- Make a release-candidate build from the release tag, and put the
build.out and build.log dfiles somewhere safe. Normally I store
these in an adjacent directory, so I'll run a command like
bob -o ../X.YZ/build-X.YZ-rcN.out -l ../X.YZ/build-X.YZ-rcN.log -c X.YZ . RELEASE=X.YZ
This should generate a basically valid release directory as
`build-X.YZ-rcN.out/putty', and provide link maps and sign.sh
alongside that.
- Double-check in build-X.YZ-rcN.log that the release was built from
the right git commit.
- Do a bit of checking of the release binaries:
* make sure they basically work
* check they report the right version number
* if there's any easily observable behaviour difference between
the release branch and master, arrange to observe it
* test the Windows installer
* test the Unix source tarball.
- Sign the release: in the `build-X.YZ-rcN.out' directory, type
- Sign the release in full. In the `build-X.YZ-rcN.out' directory,
re-verify that the preliminary signed checksums file has a correct
signature on it and also matches the files you're about to sign for real:
gpg -d sha512sums-preliminary.gpg | (cd putty; sha512sum -c)
If the combined output of that pipeline reports both a good
signature (from the release key) and a successful verification of
all the sha512sums, then all is well, so now run
sh sign.sh -r putty
and enter the passphrases a lot of times.
- For my own safety, make the release candidate build read-only.
chmod -R a-w build-X.YZ-rcN.out build-X.YZ-rcN.log
and enter the release key passphrase a lot of times.
The actual release procedure
----------------------------
View
@@ -1 +1 @@
0.69
0.70
View
6 README
@@ -1,4 +1,4 @@
This is the README for the source archive of PuTTY, a free Win32
This is the README for the source archive of PuTTY, a free Windows
and Unix Telnet and SSH client.
If you want to rebuild PuTTY from source, we provide a variety of
@@ -127,11 +127,11 @@ 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/>.
found at <https://www.chiark.greenend.org.uk/~sgtatham/halibut/>.
The PuTTY home web site is
http://www.chiark.greenend.org.uk/~sgtatham/putty/
https://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
View
Binary file not shown.
View
Binary file not shown.
Binary file not shown.
Binary file not shown.
Oops, something went wrong.

0 comments on commit 37bbd0d

Please sign in to comment.