simon-git: putty (master): Simon Tatham

Fri Jun 1 19:39:30 BST 2018

TL;DR:
  8615892 Buildscr: separate 'make all' from 'make cleantestprogs'.
  cbf4b10 Buildscr: add one more make -j flag.
  23698d6 Installer: condition out use of WiX DLL components.
  ec850f4 Build MSI installers for Arm Windows.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2018-06-01 19:39:30

commit 8615892fb76fc99bed2e5437bed14d7d5a7b2322
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=8615892fb76fc99bed2e5437bed14d7d5a7b2322;hp=108e19e73cf7dad9bfd8732784ced04d97f827d9
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Jun 1 19:35:15 2018 +0100

    Buildscr: separate 'make all' from 'make cleantestprogs'.

    When our Windows make commands were serial, 'make all cleantestprogs'
    was a nice shorthand for 'first build all the binaries, then delete
    the ones we don't want to ship'. Now they're using -j, that doesn't
    work so well - last night's snapshot build log shows that the command
    'rm -f testbn.exe' from the cleantestprogs target happened _before_
    the lld-link command that created testbn.exe in the first place, so
    that file got shipped into the download directory by mistake.

    Easily fixed, of course - just run two separate make commands per
    build directory.

 Buildscr | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

commit cbf4b10ebd1b90a910eca7f1448cfa8748925891
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=cbf4b10ebd1b90a910eca7f1448cfa8748925891;hp=8615892fb76fc99bed2e5437bed14d7d5a7b2322
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Jun 1 06:54:13 2018 +0100

    Buildscr: add one more make -j flag.

    Somehow yesterday I managed to miss the one in the icons build
    command. It's not the most critical one to speed up, but every little
    helps.

 Buildscr | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 23698d616419a9b42c5d15c578f50ffb38ea0b9c
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=23698d616419a9b42c5d15c578f50ffb38ea0b9c;hp=cbf4b10ebd1b90a910eca7f1448cfa8748925891
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 31 19:23:59 2018 +0100

    Installer: condition out use of WiX DLL components.

    This arranges that we can build a completely pure MSI file, which
    doesn't depend on any native code at install time. We don't lose much
    by doing this - only the option to pop up the README file at the end
    of installation, and validation of the install directory when you
    select it from a file browser.

    My immediate use for this is that I want to use it for installers that
    will run on Windows on Arm. But it also seems to me like quite an
    attractive property in its own right - no native code at all running
    at install time would be an _especially_ good guarantee that that code
    can't be hijacked by DLLs in the download directory. So I may yet
    decide that the features we're losing are not critical to _any_
    version of the MSI, and throw them out unconditionally.

 Buildscr              |  4 ++--
 windows/installer.wxs | 10 ++++++++++
 2 files changed, 12 insertions(+), 2 deletions(-)

commit ec850f4d98ea4ce33bfba9ebd790376aaaaf7a71
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=ec850f4d98ea4ce33bfba9ebd790376aaaaf7a71;hp=23698d616419a9b42c5d15c578f50ffb38ea0b9c
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 31 19:31:20 2018 +0100

    Build MSI installers for Arm Windows.

    I expected this to be nightmarish because WiX 3 doesn't know about the
    Windows on Arm platform at all. Fortunately, it turns out that it
    doesn't have to: testing on a borrowed machine I find that Windows on
    Arm's msiexec.exe is quite happy to take MSIs whose platform field in
    the _SummaryInformation table says "Intel".

    In fact, that seemed to be _all_ that my test machine would accept: I
    tried taking the MSI apart with msidump, putting some other value in
    there (e.g. "Arm64" or "Arm") and rebuilding it with msibuild, and all
    I got was messages from msiexec saying "This installation package is
    not supported by this processor type."

    So in fact I just give WiX the same -arch x86 option that I give it
    for the real 32-bit x86 Windows installer, but then I point it at the
    Arm binaries, and that seems to produce a viable MSI. There is the
    unfortunate effect that msiexec forcibly sets the default install
    location to 'Program Files (x86)' no matter how I strive to make it
    set it any other way, but that's only cosmetic: the programs _run_
    just fine no matter which Program Files directory they're installed
    into (and I know this won't be the first piece of software that
    installs itself into the wrong one). Perhaps some day we can find a
    way to do that part better.

    On general principles of caution (and of not really wanting to force
    Arm machines to emulate x86 code at all), the Arm versions of the
    installers have the new DllOk=no flag, so they're pure MSI with no
    embedded DLLs.

 Buildscr              | 12 ++++++++---
 windows/installer.wxs | 60 ++++++++++++++++++++++++++++++++++++++++++++-------
 2 files changed, 61 insertions(+), 11 deletions(-)