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

Buildscr

@@ -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/$@

CHECKLST.txt

@@ -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
 ----------------------------

LATEST.VER

@@ -1 +1 @@
-0.69
+0.70

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